Jason Lee wrote:
> On Sat, Apr 26, 2008 at 9:18 PM, Tim Quinn <Timothy.Quinn_at_sun.com
> <mailto:Timothy.Quinn_at_sun.com>> wrote:
>
> In v3 each container is responsible for doing most of the work of
> deploying an app of that type. Yet the basic GF deployment
> framework needs to be able to tell which container to ask to
> deploy a given app, and it needs to do so without loading the
> candidate containers' modules and starting the candidate
> containers. This is where sniffers come in. All sniffers,
> regardless of the module type they might recognize, are checked
> during deployment. When a deployment request arrives, GF asks
> each sniffer it knows about whether it recognizes the type of the
> module being deployed. If so, the GF deployment framework
> delegates the work to the deployer corresponding to that module
> type. (Note that a given app might be recognized by more than one
> sniffer; for example, a given app might be recognized by both the
> EJB sniffer and the persistence sniffer.)
>
>
> OK, so if I understand this correctly, I'll need a Sniffer that
> recognizes the resource deployment file (which is just an XML
> document, according to the latest plan in my head :). It will tell
> the deployment framework which deployer to which to delegate, which I
> will also provide. Is that correct?
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.
>
> I think the deployment directory scanner is going to need to be fixed
> up so that it will recognize the .xml files, and not just the
> archives. It would be nice if there were an API to added acceptable
> file types to that. I don't think that would be too hard to, but I
> don't want to go running off half cocked, though I guess that's where
> code reviews come in. Since I don't have commit privs, someone
> "official" will have to be involved at some point...
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.
- Tim
>
>
> --
> 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