If you deploy a typical EAR, this won't save you a whole lot,
because the server itself will start darn fast, then try to deploy an app,
which loads the deployer, the web & EJB containers, DB pools, JNDI,
transactions, security, web connectors, "EJB connectors", and so on -- the
majority of available services. You may save the effort of JMS and J2CA,
depending on the app, but it's not the huge advantage that it initially
sounds like.
I think we'd get more mileage out of aggressively ensuring that
components start up quickly. You'd get a lot more (let's say) by ensuring
that all 20 components together start up in under a second that you would
by not starting the small number of them that an application required.
Aaron
On Sat, 9 Aug 2003, Jules Gosnell wrote:
> Jason,
>
> I followed pretty much the same though path as you have just outlined
> after posting - then I hung in there and thought some more :-)
>
> Yes it makes things more complex, however:
>
> In development, which is where we have already proven you need to
> capture hearts and minds first, startup time and footprint are
> important. You would be amazed how many people I have come across in my
> JBoss dealings who still have to do a lot of cold deployment... Besides
> as Geronimo developers, therefore the people who will be restarting it
> most, this would speed our own development cycle.
>
> J2EE decomposes nicely into a bunch of APIs javax.xxx.*. We just need a
> persistant registration service. The first time you run up Geronimo, all
> services start, declaring that e.g. they implement javax.naming or
> javax.servlet etc... (package granularity should be enough). Deployers
> also register their interest in e.g. WebContainer:war etc...
>
> These deps are saved away, and next time you start Geronimo, put to good
> use - the dependency tree is shaken out and only services required are
> loaded. This behaviour could be switchable, to load lazily in
> development and proactively in production.
>
> I was thinking that the ClassLoader could do something similar. Instead
> of sitting there watching hundreds of jars being loaded from
> server/x/lib, it could load the index that it saved from the last run
> and then load these classes lazily as and when required. Further startup
> time speedups...
>
> If you upgrade or add new services, jars, their presence would
> invalidate the relevant part of the cached dependency tree or index.
>
> Complex, yes, innovative and possibly valuable - yes.
>
> I don't want something like this to get in the way of getting a server
> out of the door ASAP, but I'd like it to be considered if anyone starts
> working, out on branch, on the ultimate plug-in component system for
> Geronimo services...
>
>
> What do you say :-)
>
>
> Jules
>
>
> Jason Dillon wrote:
>
> >> Imagine that rather than having a set number of configurations which
> >> all load every service at startup, Geronimo could load just the
> >> components needed to provide the services required by your
> >> deployables...
> >
> >
> > I like the concept, but I am not sure how easy this will be to
> > actually implement. To make something like this work, we would need
> > to load configuration metadata for everything on boot, so that we knew
> > what components we had to work with. I mean, how else would the
> > component container know which components it had to work with to start
> > the services required by the deployable?
> >
> >
> >> e.g. you are doing web development, so when you start Geronimo it
> >> just loads the webcontainer component and deploys your webapp. You
> >> webapp decides to load a javax.naming class so the JNDI service is
> >> brought on line, it loads a javax.mail class and looks up a mail
> >> service in JNDI - the mail service is brought up... etc
> >
> >
> > Sounds like a lot of complex magic inside to achieve lazy loading.
> >
> >
> >> If we could lazily load services as required, startup time would be
> >> greatly reduced, footprint as well, and the distributions complexity
> >> too - since we could just ship everything and only what was needed
> >> would be used.
> >
> >
> > Initial startup time may be reduced, but if an app requires JNDI,
> > JavaMail or whatever, then the time initialize these will not change,
> > we have just moved where that time is spent.
> >
> > I do like the concept, but I think this may not be feasible in the
> > short-term... though it would depend a lot on what we use for
> > component management I would say.
> >
> > Personally I do not believe that this buys us all that much. While
> > lazy loading may (or may not) be nice during development, in a
> > production environment I would rather have a slow startup where all of
> > my components are initialized and connected.
> >
> > On the other hand, if the component container had knowledge of the
> > available components/services, then was asked to deploy a web-app,
> > which requires a web-container, JNDI, whatever, then then container
> > could initialize and start these components automatically with out
> > having to explicitly list them as components to be started when the
> > server comes up.
> >
> > I think to make something like this work it would have to be done at a
> > component connection/dependency level and will depend much on the
> > component container we use or write.
> >
> > --jason
> >
>
>
>
