Well it turns out it's not too hard to simply turn the MQ service into a
jsr/sar and hot deploy from the deploy directory. However some problems
turn up (of course) when you have other mbeans that rely on the MQ service.
Obviously this is a problem faced by many mbeans, and it has been dealt with
previously by listing the mbeans in a particular order within the
jboss-service.xml file. Similarly the auto deployer has a "feature" where
it scans the deployment directories in a particular order to ensure certain
mbeans are deployed before others.
However if I understand RH correctly the only reason we have anything listed
in the jboss_service.xml file is to work around these dependencies, if we
came up with a method of specifying the dependencies in the service.xml file
then virtually everything (except the deployers themselves) could be
deployed by the auto-deployer from the deploy directories.
So what do people think about something like...
<?xml version="1.0" encoding="UTF-8"?>
<server>
<depends>JBOSS-SYSTEM:service=Naming</depends>
<depends>JBOSS-SYSTEM:service=AnotherService</depends>
<classpath archives="jbossmq.jar"/>
<mbean code="org.jboss.mq.server.JBossMQService"
name="JBossMQ:service=Server"/>
*snip*snip*
</server>
And then the deployer would delay the deployment of the mbeans in the xml
file until the mbeans listed in "depends" tags are deployed as well as
deploying the mbeans in the file in the order listed. This should take care
of 'fine-grained' and 'course-grained' dependencies.
Alternatively we could define dependencies on a per mbean basis rathar than
per "unit" (a unit as defined by each xml file) but in some cases there
would be just too many dependencies to list conveniently.
David
> -----Original Message-----
> From: David Maplesden [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 05, 2001 1:49 PM
> To: JBossDev (E-mail)
> Subject: RE: [JBoss-dev] RH startup and JBossMQ
>
>
> Ok I have just committed some changes to the ServiceDeployer and
> ServiceController code.
>
> Basically the ServiceDeployer now initialises all the mbeans
> referred to in
> a jboss-service.xml file before starting them. The changes
> were fairly
> straight-forward and I tested them out with the default
> configuration and by
> deploying and undeploying additional .jsr files. Everything
> seems to work
> fine, let me know if anyone has any problems.
>
> JBossMQ should now work as it did before, at least it does
> for me. However
> I am also in the process of turning the MQ service into a
> .jsr file, just
> because it would be cool to hot deploy JBossMQ.
>
> I also changed the code to recognise .sar files as well as
> .jsr files (same
> format just different extension).
>
> Cheers,
> David.
>
> > -----Original Message-----
> > From: David Maplesden [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, September 05, 2001 10:33 AM
> > To: JBossDev (E-mail)
> > Subject: RE: [JBoss-dev] RH startup and JBossMQ
> >
> >
> > OK, I will have a look at this and packaging JBossMQ into a
> > jsr file to get
> > it all working (at the moment it is seriously broken, no
> messages are
> > restored from backup at all).
> >
> > I think though that there are advantages to refactoring
> > JBossMQ away from
> > having so many mbeans to letting the statemanager handle more
> > of the queue
> > and topic setup. I would like to hear Hirams thoughts on the
> > matter before
> > charging into it.
> >
> > David
> >
> > > -----Original Message-----
> > > From: marc fleury [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, September 05, 2001 10:32 AM
> > > To: David Maplesden; JBossDev (E-mail)
> > > Subject: RE: [JBoss-dev] RH startup and JBossMQ
> > >
> > >
> > > 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
> >
>
> _______________________________________________
> 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
