Hi Laurent:
Here is that reply that I promised a few days ago!
Laurent Rieu wrote:
Hello,
Stephen, you're talking about "lots of demos available". Do you have
anything close to a kernel loader able to work in a J2EE context (Web App)
?
I have in place a web server based on the Tomcat Coyote engine that runs as an embedded server within Merlin. The component basically provides services supporting the registration of web applications and the establishment of a service context for the application based on dependencies declared by the app. Keep in mind that this is not the same scenario as a pure web-app - but it's the precursor to the pure web-app solution.
What are the issues I have to deal with ? I am mainly worrying about
potential classloading conflicts / problems : should I put the component
jar files in the root of the EAR and declare this directory as the system
or shared directory ?
Embedded jar files are problematic because the JVM does not support the loading of embedded jars into a classloader. In all of the cases where this is supported the solution is a complete classloader implementation (which I have not been too keen on implementing). Also, there is an open question concerning the difference between a web-app and a block in terms of how jar files are shared. There are several possible approaches - (a) use of extension an directory which is already possible, (b) loader and unpack embedded jar files into a cache, or (c) use a system wide repository. The third option (c) is the direction I'm leaning towards.
By the way, could you give me some hint about what are the context informations I should pass to the Merlin kernel when bootstraping it (ie : home, system, shared, ...) ?
http://home.osm.net/products/avalon/merlin/apidocs/org/apache/avalon/merlin/kernel/impl/DefaultKernel.html
You also told me about some interesting things about how you see component
adminstration using JMX in Merlin. Basically, if I understand you well, we
have two different level of administration : Appliance and Component
instances. While it is feasible to plug a Component-level administration
using lifecycle extensions, it seems more intrusive to me to have Appliance
management. Am I right ?
Yes - at least that's where the real action is.
This brings one question to my mind : are Appliances and other internal stuff "true" components", meaning : are such things registered within the container as components which would potentially enable us to provide them with lifecycle extensions ? I guess this is not that easy as these form the core of the container. I'm talking about all that coz I'm pretty interested in giving Merlin a try within a J2EE webapp and providing it with JMX administration.
Appliance instances are created using an appliance factory. The appliance factory and the appliance can be customized using mate info attributes. The attributes basically declare the classes to use and these are instantiated using the assembly framework. This means that both factory of appliance are handled as first-class components - they can have dependencies, custom lifestyle, lifecycle stages, dependencies - whatever you want.
Keep in mind that if you thinking about a custom appliance factory then your basically thinking about the introduction of an entirely new component model. In the case of a custom appliance, you basically introducing additional resources and capabilities to the component deployment process. Factory customization would be unusual. I'm currently working on a custom IIOP appliance. It a custom appliance because the URL generation and object activation models are completely different to the default appliance implementation. Once completed - the IIOP appliance will enable automatic creation of a CORBA POA based server based on three or four attributes.
I'm also taking care of persistent object references as part of the IIOP Appliance case.
By the way (sorry for so many questions at the same time !), what about component proxies (using Dynamic proxies, CGlib, ...) which would enable us to plug interceptors and potentially provide components with security, conversational state, ... ? Does it fit in Merlin plans ?
It fits in the plan. Currently the only proxy support is to take care of the legacy Component stuff. Introducing proxy support into the default appliance would be relatively easy. I'm already doing a lot of stuff related to current principals (establishment of principal identity, propagation of identity over IIOP, identity interception on the server side, identity to business role mapping, etc.).
Oh, one last thing. Where are you at with your Service URL stuff ? How can a client access a component deployed in the container ?
As a temporary measure I've put in place operations that enable access to appliance instances in a block. The short-term objective is to retract these operations once service based access is in place. The IIOP activation that I'm working on will provide a support for corbaloc URL resolution which means that when services are access via URLs, you may be dealing with a local or remote service as part of the implementation of your block. Once this is all validated I'm drop the direct appliance access and seal the block implementation model. At that point the appliance instances used for the implementation will not be accessible - but the services they provide will be (via published service declarations on the block definition).
Aside from all of the above - a roadmap is in preparation.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
