Hi, I just read through and digested this and I like it. Would you consider turning this into an XML document that we can stick on the avalon site somewhere ?
On Mon, 1 Apr 2002 17:28, Bernhard Huber wrote: > hi > > i was following the discussion AvalonJ2EE, as > i see some benefits using the avalon component framework > in an ejb environment. > The ejb would should designed in coarse grained fashion. > In contrast Avalon components could be designed a bit > more fine-grained. > Moreover it should be possible to use the Avalon components > in a servlet environment, or in some other environment, too. > > As the EJB are implemented using avalon components, the components > could be JUnit tested and used indepent from the EJB framework. > > Thus it might be possible to reuse the JUnit test in some JMX > framework to provide some continouse testing. > > Last as avalon components should not be too visible i > would suggest to use some delegate approach. As it was > suggested by Peter and the AvalonEJBFrame. > > For example: > UseCase is some OrderManagement. OrderData of this > OrderManagerment is gathered by an servlet. > Avolon components implement the validating of the OrderData, > and calculating some information. > Using this approach will give you the opportunity to test, and > use the avalon components either from the servlet or from the ejb. > > Testing of the avalon components can be done indepent from its > J2EE deployment. You may even think to reuse the code in some > fat client. > > 1. Configuring the Avalon EJB Delegation > > 1.1. Defining the avalon configuration in the ejb-jar.xml > ie: > ... the ejb-jar.xml snippet ... > <env-entry> > <env-entry-name>AvalonEJBFrame</env-entry-name> > <env-entry-type>java.lang.String</env-entry-type> > <env-entry-value><![CDATA[ > <configuration> > <logger> > <!-- use the log4j logger --> > <log4logger/> > <!-- use the jdk14logger > <jdk14logger/> > --> > <!-- optionally you may use the logkit logger > see ExcaliburTestCase, and avalon.excalibur.logger > <logkit> > <factories>...</factories> > <targets>...</targets> > <categories>...</categories> > </logkit> > --> > </logger> > <components> > <component role="A.ROLE" class="x.y.z.AImpl1"/> > </components> > <configuration> > ]]> > <env-entry-value> > .... > > Accessing this configuration: > Context ctx = new InitialContext(); > String xconfString = ctx.lookup( "java:comp/env/AvalonEJBFrame" ); > Configuration xconf = ... // build configuration from xconfString > > Note: prefix java:comp/env is part of the EJB spec and should be > portable across the different application servers. > > 1.2. Lookup the avalon configuration from the JNDI stored as DOM, or > plain xml > ... the ejb-jar.xml snippet ... > <env-entry> > <env-entry-name>AvalonEJBFrame</env-entry-name> > <env-entry-type>java.lang.String</env-entry-type> > <env-entry-value>avalon/xconf/a/b/c/EJB1.xconf</env-entry-value> > </env-entry> > .... > > 1.3. Lookup the AvalonEJBFrame from the JNDI > ... the ejb-jar.xml snippet ... > <env-entry> > <env-entry-name>AvalonEJBFrame</env-entry-name> > <env-entry-type>java.lang.String</env-entry-type> > <env-entry-value>avalon/xconf/a/b/c/AvalonEJBFrame</env-entry-value> > </env-entry> > .... > > 2. Using the AvalonEJBFrame > > I see two usage scenario of AvalonEJBFrame/AbstractAvalonEJB. > > 2.1 First use it in ONE stateless or stateful SessionBean as an > central instance. All other EJBs and classes has to request > avalon components from this SessionBean, let's call it > CentralServiceManager. > > Managing an Avalon component means an EJB call, making the call > surely not lightweighted. > > 2.2 Secondly each EJB has its own ServiceManager. > That's the usage scenario I thought about it would be okay. > As EJBs are coarse grained, the avalon components should be > a bit more fine-grained, acting as a toolbox for implementing > EJBs quickly, offering some kind of infrastructure which > is used by all EJB, and implementing simple basic business logic. > > 3. Consequences of EJB lifecyle > > 3.1 Using in a StatelessSessionBean > The AvalonEJBFrame object is shared by all StatelessSessionBean instances. > This means that all avalon components should be ThreadSafe. > > 3.2 Using in a StatefulSessionBean > Each StatefulSessionBean instance has its own AvalonEJBFrame. > > 3.3 Using in an EntityBean > I think it is like 3.2 > > > I hope my thoughts are valuable and understandable. > > bye bernhard -- Cheers, Pete It said "Don't Panic" in big friendly letters. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
