Sanity,

thanks professor seems you are on shore with me for once :)

|> Regardless, I'm going to work on the deployment layer to clean it up
|> and add support unarchived ears.
|
|I the likely case you get to this before I do, my goals for j2ee and other
|deployment are:
|
|
|- Unify the ServiceLibraries and the Scoped Classloader and always use the
|result.

correct.  I will do it if you don't.

|- Separate deployment into
|--autodeploy detection. This will watch directories and on timestamp change
|undeploy and redeploy.
|
|-Universal deployer. This will
|--determine which classloader to use (system (now ServiceLibraries) or
|application (now Scoped), but these should use the same code base).  This
|may turn into your idea of virtual host.

Yes, good how are you going to do that?

how about just moving the scl to sl? the only problem there is the ordering
of lookups which I think differs significantly but... we can look at using
one structure.  If we always set the SL as parent to teh scl then I don't
think we need to hint anything.

|--put all accessible classes from the packaging into the extensible
|classloader (I'd use extractPackages from DeployerMBeanSupport)

woot?  what is this?

|--Figure out what order to process the xml dd files, discovered in the
|previous step.
|--Feed the xml files to the appropriate deployers in the appropriate order.
|
|-individual deployers (Service, RAR, ContainerFactory, J2ee, etc)
|--these will now only process the (xml) dd.

yes, good

|-A new deployer for "deployment scripts" that basically contain an ordered
|list of other things that can be deployed.  Although in principal I think
|all dependencies should be stated explicitly, a script facility would allow
|deployment of units in a specified order rather than relying on the random
|order of detection by autodeployer.
|
|Any thoughts?

Excellent, some sanity finally, excellent professor, excellent.

|David Jencks

marcf
|>
|> ----- Original Message -----
|> From: "Rickard �berg" <[EMAIL PROTECTED]>
|> To: "Scott M Stark" <[EMAIL PROTECTED]>
|> Cc: <[EMAIL PROTECTED]>;
|> <[EMAIL PROTECTED]>
|> Sent: Wednesday, November 21, 2001 3:30 AM
|> Subject: Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott -
|> Optimised intra-container calls & ClassLoaders
|>
|>
|> > Scott M Stark wrote:
|> >
|> > > That is correct. The packaging required to run under a 2.2 servlet
|> container
|> > > is inconsistent with that required to run under a 2.3 container due
|> to
|> the
|> > > change in the web container class loader behavior. I see this with
|> Tomcat
|> > > 3.2.3
|> > > vs Tomcat 4.0. Really, the only time this shows up is for JSP pages
|> trying
|> > > to access EJBs.
|> >
|> >
|> > Well, *all* access from the web container to EJB's (i.e. servlets too)
|> > need to be aware of these changes. We ran into this the other day, and
|> > the fix was to bundle crimson.jar into our app too (i.e. not rely on it
|> > being available).
|> >
|> > Now, because of all this bundling going on, the EAR quickly grows HUGE,
|> > which means that for development you want hot-deploy on exploded EAR
|> > files. Unfortunately JBoss does not currently support that, so the
|> > cycling time becomes somewhat excessive. :-(
|> >
|> > /Rickard
|> >
|> > --
|> > Rickard �berg
|> >
|> >
|> > _______________________________________________
|> > 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
|>
|>
|
|------------------------ Yahoo! Groups Sponsor ---------------------~-->
|Universal Inkjet Refill Kit $29.95
|Refill any ink cartridge for less!
|Includes black and color ink.
|http://us.click.yahoo.com/XwUZwC/MkNDAA/ySSFAA/CefplB/TM
|---------------------------------------------------------------------~->
|
|For the latest information about Jetty, please see http://jetty.mortbay.
|
|Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
|
|


_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to