You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by CheffPJ <pa...@gmail.com> on 2008/10/01 01:12:48 UTC
Classloading, Contexts, Resources, and Runtime configurations
The feedback from my earlier post about
http://www.nabble.com/What-are-the-Best-Practices-for-updating-physical-addresses-bindings-when-deploying-on-different-environments-domains--td19696522.html
best practices for environmental configuration parameters has me curious
about several things relating to the underlying use of Spring in ServiceMix.
The suggestion was to utilize Spring's PropertyPlaceholderConfigurer, which
is roughly equivalent to how we've solved this problem in another
application using its subclass ServletContextPropertyPlaceholderConfigurer.
But in thinking of the trade-offs in implementing this approach, now I'm
realizing I don't understand how Classloading and Spring contexts work
within service units, service archives, and the entire runtime. In the case
of using the PropertyPlaceholderConfigurer:
a. If I identify the PropertyPlaceholderConfigurer in Service Unit A, will
Service Unit B (within the same Service Archive 1) be able to point to that
bean in order to grab the properties?
b. Will Service Unit C from a different Service Archive 2 be able to access
that bean?
c. Assuming a is a yes and b is a no, is there any way to identify global
resources, such that Service Archive 1 and Service Archive 2 can utilize the
same "global" resources (eg. an external message broker or database pool)?
d. When using a PropertyPlaceholderConfigurer and changing the properties of
the associated file at runtime, is there a command/api/etc. to trigger a
"reload" of the given SU/SA in order to read new configs?
I probably could have written a little test by now, but I thought I'd ask in
case anybody has the answers quickly or can point me to some documentation
that explains it.
--
View this message in context: http://www.nabble.com/Classloading%2C-Contexts%2C-Resources%2C-and-Runtime-configurations-tp19751177p19751177.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Classloading, Contexts, Resources, and Runtime configurations
Posted by Lars Heinemann <la...@compart.net>.
I would suggest that you define data sources for example inside the
conf/jndi.xml. That will give you global access to this data source via jndi
lookup.
Regards
Lars
Am Donnerstag 02 Oktober 2008 08:27:20 schrieb CheffPJ:
> I don't think we're talking about completely different things.
>
> I was suggesting that the combination of a PropertyConfigurerPlaceholder
> and undeploying then redeploying the associated SA while the ESB is still
> up would be close to "changing properties at runtime" (although,
> questionably useful). This seems to be what you suggested at the end.
>
> As far as the resource issues I was talking about, that is a bit of a
> broader question. Let's say we have two service units, each of which is
> using the PropertyConfigurerPlaceholder. It sounds like that would result
> in having two separate objects on the heap for what is really the same bean
> - probably not a big deal, but technically not the most efficient.
>
> But let's also say each of those SUs is using those properties to define
> the same connection factory. It would seem this is cause for concern
> because a connection factory makes me start thinking about managing
> "resources" such as connections, sessions, pools, etc. So although I have
> my "externalizing properties" problem solved, I'm now likely running into
> efficiency issues. Hence the questions about how to share these types of
> resources.
>
> Thanks for all the feedback.
Re: Classloading, Contexts, Resources, and Runtime configurations
Posted by CheffPJ <pa...@gmail.com>.
I don't think we're talking about completely different things.
I was suggesting that the combination of a PropertyConfigurerPlaceholder and
undeploying then redeploying the associated SA while the ESB is still up
would be close to "changing properties at runtime" (although, questionably
useful). This seems to be what you suggested at the end.
As far as the resource issues I was talking about, that is a bit of a
broader question. Let's say we have two service units, each of which is
using the PropertyConfigurerPlaceholder. It sounds like that would result
in having two separate objects on the heap for what is really the same bean
- probably not a big deal, but technically not the most efficient.
But let's also say each of those SUs is using those properties to define the
same connection factory. It would seem this is cause for concern because a
connection factory makes me start thinking about managing "resources" such
as connections, sessions, pools, etc. So although I have my "externalizing
properties" problem solved, I'm now likely running into efficiency issues.
Hence the questions about how to share these types of resources.
Thanks for all the feedback.
--
View this message in context: http://www.nabble.com/Classloading%2C-Contexts%2C-Resources%2C-and-Runtime-configurations-tp19751177p19774044.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Classloading, Contexts, Resources, and Runtime configurations
Posted by Lars Heinemann <la...@compart.net>.
I think we are talking about different things maybe.
What is the so called "hot deployment" ?
-------------------------------------------------------------------------
This is the process putting new service-assemblies / service engines / binding
components into smx. This can be done in different ways...one of it is copying
the files into the "hotdeploy" folder of smx.
What about properties on deployment time?
-------------------------------------------------------------------------
When deploying a service assembly, the service unit inside the assembly will
load the properties mostly from the integrated xbean.xml file (see the
main/resources/ folder of your SU). Every time you deploy your SU, those
properties will be loaded from the xbean.xml.
And if I use the PropertyConfigurerPlaceholder?
-------------------------------------------------------------------------
When using this one, you define a bean for it in the xbean.xml. When you deploy
your SA, the properties may be loaded from the referenced property file if you
done it correctly inside your xbean.xml.
What about changing those properties after deployment?
----------------------------------------------------------------------------------------
You can do this if you used the PropertyConfigurerPlaceholder. You simply
change the values inside the properties file and restart the servicemix
afterwards OR undeploy and redeploy the SA which is affected by the change.
Hopefully this makes it more clear to you.
Regards
Lars
Am Mittwoch 01 Oktober 2008 19:11:27 schrieb CheffPJ:
> lhe77 wrote:
> >> c. Assuming a is a yes and b is a no, is there any way to identify
> >> global resources, such that Service Archive 1 and Service Archive 2 can
> >> utilize the same "global" resources (eg. an external message broker or
> >> database pool)?
> >
> > --> see how I did it in my blog. Referencing to a global file is not a
> > bad solution imho.
>
> I agree that referring to the same file is fine, but wouldn't this approach
> be inefficiently duplicating "resources" (i.e. connections, sessions, etc.)
> at runtime?
>
> Maybe what I should be asking is how you can pool resources such as DB and
> JMS connections, sessions, etc. Would abandoning stand-alone deployment
> and using an app server and some kind of JNDI hook be best (I hope not)?
> Maybe JCA, (but I wasn't sure if that is only for embedded deployments)?
>
> lhe77 wrote:
> >> d. When using a PropertyPlaceholderConfigurer and changing the
> >> properties of the associated file at runtime, is there a
> >> command/api/etc. to trigger a
> >> "reload" of the given SU/SA in order to read new configs?
> >
> > --> unfortunately you have to restart the whole esb after changing values
>
> Am I misunderstanding hot deployment? If you were to undeploy/deploy the
> SA, wouldn't it pick up the new properties without having to restart the
> ESB?
Re: Classloading, Contexts, Resources, and Runtime configurations
Posted by CheffPJ <pa...@gmail.com>.
lhe77 wrote:
>
>> c. Assuming a is a yes and b is a no, is there any way to identify global
>> resources, such that Service Archive 1 and Service Archive 2 can utilize
>> the same "global" resources (eg. an external message broker or database
>> pool)?
>
> --> see how I did it in my blog. Referencing to a global file is not a bad
> solution imho.
>
I agree that referring to the same file is fine, but wouldn't this approach
be inefficiently duplicating "resources" (i.e. connections, sessions, etc.)
at runtime?
Maybe what I should be asking is how you can pool resources such as DB and
JMS connections, sessions, etc. Would abandoning stand-alone deployment and
using an app server and some kind of JNDI hook be best (I hope not)? Maybe
JCA, (but I wasn't sure if that is only for embedded deployments)?
lhe77 wrote:
>
>> d. When using a PropertyPlaceholderConfigurer and changing the properties
>> of the associated file at runtime, is there a command/api/etc. to trigger
>> a
>> "reload" of the given SU/SA in order to read new configs?
>
> --> unfortunately you have to restart the whole esb after changing values
>
Am I misunderstanding hot deployment? If you were to undeploy/deploy the
SA, wouldn't it pick up the new properties without having to restart the
ESB?
--
View this message in context: http://www.nabble.com/Classloading%2C-Contexts%2C-Resources%2C-and-Runtime-configurations-tp19751177p19765065.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Classloading, Contexts, Resources, and Runtime configurations
Posted by Lars Heinemann <la...@compart.net>.
Am Mittwoch 01 Oktober 2008 01:12:48 schrieb CheffPJ:
> The feedback from my earlier post about
> http://www.nabble.com/What-are-the-Best-Practices-for-updating-physical-add
>resses-bindings-when-deploying-on-different-environments-domains--td19696522
>.html best practices for environmental configuration parameters has me
> curious about several things relating to the underlying use of Spring in
> ServiceMix. The suggestion was to utilize Spring's
> PropertyPlaceholderConfigurer, which is roughly equivalent to how we've
> solved this problem in another
> application using its subclass ServletContextPropertyPlaceholderConfigurer.
>
> But in thinking of the trade-offs in implementing this approach, now I'm
> realizing I don't understand how Classloading and Spring contexts work
> within service units, service archives, and the entire runtime. In the
> case of using the PropertyPlaceholderConfigurer:
>
> a. If I identify the PropertyPlaceholderConfigurer in Service Unit A, will
> Service Unit B (within the same Service Archive 1) be able to point to that
> bean in order to grab the properties?
--> no, you need to specify this bean in each SU but you can point to the same
property file
>
> b. Will Service Unit C from a different Service Archive 2 be able to access
> that bean?
>
--> see answer above (no)
> c. Assuming a is a yes and b is a no, is there any way to identify global
> resources, such that Service Archive 1 and Service Archive 2 can utilize
> the same "global" resources (eg. an external message broker or database
> pool)?
--> see how I did it in my blog. Referencing to a global file is not a bad
solution imho.
>
> d. When using a PropertyPlaceholderConfigurer and changing the properties
> of the associated file at runtime, is there a command/api/etc. to trigger a
> "reload" of the given SU/SA in order to read new configs?
--> unfortunately you have to restart the whole esb after changing values
>
> I probably could have written a little test by now, but I thought I'd ask
> in case anybody has the answers quickly or can point me to some
> documentation that explains it.
Regards
Lars