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). 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.
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?
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.
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?
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).
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
On 2002.12.14 23:17:43 -0500 Anatoly Akkerman wrote:
> Hello, Jbossers
>
> It seems that for the benefit of the wider audience I'll start with the
> deployment scripting idea. For those interested in what drove me to the
> idea, see below in the security part (I am sure people will have their
> own use-cases for this stuff, I remember discussions from before)
>
> For my project I need to be able not only to deploy/undeploy services on
> the fly but, sometimes this is insufficient, I also need to stich them
> together after deploy, unstich before undeploy, say by invoking a bunch
> of methods on a bunch of MBeans.
>
> This is clearly a deployment issue, perhaps, there is a need to move
> from 'Slackware'-style packaging to 'Debian'-style packaging for
> components (or at least, add extensions people can use). To explain the
> analogy:
>
> Slackware used plain old tgz's for its packages which one would just
> untar and that's it. This works for simple things but when the system
> grows and packages become more dependent on other packages and
> versioning info, etc., this does not cut it anymore.
>
> Debian uses a sophisticated package format with a whole bunch of stuff
> packed into the package, like dependency information, pre-/post-
> -installation/-configuration/-removal scripts that can modify/unmodify
> various config files, etc. Obviously, in the simplest form a .deb can be
> do as little as a .tgz does.
>
> The simplest scripting tool which would be suitable for quick jobs like
> the one I need, would be something based on Apache Jelly.
>
> Let's say, the *-service.xml is not really a descriptor (though it
> appears as such, we don't need to change old descriptors either) but,
> say the JBoss DeployerMBean, instead of treating it as plain XML
> interprets it as a Jelly script. JBoss provides a standard JBoss tag
> library that interprets the tags for the *-service.xml, say, <mbean> tag
> deploys the MBean specified by the tag's attributes and configures it
> appropriately. So, a simple deployment descriptor would not notice any
> difference. But, say you add another attributed to the <mbean> tag, say,
> 'referenceVar' which specifies the name of the variable under which the
> object name of the newly created bean will be stored in the JellyContext
> in which this script is running. Then, one can simply add a scripting
> section at the end of *-service.xml which manipulates the initialized
> variables, e.g. through custom jelly tags locate and invoke methods on
> MBeans specified by variables from the JellyContext:
>
> <mbean code="xxx" name="yyy" refVar="mbeanX"/>
> <jmxinvoke targetObj="${mbeanX}" method=${methodDesc} args="${args}" />
>
> where jmxinvoke is a custom Jelly tag which takes a target object name,
> method description object and arguments array and does the invocation.
> Obviously this is very similar to the jsp tags, which is exactly the
> point of Jelly. So, with properly defined tags for invocation, exception
> handling, etc, one can do simple meta-programming of MBeans during
> deployment.
>
> At the end, the DeployerMBean which processes this script, checks for
> exceptions coming from the script execution and deals with them
> according to the convention: calls the cleanup section of the script or
> whatever. (By clean-up section I mean that the *-service.xml can be made
> of sections which the deployer 'executes' depending on whether previous
> stages succeed/fail)
>
> This is the end of deployment issue/proposal. Now the security question.
>
> Here is the problem setting:
> I need to be able to have deploy any JBoss service, possibly multiple
> instances, simultaneously on the same server. For that I have an
> infrastructure for reconfiguring JBoss descriptors of services. For
> example, for JBossMQ, I make sure that all MBeans that comprise JBossMQ
> have unique object IDs, all JNDI objects exported by the service are
> also uniquefied, that all cross-references are correct, etc. It turns
> out that this is not enough. One aspect (yeah that 'a'-word again) of
> deploying JBossMQ is completely separated from jbossmq-service.xml and
> cannot be folded into *-service.xml. Namely, it is configuring security
> for this particular JBossMQ instance.
>
> It turns out (as for 3.0.4) that login-conf.xml contains an application
> policy for 'jbossmq' which has a reference to a particular JBossMQ
> MBean, namely StateManager. Since I always change the object name of
> this MBean, I need to be able to deploy the login-config on the fly. It
> would seem that ideally, one should be able to deploy the JBossMQ
> service together with specification of its security domain.
>
> My thought was, well, I'll just create my custom login-conf.xml with an
> entry for just JBossMQ that I am deploying and would utilize the
> XMLLoginConfig MBean, which I would deploy together with MQ. As it turns
> out, this is not sufficient (silly me). After looking further into
> security architecture, I can only fully replace the current
> Configuration with a new one. My idea was to allow changes to the
> current configuration. Is this idea crazy or not?
>
> Well if it is not crazy, then, the best solution would be to deploy the
> XMLLoginConfig together with JBossMQ beans and then have a deployment
> scripting facility invoke appropriate methods to register the new
> LoginConfig with the SecurityConfig MBean so it appropriately ammends
> the current config. This is how I came to the deployment scripting
> facility.
>
>
> -- Anatoly.
>
>
>
> -------------------------------------------------------
> 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
>
>
-------------------------------------------------------
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
