RE: ROME and multiple classloaders

[Nick Lothian]

(I'm CC'ing rome-dev on this - I didn't see your message come though there).


The classloading problems we see most often now occur when the ROME core classes and the ROME plugins/properties files are deployed in different classloaders. I believe this works well now for the most common cases (eg, a web container with ROME in the shared classloader and properties files in a web app classloader). We've seen a few issues lately with OSGi, but the reason for the most recent one (missing property files) isn't completely understood. We know it works correctly in some OSGi deployment scenarios, so it seems likely to be some kind of configuration or platform specific issue.


Thread.currentThread().getContextClassloader() almost always works for plugin systems - the exception being when the plugin container isn't correctly setting the context classloader on the thread which runs the plugin code.

We ran into a similar issue with Axis2 (which also broke Spring & Hibernate), but it turned out they had a special switch to turn on "normal" classloading.

See https://rome.dev.java.net/servlets/ReadMsg?list=dev&msgNo=2679 and https://rome.dev.java.net/servlets/ReadMsg?list=dev&msgNo=2680 for more on this.

Nick

> -----Original Message-----
> From: Chris Janicki [mailto:Chris.Janicki@...]
> Sent: Tuesday, 9 June 2009 1:51 AM
> To: Nick Lothian
> Subject: ROME and multiple classloaders
>
> Nick,
>
> Below is a copy of a message I just sent to the dev email list.  It
> addresses the same topic as your emails from last week, and also
> issue# 118.  (I just found those.)  Note, I suggest a fix below too...
>
> = = = =
>
> I think I'm about 2 years too late to comment on this, but
> unfortunately your fancy classloader footwork breaks my plug-in
> environment.
>
> https://rome.dev.java.net/servlets/ReadMsg?list=dev&msgNo=2414
>
>
> The problem is that my plug-ins have their own built-in classloader so
> they live in their private world, but with access to the default
> classloader when the private classloader can't resolve a request... a
> basic hierarchy system.  So when your code grabs the
> Thread.currentThread().getContextClassLoader(), it breaks out my
> sandbox with brute force, rather than following the hierarchy.  (I'm
> trying to include your jars in one of my plug-ins' classpath, so it is
> distinct from my main application... it would be inelegant to put your
> jars in my main application's classpath, although they might better
> work there.)
>
> I think I have a suggested fix that usually works for me, and maybe
> addresses your underlying need to tweak the classloaders in the first
> place (Disclaimer: I didn't quite understand the original impetus.).
>
> I usually create a Beacon.class (just an empty class that extends
> Object) in whatever package location contains my resources (e.g.
> *.properties files).  Then, I reference the Beacon's classloader,
> since I know it will have access to my resources residing in the same
> directory.  So:
>
> com.xxx.pkg.Beacon.class.getClassLoader().getResourceAsStream(...)
>
> I sometimes have several Beacon classes in different package
> directories.
>
> I think if you referenced your resources this way, you might be able
> to go back to your original version of the code, while still avoiding
> your previous headaches???
>
> Thanks,
>
> Chris Janicki
> 1-781-526-7033 (mobile)
> www.AugurSystems.com
>
>

IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jsbournival]

Hi Nick,

I had the experience using OSGi on Fuse ESB 4 (which is based on Apache ServiceMix4 ... which is based on Apache Felix).

At this point I am unable to use Rome to generate my Atom feeds, as the writer plugins are defined in rome.properties, which seem to be inaccessible due to class loader mix n match.

http://www.nabble.com/RE%3A--Issue-129--New---Failing-to-load-rome.properties-tp23149514p23872200.html

Regards,

JS

Nick Lothian wrote:

(I'm CC'ing rome-dev on this - I didn't see your message come though there).


The classloading problems we see most often now occur when the ROME core classes and the ROME plugins/properties files are deployed in different classloaders. I believe this works well now for the most common cases (eg, a web container with ROME in the shared classloader and properties files in a web app classloader). We've seen a few issues lately with OSGi, but the reason for the most recent one (missing property files) isn't completely understood. We know it works correctly in some OSGi deployment scenarios, so it seems likely to be some kind of configuration or platform specific issue.


Thread.currentThread().getContextClassloader() almost always works for plugin systems - the exception being when the plugin container isn't correctly setting the context classloader on the thread which runs the plugin code.

We ran into a similar issue with Axis2 (which also broke Spring & Hibernate), but it turned out they had a special switch to turn on "normal" classloading.

See https://rome.dev.java.net/servlets/ReadMsg?list=dev&msgNo=2679 and https://rome.dev.java.net/servlets/ReadMsg?list=dev&msgNo=2680 for more on this.

Nick

> -----Original Message-----
> From: Chris Janicki [mailto:[e-mail]]
> Sent: Tuesday, 9 June 2009 1:51 AM
> To: Nick Lothian
> Subject: ROME and multiple classloaders
>
> Nick,
>
> Below is a copy of a message I just sent to the dev email list.  It
> addresses the same topic as your emails from last week, and also
> issue# 118.  (I just found those.)  Note, I suggest a fix below too...
>
> = = = =
>
> I think I'm about 2 years too late to comment on this, but
> unfortunately your fancy classloader footwork breaks my plug-in
> environment.
>
> https://rome.dev.java.net/servlets/ReadMsg?list=dev&msgNo=2414
>
>
> The problem is that my plug-ins have their own built-in classloader so
> they live in their private world, but with access to the default
> classloader when the private classloader can't resolve a request... a
> basic hierarchy system.  So when your code grabs the
> Thread.currentThread().getContextClassLoader(), it breaks out my
> sandbox with brute force, rather than following the hierarchy.  (I'm
> trying to include your jars in one of my plug-ins' classpath, so it is
> distinct from my main application... it would be inelegant to put your
> jars in my main application's classpath, although they might better
> work there.)
>
> I think I have a suggested fix that usually works for me, and maybe
> addresses your underlying need to tweak the classloaders in the first
> place (Disclaimer: I didn't quite understand the original impetus.).
>
> I usually create a Beacon.class (just an empty class that extends
> Object) in whatever package location contains my resources (e.g.
> *.properties files).  Then, I reference the Beacon's classloader,
> since I know it will have access to my resources residing in the same
> directory.  So:
>
> com.xxx.pkg.Beacon.class.getClassLoader().getResourceAsStream(...)
>
> I sometimes have several Beacon classes in different package
> directories.
>
> I think if you referenced your resources this way, you might be able
> to go back to your original version of the code, while still avoiding
> your previous headaches???
>
> Thanks,
>
> Chris Janicki
> 1-781-526-7033 (mobile)
> www.AugurSystems.com
>
>


IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]