Ok you guys are climbing up the complexity tree with something that needs to
be simple over a simple "who's got it longer" discussion.
Please stop it, it is not that important whether we have 1/2/3 ways of doing
it, just DO IT and forget the discussion, please,
marcf
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of David
|Jencks
|Sent: Wednesday, September 05, 2001 6:24 PM
|To: David Maplesden
|Cc: JBossDev
|Subject: Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and
|J Boss MQ)
|
|
|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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
