[alrubinger]

Realtime discussion:

(04:10:23 PM) ALR@MSN: About ShrinkWrapDeployer: let me ask you:
(04:10:30 PM) Ales: shoot
(04:10:35 PM) ALR@MSN: Where's the component that bridges VFS inputs to the Deployers ?
(04:10:47 PM) Ales: vfs inputs?
(04:10:51 PM) ALR@MSN: VirtualFile.
(04:10:55 PM) ALR@MSN: How do you deploy one?
(04:11:07 PM) Ales: VFSDeployment extends Deployment
(04:11:17 PM) ALR@MSN: Right.  Where does VFSDeployment live?
(04:11:27 PM) Ales: jboss-deployers-vfs-spi
(04:11:42 PM) ALR@MSN: Where should the component that bridges SW Archive inputs to Deployers be?
(04:12:02 PM) Ales: hmmm ...
(04:12:13 PM) ALR@MSN: Say it.
(04:12:16 PM) Ales: hehe
(04:12:16 PM) ALR@MSN: jboss-deployers-shrinkwrap. ;D
(04:12:19 PM) Ales: hmmmm ...
(04:12:21 PM) Ales: nope
(04:12:24 PM) ALR@MSN: Hahahahaha!
(04:12:33 PM) Ales: vfs spi is really a spi ... and it has actual impl
(04:12:45 PM) Ales: whereas your sw stuff is wrapper/facade
(04:12:50 PM) ALR@MSN: ShrinkWrapDeployers is just an impl.
(04:12:56 PM) ALR@MSN: The SPI part is yes, a wrapper.
(04:13:03 PM) ALR@MSN: But there's only one reason why:
(04:13:21 PM) ALR@MSN: I need to mount and unmount archives as VFS alongside the deployment/undeployment process
(04:13:36 PM) ALR@MSN: So I can't make the equivalent of VFSDeploymentFactory and call it a day.
(04:13:45 PM) Ales: true
(04:13:48 PM) ALR@MSN: On undeploy we need to unmount.
(04:14:18 PM) Ales: your SW is just another api for VFS
(04:14:27 PM) ALR@MSN: Correct.
(04:14:32 PM) Ales: hence it's a wrapper/facade
(04:14:39 PM) ALR@MSN: Well, no.
(04:14:45 PM) ALR@MSN: SW doesn't wrap VFS.
(04:14:47 PM) Ales: if we didn't have vfs, then I would say yes, put it into deployers
(04:14:51 PM) Ales: but we a;ready have vfs
(04:14:53 PM) ALR@MSN: We have, however, a VFS adaptor
(04:15:17 PM) Ales: yeah, you need to adapt Archive to VFSDeployment
(04:15:27 PM) ALR@MSN: Right.
(04:15:34 PM) Ales: == facade
(04:15:44 PM) ALR@MSN: And if not for the unmounting, I could do it the same way as in VFSDeploymentFactory
(04:15:58 PM) ALR@MSN: With no new deploy/undeploy APIs.
(04:16:18 PM) Ales: why's that?
(04:16:33 PM) Ales: why is mounting/unmoounting an issue?
(04:16:37 PM) ALR@MSN: VFSDeployment deployment = ShrinkWrapDeploymentFactory.createDeployment(archive); // Easy
(04:16:49 PM) ALR@MSN: Because I need to mount it using a ShrinkWrap extension.
(04:16:58 PM) ALR@MSN: ArchiveFileSystem.
(04:17:10 PM) ALR@MSN: Which is what enables VFS to read SW
(04:17:41 PM) ALR@MSN: You guys do inspection to mountReal or mountJar or something.
(04:17:47 PM) Ales: aha, so when asked if it's already mounted, it says true
(04:17:54 PM) Ales: hence it doesn't do mounting
(04:18:01 PM) ALR@MSN: "it"?
(04:18:17 PM) Ales: mounting mechanism inside deployers
(04:18:21 PM) ALR@MSN: After it comes into MainDeployer, nothing will mount it, yes.
(04:18:32 PM) ALR@MSN: We mount.
(04:18:56 PM) Ales: if you didn't?
(04:19:06 PM) ALR@MSN: Then something in deployers would need to.
(04:19:10 PM) Ales: i guess structiure deployers would try and fail?
(04:19:14 PM) ALR@MSN: And unmount it when undeployed.
(04:19:26 PM) ALR@MSN: Right.  getChildren would return nothing.
(04:19:31 PM) Ales: no
(04:19:53 PM) Ales: see AbstractVFSArchiveStructureDeployer
(04:20:57 PM) ALR@MSN: http://fisheye.jboss.org/browse/JBossAS/projects/jboss-deployers/trunk/deployers-vfs/src/main/java/org/jboss/deployers/vfs/plugins/structure/AbstractVFSArchiveStructureDeployer.java?r=101137
(04:21:01 PM) ALR@MSN: So why "no"?
(04:21:50 PM) Ales: it would try to mount
(04:21:53 PM) Ales: and probably fail
(04:21:55 PM) Ales: or not?
(04:21:58 PM) ALR@MSN: Oh, right
(04:22:05 PM) ALR@MSN: Because it'd be using the wrong FileSystem.
(04:22:09 PM) Ales: yes
(04:22:47 PM) ALR@MSN: I have no qualms with removing the wrapper API
(04:22:59 PM) ALR@MSN: If you wanna make structure deployers figure out how to mount it properly
(04:22:59 PM) Ales: perhaps this should made possible
(04:23:04 PM) Ales: yes
(04:23:05 PM) Ales: exactly
(04:23:10 PM) ALR@MSN: But I assumed you didn't wanna back that logic in.
(04:23:21 PM) Ales: didn't think of that
(04:23:41 PM) Ales: how would we recognize which FS we need to mount?
(04:23:43 PM) Ales: hmmm ...
(04:23:45 PM) ALR@MSN: No idea.
(04:23:48 PM) Ales: :-)
(04:24:07 PM) ALR@MSN: VirtualFile is just a pointer.
(04:24:15 PM) ALR@MSN: You'd have to rely on exceptions for flow control.
(04:24:25 PM) ALR@MSN: ie. try and catch the exception if it's not a SW archive.
(04:24:33 PM) ALR@MSN: Which is no good solution.
(04:25:07 PM) Ales: i'll think about it a bit

[johnbailey]

ALR and I discussed this a couple weeks ago.  One thought I had was to change the flow of the deployers to better handle/fit the VFS mounting model.  This was also discussed during the VFS3 integration work.  It would be ideal if the structure deployers were not forced to execute prior to invoking the rest of the deployers, but rather functioned as any other deployer based on inputs/outputs.  The idea was to initiate the deployment with some specific metadata that describes deployment (file, directory, SWArchive, etc..).  There would then be a series of deployers which look for these specific metadata types and would invoke the proper VFS mount/unmount operations for the deployment.  Once the mount is performed, there would be an output that could be attached to inform the structure deployer to get fired.  The structure deployes would get fired and the process would continue its normal flow.

The key change is to align the structure deployers with the Deployer API and actually have deploy and undeploy operations.  Then you can introduce deployers in front of structure determination to handle proper mounting.  With this change, all that would be needed to integrate the ShrinkWrap Archive deployment would be to create the deployment (in embedded, TorqueBox, etc.) with an attachment that would cause a special mounting deployer to pick up and mount the ArchiveFileSystem as apposed to the normal filesystem based mounting deployers.

I realize this is a bit larger change than is being discussed with regard to the SW archives, but it also seems like it would better support the mount operations.  Best of all, it would get rid of the Automounter.

[alesj]

The idea was to initiate the deployment with some specific metadata that describes deployment (file, directory, SWArchive, etc..).  There would then be a series of deployers which look for these specific metadata types and would invoke the proper VFS mount/unmount operations for the deployment.

What you're describing is all already there.

* StructureMetaData -- perhaps all it's missing is some more exact deployment type info (file, dir, ...)

* jboss-structure.xml -- again, perhaps some more info on the type

But why exactly do you need this?

But who would provide this? If it's not pre-determined, then we need to figure this out.

And that's exactly why we have structure deployers.

Imo, the structure deployer are the only one's who know where and how to (un)mount things.

As they are the only one's that (should) understand the deployment structure.

With this, I already see some inconsistency; e.g. we do mounting in VFSClassLoaderClassPathDeployer [1].

This mean we're doing some things twice; e.g. 1st mounting war's libs, then doing this again for [1]

But I guess this is a workaround for dynamically added classpath entries?

Meaning we should be able to force people to do this themselves, hence it wouldn't be needed in [1], right?

The key change is to align the structure deployers with the Deployer API and actually have deploy and undeploy operations. 

Agreed, but this is big spi change, hence it will have to wait till v3.0.

And like you said, it will help us remove Automounter.

Then you can introduce deployers in front of structure determination to handle proper mounting.  With this change, all that would be needed to integrate the ShrinkWrap Archive deployment would be to create the deployment (in embedded, TorqueBox, etc.) with an attachment that would cause a special mounting deployer to pick up and mount the ArchiveFileSystem as apposed to the normal filesystem based mounting deployers.

You can already do this -- perhaps we cound only extend StructureContext to keep the ref to (VFS)Deployment.

e.g.

* add new structure deployer SWRP, before any other -> relative order < 0

* the root or our mounting point has unique suffix; e.g. root.swrp

* we then recognize this root in our SWRP, and properly mount it

[alrubinger]

Regardless of how we impl (either do our own mounting/unmounting or delegate to StructuralDeployers), I like the simplified API wrapper for ease-of-use.  Therefore that part can sit as a ShrinkWrap/VDF extension:

https://jira.jboss.org/jira/browse/SHRINKWRAP-167

S,

ALR