David Jencks wrote:
You are correct, the two pieces are pretty much unrelated, it is just that I realized a need for (1) after having stumbled upon (2) which (within the current security framework) might need (1) just be able to point Deployer to a URL which contains a deployable unit with all its plumbing/security aspects configurable by a script contained in the unit itself.Hi Anatoly,I think your discussion has 2 parts that are to me pretty much completely unrelated: 1. you want to be able to write deployment scripts using jelly 2. you want to be able to deploy bits of security stuff with your packages.
As for 2, I need to look into this also for resource adapter deployment. I
don't see how it is related to the need for scripting: it seems to me that
either I don't understand how the xml login stuff works or it needs
extension. (so far I know little about it).
I guess it is Scott who should know :)
I am not proposing introducing scripting just for that purpose. I think, scripting is an extremely useful tool that can solve my simple problem but can make other people's lives easier as well.Making the security stuff accept say mbeans with additional rather than replacement security info is surely a more appropriate fix than introducing scripting for this reason alone.
You are correct that most things can be accomplished from within the MBean during the lifecycle methods. But not all the things that are currently done from within the lifecycle methods, imho, belong in there. I think, we can learn something from EJBs, namely, that the plumbing should be externalized and taken care by someone else, not EJB itself. (By plumbing I mean setup of the appropriate references to other beans/resources, basically the context in which the bean operates).
Lets talk about (1) some more. We already have the jboss mbean service lifecycle, with the create, start, stop, destroy methods called during
deployment and undeployment. If I understand your proposal correctly, the
same effect of your jelly script could be obtained by writing some java
code in the mbean start method say to invoke the same methods on the same
mbeans as in the jelly script. Is this correct or did I miss something?
Let me give you an example. If you take a look at JBossMQ org.jboss.mq.security.SecurityManager (3.0.4). Conceptually, what it does is some form of MQ-specific security checks which are actually delegated to the JBoss security domain. Practically speaking, the MQ SecurityManager MBean is only interested in knowing the reference to the JBoss SecurityDomain it is attached to, nothing more, no need to know where to look it up, how, etc. I would say, all this SecurityManager needs is a pair of MBean methods: setSecurityDomain(), getSecurityDomain(). It should be responsibility of the Deployer to attach MQ's SecurityManager to appropriate SecurityDomain at deployment time.
IMHO this begs for scripting. All references to other MBeans should be completely externalized and settable, say, at deploy time through scripting. This way it is infinitely easier to change connections w/o having to modify the lookup logic, names or whatever else is coded in the lifecycle methods. This should, in fact be a mandatody design pattern. Do you know how many MBeans reference the TransactionManager? How many of them have "java:/TransactionManager" hardcoded for lookup. What if I want to run 2 instances of TransactionManager (this may or may not be crazy but why not?) and under different JNDI names than "java:/TransactionManager"?
I am not proposing getting rid of lifecycle methods. Could be that some of the things done inside lifecycle methods should remain there and never be externalized.
Precisely the job of scripting. Usually your bean knows what it needs to operate. Setting up the context should be external to the business logic! This is how everything is done: servlets, ejbs. It seems that MBeans should not be any different. Scripting is just the way to achieve this, not the only one, but I guess one of the simplest.In fact, if you look at most of the mbeans I write, you see that in the start method they are often invoking methods on other mbeans. This is usually needed to set up the context in which they operate.
Another bonus of going with Jelly is, as I mentioned in the original e-mail, is the fact that with care, current *-service.xml's can remain the same -- full backward compatibility and quite infinite extensibility. There are, in fact, tags in Jelly that do JSTL (emulate standard jsp tag libs). You gain lots of stuff for free and just write a small JBoss taglib that does deployment, dependency tracking and MBean invocations.So, it seems to me that the main point in favor of jelly scripting has to be greater convenience and flexibility. Can you provide a specific example showing an example of this where the configuration has to be instance specific, so it is not appropriate to put in the start method of the java class, or is just much easier to write externally?
Yeah, perhaps. "There is more than one way to do it"Finally, since you mentioned aspects, I think you can in fact implement this kind of "lifecylce helper" as mbean interceptors. Such an interceptor would intercept only the lifecycle methods and provide pre and post actions from the jelly script (or other source).
We just need to see what makes more sense and what is easier, more compatible with current stuff and more flexible.
I'm not sure if currently xmbeans can specify their interceptor or aspect stack in their xml descriptor, but if not I think it is easy to implement, needed, and coming soon. Thanks david jencks
--
-------------------------------------------------------------------------
Anatoly Akkerman
Computer Science Dept.
Courant Institute of Mathematical Sciences, NYU
715 Broadway, #719 Tel: 212 998-3493
New York, NY 10003 Fax: 212 995-4123
-------------------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
