Alternate .war deployment

[alesj]

"BobMcWhirter" wrote:

Hiya Guys--

As ya know, I'm working on deploying Rails apps on JBossAS. At this point, my RailsDeployer constructs a synthetic VirtualFile, stitching together a .war from a Rails directory and a generated web.xml. (VFS is one freakin' cool project, very nice!)

It then sends it to the MainDeployer during the REAL deployment stage and calls process().

It seems that I lose the link between the deploy/myapp.rails (my deployable file, which is just a pointer to a Rails app directory elsewhere) and the synthetic .war I created.

And I keep seeing the nifty WebMetaData and JBossWebMetaData, but I'm not using any of.

My initial thought was to have my RailsDeployer construct a WebMetaData, which WARStructure or TomcatDeployer could pick up and run with. By handing a virgin VirtualFile tree to the MainDeployer, I feel like I'm perhaps missing out on some cool MC functionality, and not having all the control over the classpath etc that I'd like to have.

I know Newton's still working on the guides, etc, but was hoping y'all could give me a pointer or two.

So, my questions...

1) Am I off-base thinking that the RailsDeployer could/should create a WebMetaData, for consumption by the typical .war deployer already baked into AS5?

2) If I can create a WebMetaData, what stage should it occur? My RailsDeployer basically parses a deploy/myapp.rails file, and I've tried the PARSE stage.

3) If I should create a WebMetaData, should I attach it as an attachment to the VFSDeploymentUnit my RailsDeployer is handed?

4) Can you point to information about classpath semantics between deployers and things-they-deploy? My jboss-rails.deployer deployer jarfile contains a jruby.jar, which I'd like to be available to anything it deploys. I was hoping I could provide it (and other jars) via the MetaData. This is one of the bits I feel I'm missing by calling MainDeployer.deploy(...) and process() directly, instead of using the MetaData functionality.

[alesj]

"BobMcWhirter" wrote:

1) Am I off-base thinking that the RailsDeployer could/should create a WebMetaData, for consumption by the typical .war deployer already baked into AS5?

That's one way of doing it.
You can either pick-up the WMD we already create
and fill it with your info.
Or you can have Rails predetermined WMD
and then check what exactly we do with merging.

"BobMcWhirter" wrote:

2) If I can create a WebMetaData, what stage should it occur? My RailsDeployer basically parses a deploy/myapp.rails file, and I've tried the PARSE stage.

As long as it's soon enough.
Dunno what soon enough is in your case.
But definitely before WMD get's used in REAL stage. ;-)

"BobMcWhirter" wrote:

3) If I should create a WebMetaData, should I attach it as an attachment to the VFSDeploymentUnit my RailsDeployer is handed?

Yes.
But, like I already said, you have different scopes of attachments.
Pick the one that suites your purpose best.
e.g. predetermined, transient, transient-managed, ...

"BobMcWhirter" wrote:

4) Can you point to information about classpath semantics between deployers and things-they-deploy? My jboss-rails.deployer deployer jarfile contains a jruby.jar, which I'd like to be available to anything it deploys. I was hoping I could provide it (and other jars) via the MetaData. This is one of the bits I feel I'm missing by calling MainDeployer.deploy(...) and process() directly, instead of using the MetaData functionality.

This looks to me like Seam-int functionality I just did:
- http://anonsvn.jboss.org/repos/jbossas/projects/jboss-seam-int/trunk/microcontainer/src/main/java/org/jboss/seam/integration/microcontainer/deployers/SeamUrlIntegrationDeployer.java

[bob.mcwhirter]

"alesj" wrote:

"BobMcWhirter" wrote:

3) If I should create a WebMetaData, should I attach it as an attachment to the VFSDeploymentUnit my RailsDeployer is handed?

Yes.
But, like I already said, you have different scopes of attachments.
Pick the one that suites your purpose best.
e.g. predetermined, transient, transient-managed, ...

Much appreciated, Ales--

At this point, my web.xml is super-easy, and my code just programmatically assembles it. I also an building a ClassLoadingMetaData (well, a VFSClassLoaderFactory...), and have setOutput( ClassLoaderingMetaData.class ). I'm figuring (?) that's how I setup my effective classpath for the deployed web-app, and it's there I can jack in my paths to jruby.jar and friends. That sound about right?

For the scope of attachments... got a pointer for the differences?

Thanks!

-Bob

[alesj]

"bob.mcwhirter" wrote:

At this point, my web.xml is super-easy, and my code just programmatically assembles it.

Does this mean you're assembling WMD or web.xml?
I guess WMD should do it.

"bob.mcwhirter" wrote:

I also an building a ClassLoadingMetaData (well, a VFSClassLoaderFactory...), and have setOutput( ClassLoaderingMetaData.class ). I'm figuring (?) that's how I setup my effective classpath for the deployed web-app, and it's there I can jack in my paths to jruby.jar and friends. That sound about right?

Yup.
It's the CL deployers that pick this up.
Or you can hack something up, like I do it in my Seam-int.
e.g. adding custom jar if deployment is Seam app

"bob.mcwhirter" wrote:

For the scope of attachments... got a pointer for the differences?

Not really. :-)
Basic point is that some attachments are available to client,
some are just server side info, e.g. temp info passing around.

[bob.mcwhirter]

"alesj" wrote:

"bob.mcwhirter" wrote:

At this point, my web.xml is super-easy, and my code just programmatically assembles it.

Does this mean you're assembling WMD or web.xml?
I guess WMD should do it.

Yes, a WebMetaData is what I'm building, not a web.xml file.

"alesj" wrote:

Yup.
It's the CL deployers that pick this up.
Or you can hack something up, like I do it in my Seam-int.
e.g. adding custom jar if deployment is Seam app

Those exist by default, looking for any CLMD to deploy into my unit? I noticed an explicit WarClassLoaderDeployer in the codebase. Was not sure if I needed to mirror that for my own, or if I can count on a standard CLDeployer in the mix with the 'default' config.

"alesj" wrote:

"bob.mcwhirter" wrote:

For the scope of attachments... got a pointer for the differences?

Not really. :-)
Basic point is that some attachments are available to client,
some are just server side info, e.g. temp info passing around.

unit.addAttachment( WebMetaData.class, md);

That should ultimately be visible to the kernel to act upon?

Thanks muchly,

-Bob

[alesj]

"bob.mcwhirter" wrote:

Those exist by default, looking for any CLMD to deploy into my unit? I noticed an explicit WarClassLoaderDeployer in the codebase. Was not sure if I needed to mirror that for my own, or if I can count on a standard CLDeployer in the mix with the 'default' config.

There is ClassLoadingDefaultDeployer that creates 'empty' CLMD, if there is none.

For WCLD, I don't have enough info to know if you should mirror that.
But most of the times it's about providing right CL metadata
as we tried to do it as flexible as possible - to avoid n different CL deployers impls. ;-)

"bob.mcwhirter" wrote:

unit.addAttachment( WebMetaData.class, md);

That should ultimately be visible to the kernel to act upon?

Kernel?
It's one of the deployers that should pick it up and act upon it.
And kernel can be injected into deployers,
as MC eats it's own dog food. :-)