Hi,
I don't have a very good feeling about having 2 kinds of dependency tree in
the same file - the classpath one and the one you are proposing.
Another approach that is used by the jca stuff and has been requested
recently for the j2eedeployer is to use NotificationBroadcaster.
1. ServiceDeployer broadcasts notifications each time it deploys/undeploys
a sar/jar/service.xml
2. If you have a dependency to a mbean in another package, you write your
mbean to check for the object name when it is initialized, and to register
for notifications. Whenever it gets a notification, it can check for
deploy/undeploy of what it is looking for and go to an appropriate state.
This should be pretty easy to code into ServiceMBeanSupport or a descendant
so all you have to do is supply the object names you are looking for --
this could even be an attribute in the service.xml file.
what do you think?
thanks
david jencks
On 2001.09.05 17:39:15 -0400 David Maplesden wrote:
> OK just so everyone is clear (now that I have had some time to think
> about
> it) what I am proposing to do is as follows:
>
> In the jboss-service.xml (or equivalent xml snippet file) it will be
> possible to have depends tags
>
> <depends>JBOSS-SYSTEM:service=Naming</depends>
>
> that name an mbean or mbeans that must be deployed before the mbeans in
> the
> file itself can be deployed. The ServiceController will take notice of
> these tags and build a dependency list for the file. It will then delay
> the
> deployment of the file until all the mbeans on the list are deployed.
> This
> is to allow several files with interdependencies to be in the auto-deploy
> directory at the same time and have them deployed correctly.
>
> I could add a timeout to the waiting for the dependencies to resolved so
> that an exception is raised if the deployment seems to be halted
> indefinately. The mbeans listed within a single file will still be
> deployed
> in the order they are listed so that a large number of dependencies can
> be
> resolved by listing the mbeans in the same file. This mechanism though
> will
> allow us to specify services in separate jsr/sar's when it is useful to
> do
> so.
>
> This should be fairly simple to implement and relatively effective for
> our
> needs.
>
> I am not proposing any support for "undeployment" dependencies
> (automatically undeploying mbeans when mbeans they rely on are
> undeployed).
> The problem is quite a bit more complex.
>
> Any comments?
>
> David
>
> > -----Original Message-----
> > From: Jason Dillon [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, September 06, 2001 9:17 AM
> > To: David Maplesden
> > Cc: JBossDev (E-mail)
> > Subject: Re: Deployment Dependencies (was RE: [JBoss-dev] RH
> > startup and
> > JBoss MQ)
> >
> >
> > 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
>
> _______________________________________________
> 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
