Scott M Stark wrote:
Well, the use case driving this is simply a problem with how JBossMQ integrates with the security framework. Its a hardcoded property of its security manager rather than an attribute of the service. If the latter was the case then you could reference a unique configuration.
Wholeheartedly agree that this piece of MQ is poorly written.
I've taken a look at the SecurityConfig. All it does is create an XMLLoginConfig MBean and then push it to the top of the stack of Configurations. So, basically it does its own custom scripting. It solves the problem but isn't it an overkill to create an MBean whose function is only to instantiate another MBean and register it with the third? This is pure metaprogramming.The security config can be part of any deployment using the same approach as that shown in the org.jboss.test.security.service.SecurityConfig and the associated security unit tests. I'll be moving this out of the test package into the general security framework in the near future.
I still have a security question, though:
If I understand correctly, the entire Configuration gets replaced by the one that currently sits on the stack? Can I just add a particular piece, say, only application-policy for 'jbossmq-instanceid1234' while all other policies remain in place? Can I later remove any named application policy w/o affecting the rest? Stack seems to be a very limited data structure, I cannot add "jbossmq-id1", "jbossmq-id2" and then remove them in the _same_ (not stack-based) order.
Is there any technical limitation for doing what I need? Am I misreading something? Please, correct me if I am wrong.
I've taken a look at the ServiceBindingManager. It is somewhat similar to what I need but not exactly. In fact, it could have been a lot simpler (w/o requiring one to write a special delegate class that is responsible for changing configuration) by using the scripting facility itself. Here is how it could be done when *-service.xml is interpreted as a script:So let's not cloud the discussion of why scripting of deployment descriptors is needed based on an improper integration of a service. Most of what you are talking about is similar to the binding service in the varia module: org.jboss.services.binding.ServiceBindingManager. Investigate how this can be extended to incorporate what you need.
Deployer loads a configuration for a service (similar to ServiceConfig) which can be simply a property sheet.
It initializes variables in the JellyContext with values from the ServiceConfig
Let's say the ServiceConfig for this bean has the following properties, so we simply set variables in JellyContext with the appropriate names:
FooService.Name = myDomain:service=Foo-1
FooService.ref1 = otherDomain:service=someName
FooService.jndiName = java:/Foo-1
FooService.propX = someValue
Deployer loads the foo-service.xml and executes it (it sets the taglib to the deployTagLib).
foo-service.xml should have references to appropriate variables, like:
<mbean name="${FooService.Name}" class="so.and.soClass">
<depends optional-attribute-name="ref1">${FooService.ref1}</depends>
<attribute name="JndiName">${FooService.jndiName}</attribute>
<attribute name="propX">${FooService.propX}</attribute>
</mbean>
<mbean> tag creates the MBean with the given name and class (expression ${FooService.Name} is evaluated in the JellyContext and value of "myDomain:service=Foo-1" gets filled in.
the <mbean> evaluates its body (which means that <depend> and <attribute> tags get executed.
<depends> tag ensures that the dependency is present
<attribute> tag locates closes surrounding <mbean>, gets its mbean and sets the attributed to the appropriate value.
Now, if you wanted to reset certain attributes on an already existing mbean, you would run _the same_ foo-service.xml but using a reconfigureTagLib which binds the <mbean> tag to tag implementation that looks up the mbean instead of creating it.
Ain't it simpler?
xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx
--
-------------------------------------------------------------------------
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
