|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of David
|Jencks
|Sent: Wednesday, September 05, 2001 5:52 PM
|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
Hmmm... almost, the only problem is that the classpath element is optional,
we could make it mandatory to specify dependencies... sounds like a
confusing "double use" for the classpath entry. Deserves a try though... go
right ahead david.
marcf
|
|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
