Re"work" for the list.
Basically my take is that making the init/start scope go to the XML snippet
is not an issue just requires some basic changes to the ServiceDeployer and
the ServiceController. David take it away.
marcf
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of David
|Maplesden
|Sent: Tuesday, September 04, 2001 5:31 PM
|To: JBossDev (E-mail)
|Subject: RE: [JBoss-dev] RH startup and JBossMQ
|
|
|OK, it seems the situation is much as I thought.
|
|I will try to explain the problem a bit and then propose a solution.
|
|Basically the persistence manager, when it is started, needs to
|restore from
|its persistent store any messages that were left from the last run
|of the MQ
|service. For it to be able to do this effectively it needs to know what
|queues there are that are supposed to exist in the system. Hence
|the queues
|that are created at startup need to be registered with the jms server (and
|hence the persistence manager) before the persistence manager is started.
|This means that the persistence manager needs to be created and initialised
|first, then have the various queues and topics initialised before the PM is
|started. Clearly this means a two step startup process because of the
|dependencies between the mbeans.
|
|In more general terms the only reason I can see for needing a two step
|startup process is if such dependencies exist between mbeans. For example
|if mbean B requires mbean A to be initialised before it is initialised AND
|mbean A requires mbean B to be initialised before it is started
|then the two
|step init start process is required to correctly start these two mbeans. As
|in:
| init mbean A
| init mbean B
| start mbean A
| start mbean B
|
|If the only dependency that exists is that mbean B needs mbean A to be
|started before it is started then a simple one step start process should be
|enough.
|
|If this is going to be a general problem then we will need a generic
|mechanism for dealing with this dependency (the "Unit deployment" you
|mentioned?). If however the only place it exists is between the mbeans of
|jbossmq then the answer is that the individual queues, topics, persistent
|managers etc should not be mbeans.
|
|If you want to do the first then there should be no problem
|bundling MQ as a
|sar or jsr. If we want to do the second we need to change a bit
|of code and
|do away with all the mbeans (QueueManager, TopicManager,
|PersistenceManager,
|StateManager and ServerILService) that someone (Hiram?) quite recently
|created and move the MQ configuration back into a seperate XML file that is
|loaded by a single JBossMQService mbean. In this case I would be keen for
|the input of whoever made these changes. Why exactly were they made and is
|it the end of the world if we undo them.
|
|So my basic question is, do you think this co-dependency between mbeans is
|likely to occur elsewhere?
|
|IMHO the dependency only exists because there are too many mbeans in the
|jbossMQ setup. An mbean should define an entire service not a part of a
|service that is co-dependent with another mbean (in that the both need the
|other to work). One mbean using another mbean service (like a
|DataSource or
|JNDI service) is obviously fine, but co-dependent mbeans I'm not so sure
|about.
|
|David
|
|
|> -----Original Message-----
|> From: marc fleury [mailto:[EMAIL PROTECTED]]
|> Sent: Wednesday, September 05, 2001 12:26 AM
|> To: David Maplesden; JBossDev (E-mail)
|> Subject: RE: [JBoss-dev] RH startup and JBossMQ
|>
|>
|> |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
|>
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
