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
