Adding some form of dependency declaration will help improvde debugging, as
a service (or rather the service controller) could throw an exception with
the exact service name which is missing, instead of throwing other meaning
less exceptions. Not that I really know that it does throw such
exceptions, just pointing out that dependencies would help minimize the
learning curve in some ways.
I understand that it could also be confusing, but if it is left to a minimal
design, simple in nature, then it should positivly augment the boot process
rather than complicate it.
--jason
On Wed, 5 Sep 2001, David Maplesden wrote:
> 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>
> > > > |> |
> > > > |> | <DEFANGED_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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
