Hi, On Fri, 20 Sep 2002 10:38, Jason van Zyl wrote: > Could someone post a short summary of what pieces in excalibur are being > considered for use in Avalon 5? I'm plugging away at making a container > and I would like to use as many of the standard building blocks as I can > but I still do not have a very good grasp on what in excalibur is going > to be used for what.
Depends on exactly what sort of container you are building. Heres my take; * Extension: Basically manages JDK1.3+ "Optional Packages" or JDK1.2 "Extensions". These same extensions are being readily used in EJB/Servlet engines and would be great to be used in Avalon containers. While it is still "alpha" - it is fairly stable. We haven't made it beta because the stuff in excalibur.packagemanager.* will change it's API eventually (Essentially when we create a PackageManager that mirrors manages a large file directory we expect the API may change). BTW it would be great if Maven automagically generated these descriptors when created jars ... * Loader: Use it for complicated ClassLoader management. Is not yet completed but when it is it will be damn stable. I am unit testing it up the wazoo to make sure it works all good. Been bitten too many times in the past by ClassLoaders to not ;) Will be finished in 2 weeks or unless you want to help code it up ;) * Logger: Useful - but it offers a more developer centric view of logging systems. Eventually we will need to develope a more "admin" orientated system but we aren't there yet. * i18n: Stable - Use it. The above are all fairly fundamental stuff. The rest you can use or not use depending on what type of container you are writing. My recomendations * Monitor: Mostly stable. Maybe use it. Needs a complete refactoring though ... * MPool: Use it in preference to old pool stuff. * ContainerKit: Don't use it. The only stable concepts in it are the idea of separating info (type information) / metadata (instance information). The factory ideas are also fairly stable but interface will change (to add ServiceInfo). All the rest is junk code thats is being used to test/validate ideas. If you need or want anything from this project then copy-paste it into your own. * ThreadContext: Useful if you need to have separate isoalted application parts and also need to manage lots of thread-local variables. But one hell of a PITA thing to manipulate and together with ClassLoader stuff the most painful thing to work with. But then again if you need isolation then use it. * Baxter: Useful stuff if you need to use JMX. We actually need to back port a bunch of stuff from Phoenix into baxter. There is also Commons Modeller to look at aswell. * Info: Useful stuff but still not stable. If you want to do metadata then use it but realize it may change slightly in future. The things that will change; - ServiceInfo needs to be able to contain MethodDescriptor (and thus ParameterDescriptor) - ServiceInfo needs to be able to loaded from XML and so forth - Needs documentation of how we generate the descriptor from javadoc tags. - Needs unit tests for everything, especially generation of descriptors from xdoclet process * Interceptor: Not committed yet and wont be for a while. It will radiacally change the way we build containers. To the point where in many cases there will not need to be any new containers. Essentially we have 2 "flavours" of interceptor. One Intercepts invocations/method calls and can do similar stuff to EJB servers do. (ie Security, Transaction stuff) do stuff Avalon does (separate and fix thread contexts ala ContextClassLoader and friends), general things (log every method call) and do things that are fairly domain specific (charge someone 2c each time they invoke method). The other intercepts access/release calls to component. This Interceptor chain allows you to run components through their lifecycle and perform all sorts of sharing policys (pooled, created per request, etc), creation policys (facade for webservice, rmi service, EJB etc) and add all sorts of magic to lifecycle (ie bind component to RMI registry or as webservice or JMX, add instrumentation lifecycle, activate components on demand). I suspect after that is in place we will see a reduction in number of containers until the only difference is the arrangment of interceptors. Anyhow it is not in place now and probably wont be stable and complete for a while. So theres nothing to use now and depends upon the longevity you want for your container. If you want longevity then I would recomend that you build an interceptor based architecture. Of course that could be my desire for someone else to do the work talking ;) -- Cheers, Peter Donald --------------------------------------------------- Murphy's law - "Anything that can go wrong, will." (Actually, this is Finagle's law, which in itself shows that Finagle was right.) --------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
