I just feel (though I am willing to be out voted) that specifying the mbeans
you are dependent on is more portable than specifying the sar. There might
be different versions of the mbean service you want that could be started
from different places, you don't really care how or where the mbean comes
from, just that it exists before you attempt to deploy "this" file (sar or
xml snippet).
> -----Original Message-----
> From: David Jencks [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 06, 2001 9:52 AM
> To: jboss-dev
> Subject: Re: Deployment Dependencies (was RE: [JBoss-dev] RH
> startup and
> JBossMQ)
>
>
> Is explict mbean-mbean dependencies really a good idea and/or
> necessary?
> We already have, via the classpath element, sar-sar
> dependencies. Is there
> a realistic case where having finer grained dependencies is
> appropriate?
>
> Obviously it's possible, is it desirable?
>
> Right now there are 2 levels of deployment ordering:
>
> 1. in the classpath element, the sars a given sar depends on
> are loaded (if
> not already present) in the order listed
>
> 2. Within the sar, the mbeans are created in the order listed.
>
> What else is needed? Why?
>
> david jencks
>
> On 2001.09.05 10:47:41 -0400 marc fleury wrote:
> > Man, you and jason are just on fire...
> >
> > great, great...
> >
> > |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.
> >
> > Thanks that is an easy solution. You will create a graph
> of dependencies
> > in
> > the service controller. It was needed for the longest time. If I
> > remember
> > correctly someone coded that long time ago and you might
> find a trace of
> > the
> > dependency manager somewhere in the attic.
> >
> > On another note, when we did the CL research with Jung back
> in December,
> > we
> > exchanged a couple of emails on the topic you are adressing. My gut
> > feeling
> > at the time was that we could possibly intercept a
> dependency call (on
> > class
> > dependency) (in our precise case in the MBeanClassLoader)
> and if there is
> > a
> > CNFE then we hold on that dependency in the
> ServicesLibrary. When that
> > class is deployed the SL notifies the deployer that can restart
> > deployment
> > on the MBean. Advantages: mr clean, automated, no admin
> intervention,
> > will
> > even feel spooky :) down: complicated to code, tricky
> concurrency issues,
> > doesn't work for JMX calls (you never reference the *class* of the
> > target).
> >
> > My own vote on my own suggestion at this point is thumbs
> down for the
> > simple
> > reason that the "explicit" MBean dependency is simpler for
> us to code. So
> > go
> > ahead with your idea, XP.
> >
> > It is simpler than ClassLoader dependency graphs that a
> certain Rickard
> > Oberg was advocating for administrators to build, but it is
> still "MBean
> > dependencies" built by administrators when we could do away
> with it. I
> > don't see a problem with requiring that administrators be
> aware of what
> > services depend on what services. It seems like a natural
> task, jason?
> >
> > marcf
> >
> > marcf
> >
> > |
> > |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
>
>
> _______________________________________________
> 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
