I am trying to deploy on JBoss 5.1 an application that correctly deploys and runs on JBoss 4.2.3.
Appart from obvious class loading configuration issues (we use parent-last policy, so the configuration must be altered, i.e. jboss-classloading.xml had to be created) I'm having trouble with class path scanning.
The problem is: I am unable to persuade JBoss 5.1 to unpack EAR into tmp dir and have classpath reference the unpacked files. Without this, i cannot create JarInputStream to read all files. I know about Snowdrop, but Snowdrop solves the problem in Spring and here the class path scanning is not done by Spring, it is done by application code.
my.ear - my.jar - com.example.Some.class - my.war [...]
When i do something like classLoader.getResources("com.example") it returns something like
What i would like to get is something like below, so that i can locate and read the jar by myself:
Is it somehow possible?
Why not use VFS for scanning?
If it's the case of having it working in other non-VFS envs,
simply create an abstraction, which checks if VFS is available,
if not, fall-back to non-VFS / jar scanning.
At least that's what I would do, or did for Facelets (for some support patch).
Getting a hold of tmp resources is even uglier, more impl details,
then having a simple and proper VFS impl, over some simple abstarction.
thanks for your reply. Apparently i can use VFS scanning indirectly, thanks to Snowdrop, like this:
This is great -- but this does not free me from detection code, as this method does not work on JBoss 4.2.3.
If there is indeed no other way to have portable code without "appserver IF-ing", then i will go for this. But i wish there was
|Retrieving data ...|