Comments below... --- Laurent Rieu <[EMAIL PROTECTED]> 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) > ? 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 ? 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, ...) ? > > 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 ? 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. > > 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 ? > > Oh, one last thing. Where are you at with your Service URL stuff ? How can > a client access a component deployed in the container ? > > Thanks ! > > Laurent >
This is definitely along the lines of what I was thinking of. I have one app that has one implementation that connects to an Oracle XSQL servlet, while another implementation uses a mix of JNDI and regular JDBC. In either case, the client code works it out. The thing is, a DaoManager of this sort is really a small container in and of itself. It could be implemented using Fortress or Merlin I think, but I want to keep it light weight enough that it could be used either as just another component in a larger Avalon based app, or used outside of Avalon (so it would have to handle it's own lifecycle or something like that). One way to do this is to extend one of the current containers and customize it to be a DaoManager. Or one could write a simplier DaoManager that handled the lifecyles of the DAOs. I'm not sure which is best. jaaron __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
