|I think we have a problem with RH and jbossmq. With the advent of Marc's
|changes the order in which the mbeans are initialised and started seems to
|have changed. Previously all mbeans listed in the jboss.jcml file where
|initialised before any where started. This meant that when the Persistence
|Manager was started the queues had already been initialised and the PM knew
|which queues it had to try to restore from persistant backup storage.
Yes for that to happen we would have to change the way services are started.
Previously there was one xml list and everyone was initialized together and
started together.
To be able to deploy services independently I broke this to individual
Elements and each is initialized/started as an individual unit. It still
respects the order of the Elements.
If you need an init together and started together I recommend coding that as
part of a "Unit" deployment. That unit can be embodied in a
jboss-service.xml file with Elements signifying init first start then as
unit. The simplest, in that view would be to come up with a MQ sar.
Then another angle is, is there any way for you to do what you do but in one
step? do you *really* need the init/start steps (as in *2* steps) can you
make it in one step? Init/start is not really used as a combo throughout
the server and there has been talk of removing one.
I am curious to see a case where you really need the two steps.
|Now it seems that each mbean is initialised and then started
|before the next
|is initialised. They are still processed in order (now defined by
|jboss-services.xml) but each one is started before the next is initialised.
correct needed if we want independence. The better option is the Unit
signified by snippets of services that we could initialize as one (and then
keep the URL/set of service association so as to init/start/stop/destroy
together as a unit, but again do you really need the 4 steps?)
|If this is the case (and I'm pretty sure it is) then it will break the
|restoration processes in jbossmq.
Make sure that you need 4 steps and not 2, is that your final answer?
|My question then is could we change the startup process back to how it was
|before or do we change the jbossmq restoration to work with the new startup
No I can't change to what it was before for the simple reason that before
stuck the configuration.
what we can do is
1- make sure that you need the 2 step init/start. Everyone is not down with
the "init" and jsr77 is modeling only a start on services (no 2 steps). I
tried pushing the 2 steps but it seems no one uses this. Maybe it is not
needed?
2- If you *really* need a 2 step init/start over many beans then I would
need to code that support, which might not be too difficult but will take me
some hours.
|process. This change to jbossmq may be quite tricky (its hard to
|tell until
|I have a good look at it) and I am not that keen to do it. However if RH
Please have that hard look if you determine that a 2 step init/start is
necessary, first double check again, then show me that example clearly as I
would love to take it to JSR77
|startup process is the result of a fundamental change in how mbeans are
|loaded and managed then jbossmq will just have to be fixed.
Nah don't start taking out the big words, not just yet. There is a
fundamental change in how and where we load the beans, but it shouldn't
affect you that much, it is just the init start steps
|
|Cheers
|David
|
|PS: I have also had issues with the security mechanisms in RH.
|The problem
|is that currently it ignores the server.policy file, which usually is fine
|since no SecurityManager is installed. However we have a custom service we
|are writing that uses RMI and hence requires a SecurityManager.
|Unfortunately as soon as we install one because the server.policy file has
|not been loaded there are all sorts of access restrictions that come into
|play that effectively stuff the whole server.
The security stuff was hardcoded in the Main. I want this to be a JMX
configured service. Hence the commented code in Main.
|I tried to fix this by using the SecurityPolicyService mbean to implement a
|security policy but it uses an xml policy file and I can't seem to get the
|right syntax for it. I took an educated guess (based on one in the test
|directory of the security module) but it doesn't seem to work. If anyone
|has any ideas (Scott this is your area, right?) then I would appreciate a
|helping hand. What I am basically asking for is a pointer to the correct
|syntax for the xml file or how to run jboss using a convential policy file
|(like server.policy).
|
| (xml file I am using for policy)
|
| <?xml version = "1.0" encoding = "UTF-8"?>
| <policy>
|
| <application-policy name = "other">
| <authorization>
| <grant>
| <permission code = "java.security.AllPermission"/>
| </grant>
| </authorization>
| </application-policy>
|
| </policy>
|
I will work with Scott to get the security stuff going in RH.
I need to spend another day on the slides for the London training next week
and will try to code something before next Saturday.
marcf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
