springframework-developer — Spring Framework developers list

RE: [Springframework-developer] BeanFactory partial pre-population with applicat

[Venkat S. <vso...@ho...>]

Hi Colin,

Yes, I should have spotted the no need for communicatorFactory. I had got my
ICE stuff working/running (both client and server side) just then and was
too excited about that and the generic solution you posted.

I looked at the code below more closely now and found you were already
registering ( factory.registerSingleton("communicator", communicator); )
communicator as the singleton as opposed to communicatorFactory. 

I will be stick to the simple solution as I don't think I will be needing
more than one refresh.

Thanks,
--Venkat.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Colin Sampaleanu
Sent: Thursday, November 04, 2004 7:10 PM
To: spr...@li...
Subject: Re: [Springframework-developer] BeanFactory partial pre-population
with applicat

Just for the record though, I was being incredibly dense below, as of 
course there is not even a need of the factory bean. The Communicator 
itself can just be registered as the singleton.

In my own defence, I started off with another approach that did need the 
factory bean. That approach was a bit more complex, but would allow a 
refresh too. It's to create a MutablePropertyValue wrapping the factory 
bean, and use it with a new RootBeanDefinition which is just registered 
manually. Then the xml context def can also be read in. I would stick to 
the simpler approach until you actually need more than one refresh though...

Venkat Sonnathi wrote:

> Hi Colin,
>
> Yes, this is what I was looking for. With the solution given below I 
> don't have to write custom FactoryBean's and ApplicationContext's for 
> each application object I want to expose.
>
> You guys rock!
>
> Thank you very much.
> --Venkat.
>
> From: Colin Sampaleanu <col...@ex...>
> Reply-To: spr...@li...
> To: spr...@li...
> Subject: Re: [Springframework-developer] BeanFactory partial 
> pre-population with applicat
> Date: Thu, 04 Nov 2004 13:38:15 -0500
>
> Venkat,
>
> If you are willing to rely on the new GenericApplicationContext class 
> which was introduced for Spring 1.1.2 (which is planned for release 
> this weekend, but the code is in CVS already), there is an even easier 
> mechanism.
>
> Make a simple PassthroughFactoryBean, which always returns an object 
> that it was fed as a constructor:
>    static class PassthroughFactoryBean implements FactoryBean {
>        private Object object;
>
>        public PassthroughFactoryBean(Object object) {
>            this.object = object;
>        }
>        public Object getObject() throws Exception {
>            return object;
>        }
>        public Class getObjectType() {
>            return object.getClass();
>        }
>        public boolean isSingleton() {
>            return true;
>        }
>    }
>
> now, just use GenericApplicationContext:
>
>        GenericApplicationContext ctx = new GenericApplicationContext();
>        ConfigurableListableBeanFactory factory = ctx.getBeanFactory();
>
>        PassthroughFactoryBean communicatorFactory = new 
> PassthroughFactoryBean(communicator);
>        factory.registerSingleton("communicator", communicator);
>              XmlBeanDefinitionReader xmlReader = new 
> XmlBeanDefinitionReader(ctx);
>        xmlReader.loadBeanDefinitions(new 
> ClassPathResource(contextFileLocation));
>              ctx.refresh();
>
> And after writing this, I just realized that even with a normal 
> ClasspathXmlApplicationContext, what you should be able to do is just 
> use the constructor with refresh=false to create the context but not 
> initialize it yet, then just add the singleton factory bean exactly as 
> above, then call refresh on it. Just be careful, as a subsequent 
> refresh will not have the manually added singleton bean! That's why 
> GenericApplicationContext doesn't even allow more than one refresh.
>
> Colin
>
>
> Venkat Sonnathi wrote:
>
>> Hi Colin,
>>
>> Thanks for the solution, that was quite descriptive. As you said it 
>> took me 10 min to implement.
>>
>> It would be nice to have a generic mechanism that is part of the 
>> framework that will do the same, probably the requrement is not too 
>> common to warrant that.
>>
>> Thanks again,
>> --Venkat.
>>
>>
>>
>> From: Colin Sampaleanu <col...@ex...>
>> Reply-To: spr...@li...
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] BeanFactory partial 
>> pre-population with application objects.
>> Date: Tue, 02 Nov 2004 16:56:10 -0500
>>
>> There's probably some cleaner ways to handle this, but off the top of 
>> my head I can think of one fairly easy mechanism that should take 10 
>> minutes or less to implement.
>>
>> Sucblass ClasspathXmlApplicationContext to have a Communicator field, 
>> and getCommunicator() method to get the value of this. When your 
>> variant of ClasspathXmlApplicationContext is created, the 
>> Communicator instance could be passed in as a constructor arg (make a 
>> new constructor), or as a setter property (you would need to make 
>> sure to use the existing constructor with refresh=false, for that 
>> approach). To actually get at the Communicator instance inside the 
>> context def, the user would just use a custom FactoryBean you define. 
>> This factory bean would be ApplicationContextAware, so would have the 
>> context given to it. All it would do on the getObject() method, is 
>> cast the context to your subclass type, and return the value of the 
>> getCommunicator() method.  All the user has to do when setting up 
>> their context.xml file is remember to add in a one line bean 
>> definition for your factory:
>>
>> <bean id="communicator" class="x.y.z.CommunicatorFactoryBean"/>
>>
>>
>> Regards,
>> Colin
>>
>> Venkat Sonnathi wrote:
>>
>>> Hi,
>>>
>>> The subject may sound strange but please bear with me. I am trying 
>>> to use Spring to isolate ICE (http://www.zeroc.com) specific 
>>> depedencies. I could prototype the client side interaction (Thanks 
>>> to Jurgen for pointing me in the right direction), but have come to 
>>> a block when trying Server side.
>>>
>>> ICE has a kind of app server called IceBox, it loads different 
>>> services from a Config file, it has a feature called 
>>> UseSharedCommunicator, which means all the loaded services share the 
>>> same ICE runtime instance and calls to other services located in the 
>>> same instance are treated as local calls.
>>>
>>> Basically you wrap a ServiceImpl class in ServiceAdapter so that 
>>> IceBox can load it, here is an example of the ServiceAdapter for a 
>>> ServiceImpl class PrinterI
>>>
>>> public class IceBoxService  extends Ice.LocalObjectImpl implements 
>>> IceBox.Service {
>>>
>>>        private Ice.ObjectAdapter adapter;
>>>
>>>        public void start(String s, Communicator communicator, 
>>> String[] strings) {
>>>
>>>            this.adapter = communicator.createObjectAdapter(s);
>>>            Ice.Object object = new PrinterI(communicator);
>>>            adapter.add(object, 
>>> Ice.Util.stringToIdentity("SimpleFCASearch"));
>>>            adapter.activate();
>>>        }
>>>
>>>        public void stop() {
>>>            adapter.deactivate();
>>>        }
>>>    }
>>>
>>> }
>>>
>>> I was planning on writing a generic IceBoxService which takes a 
>>> parameter to context.xml file and instantiate a BeanFactory which 
>>> loads the ServiceImpls and resolve the services they depend upon.  
>>> But, if you observe how the PrinterI is instantiated, the 
>>> communicator instance passed to it should be one that is supplied by 
>>> the IceBox server (passed in as a parameter to start method). How to 
>>> make a bean factory aware of this communicator?
>>>
>>> The following code explains the behaviour I am looking for:
>>> BeanFactory bf = new ClassPathXmlApplicationContext();
>>> bf.setBean("communicator", communicator); // Setting/passing the 
>>> application communicator instance to the Bean
>>> bf.load("context.xml"); // refers to the communicator bean passed in 
>>> above statement.
>>>
>>> Thanks for your time and patience.
>>>
>>> --Venkat.
>>



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] beandoc tool

[Darren D. <da...@da...>]

On Friday 05 November 2004 00:53, Daniel Potter wrote:
> Will it handle autowired bean factories?

not right now, some of the really basic stuff isn't finished yet ;)

> I really like the approach=20
> you've taken with this (sort of a combination of SpringViz and
> JavaDoc).  A few weeks ago, someone suggested the idea of actually
> loading the application context or bean factory and generating the graph
> and documentation from that.  It seems like this would be the only way
> to support autowired configurations, but obviously poses problems b/c
> you don't want to actually instantiate/lookup all the beans.

exactly.  Some of which may depend on container resources and so on.  At th=
e=20
moment the tool has no dependencies on anything other than a couple of=20
libs.

> I played=20
> with this a bit and wrote a custom BeanFactory or ApplicationContext
> (can't remember which) that simply skipped bean creation.  I thought I'd
> just be able to then query for all the bean definitions and use them to
> generate the documentation, including dependency links.   Unfortunately,
> it turns out that autowired dependencies aren't stored in the collection
> of bean definitions (the definitions just reflect what was in the
> configuration files).  I stopped there and decided to wait for someone
> else to figure it out. ;)  Perhaps all that is needed is a custom
> BeanFactory that maintains these details and updates its bean
> definitions to reflect autowired dependencies as it's loaded?
>
> Thoughts?

depends how many are really using autowiring heavily - may look at it in th=
e=20
future but there's lots of other stuff to do first.


=2D-=20
Darren Davison
Public Key: #DD356B0D

Re: [Springframework-developer] beandoc tool

[Daniel P. <po...@ci...>]

Will it handle autowired bean factories?  I really like the approach
you've taken with this (sort of a combination of SpringViz and
JavaDoc).  A few weeks ago, someone suggested the idea of actually
loading the application context or bean factory and generating the graph
and documentation from that.  It seems like this would be the only way
to support autowired configurations, but obviously poses problems b/c
you don't want to actually instantiate/lookup all the beans.  I played
with this a bit and wrote a custom BeanFactory or ApplicationContext
(can't remember which) that simply skipped bean creation.  I thought I'd
just be able to then query for all the bean definitions and use them to
generate the documentation, including dependency links.   Unfortunately, 
it turns out that autowired dependencies aren't stored in the collection
of bean definitions (the definitions just reflect what was in the
configuration files).  I stopped there and decided to wait for someone
else to figure it out. ;)  Perhaps all that is needed is a custom
BeanFactory that maintains these details and updates its bean
definitions to reflect autowired dependencies as it's loaded?

Thoughts? 

Daniel

On Thu, Nov 04, 2004 at 02:42:57PM -0500, Colin Sampaleanu wrote:
> That is way cool!
> 
> Darren Davison wrote:
> 
> >I've done a bit of work on a tool to document and graph context files.  It 
> >still needs some work in a few areas but it's starting to show promise I 
> >think.
> >
> >Although highly configurable in terms of output, the defaults are pretty 
> >sane and were used to generate docs from JPetStore's config.  They can be 
> >seen at http://www.davison.uk.net/beandoc/ for a short while.  All of the 
> >HTML and graphs were generated by simply calling the main class and 
> >supplying the input files and an output location as command line args.
> >
> >The only changes made to the input files was to move some of the XML 
> >comments into <description> tags.  Output of <list> <map> <set> and one or 
> >two other tags is currently either broken or not started, but there's 
> >enough there to get the idea.
> >
> >Stuff still to do: finish XSLT templates, add an ANT task, write docs, 
> >etc. etc.
> >
> >Is there any interest from others in using this and seeing it added as a 
> >subproject (like RCP or Spring-IDE)?
> >
> > 
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] BeanFactory partial pre-population with applicat

[Colin S. <col...@ex...>]

Just for the record though, I was being incredibly dense below, as of 
course there is not even a need of the factory bean. The Communicator 
itself can just be registered as the singleton.

In my own defence, I started off with another approach that did need the 
factory bean. That approach was a bit more complex, but would allow a 
refresh too. It's to create a MutablePropertyValue wrapping the factory 
bean, and use it with a new RootBeanDefinition which is just registered 
manually. Then the xml context def can also be read in. I would stick to 
the simpler approach until you actually need more than one refresh though...

Venkat Sonnathi wrote:

> Hi Colin,
>
> Yes, this is what I was looking for. With the solution given below I 
> don't have to write custom FactoryBean's and ApplicationContext's for 
> each application object I want to expose.
>
> You guys rock!
>
> Thank you very much.
> --Venkat.
>
> From: Colin Sampaleanu <col...@ex...>
> Reply-To: spr...@li...
> To: spr...@li...
> Subject: Re: [Springframework-developer] BeanFactory partial 
> pre-population with applicat
> Date: Thu, 04 Nov 2004 13:38:15 -0500
>
> Venkat,
>
> If you are willing to rely on the new GenericApplicationContext class 
> which was introduced for Spring 1.1.2 (which is planned for release 
> this weekend, but the code is in CVS already), there is an even easier 
> mechanism.
>
> Make a simple PassthroughFactoryBean, which always returns an object 
> that it was fed as a constructor:
>    static class PassthroughFactoryBean implements FactoryBean {
>        private Object object;
>
>        public PassthroughFactoryBean(Object object) {
>            this.object = object;
>        }
>        public Object getObject() throws Exception {
>            return object;
>        }
>        public Class getObjectType() {
>            return object.getClass();
>        }
>        public boolean isSingleton() {
>            return true;
>        }
>    }
>
> now, just use GenericApplicationContext:
>
>        GenericApplicationContext ctx = new GenericApplicationContext();
>        ConfigurableListableBeanFactory factory = ctx.getBeanFactory();
>
>        PassthroughFactoryBean communicatorFactory = new 
> PassthroughFactoryBean(communicator);
>        factory.registerSingleton("communicator", communicator);
>              XmlBeanDefinitionReader xmlReader = new 
> XmlBeanDefinitionReader(ctx);
>        xmlReader.loadBeanDefinitions(new 
> ClassPathResource(contextFileLocation));
>              ctx.refresh();
>
> And after writing this, I just realized that even with a normal 
> ClasspathXmlApplicationContext, what you should be able to do is just 
> use the constructor with refresh=false to create the context but not 
> initialize it yet, then just add the singleton factory bean exactly as 
> above, then call refresh on it. Just be careful, as a subsequent 
> refresh will not have the manually added singleton bean! That's why 
> GenericApplicationContext doesn't even allow more than one refresh.
>
> Colin
>
>
> Venkat Sonnathi wrote:
>
>> Hi Colin,
>>
>> Thanks for the solution, that was quite descriptive. As you said it 
>> took me 10 min to implement.
>>
>> It would be nice to have a generic mechanism that is part of the 
>> framework that will do the same, probably the requrement is not too 
>> common to warrant that.
>>
>> Thanks again,
>> --Venkat.
>>
>>
>>
>> From: Colin Sampaleanu <col...@ex...>
>> Reply-To: spr...@li...
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] BeanFactory partial 
>> pre-population with application objects.
>> Date: Tue, 02 Nov 2004 16:56:10 -0500
>>
>> There's probably some cleaner ways to handle this, but off the top of 
>> my head I can think of one fairly easy mechanism that should take 10 
>> minutes or less to implement.
>>
>> Sucblass ClasspathXmlApplicationContext to have a Communicator field, 
>> and getCommunicator() method to get the value of this. When your 
>> variant of ClasspathXmlApplicationContext is created, the 
>> Communicator instance could be passed in as a constructor arg (make a 
>> new constructor), or as a setter property (you would need to make 
>> sure to use the existing constructor with refresh=false, for that 
>> approach). To actually get at the Communicator instance inside the 
>> context def, the user would just use a custom FactoryBean you define. 
>> This factory bean would be ApplicationContextAware, so would have the 
>> context given to it. All it would do on the getObject() method, is 
>> cast the context to your subclass type, and return the value of the 
>> getCommunicator() method.  All the user has to do when setting up 
>> their context.xml file is remember to add in a one line bean 
>> definition for your factory:
>>
>> <bean id="communicator" class="x.y.z.CommunicatorFactoryBean"/>
>>
>>
>> Regards,
>> Colin
>>
>> Venkat Sonnathi wrote:
>>
>>> Hi,
>>>
>>> The subject may sound strange but please bear with me. I am trying 
>>> to use Spring to isolate ICE (http://www.zeroc.com) specific 
>>> depedencies. I could prototype the client side interaction (Thanks 
>>> to Jurgen for pointing me in the right direction), but have come to 
>>> a block when trying Server side.
>>>
>>> ICE has a kind of app server called IceBox, it loads different 
>>> services from a Config file, it has a feature called 
>>> UseSharedCommunicator, which means all the loaded services share the 
>>> same ICE runtime instance and calls to other services located in the 
>>> same instance are treated as local calls.
>>>
>>> Basically you wrap a ServiceImpl class in ServiceAdapter so that 
>>> IceBox can load it, here is an example of the ServiceAdapter for a 
>>> ServiceImpl class PrinterI
>>>
>>> public class IceBoxService  extends Ice.LocalObjectImpl implements 
>>> IceBox.Service {
>>>
>>>        private Ice.ObjectAdapter adapter;
>>>
>>>        public void start(String s, Communicator communicator, 
>>> String[] strings) {
>>>
>>>            this.adapter = communicator.createObjectAdapter(s);
>>>            Ice.Object object = new PrinterI(communicator);
>>>            adapter.add(object, 
>>> Ice.Util.stringToIdentity("SimpleFCASearch"));
>>>            adapter.activate();
>>>        }
>>>
>>>        public void stop() {
>>>            adapter.deactivate();
>>>        }
>>>    }
>>>
>>> }
>>>
>>> I was planning on writing a generic IceBoxService which takes a 
>>> parameter to context.xml file and instantiate a BeanFactory which 
>>> loads the ServiceImpls and resolve the services they depend upon.  
>>> But, if you observe how the PrinterI is instantiated, the 
>>> communicator instance passed to it should be one that is supplied by 
>>> the IceBox server (passed in as a parameter to start method). How to 
>>> make a bean factory aware of this communicator?
>>>
>>> The following code explains the behaviour I am looking for:
>>> BeanFactory bf = new ClassPathXmlApplicationContext();
>>> bf.setBean("communicator", communicator); // Setting/passing the 
>>> application communicator instance to the Bean
>>> bf.load("context.xml"); // refers to the communicator bean passed in 
>>> above statement.
>>>
>>> Thanks for your time and patience.
>>>
>>> --Venkat.
>>

Re: [Springframework-developer] BeanFactory partial pre-population with applicat

[Colin S. <col...@ex...>]

Just for the record though, I was being incredibly dense below, as of 
course there is not even a need of the factory bean. The Communicator 
itself can just be registered as the singleton.

In my own defence, I started off with another approach that did need the 
factory bean. That approach was a bit more complex, but would allow a 
refresh too. It's to create a MutablePropertyValue wrapping the factory 
bean, and use it with a new RootBeanDefinition which is just registered 
manually. Then the xml context def can also be read in. I would stick to 
the simpler approach until you actually need more than one refresh though...


Venkat Sonnathi wrote:

> Hi Colin,
>
> Yes, this is what I was looking for. With the solution given below I 
> don't have to write custom FactoryBean's and ApplicationContext's for 
> each application object I want to expose.
>
> You guys rock!
>
> Thank you very much.
> --Venkat.
>
> From: Colin Sampaleanu <col...@ex...>
> Reply-To: spr...@li...
> To: spr...@li...
> Subject: Re: [Springframework-developer] BeanFactory partial 
> pre-population with applicat
> Date: Thu, 04 Nov 2004 13:38:15 -0500
>
> Venkat,
>
> If you are willing to rely on the new GenericApplicationContext class 
> which was introduced for Spring 1.1.2 (which is planned for release 
> this weekend, but the code is in CVS already), there is an even easier 
> mechanism.
>
> Make a simple PassthroughFactoryBean, which always returns an object 
> that it was fed as a constructor:
>    static class PassthroughFactoryBean implements FactoryBean {
>        private Object object;
>
>        public PassthroughFactoryBean(Object object) {
>            this.object = object;
>        }
>        public Object getObject() throws Exception {
>            return object;
>        }
>        public Class getObjectType() {
>            return object.getClass();
>        }
>        public boolean isSingleton() {
>            return true;
>        }
>    }
>
> now, just use GenericApplicationContext:
>
>        GenericApplicationContext ctx = new GenericApplicationContext();
>        ConfigurableListableBeanFactory factory = ctx.getBeanFactory();
>
>        PassthroughFactoryBean communicatorFactory = new 
> PassthroughFactoryBean(communicator);
>        factory.registerSingleton("communicator", communicator);
>              XmlBeanDefinitionReader xmlReader = new 
> XmlBeanDefinitionReader(ctx);
>        xmlReader.loadBeanDefinitions(new 
> ClassPathResource(contextFileLocation));
>              ctx.refresh();
>
> And after writing this, I just realized that even with a normal 
> ClasspathXmlApplicationContext, what you should be able to do is just 
> use the constructor with refresh=false to create the context but not 
> initialize it yet, then just add the singleton factory bean exactly as 
> above, then call refresh on it. Just be careful, as a subsequent 
> refresh will not have the manually added singleton bean! That's why 
> GenericApplicationContext doesn't even allow more than one refresh.
>
> Colin
>
>
> Venkat Sonnathi wrote:
>
>> Hi Colin,
>>
>> Thanks for the solution, that was quite descriptive. As you said it 
>> took me 10 min to implement.
>>
>> It would be nice to have a generic mechanism that is part of the 
>> framework that will do the same, probably the requrement is not too 
>> common to warrant that.
>>
>> Thanks again,
>> --Venkat.
>>
>>
>>
>> From: Colin Sampaleanu <col...@ex...>
>> Reply-To: spr...@li...
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] BeanFactory partial 
>> pre-population with application objects.
>> Date: Tue, 02 Nov 2004 16:56:10 -0500
>>
>> There's probably some cleaner ways to handle this, but off the top of 
>> my head I can think of one fairly easy mechanism that should take 10 
>> minutes or less to implement.
>>
>> Sucblass ClasspathXmlApplicationContext to have a Communicator field, 
>> and getCommunicator() method to get the value of this. When your 
>> variant of ClasspathXmlApplicationContext is created, the 
>> Communicator instance could be passed in as a constructor arg (make a 
>> new constructor), or as a setter property (you would need to make 
>> sure to use the existing constructor with refresh=false, for that 
>> approach). To actually get at the Communicator instance inside the 
>> context def, the user would just use a custom FactoryBean you define. 
>> This factory bean would be ApplicationContextAware, so would have the 
>> context given to it. All it would do on the getObject() method, is 
>> cast the context to your subclass type, and return the value of the 
>> getCommunicator() method.  All the user has to do when setting up 
>> their context.xml file is remember to add in a one line bean 
>> definition for your factory:
>>
>> <bean id="communicator" class="x.y.z.CommunicatorFactoryBean"/>
>>
>>
>> Regards,
>> Colin
>>
>> Venkat Sonnathi wrote:
>>
>>> Hi,
>>>
>>> The subject may sound strange but please bear with me. I am trying 
>>> to use Spring to isolate ICE (http://www.zeroc.com) specific 
>>> depedencies. I could prototype the client side interaction (Thanks 
>>> to Jurgen for pointing me in the right direction), but have come to 
>>> a block when trying Server side.
>>>
>>> ICE has a kind of app server called IceBox, it loads different 
>>> services from a Config file, it has a feature called 
>>> UseSharedCommunicator, which means all the loaded services share the 
>>> same ICE runtime instance and calls to other services located in the 
>>> same instance are treated as local calls.
>>>
>>> Basically you wrap a ServiceImpl class in ServiceAdapter so that 
>>> IceBox can load it, here is an example of the ServiceAdapter for a 
>>> ServiceImpl class PrinterI
>>>
>>> public class IceBoxService  extends Ice.LocalObjectImpl implements 
>>> IceBox.Service {
>>>
>>>        private Ice.ObjectAdapter adapter;
>>>
>>>        public void start(String s, Communicator communicator, 
>>> String[] strings) {
>>>
>>>            this.adapter = communicator.createObjectAdapter(s);
>>>            Ice.Object object = new PrinterI(communicator);
>>>            adapter.add(object, 
>>> Ice.Util.stringToIdentity("SimpleFCASearch"));
>>>            adapter.activate();
>>>        }
>>>
>>>        public void stop() {
>>>            adapter.deactivate();
>>>        }
>>>    }
>>>
>>> }
>>>
>>> I was planning on writing a generic IceBoxService which takes a 
>>> parameter to context.xml file and instantiate a BeanFactory which 
>>> loads the ServiceImpls and resolve the services they depend upon.  
>>> But, if you observe how the PrinterI is instantiated, the 
>>> communicator instance passed to it should be one that is supplied by 
>>> the IceBox server (passed in as a parameter to start method). How to 
>>> make a bean factory aware of this communicator?
>>>
>>> The following code explains the behaviour I am looking for:
>>> BeanFactory bf = new ClassPathXmlApplicationContext();
>>> bf.setBean("communicator", communicator); // Setting/passing the 
>>> application communicator instance to the Bean
>>> bf.load("context.xml"); // refers to the communicator bean passed in 
>>> above statement.
>>>
>>> Thanks for your time and patience.
>>>
>>> --Venkat.
>>>

Re: [Springframework-developer] BeanFactory partial pre-population with applicat

[Venkat S. <vso...@ho...>]

Hi Colin,

Yes, this is what I was looking for. With the solution given below I don't 
have to write custom FactoryBean's and ApplicationContext's for each 
application object I want to expose.

You guys rock!

Thank you very much.
--Venkat.

From: Colin Sampaleanu <col...@ex...>
Reply-To: spr...@li...
To: spr...@li...
Subject: Re: [Springframework-developer] BeanFactory partial pre-population 
with applicat
Date: Thu, 04 Nov 2004 13:38:15 -0500

Venkat,

If you are willing to rely on the new GenericApplicationContext class which 
was introduced for Spring 1.1.2 (which is planned for release this weekend, 
but the code is in CVS already), there is an even easier mechanism.

Make a simple PassthroughFactoryBean, which always returns an object that it 
was fed as a constructor:
    static class PassthroughFactoryBean implements FactoryBean {
        private Object object;

        public PassthroughFactoryBean(Object object) {
            this.object = object;
        }
        public Object getObject() throws Exception {
            return object;
        }
        public Class getObjectType() {
            return object.getClass();
        }
        public boolean isSingleton() {
            return true;
        }
    }

now, just use GenericApplicationContext:

        GenericApplicationContext ctx = new GenericApplicationContext();
        ConfigurableListableBeanFactory factory = ctx.getBeanFactory();

        PassthroughFactoryBean communicatorFactory = new 
PassthroughFactoryBean(communicator);
        factory.registerSingleton("communicator", communicator);
              XmlBeanDefinitionReader xmlReader = new 
XmlBeanDefinitionReader(ctx);
        xmlReader.loadBeanDefinitions(new 
ClassPathResource(contextFileLocation));
              ctx.refresh();

And after writing this, I just realized that even with a normal 
ClasspathXmlApplicationContext, what you should be able to do is just use 
the constructor with refresh=false to create the context but not initialize 
it yet, then just add the singleton factory bean exactly as above, then call 
refresh on it. Just be careful, as a subsequent refresh will not have the 
manually added singleton bean! That's why GenericApplicationContext doesn't 
even allow more than one refresh.

Colin


Venkat Sonnathi wrote:

>Hi Colin,
>
>Thanks for the solution, that was quite descriptive. As you said it took me 
>10 min to implement.
>
>It would be nice to have a generic mechanism that is part of the framework 
>that will do the same, probably the requrement is not too common to warrant 
>that.
>
>Thanks again,
>--Venkat.
>
>
>
>From: Colin Sampaleanu <col...@ex...>
>Reply-To: spr...@li...
>To: spr...@li...
>Subject: Re: [Springframework-developer] BeanFactory partial pre-population 
>with application objects.
>Date: Tue, 02 Nov 2004 16:56:10 -0500
>
>There's probably some cleaner ways to handle this, but off the top of my 
>head I can think of one fairly easy mechanism that should take 10 minutes 
>or less to implement.
>
>Sucblass ClasspathXmlApplicationContext to have a Communicator field, and 
>getCommunicator() method to get the value of this. When your variant of 
>ClasspathXmlApplicationContext is created, the Communicator instance could 
>be passed in as a constructor arg (make a new constructor), or as a setter 
>property (you would need to make sure to use the existing constructor with 
>refresh=false, for that approach). To actually get at the Communicator 
>instance inside the context def, the user would just use a custom 
>FactoryBean you define. This factory bean would be ApplicationContextAware, 
>so would have the context given to it. All it would do on the getObject() 
>method, is cast the context to your subclass type, and return the value of 
>the getCommunicator() method.  All the user has to do when setting up their 
>context.xml file is remember to add in a one line bean definition for your 
>factory:
>
><bean id="communicator" class="x.y.z.CommunicatorFactoryBean"/>
>
>
>Regards,
>Colin
>
>Venkat Sonnathi wrote:
>
>>Hi,
>>
>>The subject may sound strange but please bear with me. I am trying to use 
>>Spring to isolate ICE (http://www.zeroc.com) specific depedencies. I could 
>>prototype the client side interaction (Thanks to Jurgen for pointing me in 
>>the right direction), but have come to a block when trying Server side.
>>
>>ICE has a kind of app server called IceBox, it loads different services 
>>from a Config file, it has a feature called UseSharedCommunicator, which 
>>means all the loaded services share the same ICE runtime instance and 
>>calls to other services located in the same instance are treated as local 
>>calls.
>>
>>Basically you wrap a ServiceImpl class in ServiceAdapter so that IceBox 
>>can load it, here is an example of the ServiceAdapter for a ServiceImpl 
>>class PrinterI
>>
>>public class IceBoxService  extends Ice.LocalObjectImpl implements 
>>IceBox.Service {
>>
>>        private Ice.ObjectAdapter adapter;
>>
>>        public void start(String s, Communicator communicator, String[] 
>>strings) {
>>
>>            this.adapter = communicator.createObjectAdapter(s);
>>            Ice.Object object = new PrinterI(communicator);
>>            adapter.add(object, 
>>Ice.Util.stringToIdentity("SimpleFCASearch"));
>>            adapter.activate();
>>        }
>>
>>        public void stop() {
>>            adapter.deactivate();
>>        }
>>    }
>>
>>}
>>
>>I was planning on writing a generic IceBoxService which takes a parameter 
>>to context.xml file and instantiate a BeanFactory which loads the 
>>ServiceImpls and resolve the services they depend upon.  But, if you 
>>observe how the PrinterI is instantiated, the communicator instance passed 
>>to it should be one that is supplied by the IceBox server (passed in as a 
>>parameter to start method). How to make a bean factory aware of this 
>>communicator?
>>
>>The following code explains the behaviour I am looking for:
>>BeanFactory bf = new ClassPathXmlApplicationContext();
>>bf.setBean("communicator", communicator); // Setting/passing the 
>>application communicator instance to the Bean
>>bf.load("context.xml"); // refers to the communicator bean passed in above 
>>statement.
>>
>>Thanks for your time and patience.
>>
>>--Venkat.
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by:
>>Sybase ASE Linux Express Edition - download now for FREE
>>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] beandoc tool

[Colin S. <col...@ex...>]

That is way cool!

Darren Davison wrote:

>I've done a bit of work on a tool to document and graph context files.  It 
>still needs some work in a few areas but it's starting to show promise I 
>think.
>
>Although highly configurable in terms of output, the defaults are pretty 
>sane and were used to generate docs from JPetStore's config.  They can be 
>seen at http://www.davison.uk.net/beandoc/ for a short while.  All of the 
>HTML and graphs were generated by simply calling the main class and 
>supplying the input files and an output location as command line args.
>
>The only changes made to the input files was to move some of the XML 
>comments into <description> tags.  Output of <list> <map> <set> and one or 
>two other tags is currently either broken or not started, but there's 
>enough there to get the idea.
>
>Stuff still to do: finish XSLT templates, add an ANT task, write docs, etc. 
>etc.
>
>Is there any interest from others in using this and seeing it added as a 
>subproject (like RCP or Spring-IDE)?
>
>  
>

Re: [Springframework-developer] beandoc tool

[Dmitriy K. <dko...@ru...>]

Looks good to me too!

Keith Donald wrote:

>This is great! Very cool! I think we need this--Hivemind has HiveDoc, why
>can't we have SpringDoc? :-)
>
>Perhaps a slogan, too?
>"SpringDoc: dependency visualization for Spring-powered applications" :-)
>
>Keith
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Darren Davison
>Sent: Thursday, November 04, 2004 12:55 PM
>To: spr...@li...
>Subject: [Springframework-developer] beandoc tool
>
>I've done a bit of work on a tool to document and graph context files.  It 
>still needs some work in a few areas but it's starting to show promise I 
>think.
>
>Although highly configurable in terms of output, the defaults are pretty 
>sane and were used to generate docs from JPetStore's config.  They can be 
>seen at http://www.davison.uk.net/beandoc/ for a short while.  All of the 
>HTML and graphs were generated by simply calling the main class and 
>supplying the input files and an output location as command line args.
>
>The only changes made to the input files was to move some of the XML 
>comments into <description> tags.  Output of <list> <map> <set> and one or 
>two other tags is currently either broken or not started, but there's 
>enough there to get the idea.
>
>Stuff still to do: finish XSLT templates, add an ANT task, write docs, etc. 
>etc.
>
>Is there any interest from others in using this and seeing it added as a 
>subproject (like RCP or Spring-IDE)?
>
>  
>

Re: [Springframework-developer] beandoc tool

[Andy D. <an...@ma...>]

I would most certainly use it and see alot of value in something like this for 
what I'm doing.

  - Andy

On Thursday 04 November 2004 09:54 am, Darren Davison wrote:
> I've done a bit of work on a tool to document and graph context files.  It
> still needs some work in a few areas but it's starting to show promise I
> think.
>
> Although highly configurable in terms of output, the defaults are pretty
> sane and were used to generate docs from JPetStore's config.  They can be
> seen at http://www.davison.uk.net/beandoc/ for a short while.  All of the
> HTML and graphs were generated by simply calling the main class and
> supplying the input files and an output location as command line args.
>
> The only changes made to the input files was to move some of the XML
> comments into <description> tags.  Output of <list> <map> <set> and one or
> two other tags is currently either broken or not started, but there's
> enough there to get the idea.
>
> Stuff still to do: finish XSLT templates, add an ANT task, write docs, etc.
> etc.
>
> Is there any interest from others in using this and seeing it added as a
> subproject (like RCP or Spring-IDE)?

RE: [Springframework-developer] beandoc tool

[Keith D. <kd...@cs...>]

This is great! Very cool! I think we need this--Hivemind has HiveDoc, why
can't we have SpringDoc? :-)

Perhaps a slogan, too?
"SpringDoc: dependency visualization for Spring-powered applications" :-)

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Darren Davison
Sent: Thursday, November 04, 2004 12:55 PM
To: spr...@li...
Subject: [Springframework-developer] beandoc tool

I've done a bit of work on a tool to document and graph context files.  It 
still needs some work in a few areas but it's starting to show promise I 
think.

Although highly configurable in terms of output, the defaults are pretty 
sane and were used to generate docs from JPetStore's config.  They can be 
seen at http://www.davison.uk.net/beandoc/ for a short while.  All of the 
HTML and graphs were generated by simply calling the main class and 
supplying the input files and an output location as command line args.

The only changes made to the input files was to move some of the XML 
comments into <description> tags.  Output of <list> <map> <set> and one or 
two other tags is currently either broken or not started, but there's 
enough there to get the idea.

Stuff still to do: finish XSLT templates, add an ANT task, write docs, etc. 
etc.

Is there any interest from others in using this and seeing it added as a 
subproject (like RCP or Spring-IDE)?

-- 
Darren Davison
Public Key: #DD356B0D

Re: [Springframework-developer] BeanFactory partial pre-population with applicat

[Colin S. <col...@ex...>]

Venkat,

If you are willing to rely on the new GenericApplicationContext class 
which was introduced for Spring 1.1.2 (which is planned for release this 
weekend, but the code is in CVS already), there is an even easier mechanism.

Make a simple PassthroughFactoryBean, which always returns an object 
that it was fed as a constructor:
    static class PassthroughFactoryBean implements FactoryBean {
        private Object object;

        public PassthroughFactoryBean(Object object) {
            this.object = object;
        }
        public Object getObject() throws Exception {
            return object;
        }
        public Class getObjectType() {
            return object.getClass();
        }
        public boolean isSingleton() {
            return true;
        }
    }

now, just use GenericApplicationContext:

        GenericApplicationContext ctx = new GenericApplicationContext();
        ConfigurableListableBeanFactory factory = ctx.getBeanFactory();

        PassthroughFactoryBean communicatorFactory = new 
PassthroughFactoryBean(communicator);
        factory.registerSingleton("communicator", communicator);
       
        XmlBeanDefinitionReader xmlReader = new 
XmlBeanDefinitionReader(ctx);
        xmlReader.loadBeanDefinitions(new 
ClassPathResource(contextFileLocation));
       
        ctx.refresh();   

And after writing this, I just realized that even with a normal 
ClasspathXmlApplicationContext, what you should be able to do is just 
use the constructor with refresh=false to create the context but not 
initialize it yet, then just add the singleton factory bean exactly as 
above, then call refresh on it. Just be careful, as a subsequent refresh 
will not have the manually added singleton bean! That's why 
GenericApplicationContext doesn't even allow more than one refresh.

Colin


Venkat Sonnathi wrote:

> Hi Colin,
>
> Thanks for the solution, that was quite descriptive. As you said it 
> took me 10 min to implement.
>
> It would be nice to have a generic mechanism that is part of the 
> framework that will do the same, probably the requrement is not too 
> common to warrant that.
>
> Thanks again,
> --Venkat.
>
>
>
> From: Colin Sampaleanu <col...@ex...>
> Reply-To: spr...@li...
> To: spr...@li...
> Subject: Re: [Springframework-developer] BeanFactory partial 
> pre-population with application objects.
> Date: Tue, 02 Nov 2004 16:56:10 -0500
>
> There's probably some cleaner ways to handle this, but off the top of 
> my head I can think of one fairly easy mechanism that should take 10 
> minutes or less to implement.
>
> Sucblass ClasspathXmlApplicationContext to have a Communicator field, 
> and getCommunicator() method to get the value of this. When your 
> variant of ClasspathXmlApplicationContext is created, the Communicator 
> instance could be passed in as a constructor arg (make a new 
> constructor), or as a setter property (you would need to make sure to 
> use the existing constructor with refresh=false, for that approach). 
> To actually get at the Communicator instance inside the context def, 
> the user would just use a custom FactoryBean you define. This factory 
> bean would be ApplicationContextAware, so would have the context given 
> to it. All it would do on the getObject() method, is cast the context 
> to your subclass type, and return the value of the getCommunicator() 
> method.  All the user has to do when setting up their context.xml file 
> is remember to add in a one line bean definition for your factory:
>
> <bean id="communicator" class="x.y.z.CommunicatorFactoryBean"/>
>
>
> Regards,
> Colin
>
> Venkat Sonnathi wrote:
>
>> Hi,
>>
>> The subject may sound strange but please bear with me. I am trying to 
>> use Spring to isolate ICE (http://www.zeroc.com) specific 
>> depedencies. I could prototype the client side interaction (Thanks to 
>> Jurgen for pointing me in the right direction), but have come to a 
>> block when trying Server side.
>>
>> ICE has a kind of app server called IceBox, it loads different 
>> services from a Config file, it has a feature called 
>> UseSharedCommunicator, which means all the loaded services share the 
>> same ICE runtime instance and calls to other services located in the 
>> same instance are treated as local calls.
>>
>> Basically you wrap a ServiceImpl class in ServiceAdapter so that 
>> IceBox can load it, here is an example of the ServiceAdapter for a 
>> ServiceImpl class PrinterI
>>
>> public class IceBoxService  extends Ice.LocalObjectImpl implements 
>> IceBox.Service {
>>
>>        private Ice.ObjectAdapter adapter;
>>
>>        public void start(String s, Communicator communicator, 
>> String[] strings) {
>>
>>            this.adapter = communicator.createObjectAdapter(s);
>>            Ice.Object object = new PrinterI(communicator);
>>            adapter.add(object, 
>> Ice.Util.stringToIdentity("SimpleFCASearch"));
>>            adapter.activate();
>>        }
>>
>>        public void stop() {
>>            adapter.deactivate();
>>        }
>>    }
>>
>> }
>>
>> I was planning on writing a generic IceBoxService which takes a 
>> parameter to context.xml file and instantiate a BeanFactory which 
>> loads the ServiceImpls and resolve the services they depend upon.  
>> But, if you observe how the PrinterI is instantiated, the 
>> communicator instance passed to it should be one that is supplied by 
>> the IceBox server (passed in as a parameter to start method). How to 
>> make a bean factory aware of this communicator?
>>
>> The following code explains the behaviour I am looking for:
>> BeanFactory bf = new ClassPathXmlApplicationContext();
>> bf.setBean("communicator", communicator); // Setting/passing the 
>> application communicator instance to the Bean
>> bf.load("context.xml"); // refers to the communicator bean passed in 
>> above statement.
>>
>> Thanks for your time and patience.
>>
>> --Venkat.
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Sybase ASE Linux Express Edition - download now for FREE
>> LinuxWorld Reader's Choice Award Winner for best database on Linux.
>> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] beandoc tool

[Rodrigo U. F. J. <rod...@us...>]

great tool,
I was looking for some think like this, that can graph "autowire" 
relationships too.
if you want, I can help to implement this an other things :D

Darren Davison wrote:

>I've done a bit of work on a tool to document and graph context files.  It 
>still needs some work in a few areas but it's starting to show promise I 
>think.
>
>Although highly configurable in terms of output, the defaults are pretty 
>sane and were used to generate docs from JPetStore's config.  They can be 
>seen at http://www.davison.uk.net/beandoc/ for a short while.  All of the 
>HTML and graphs were generated by simply calling the main class and 
>supplying the input files and an output location as command line args.
>
>The only changes made to the input files was to move some of the XML 
>comments into <description> tags.  Output of <list> <map> <set> and one or 
>two other tags is currently either broken or not started, but there's 
>enough there to get the idea.
>
>Stuff still to do: finish XSLT templates, add an ANT task, write docs, etc. 
>etc.
>
>Is there any interest from others in using this and seeing it added as a 
>subproject (like RCP or Spring-IDE)?
>
>  
>

[Springframework-developer] beandoc tool

[Darren D. <da...@da...>]

I've done a bit of work on a tool to document and graph context files.  It=
=20
still needs some work in a few areas but it's starting to show promise I=20
think.

Although highly configurable in terms of output, the defaults are pretty=20
sane and were used to generate docs from JPetStore's config.  They can be=20
seen at http://www.davison.uk.net/beandoc/ for a short while.  All of the=20
HTML and graphs were generated by simply calling the main class and=20
supplying the input files and an output location as command line args.

The only changes made to the input files was to move some of the XML=20
comments into <description> tags.  Output of <list> <map> <set> and one or=
=20
two other tags is currently either broken or not started, but there's=20
enough there to get the idea.

Stuff still to do: finish XSLT templates, add an ANT task, write docs, etc.=
=20
etc.

Is there any interest from others in using this and seeing it added as a=20
subproject (like RCP or Spring-IDE)?

=2D-=20
Darren Davison
Public Key: #DD356B0D

RE: [Springframework-developer] OT: Data Mapping with JavaBeans

[March, A. <am...@so...>]

Mapforce is awesome.  That is all.

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
Behalf
> Of Torsten Juergeleit
> Sent: Thursday, November 04, 2004 8:40 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] OT: Data Mapping with
JavaBeans
>=20
> Good point.
>=20
> In our case the external JavaBeans (defined via XML
> schema and generated via Castor) contain only a very
> small subset of the data available in the internal
> JavaBeans (defined via XML schema and generated via
> Castor too). So the external ones only within the
> system-specific adapter. This adapter is responsible
> to create the generic JavaBeans (defined via XML
> schema and generated via Castor too) with the data
> from the external ones and sending these into our
> system or vice versa. This process of transforming
> JavaBeans is what I am looking for.
>=20
> Has anyone experience with tools like Altova's
> MapForce which support code generation for XML schema
> mapping (XSD to XSD)?
>=20
> Torsten
>=20
> --- Rob Butler <cro...@ya...> wrote:
>=20
> > This may or may not work for you, but here's a
> > suggestion.
> >
> > If possible, have the internal generic JavaBeans
> > implement an interface.  The code which uses these
> > generic JavaBeans should be coded to the interface
> > so
> > that various implementations of it can be used.
> >
> > Then, instead of mapping data from the external
> > JavaBeans to your generic ones, you implement new
> > implementations of the generic JavaBeans, which
> > encapsulate the system-specific ones within them.
> > The
> > implementation of the generic JavaBean interface can
> > then call the appropriate methods of the
> > system-specific JavaBean to obtain the data they
> > would
> > need.
> >
> > There is no "mapping" where data is read out of one
> > bean and placed in another, just methods in your
> > "generic" JavaBeans (which implement the interface)
> > and make calls to the system-specific JavaBeans for
> > data.
> >
> > Just an idea.
> > Later
> > Rob
> >
> > --- Torsten Juergeleit <tju...@ya...> wrote:
> >
> > > Maybe the bright people on the Spring developer
> > list
> > > can give me a hint for the following
> > > non-Spring-related topic:
> > >
> > > We are using XML messages to communicate with
> > > external
> > > systems. At the boundaries of our system these XML
> > > messages are mapped / bound to JavaBeans via
> > Castor.
> > > Within a system-specific adapter these external
> > > JavaBeans are mapped to our internal, generic
> > > JavaBeans.
> > >
> > > What we need now is an easy to use / configure and
> > > performant way to map data between different
> > > JavaBeans.
> > >
> > > Any experiences / suggestions?
> > >
> > > Thanx.
> > > Torsten
> > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Check out the new Yahoo! Front Page.
> > > www.yahoo.com
> > >
> > >
> > >
> > >
> > >
> >
> -------------------------------------------------------
> > > This SF.Net email is sponsored by:
> > > Sybase ASE Linux Express Edition - download now
> > for
> > > FREE
> > > LinuxWorld Reader's Choice Award Winner for best
> > > database on Linux.
> > >
> >
> http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > >
> >
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Check out the new Yahoo! Front Page.
> > www.yahoo.com
> >
> >
> >
> >
> >
> -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Sybase ASE Linux Express Edition - download now for
> > FREE
> > LinuxWorld Reader's Choice Award Winner for best
> > database on Linux.
> >
> http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>=20
>=20
>=20
>=20
> __________________________________
> Do you Yahoo!?
> Check out the new Yahoo! Front Page.
> www.yahoo.com
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] OT: Data Mapping with JavaBeans

[Torsten J. <tju...@ya...>]

Good point.

In our case the external JavaBeans (defined via XML
schema and generated via Castor) contain only a very
small subset of the data available in the internal
JavaBeans (defined via XML schema and generated via
Castor too). So the external ones only within the
system-specific adapter. This adapter is responsible
to create the generic JavaBeans (defined via XML
schema and generated via Castor too) with the data
from the external ones and sending these into our
system or vice versa. This process of transforming
JavaBeans is what I am looking for.

Has anyone experience with tools like Altova's
MapForce which support code generation for XML schema
mapping (XSD to XSD)?

Torsten

--- Rob Butler <cro...@ya...> wrote:

> This may or may not work for you, but here's a
> suggestion.
> 
> If possible, have the internal generic JavaBeans
> implement an interface.  The code which uses these
> generic JavaBeans should be coded to the interface
> so
> that various implementations of it can be used.
> 
> Then, instead of mapping data from the external
> JavaBeans to your generic ones, you implement new
> implementations of the generic JavaBeans, which
> encapsulate the system-specific ones within them. 
> The
> implementation of the generic JavaBean interface can
> then call the appropriate methods of the
> system-specific JavaBean to obtain the data they
> would
> need.  
> 
> There is no "mapping" where data is read out of one
> bean and placed in another, just methods in your
> "generic" JavaBeans (which implement the interface)
> and make calls to the system-specific JavaBeans for
> data.
> 
> Just an idea.
> Later
> Rob
> 
> --- Torsten Juergeleit <tju...@ya...> wrote:
> 
> > Maybe the bright people on the Spring developer
> list
> > can give me a hint for the following
> > non-Spring-related topic:
> > 
> > We are using XML messages to communicate with
> > external
> > systems. At the boundaries of our system these XML
> > messages are mapped / bound to JavaBeans via
> Castor.
> > Within a system-specific adapter these external
> > JavaBeans are mapped to our internal, generic 
> > JavaBeans.
> > 
> > What we need now is an easy to use / configure and
> > performant way to map data between different
> > JavaBeans.
> > 
> > Any experiences / suggestions?
> > 
> > Thanx.
> > Torsten
> > 
> > 
> > 		
> > __________________________________ 
> > Do you Yahoo!? 
> > Check out the new Yahoo! Front Page. 
> > www.yahoo.com 
> >  
> > 
> > 
> > 
> >
>
-------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Sybase ASE Linux Express Edition - download now
> for
> > FREE
> > LinuxWorld Reader's Choice Award Winner for best
> > database on Linux.
> >
>
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > 
> 
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Check out the new Yahoo! Front Page. 
> www.yahoo.com 
>  
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for
> FREE
> LinuxWorld Reader's Choice Award Winner for best
> database on Linux.
>
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 



		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 

Re: [Springframework-developer] BeanFactory partial pre-population with applicat

[Venkat S. <vso...@ho...>]

Hi Colin,

Thanks for the solution, that was quite descriptive. As you said it took me 
10 min to implement.

It would be nice to have a generic mechanism that is part of the framework 
that will do the same, probably the requrement is not too common to warrant 
that.

Thanks again,
--Venkat.



From: Colin Sampaleanu <col...@ex...>
Reply-To: spr...@li...
To: spr...@li...
Subject: Re: [Springframework-developer] BeanFactory partial pre-population 
with application objects.
Date: Tue, 02 Nov 2004 16:56:10 -0500

There's probably some cleaner ways to handle this, but off the top of my 
head I can think of one fairly easy mechanism that should take 10 minutes or 
less to implement.

Sucblass ClasspathXmlApplicationContext to have a Communicator field, and 
getCommunicator() method to get the value of this. When your variant of 
ClasspathXmlApplicationContext is created, the Communicator instance could 
be passed in as a constructor arg (make a new constructor), or as a setter 
property (you would need to make sure to use the existing constructor with 
refresh=false, for that approach). To actually get at the Communicator 
instance inside the context def, the user would just use a custom 
FactoryBean you define. This factory bean would be ApplicationContextAware, 
so would have the context given to it. All it would do on the getObject() 
method, is cast the context to your subclass type, and return the value of 
the getCommunicator() method.  All the user has to do when setting up their 
context.xml file is remember to add in a one line bean definition for your 
factory:

<bean id="communicator" class="x.y.z.CommunicatorFactoryBean"/>


Regards,
Colin

Venkat Sonnathi wrote:

>Hi,
>
>The subject may sound strange but please bear with me. I am trying to use 
>Spring to isolate ICE (http://www.zeroc.com) specific depedencies. I could 
>prototype the client side interaction (Thanks to Jurgen for pointing me in 
>the right direction), but have come to a block when trying Server side.
>
>ICE has a kind of app server called IceBox, it loads different services 
>from a Config file, it has a feature called UseSharedCommunicator, which 
>means all the loaded services share the same ICE runtime instance and calls 
>to other services located in the same instance are treated as local calls.
>
>Basically you wrap a ServiceImpl class in ServiceAdapter so that IceBox can 
>load it, here is an example of the ServiceAdapter for a ServiceImpl class 
>PrinterI
>
>public class IceBoxService  extends Ice.LocalObjectImpl implements 
>IceBox.Service {
>
>        private Ice.ObjectAdapter adapter;
>
>        public void start(String s, Communicator communicator, String[] 
>strings) {
>
>            this.adapter = communicator.createObjectAdapter(s);
>            Ice.Object object = new PrinterI(communicator);
>            adapter.add(object, 
>Ice.Util.stringToIdentity("SimpleFCASearch"));
>            adapter.activate();
>        }
>
>        public void stop() {
>            adapter.deactivate();
>        }
>    }
>
>}
>
>I was planning on writing a generic IceBoxService which takes a parameter 
>to context.xml file and instantiate a BeanFactory which loads the 
>ServiceImpls and resolve the services they depend upon.  But, if you 
>observe how the PrinterI is instantiated, the communicator instance passed 
>to it should be one that is supplied by the IceBox server (passed in as a 
>parameter to start method). How to make a bean factory aware of this 
>communicator?
>
>The following code explains the behaviour I am looking for:
>BeanFactory bf = new ClassPathXmlApplicationContext();
>bf.setBean("communicator", communicator); // Setting/passing the 
>application communicator instance to the Bean
>bf.load("context.xml"); // refers to the communicator bean passed in above 
>statement.
>
>Thanks for your time and patience.
>
>--Venkat.
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer





-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] OT: Data Mapping with JavaBeans

[Dmitriy K. <dko...@ru...>]

So basically this is a classic "GoF" Adapter pattern ;-)

Cheers,
Dmitriy.


Rob Butler wrote:

>This may or may not work for you, but here's a
>suggestion.
>
>If possible, have the internal generic JavaBeans
>implement an interface.  The code which uses these
>generic JavaBeans should be coded to the interface so
>that various implementations of it can be used.
>
>Then, instead of mapping data from the external
>JavaBeans to your generic ones, you implement new
>implementations of the generic JavaBeans, which
>encapsulate the system-specific ones within them.  The
>implementation of the generic JavaBean interface can
>then call the appropriate methods of the
>system-specific JavaBean to obtain the data they would
>need.  
>
>There is no "mapping" where data is read out of one
>bean and placed in another, just methods in your
>"generic" JavaBeans (which implement the interface)
>and make calls to the system-specific JavaBeans for
>data.
>
>Just an idea.
>Later
>Rob
>
>--- Torsten Juergeleit <tju...@ya...> wrote:
>
>  
>
>>Maybe the bright people on the Spring developer list
>>can give me a hint for the following
>>non-Spring-related topic:
>>
>>We are using XML messages to communicate with
>>external
>>systems. At the boundaries of our system these XML
>>messages are mapped / bound to JavaBeans via Castor.
>>Within a system-specific adapter these external
>>JavaBeans are mapped to our internal, generic 
>>JavaBeans.
>>
>>What we need now is an easy to use / configure and
>>performant way to map data between different
>>JavaBeans.
>>
>>Any experiences / suggestions?
>>
>>Thanx.
>>Torsten
>>
>>
>>		
>>__________________________________ 
>>Do you Yahoo!? 
>>Check out the new Yahoo! Front Page. 
>>www.yahoo.com 
>> 
>>
>>
>>
>>
>>    
>>
>-------------------------------------------------------
>  
>
>>This SF.Net email is sponsored by:
>>Sybase ASE Linux Express Edition - download now for
>>FREE
>>LinuxWorld Reader's Choice Award Winner for best
>>database on Linux.
>>
>>    
>>
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>  
>
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>
>>    
>>
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>
>
>
>
>		
>__________________________________ 
>Do you Yahoo!? 
>Check out the new Yahoo! Front Page. 
>www.yahoo.com 
> 
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

[Springframework-developer] pdfbox and itext

[Dmitriy K. <dko...@ru...>]

Hello everyone.

I've noticed in our lib/itext directory there are two jars for both 
itext and pdfbox. As they're two different libraries, would it make more 
sense to rename top level directory into something like pdf? Or maybe 
create two separate directories one for itext and one for pdfbox?

Any thoughts?

Regards,
Dmitriy.

Re: [Springframework-developer] OT: Data Mapping with JavaBeans

[Rob B. <cro...@ya...>]

This may or may not work for you, but here's a
suggestion.

If possible, have the internal generic JavaBeans
implement an interface.  The code which uses these
generic JavaBeans should be coded to the interface so
that various implementations of it can be used.

Then, instead of mapping data from the external
JavaBeans to your generic ones, you implement new
implementations of the generic JavaBeans, which
encapsulate the system-specific ones within them.  The
implementation of the generic JavaBean interface can
then call the appropriate methods of the
system-specific JavaBean to obtain the data they would
need.  

There is no "mapping" where data is read out of one
bean and placed in another, just methods in your
"generic" JavaBeans (which implement the interface)
and make calls to the system-specific JavaBeans for
data.

Just an idea.
Later
Rob

--- Torsten Juergeleit <tju...@ya...> wrote:

> Maybe the bright people on the Spring developer list
> can give me a hint for the following
> non-Spring-related topic:
> 
> We are using XML messages to communicate with
> external
> systems. At the boundaries of our system these XML
> messages are mapped / bound to JavaBeans via Castor.
> Within a system-specific adapter these external
> JavaBeans are mapped to our internal, generic 
> JavaBeans.
> 
> What we need now is an easy to use / configure and
> performant way to map data between different
> JavaBeans.
> 
> Any experiences / suggestions?
> 
> Thanx.
> Torsten
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Check out the new Yahoo! Front Page. 
> www.yahoo.com 
>  
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for
> FREE
> LinuxWorld Reader's Choice Award Winner for best
> database on Linux.
>
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 



		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 

[Springframework-developer] OT: Data Mapping with JavaBeans

[Torsten J. <tju...@ya...>]

Maybe the bright people on the Spring developer list
can give me a hint for the following
non-Spring-related topic:

We are using XML messages to communicate with external
systems. At the boundaries of our system these XML
messages are mapped / bound to JavaBeans via Castor.
Within a system-specific adapter these external
JavaBeans are mapped to our internal, generic 
JavaBeans.

What we need now is an easy to use / configure and
performant way to map data between different
JavaBeans.

Any experiences / suggestions?

Thanx.
Torsten


		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 

[Springframework-developer] ContextClosedEvent

[Colin S. <col...@ex...>]

I'm just documenting somehting on the ContextClosedEvent. It's called 
when all singletons have been destroyed (i.e. destroy method has been 
called)

    public void close() {
        if (logger.isInfoEnabled()) {
            logger.info("Closing application context [" + 
getDisplayName() + "]");
        }

        // Destroy all cached singletons in this context,
        // invoking DisposableBean.destroy and/or "destroy-method".
        ConfigurableListableBeanFactory beanFactory = getBeanFactory();
        if (beanFactory != null) {
            beanFactory.destroySingletons();
        }

        // publish corresponding event
        publishEvent(new ContextClosedEvent(this));
    }

I've personally never used the context closed event, but what I have to 
ask here is, does nobody else think this sequence is not usable and/or 
potentially dangerous. On the not usable part, an event listener must 
not have a destroy method, since the onApplicationEvent() would end up 
being called after the bean has been destroyed. As for potentially 
dangerous, that's if somebody forgets that they can't have a destroy 
method, and then spring does call the two methods in the wrong sequence.

Colin

[Springframework-developer] spring build.141 Build Successful

[<al...@jt...>]

<html><head>
<style>
.white { color:#FFFFFF }.index { background-color:#FFFFFF }.index-passed { =
color:#004400 }.index-failed { color:#FF0000; font-weight:bold }.index-head=
er { font-weight:bold }.link { font-family:arial,helvetica,sans-serif; font=
-size:10pt; color:#FFFFFF; text-decoration:none; }.tab-table { margin: 0em =
0em 0.5em 0em; }.tabs { font-family:arial,helvetica,sans-serif; font-size:8=
pt; color:#000000; font-weight:bold; padding: 0em 2em; background-color:#EE=
EEEE; }.tabs-link { color:#000000; text-decoration:none; }.tabs-link:visite=
d { color:#000000; text-decoration:none; }.tabs-selected { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; font-weight:bold; pad=
ding: 0em 2em; }.tabs-selected { border: inset; }.header-title { font-famil=
y:arial,helvetica,sans-serif; font-size:12pt; color:#000000; font-weight:bo=
ld; }.header-label { font-weight:bold; }.header-data { font-family:arial,he=
lvetica,sans-serif; font-size:10pt; color:#000000; }.modifications-data { f=
ont-family:arial,helvetica,sans-serif; font-size:8pt; color:#000000; }.modi=
fications-sectionheader { background-color:#000066; font-family:arial,helve=
tica,sans-serif; font-size:10pt; color:#FFFFFF; }.modifications-oddrow { ba=
ckground-color:#CCCCCC }.modifications-evenrow { background-color:#FFFFCC }=
.changelists-oddrow { background-color:#CCCCCC }.changelists-evenrow { back=
ground-color:#FFFFCC }.changelists-file-spacer { background-color:#FFFFFF }=
.changelists-file-evenrow { background-color:#EEEEEE }.changelists-file-odd=
row { background-color:#FFFFEE }.changelists-file-header { background-color=
:#666666; font-family:arial,helvetica,sans-serif; font-size:8pt; color:#FFF=
FFF; }.compile-data { font-family:arial,helvetica,sans-serif; font-size:8pt=
; color:#000000; }.compile-error-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#FF0000; }.compile-warn-data { font-family:arial,=
helvetica,sans-serif; font-size:8pt; color:#CC9900; }.compile-sectionheader=
 { background-color:#000066; font-family:arial,helvetica,sans-serif; font-s=
ize:10pt; color:#FFFFFF; }.distributables-data { font-family:arial,helvetic=
a,sans-serif; font-size:8pt; color:#000000; }.distributables-sectionheader =
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-si=
ze:10pt; color:#FFFFFF; }.distributables-oddrow { background-color:#CCCCCC =
}.unittests-sectionheader { background-color:#000066; font-family:arial,hel=
vetica,sans-serif; font-size:10pt; color:#FFFFFF; }.unittests-oddrow { back=
ground-color:#CCCCCC }.unittests-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#000000; }.unittests-error { font-family:arial,he=
lvetica,sans-serif; font-size:8pt; color:#FF0000; }.checkstyle-oddrow { bac=
kground-color:#CCCCCC }.checkstyle-data { font-family:arial,helvetica,sans-=
serif; font-size:8pt; color:#000000; }.checkstyle-sectionheader { backgroun=
d-color:#000066; font-family:arial,helvetica,sans-serif; font-size:10pt; co=
lor:#FFFFFF; }
</style>
</head><body>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"header-title">BUILD COMPLETE&nbsp;-&nbsp;     =
               build.141</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>11/04/2004 00:16:38</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 27 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed:&nbsp;</span>11/03/2004 03:40:56</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try:&nbsp;</span>fix indenting on continuation lines</td></tr></table><p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"/><p>
<p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader">                        &nbsp;Errors/Warnings: (=
6)                    </td></tr><tr><td><pre class=3D"compile-error-data">N=
ote: Some input files use or override a deprecated API.<br class=3D"none"/>=
Note: Recompile with -deprecation for details.Note: /jteam/build/checkout/s=
pring/spring/mock/org/springframework/mock/web/MockHttpSession.java uses or=
 overrides a deprecated API.<br class=3D"none"/>Note: Recompile with -depre=
cation for details.<br class=3D"none"/>Note: Some input files use or overri=
de a deprecated API.<br class=3D"none"/>Note: Recompile with -deprecation f=
or details.<br class=3D"none"/></pre></td></tr></table><p>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"unittests-sectionheader">       =
            &nbsp;Unit Tests: (1470)                </td></tr><tr><td><tabl=
e width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"c=
enter"><tr><td class=3D"unittests-data">                failure            =
</td><td width=3D"40%" class=3D"unittests-data">testHomePage</td><td width=
=3D"40%" class=3D"unittests-data">org.springframework.apptests.buildtest.Al=
lTests</td></tr></table></td></tr><tr></tr><tr><td colspan=3D"2">&nbsp;</td=
></tr><tr><td colspan=3D"4" class=3D"unittests-sectionheader">             =
       &nbsp;Unit Test Error Details:&nbsp;(1)                </td></tr><tr=
><td class=3D"unittests-data" colspan=3D"2">                Test:&nbsp;test=
HomePage</td></tr><tr><td class=3D"unittests-data" colspan=3D"2">          =
      Class:&nbsp;org.springframework.apptests.buildtest.AllTests</td></tr>=
<tr><td class=3D"unittests-data" colspan=3D"2">                Type: junit.=
framework.AssertionFailedError</td></tr><tr><td class=3D"unittests-data" co=
lspan=3D"2">                Message: Exception while testing URL http://loc=
alhost:13084/buildtest:java.io.IOException</td></tr><tr><td class=3D"unitte=
sts-error" colspan=3D"2"><pre>junit.framework.AssertionFailedError: Excepti=
on while testing URL http://localhost:13084/buildtest:java.io.IOException<b=
r>=09at org.springframework.apptests.buildtest.AllTests.testHomePage(Unknow=
n Source)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meth=
od)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess=
orImpl.java:39)<br>=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(De=
legatingMethodAccessorImpl.java:25)<br></pre></td></tr><tr><td colspan=3D"2=
">&nbsp;</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"modifications-sectionheader">   =
                 &nbsp;Modifications since last build:&nbsp;               =
     (1)                </td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">c=
olins</td><td class=3D"modifications-data">src/org/springframework/web/cont=
ext/support/RequestHandledEvent.java</td><td class=3D"modifications-data">f=
ix indenting on continuation lines</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"distributables-sectionheader">                =
        &nbsp;Deployments by this build:&nbsp;(8)                    </td><=
/tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/checko=
ut/spring/spring/dist/spring.jar</td></tr><tr class=3D"distributables-oddro=
w"><td class=3D"distributables-data">Building war: /jteam/build/checkout/sp=
ring/spring/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr><td c=
lass=3D"distributables-data">Building war: /jteam/build/checkout/spring/spr=
ing/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr class=3D"dist=
ributables-oddrow"><td class=3D"distributables-data">Building war: /jteam/b=
uild/checkout/spring/spring/autobuilds/apps/buildtest/dist/buildtest.war</t=
d></tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/che=
ckout/spring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar=
</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-d=
ata">Building war: /jteam/build/checkout/spring/spring/autobuilds/apps/jpet=
store/dist/jpetstore.war</td></tr><tr><td class=3D"distributables-data">Bui=
lding jar: /jteam/build/checkout/spring/spring/autobuilds/apps/jpetstore/wa=
r/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building war: /jteam/build/checkout/spring/=
spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr></table>
</body></html>

Re: [Springframework-developer] CommonsPoolTargetSource broken?

[Rainer S. <Rai...@ab...>]

Rod Johnson wrote:
> Rainer
> 
> Why do you say "without success"? Getting back the same object isn't 
> necessarily an error.

I misunderstood the intention of CommonsPoolTargetSource.
I missed the line "acquiring and releasing a target object from the pool 
for each method invocation". So I expected to get an object from pool, 
do some work with it, and finally release it again. In this case of 
course I should get a new object when calling getTarget() before 
releasing the old one.

My fault, sorry.

Thanks for the clarification,
Rainer

[Springframework-developer] Using spring to implement modularization?

[Lachezar D. <l.d...@pa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

~  Hello groups.

~  First: Congrats on making Spring that good.

~  As a part of our new project I am assigned to the team evaluating
different frameworks available for a
((distributed)server)-((unknown)client) application.

~  I have had some experience with Hibernate, and saw Spring as an
eventual rival to the JBoss kernel (which I also find quite appealing).

~  I like very much the Spring IOC and Aspecting.

~  What I am missing is:
~  1. Multiplex wiring: I would like to be able to define an
addSomething() and removeSomething() "property" methods and use Spring
to autowire all implementors/extenders of the "property" class.

~  2. Modularization: I would like to have multiple descriptors, and to
have them cross-wired.

~  3. Post aspecting: I would like to insert/add an interceptor to an
existing bean following its definition (i.e. I want to advise a bean
outside the tag where the bean is declared).

~  4. Autowiring a single property: I would like a bean's property to be
autowired, i.e. just defining the bean's property without setting its
value to signal Spring, that this property should be autowired as
available. Very handy if Multiplex wiring is implemented.

~  5. Runtime moduling: Of course this assumes, that Spring is first
modularized. I would like to be able to dynamicaly runtime add, remove
or substitute modules (or better off single beans).

~  Can someone please tell me if some of these features are already
implemented. I would also like to know if any of the features will NOT
be implemented (at least in the next couple of weeks :)).

~  I can also help developing these parts both with some ideas, and raw
code-power.

~  Wating for a call: Lachezar Dobrev.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBiP0zJFPBXrWeBJURAq4XAJ422aCZrinbhncrtRnhj/RTIqL2LwCfSS9Z
5PtCOwW3foSHEB473y+SBOk=
=60nM
-----END PGP SIGNATURE-----

Re: [Springframework-developer] CommonsPoolTargetSource broken?

[Rod J. <ro...@in...>]

Rainer

Why do you say "without success"? Getting back the same object isn't necessarily an error.

This is actually hard to test. Returning the same instance in successive calls is perfectly legitimate as long as there 
is no blocking. Perhaps I should strengthen the tests using two threads, but of course the behaviour will still depend 
on the underlying pool instance.

If you look at the Commons PoolTargetSource implementation, getTarget() is as follows:

public Object getTarget() throws Exception {
	return this.pool.borrowObject();
}

Thus it defers whether it's the same or another object to the pool implementation: Spring isn't caching the object.

Rgds
Rod


Rainer Schmitz wrote:
> Aloha!
> 
> I tried to use CommonsPoolTargetSource without success - calling 
> beanFactory.getBean() always returns the same instance.
> 
> I looked into CommonsPoolTargetSourceTests and as far as I can see it's 
> not tested wether the pool is returning new objects or is working at 
> all. Inspecting the objects returned by getBean() in testFunctionality() 
> with a debugger shows both calls return the same SideEffectBean instance.
> 
> Is this feature broken or am I missing something?
> 
> Cheers,
> Rainer
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

-- 

____________________________________________________
Rod Johnson
Interface21 - Spring Services from the Source
http://www.springframework.com

Founder, Spring Framework:
http://www.springframework.org

Author, "Expert One-on-One J2EE Development Without EJB"
(May 2004, with Juergen Hoeller).
http://www.amazon.com/exec/obidos/ASIN/0764558315/

Author, "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/


____________________________________________________
Interface21 Limited
Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY
Registered in England and Wales No. 5187766
____________________________________________________