See below.
On Sat, 24 Nov 2001, David Jencks wrote:
> 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?
>
Yes, this is not j2ee-spec compliant and I agree, we should also support
standard packaging as well, this is just in addition, for those who see
advantage in having flexible packaging.
> 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.
One file is purely a convenience, though a very useful one.
> >
> > 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?
Could very well be so, I have not looked into how *service.xml is
composed.
> >
> > (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?
Well, I don't know at the moment if having a tree of scopes is useful. I
have one scenario in mind where it may be useful, but don't know if this
is such a common issue. The case is like this:
Application Z uses 2 modules that introduce the following conflict:
module 1 uses a specific version of an off-the shelf package, say
org.exolab.castor v. X
module 2 uses a different version of the same
package. The apis, classes are incompatible, so they cannot be shared in
the same scope.
Using subscopes for each module would solve this issue.
Now, even forgetting about subscoping, having an ability to add libraries
at module deploy time in the module descriptor is useful in and of itself.
Presumably, the deployment script or the person who deploys the app would
deploy truly global libraries into the global scope _prior_ to deployment
of any descriptors. And then each module at descriptor deploy time can
specify any additional libraries that go into the scope. This preserves
the locality of configuration -- if a library is really local, i.e. for
this module only, I should be able to specify where it is and how to
access it through the module descriptor, not in an unrelated scope
definition file. Same thing goes for WAR files, such as jsps, htmls, jpgs,
which are packaged into a jar. This jar is really 'local' to the WAR
module, so the information about this jar's location should be in WARs
deployment descriptor.
see more below
>
> >
> > 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.
Exactly, we should have an ability to configure classloading separately
from deployment of descriptors. And yes, it would be nice to be able to
deploy just a descriptor outside its packaging.
>
> How much overlap do you see between your suggestion of a all inclusive dd
> and my suggestion of a deployment script facility?
>
I am not familiar with the deployment script facility you have proposed, I
would be very interested in seeing it. And it seems to me it is a great
idea. Descriptors are not expressive or convenient enough in specifying
the sequence of commands and events that should happen during
deployment/undeployment/redeployment. A scripting facility is a great
idea. And just note that being able to glue xmls together would buy you an
ability to glue pieces of scripts into the descriptors as well. These
scripts would do the necessary scope configuration, event handling,
library registration, whatever.
> 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.
>
In order to tie a descriptor to a scope one would either:
wrap the descriptor within a super-jboss.xml which specifies
scoping of this descriptor
or invoke the deployment of this dd into a scope (ala what
Dr. Jung's scoped deployer does now with archives).
>
> Perhaps if you gave a simple example of what kind of unified dd you are
> thinking of it would focus my thoughts better.
>
Let's say, I have an entity bean (CMP) I want to deploy. Currently I would
have to write 3 separate files ejb-jar.xml, jboss.xml and jaws.xml. Write
all the necessary classes, package this stuff together into a jar. In my
view of the system, the developer would glue all 3 xml files into one
file, say super-jboss.xml using namespaces, add an entry about
scoping and the classfiles JAR location. drop the descriptor into
scope. Or drop the jar with classfiles into scope and the simply deploy
the descriptor.
What this would get me, is that, say, I want to add another finder
method. I just modify and redeploy the descriptor, no need to touch the
classes, repackage, etc.
In general it would appear to me that most developers don't want to keep
track of which classes will a particular bean need when deployed. Just
build a library of all relevant project files. Write descriptors and let
JBoss take care of the rest.
In my project, I am trying to deploy large applications piecewise on
multiple servers. Keeping track of which libraries which module needs is
just too cumbersome, it is much easier to just deploy descriptors for the
pieces I need on top of preconfigured CL scope that has all the classes
availble for module deployments.
> 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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
