Hi,

I may not totally understand the situation, but if shutting down Felix properly resolves the issue, then it is clear you should be doing that. It is always a good idea to properly shutdown the framework, otherwise threads will possibly hang around and it won't ever get garbage collected.

Yes, i agree (of course). I will do that eventually, but currently the main focus is to get a prototype running and ear's don't have nice hooks that enable you to shutdown properly (well, not yet in ejb 3.0 that is...).

Regarding the NCDFE, perhaps this is a JBoss thing were it disables the class loader of its web apps after the are undeployed. The Felix framework does not have any control over how its own classes are loaded, they are usually set up for it on the application class loader or in this case on the container class loader.

Yes, that is clear. What surprised me is that some classes were found (org.apache.felix.framework.Felix), but others were not (org/apache/ felix/framework/FilterImpl), while they are in the same package and in the same archive, and the (loading of the) second is triggered by the first. I checked the Felix source, and there is no special classloading going on right there, it's just "new FilterImpl(...)", which - in my (limited) understanding of classloading means that the FilterImpl class is loaded by the same class that loaded the calling class ("Felix"), right? I can image JBoss doing "smart" things when an ear (classloader) is discarded, but than i'd expect problems only when switching from one classloader to another.... I was just hoping that someone could give me a clue, why such errors (can) occur, but well, don't bother too much, we'll fix the shutdown issue shortly i guess...

Thanks anyway.
Regards,
Peter




-> richard

On 5/6/09 10:36 AM, Peter Doornbosch wrote:
Follow up:

When i shutdown the framework before undeploy, it works fine.
I would assume that JBoss discards the old classloader / creates a new
classloader when i redeploy the ear, especially since we use the
classloader-per-ear configuration (not the JBoss default).

Regards,
Peter.


2009/5/6 Peter Doornbosch<[email protected]>


Hi,

I'm running Felix (1.6.0) embedded in an ear that is deployed in JBoss. Was
quite easy, works like charm, compliments for you guys!

Now i'm running in an issue that i don't understand when i hot- deploy the
ear.
Here is the case.
When I autostart Felix with only the shell bundle and the remote shell bundle, everything works fine. Hot deploy of the ear works without problem
(although i should add that during undeploy of the ear, felix is not
shutdown (shutted-down? shutdowned? ;-)), which for example leads to a bindexception when the remote shell is started - but apart from that it
works fine).

But... When I autostart Felix with these bundles and the fileinstall
bundle, the hot deploy results in the following error (note that the initial
startup works fine):

java.lang.NoClassDefFoundError: org/apache/felix/framework/ FilterImpl at org.apache.felix.framework.Felix.addServiceListener(Felix.java:2434)
    at
org .apache .felix .framework .BundleContextImpl.addServiceListener(BundleContextImpl.java:203) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:270) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:235) at org.apache.felix.fileinstall.FileInstall.start(FileInstall.java:51)

And the same for the other two bundles, e.g.

java.lang.NoClassDefFoundError: org/apache/felix/framework/ FilterImpl at org.apache.felix.framework.Felix.addServiceListener(Felix.java:2434)
    at
org .apache .felix .framework .BundleContextImpl.addServiceListener(BundleContextImpl.java:203) at org.apache.felix.shell.impl.Activator.start(Activator.java: 66)

I don't have a clue, something weird is happening here.
Maybe it is related to the fact that felix is not properly shutdown before
the redeploy? (i will try to test that scenario right away)
Any ideas?

Regards
Peter







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

Reply via email to