Alternative JAR extensions

[bob.mcwhirter]

I've started working on my RailsStructure structure deployer again.

I'm hoping to deploy "myapp.rails" which is just a JAR archive with a magical extension of ".rails".

I've found that if I modify conf/deployers.xml and add

<value>.rails</value>

to the JARStructure, then my .rails archives are recognized as vfszip files, correctly.

If my RailsStructure calls the underlying JarUtils.addJarSuffix( ".rails" ) in its own constructor, though, it fails to recognize my .rails file as a Jar, and ends up with a FileHandler handling it, instead of a JarHandler.

public RailsStructure() {
 setRelativeOrder( -10000 );
 JarUtils.addJarSuffix( ".rails" );
}

I've also attempted to do the install callback against JARStructure, with my RailsStructure implementing JarExtensionProvider.

public String getJarExtension() {
 return ".rails";
}

<install bean="JARStructure" method="addJarExtension">
 <parameter>
 <this/>
 </parameter>
</install>
<uninstall bean="JARStructure" method="removeJarExtension">
 <parameter>
 <this/>
 </parameter>
</uninstall>

This also results in failure.

I'd like to not have to have edits to deployers.xml, as that breaks the self-contained-ness of my deployer. But I seem otherwise unable to get ".rails" added as a vfszip-handleable type.

Any pointers would be appreciated.

Thanks!

-Bob

[alesj]

Weird, we've added JarExtensionProvider (JEP) for exactly this reason.

We usually have parser deployers that implement this interface.
e.g. BeanDeployer --> -beans.xml + JEP .beans (old extension)

I'll have a look, although I remember adding test for it.

btw: no need for install, as JEP is contextually injected via callbacks into JARStructure ;-)

[alesj]

"alesj" wrote:

I'll have a look, although I remember adding test for it.

- http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-vfs/src/test/java/org/jboss/test/deployers/vfs/matchers/test/JarExtensionsTestCase.java

[bob.mcwhirter]

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 FileHandler@382560742[path=oddthesis.rails 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 org.jboss.deployers.vfs.spi.structure.StructureContext@7e386bc from oddthesis.rails
19:47:57,194 TRACE [JARStructure] Added classpath entry for oddthesis.rails from FileHandler@382560742[path=oddthesis.rails 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 DelegatingHandler@476923950[path=oddthesis.rails 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

[alesj]

"bob.mcwhirter" wrote:

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.

Aha, you're right.
If the .rails is not there soon enough it will fallback to FileSystemContext.

"bob.mcwhirter" wrote:

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?

If you mark one of your deployers as JarExtensionProvider
+ you put your deployers into deployers directory (the proper way)
you should be fine, as deployers are booted before deploy is scanned.
--> different boot phases: BOOTSTRAP, DEPLOYERS, APPLICATIONS

[bob.mcwhirter]

If you mark one of your deployers as JarExtensionProvider

My RailsStructure deployer implements JEP. Additionally, I've added setJarExtension( ".rails" ) on one of my parsing deployers (seems like a weird place for it, honestly), since AbstractParsingDeployerWithOutput implements JEP, too. Both result in the same FileHandler'ing of my oddthesis.rails JAR, instead of the DelegatingHandler/JarHandler.

+ you put your deployers into deployers directory (the proper way)

Yah, I've been using deployers/ always to deploy the jboss-rails.deployer itself.

you should be fine, as deployers are booted before deploy is scanned.
--> different boot phases: BOOTSTRAP, DEPLOYERS, APPLICATIONS

Yah, that's what I figured the code told me, but it still seems that boot-scan doesn't enable the .rails in time for the VFSContextFactory bits, even for deploy/ but subsequent scans do.

I'm going to keep poking, and I'll update here.

Thanks,

-Bob

[alesj]

"bob.mcwhirter" wrote:

My RailsStructure deployer implements JEP. Additionally, I've added setJarExtension( ".rails" ) on one of my parsing deployers (seems like a weird place for it, honestly),

This mostly comes from our legacy usage.
e.g. -beans.xml was packed as .beans
my SpringDeployer expected .spring + -spring.xml.

"bob.mcwhirter" wrote:

Yah, that's what I figured the code told me, but it still seems that boot-scan doesn't enable the .rails in time for the VFSContextFactory bits, even for deploy/ but subsequent scans do.

Hmmm, could be that getChildren is called to soon on deploy/.

I'll check tomorrow (just downloading IDEA 8.0.1 :-)
or if you dig up something while poking.

[bob.mcwhirter]

So, a quick analysis might confirm your suspicions of HDScanner doing the scan() "too soon". I may be confused, of course, but here's my amateur analysis...

While HDScanner itself is a BOOTSTRAP bean, I assume it gets completely start()'d and running before the DEPLOYER phase.

When start()'d, it scan()'s. Conceivably scanning deploy/ for APPLICATION before all deployers have been deployed. Hence getChildren(...) on deploy/ not being enabled to view .rails archives as vfszips. Maybe. :)

Looking at my log timestamps, I see...

16:11:20,978 TRACE [HDScanner] Begin deployment scan

Then a while later (5 seconds), my log indicates the JEP installation from my deployer in the deployers/ directory.

16:11:25,860 INFO [RailsStructure] getJarExtension()...

I don't know the implementation of the solution, but seems like some barrier on the start()/scan() of HDScanner to hold it until the DEPLOYER phase is completely completed, perhaps.

For now, I can just use ".jar" as an extension.

Thanks,

-Bob

[alesj]

"bob.mcwhirter" wrote:

While HDScanner itself is a BOOTSTRAP bean, I assume it gets completely start()'d and running before the DEPLOYER phase.

Not any more, it's part of deploy/ now (build trunk).
- http://anonsvn.jboss.org/repos/jbossas/trunk/profileservice/src/resources/hdscanner-jboss-beans.xml

[bob.mcwhirter]

Not any more, it's part of deploy/ now (build trunk).

Okay, I'm still on CR2 at this point. With the move from conf/profile.xml to deploy/... should cause the ordering to be happier, as I understand it.

Thanks for the follow-up. I'll use .jar as an extension with appropriate content introspection to identify my rails deployments for now. I don't want to be dependent on a build from SVN, since I'm hoping other people will use all of this, too.

Or I may try to locate some nightly builds. Or wait for GA.

Thanks!

-Bob

[bob.mcwhirter]

Okay, I gave this morning's nightly build a try, and I'm still seeing a timing issue between my JEP and the deployment scan. But the problem has moved.

But first, congrats on making the nightlies boot up much much faster than CR2 even. That's very pleasant.

Now my analysis...

The HDScanner in deploy/ helps, as it doesn't seem to trip over the .rails archive before it's recognizable as a vfszip.

But there's still conf/bootstrap/profile.xml setting up and starting a VFSDeploymentScanner, which has inherited the scanning-deploy-too-soon issue I saw the other day with HDScanner.

This non-hotdeploy, boot-time scan grabs myapp.rails with a FileHandler before my deployer has had its JEP triggered.

It's still a bootstrap scanner iterating deploy/'s children before deployers/ has been fully install, I think. Having scan() wait at a barrier of some sort until the DEPLOYERS phase is complete would seem a possible solution.

Thoughts?

-Bob

[alesj]

"bob.mcwhirter" wrote:

It's still a bootstrap scanner iterating deploy/'s children before deployers/ has been fully install, I think. Having scan() wait at a barrier of some sort until the DEPLOYERS phase is complete would seem a possible solution.

So, if I understand this correctly,
we have another 1-time-only boot scan.
And it's before DEPLOYERS phase?

I need to check this, as it's clearly wrong,
for obvious reasons - for one this suffix case.

[bob.mcwhirter]

I may be wrong in that analysis, looking further. I'd assumed conf/ is recursively loaded.

bootstrap.xml does not directly reference the bootstrap/profile.xml any more. There's a bootstrap-minimal.xml and bootstrap-norepo.xml that do reference it though.

If the VFSDeploymentScanner isn't actually being used (I'll check in my logs in a minute), then I don't know what the problem is. But I'm still seeing the problem.

And something is causing deploy/myapp.rails to go through structure recognition before HDScanner does its first run. Structure recognition is coming after my JEP installation.

But I'm still ending up with a FileHandler'd archive if myapp.rails is in deploy/ at boot time, but getting a correctly handled vfszip if HDScanner picks it up post-boot.

I'll keep digging.

[starksm64]

The hotdeployment scanner initialization has been moved to deploy/hdscanner-jboss-beans.xml, so it cannot be deploying anything before the deployers are initialized.

The profile service that is loaded by default now is the conf/bootstrap/profile-repository.xml. It is doing a rebuild of the structure metadata when it loads admin edits, so that must be causing this.

[bob.mcwhirter]

Scott--

Thanks for the response. Is this something fixable? By GA?

Or is there some work-around you can think of?

Thanks,

-Bob