On 2001.11.24 21:11:40 -0500 Anatoly Akkerman wrote:
> Hi,
>
> The bulk of this e-mail has been posted earlier on the topic of j2ee
> packaging and nobody but Scott replied to it. It shares some of the ideas
> with the author of this thread.
Thanks for reposting this, I meant to respond but got too busy and forgot.
>
> Here is what seems to be a better design that is consistent with JBoss
> philosophy. Please, don't flame, these are just ideas for discussion.
>
> Deploying anything is just giving 1 xml file to a deployer. No more
> multiple files (Richard mentioned that a few days ago, just use XML
> namespaces and whatever else is needed to glue the pieces together).
> From my prospective, though, it is important to separate classes from
> descriptors as well, more below.
This is contrary to all the j2ee specs, right? or do I misunderstand?
I think we need to keep standard j2ee dd as at least an option. My
understanding of this part of your proposal is that you want to be able to
embed (perhaps in a different namespace) all spec-required info
(ejb-jar.xml, ra.xml, etc etc) inside one super-jboss.xml, rather than
using the spec-suggested xml references.
>
> This single XML file has all the necessary information about the item
> being deployed:
>
> For services this would be whatever is now in jboss-service.xml
> For j2ee modules/applications the file would contain sections with
> standard j2ee metadata, jboss-specific metadata, jaws, whatever.
>
> And, I think the crucial part for all of the above , is the
> packaging/scoping information which specifies:
> 1) CL scoping for this deployable entity
definitely
> 2) any module-specific class library URLs
> 3) file archive URLs
I think these are supplied in *service.xml via the classpath elements?
>
> (This is very similar to what Dr. Jencks proposes with "deploy to
> scope" but points 2 and 3 may be somewhat new, don't know)
>
> Here is my look at it. CL Scoping is just a service that JBoss provides
> which ought to be configurable through standard means, i.e. XML
> descriptors, just like I can configure, say the interceptor stack for the
> container. No more 'implied' derivations of module dependencies from
> awkward MANIFEST.MF Class-Path: entries (though this can still be
> supported for modules which are packaged in the old-fashioned way).
>
>
> Scope:
> keeps scope-wise global (for Scope) class library repository
> libraries can be added to the scope/removed/updated
>
> Modules (services, applications, etc.):
> deployed in a scope
> specify libraries it depends on (from the Scope)
> additional libraries/ file archives needed for successful start
I was assuming all the jars/files/whatever would go to the
scope/application/virtual host classloader. Are you proposing further
subdividing the "classloader space" within a scope? If so, what does this
gain you?
>
> I want to be able to just give all the jar library URLs to my personal
> Scope and then deploy only the XML descriptors of j2ee modules.
>
> So, to accomplish this, in this new architecture, one might prepare
> ('deploy') a new Scope with whatever libraries he may want to use. (Say,
> by creating an xml files with the scope description and library URLs that
> need to be made available in this scope)
>
> Then deploy modules in that scope by just giving xml files describing
> these modules. It may also be important to include additional library /
> file archive URLs at module deploy time in that same xml file. For
> example
> when deploying a WAR, one would necessarily have to provide the WAR file
> archive with jsps, taglibs, whatever else which is not obtained through
> standard classloading mechanisms, so a URL of this archive can be placed
> into the xml.
>
> Nice things about this:
> - no hard coded xml descriptor names (like META-INF/ejb-jar.xml,
> WEB-INF/web.xml)
> - unified configuration of underlying services in one file
> - package libraries/classes whichever way you want just make them
>
> available to the underlying CL through scope definition or
> module description
> - no more messing with MANIFEST.MF, jarring/unjarring just
> to modify descriptors, yak...
>
> My current project would benefit tremendously in trimming down
> packaging/unpackaging complexity if this architecture was in place. Do
> others think this may be useful?
>
> A few days ago I just went ahead and put in minor modifications to the
> org.jboss.deployment.Installer on my personal system to be able to deploy
> libraries that have no descriptors. If I use Scoped deployer from Dr.
> Jung, everything works like a charm (meaning deploying a library and then
> deploying a jar that contains _only_ deployment descriptors). Ideally, as
> I meantioned earlier, I would just deploy a single XML file instead of
> packaging descriptors into jars, then ears, whatever. But for now this
> was
> also useful.
It seems to me that this scheme would be a minor modification to my
proposal to separate the "add stuff to scope classloader" and "process
deployment descriptor" phases. As I understand what you are suggesting it
is that one should be able to deploy any deployment descriptor
(jboss-service.xml, ejb-jar.xml, ra.xml, ....) by itself, into a scope,
outside of its j2ee mandated packaging.
How much overlap do you see between your suggestion of a all inclusive dd
and my suggestion of a deployment script facility?
The only thing I am not completely comfortable with about this is how to
specify the scope to deploy a j2ee dd into. Once it is deployed into a
scope, perhaps by a deployment script or from a reference from some other
jboss-specific dd, the autodeployer could do an undeploy/redeploy cycle
since the "undeploy" operation could return the list of scopes the dd was
deployed into, and redeploy the new version to all of them.
Perhaps if you gave a simple example of what kind of unified dd you are
thinking of it would focus my thoughts better.
thanks!
david jencks
(I'm not a dr, marc just thinks how I write is so convoluted I must be
one;-)
>
>
> -------------------------------------------------------------------------
> Anatoly Akkerman
> Computer Science Dept.
> Courant Institute of Mathematical Sciences, NYU
> 715 Broadway, #719 Tel: 212 998-3493
> New York, NY 10003 Fax: 212 995-4123
> -------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
