Doing some more debugging...

It *does* seem to affect the JarUtils.isArchive(...) call successfully, and 
JARStructure will match my .rails since, as the deployer says... "... ok - its 
an archive or at least pretending to be."

But it's still mapping to a FileHandler instead of a JarHandler


  | 19:47:57,193 DEBUG [RailsStructure] Determining structure for [EMAIL 
PROTECTED] context=file:/Users/bob/oddthesis/jboss/jdk1.6/jboss-5.0.0
  | .CR2/server/default/deploy/ 
real=file:/Users/bob/oddthesis/jboss/jdk1.6/jboss-5.0.0.CR2/server/default/deploy/oddthesis.rails]
  | 

and


  | 19:47:57,194 TRACE [JARStructure] ... ok - its an archive or at least 
pretending to be.
  | 19:47:57,194 TRACE [JARStructure] Added context [EMAIL PROTECTED] from 
oddthesis.rails
  | 19:47:57,194 TRACE [JARStructure] Added classpath entry  for 
oddthesis.rails from [EMAIL PROTECTED] context=file:/Users/bob/oddthesis/jbos
  | s/jdk1.6/jboss-5.0.0.CR2/server/default/deploy/ 
real=file:/Users/bob/oddthesis/jboss/jdk1.6/jboss-5.0.0.CR2/server/default/deploy/oddthesis.rails]
  | 

The JARStructure happily sets up the ContextInfo etc.

The RailsStructure fails though, since I go digging around in root.getChild( 
"config" ) to see if it *really* is a rails archive (similar to how 
JARStructure looks for META-INF/).  FileHandler's getChild(...) doesn't do the 
job.

If I remove my oddthesis.rails archive from deploy/, and then add it back, it 
*is* then recognized as a JAR archive from a VFS point-of-view, and then my 
RailsStructure matches it from the StructureDeployer point-of-view.


  | 20:11:06,310 DEBUG [RailsStructure] Determining structure for [EMAIL 
PROTECTED] context=file:/Users/bob/oddthesis/jboss/jdk1.6/jboss
  | -5.0.0.CR2/server/default/deploy/ 
real=file:/Users/bob/oddthesis/jboss/jdk1.6/jboss-5.0.0.CR2/server/default/deploy/oddthesis.rails]
  | 

So, to me, it seems like a timing issue.  The JarUtils.addJarSuffix(...) 
happens soon enough for JARStructure to see and use it, but *not* soon enough 
for the HDScanner/Profile/whatever that initially loads the deploy/ directory 
and constructs the VirtualFile/VFSContext from its children.

Your test is correct, but isn't quite testing the problem I'm seeing, I think.  

If the deploy/oddthesis.rails archive is present at boot, it's mis-handled.  If 
it's added *after* the system is fully booted, it is correctly handled with a 
JarHandler.

Is there some way to register the jar extension extra-early so that the deploy/ 
directory scanner has it when it's first scanned at boot time?

Thanks!

-Bob



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

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193206
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to