[jboss-as7-dev] Modularity is the spawn of Lucifer and a stinking donkey

Ales Justin ales.justin at gmail.com
Thu May 10 11:59:01 EDT 2012


Since I think it's exactly on the subject, I'll just ask you (David) here. :-)

> loader.  This mechanism (at least as of today) is going to vary 
> substantially from one runtime environment to another though.  Thus 
> being able to plug in to the process is critical [1].

CapeDwarf is using Infinispan to store some data.
We always wrap Cache usage with app's CL - cache::getAdvancedCache::with(cl).
So when that data is persisted (mashalled), it is app's CL / module that gets into serialized info.

But it cannot get deserialized:

Full stack-trace: http://pastebin.com/5SWvahNV

Caused by: org.jboss.modules.ModuleNotFoundException: deployment.29bc6d63-8cc8-4a4e-a626-94f3a9dca7ed.war:main
	at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:206) [jboss-modules.jar:1.1.2.GA]
	at org.jboss.marshalling.ModularClassResolver.resolveClass(ModularClassResolver.java:106)

The problem as you can see is that deployment module cannot be found by plain ModuleLoader,
but - I guess?- only by AS7' ServiceModuleLoader -- which has the deployment module info.

Do we already have such (based off ServiceML) ClassResolver?
If yes, why it's not used? 
As I don't see how apps that use Infinispan (EDG?) can work w/o it (aka not having the same problem).

-Ales

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20120510/f9ae1eab/attachment.html 


More information about the jboss-as7-dev mailing list