[jboss-cvs] jboss-cvs-commits Digest, Vol 42, Issue 123

David M. Lloyd david.lloyd at redhat.com
Thu Dec 10 11:55:22 EST 2009


(resending so that it sticks to the list)

On 12/10/2009 09:39 AM, Ales Justin wrote:
> This looks wrong, at least to me.
>
> Here are my concerns:
> (1) VFSHandleRegistry is complete VFS impl detail, and as such, doesn't
> belong to Deployers

It's actually a VFS deployer implementation detail.  VFS doesn't care about 
it at all.

> (2) like I already mentioned, StructureDeployer(s) might not even be invoked

That's fine.  Whoever creates the SMD will have the responsibility to 
register all deployment and classpath roots with the registry.

> (3) addition to (2a), this means each SD will have to include this mount
> code, which is very intrusive

It already includes code to add to the classpath, how is this any different?

> (4) addition to (2b), the next step are real deployers, where this code
> also doesn't belong -- I only wanna think about my logic in my deployer,
> nothing else

We're not touching real deployers.

> VFS3 looks a lot like what we did for previous Deployers (pre AS5),
> but there one deployer controlled it all, making such mount/unmount easy
> to add/handle.
> With "aspectized" deployers, and clean separation of user/dev/server
> view and structure/real handling and predetermined/vfs, this becomes
> harder to impl in such a straight way.

Indicates a design error to me.

> Apart from being very much intrusive and not actually finding proper
> place to mount, I only see auto-mounting as a solution.
> While DeploymentContext::cleanup is already a proper place to unmount.
>
> Well, this is all already being discussed on the forum and jboss-dev,
> but you're not listening to me at all ... just don't say I didn't warn
> you when we're gonna disagree on the actual inclusion of this into MC. ;-)

Please don't threaten.  It's not helpful.

- DML



More information about the jboss-cvs-commits mailing list