[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Alternative vfs jar implementation

[mstruk]

The first problem you encounter and it's a reaper issue :)

As far as VFS is concerned -DforceNoReaper=true should do the trick here.

Regarding NoClassDefFoundError, this looks to be an issue beyond VFS, I may not totally understand the issue but some ideas - off the bat ...

So the essence of the problem is that when a deployed archive is removed jboss learns about it after the fact, there can be no beforeRemove event where components could be undeployed, and lifecycle events processed while classes are still available. But if required classes have already been loaded then there should be no issue.

For well known deployment modules that are part of wider jbossAS infrastructure we can know in advance what classes are still required after file removal. Deployer could have a preload feature - where it reads some configuration that tells it - 'when you load this class, also load these classes'.

It's a relatively high-maintenance solution (having to determine all the dependencies and keeping them up-to-date), but it might be a reasonable best-of-both-worlds.

For unknown third party components - like user applications - I don't see any other way but to either (1) use jboss-4 style tmp copies as suggested or (2) preload all the classes in the archive - this one could be used for small archives. Or (3) if we can determine in advance that after file removal there will be no need for any additional classes (depending on component type maybe) then we don't have to do anything, but I'm not sure it's possible to reliably predict that.

Now, I have no idea how difficult this would be to implement :)

Cheers,

- marko

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155446#4155446

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155446