On Tue, Apr 29, 2008 at 1:23 PM, Tim Quinn <Timothy.Quinn_at_sun.com> wrote:
> Basically, yes. It might help for you to take a look at the existing web
> module-related classes in v3 and see how they work together to accomplish
> this.
>
That's what I'm doing. ;)
>
> Actually, because the v3 autodeployer has no idea what an autodeployed
> module might look like - a JAR file, an EAR, an XML file, etc. - because
> module types can be added and removed at any time, it simply detects new
> files that have been placed in the autodeploy directory, existing ones that
> have been updated, or old ones that have been removed. It then delegates to
> the same implementation of the deployment, redeployment, or undeployment
> functionality that the rest of v3 uses, regardless of how the
> [re|un]deployment was triggered. It is that logic which polls the available
> sniffers to see if any recognizes the new file, etc.
>
> No changes at all should be necessary to the autodeployer as new module
> types come and go.
>
OK. Let me do some more code reading. Somewhere in there, though, is code
that makes sure the file is an ear, war, jar, or rar before continuing, and
another part to make sure the archive is valid (iirc, to catch the instances
where the file upload/copy is not yet complete). It's possible, though,
that I'm digging in the wrong place. Let me dig up that class and I'll get
back with you...
--
Jason Lee, SCJP
Software Architect -- Objectstream, Inc.
Mojarra and Mojarra Scales Dev Team
https://mojarra.dev.java.net
https://scales.dev.java.net
http://blogs.steeplesoft.com