Hi, I am not sure that this would really be useful. A few reasons;
Using the "Services JAR specification" is really misusing it as it is meant to be a way to map implementations for services. Lifestyles are an artififical artefact that don't really need to be defined this way. ie It needs to be flexible enough to have lifestyles like "by default I am transient, between 3-6 on Friday I pool". It would be far better to try to write a flexible architecture rather than trying to gaffa tape one together out of components. On Sat, 23 Nov 2002 07:51, Berin Loritsch wrote: > I would like to propose a plan for starting the multi-tiered > container model. Keep in mind that what we had identified as > the #1 need for Avalon 5 is better container/component > contracts. So starting out with the basic needs for Avalon ME > (Micro Edition) we need to identify the requirements: > > * Small footprint (both JAR and memory) > * One container (no need for kernel/cli/etc) > * Works with J2ME > - Any suggestions on reference platform? > * Easy to test > * Easy to configure > * Follows core Avalon framework only > * No extensions supported (less complex) > * Minimal set of meta-info supported > * Uses Java's standard Services JAR specification to list > options for a service interface. > > We need to build on this foundation, and we can add to it. > > We are looking for a container that isn't much larger than > the Framework JAR. In fact, I would be happiest if it is > less than 100KB. > > As to the minimal set of meta-info, I suggest that we support > declared dependencies and name/version. The ME version has > to determine if it is permissible to have a global namespace > like ECM/Fortress, or if the namespace is scoped like Merlin/ > Phoenix. What would it take to do that? > > Support for ThreadSafe components is mandated, but support > for ThreadLocal components is permitted. As to pooled and > "factory" components I think the memory constraints rule them > out. For ME, lean and mean is the name of the game. > > I strongly suggest that we use the spec for JAR Services listed > here: > > "http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service Provider" > > for two reasons: > > 1) It is standard and well understood > 2) It is very simple to tool (we can borrow code from Batik > to do it). -- Cheers, Peter Donald -------------------------------------------- Beer is proof that God loves us and wants us to be happy. -- Benjamin Franklin -------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
