JBossDeveloper

> 1. You have to start somewhere, I think that is going
> to be a bunch of *-service.xml files for a long time
> to come.

Yes, you start with the definition of the server, I'm not going to call it configuration because obviously it means different things to different people. This is where you define the set of MBeans that get registered at startup.

I don't know why you say it has to be service.xml for a long time to come though. It can be anything the application loader is able to parse.


> 2. I don't think it is reasonable to say "even if you
> change the *-service.xml file, once it is deployed
> all changes have to be made directly through the jmx
> server"

No one is saying that.

I'm saying you separate the persistent state of MBeans from the definition of the server.

These are two different issues. You can think of it in terms of MLetMBean and PersistentMBean interfaces. Both "externalize" something persistent (a file, db, whatever) but for different purposes. Having them both share the same file creates the mess that is difficult for the users to understand/edit.


> Today, there are 2 ways to change the configuration,
> directly through the server or by changing
> *-service.xml files.

And the "configuration" as far as the state of individual attributes go should not be here. Only the definition of which MBeans get registered to the server at startup.

> method persists over server stop/start. I think this
> discussion is how to make direct changes to mbean
> configuration persistent over server stop/start
> without breaking the ability to change the state
> through the *-service.xml files

right.

and without confusing
> people too much. (e.g. as we did with
> jboss-auto.jcml)

the problem with auto.jcml was that it contained both the definition and the state of the server. Two basically identical files, in the same directory. Much confusion.

-- Juha

the forums are completely fucked up

> > 1. You have to start somewhere, I think that is going
> > to be a bunch of *-service.xml files for a long time
> > to come.
>
> Yes, you start with the definition of the server, I'm
> not going to call it configuration because obviously
> it means different things to different people. This
> is where you define the set of MBeans that get
> registered at startup.
>
> I don't know why you say it has to be service.xml for
> a long time to come though. It can be anything the
> application loader is able to parse.
>
>
> > 2. I don't think it is reasonable to say "even if you
> > change the *-service.xml file, once it is deployed
> > all changes have to be made directly through the jmx
> > server"
>
> No one is saying that.
>
> I'm saying you separate the persistent state of
> MBeans from the definition of the server.
>
> These are two different issues. You can think of it
> in terms of MLetMBean and PersistentMBean interfaces.
> Both "externalize" something persistent (a file, db,
> whatever) but for different purposes. Having them
> both share the same file creates the mess that is
> difficult for the users to understand/edit.
>
>
> > Today, there are 2 ways to change the configuration,
> > directly through the server or by changing
> > *-service.xml files.
>
> And the "configuration" as far as the state of
> individual attributes go should not be here. Only the
> definition of which MBeans get registered to the
> server at startup.
>
> > method persists over server stop/start. I think this
> > discussion is how to make direct changes to mbean
> > configuration persistent over server stop/start
> > without breaking the ability to change the state
> > through the *-service.xml files
>
> right.
>
> > and without confusing people too much. (e.g. as we did with
> > jboss-auto.jcml)
>
> the problem with auto.jcml was that it contained both
> the definition and the state of the server. Two
> basically identical files, in the same directory.
> Much confusion.
>
> -- Juha

> > 1. You have to start somewhere, I think that is
> going
> > to be a bunch of *-service.xml files for a long
> time
> > to come.
>
> Yes, you start with the definition of the server, I'm
> not going to call it configuration because obviously
> it means different things to different people. This
> is where you define the set of MBeans that get
> registered at startup.

"Define" here meaning IMO class, object name, constructor arguments, and initial attribute values. Apparently you disagree about at least the initial attribute values?
>
> I don't know why you say it has to be service.xml for
> a long time to come though. It can be anything the
> application loader is able to parse.

Agreed. I didn't say it had to be *-service.xml, I predicted it would be. I haven't seen any other proposals.
>
>
> > 2. I don't think it is reasonable to say "even if
> you
> > change the *-service.xml file, once it is deployed
> > all changes have to be made directly through the
> jmx
> > server"
>
> No one is saying that.
>
> I'm saying you separate the persistent state of
> MBeans from the definition of the server.
>
> These are two different issues. You can think of it
> in terms of MLetMBean and PersistentMBean interfaces.
> Both "externalize" something persistent (a file, db,
> whatever) but for different purposes. Having them
> both share the same file creates the mess that is
> difficult for the users to understand/edit.
>
>
> > Today, there are 2 ways to change the
> configuration,
> > directly through the server or by changing
> > *-service.xml files.
>
> And the "configuration" as far as the state of
> individual attributes go should not be here. Only the
> definition of which MBeans get registered to the
> server at startup.

How do mbeans get their initial attribute values?

>
> > method persists over server stop/start. I think
> this
> > discussion is how to make direct changes to mbean
> > configuration persistent over server stop/start
> > without breaking the ability to change the state
> > through the *-service.xml files
>
> right.
>
> and without confusing
> > people too much. (e.g. as we did with
> > jboss-auto.jcml)
>
> the problem with auto.jcml was that it contained both
> the definition and the state of the server. Two
> basically identical files, in the same directory.
> Much confusion.

I think the problem was that no one thought through the relationship between jboss-auto.jcml and jboss.jcml. In particular, removing a bean from jboss.jcml did not undeploy it after jboss.jcml was processed.

It looks to me like you have some other idea about how to set attribute values at startup or initial mbean creation, and some other idea about how to change attribute values. I'd like to know how you think of doing this, I'm stumped. I haven't thought of any way of creating a new, configured, mbean that isn't equivalent to processing an *-service.xml file, nor any ways of changing the state of an mbean that isn't direct manipulation through e.g the html connector or equivalent to reprocessing a modified *-service.xml file.

David

>
> -- Juha

> "Define" here meaning IMO class, object name,
> constructor arguments, and initial attribute values.
> Apparently you disagree about at least the initial
> l attribute values?

no

I don't care where you get the inital default values. hard code them for all I care.

The problem is, and you said this yourself, is that the service files are used for two different purposes: for the server definition and persistence. This needs to be separated. This is what Rickard did and this was correct, although the implementation wasn't perfect. The problem was there was a duplicate definition for the server rather than just the persistence (or just a diff from the original definition).


> How do mbeans get their initial attribute values?

This is not the point. We provide the initial values.

> > the problem with auto.jcml was that it contained both
> > the definition and the state of the server. Two
> > basically identical files, in the same directory.
> > Much confusion.
>
> I think the problem was that no one thought through
> the relationship between jboss-auto.jcml and
> jboss.jcml. In particular, removing a bean from
> jboss.jcml did not undeploy it after jboss.jcml was
> processed.

Yes, because there was duplicate definition and the users didn't know which file to edit. It's more than a definition of relationship. It was duplication. No amount of defining the relationship would have made it any clearer to the user.


> It looks to me like you have some other idea about
> how to set attribute values at startup or initial
> mbean creation, and some other idea about how to
> change attribute values.

??

separate the persistence from the server definition. don't force the user to wade through all mbean definitions just to change the JNDI port. expose only the user made changes (diff).

-- Juha

1. What do you think useful mbean persistence will look like? I have been thinking that it would probably look more or less like a *-service.xml file with one mbean in it, but I see your implementation in the book uses serialization. Obviously many implementations are possible, I would like to know what you think will be most useful.

2. My understanding of the purpose of the persistence service is that if you stop and restart the server all the same mbeans should be there with the same configuration. What we do now is incompatible with a persistence service, because we undeploy every script (service.xml file) on shutdown that we deployed earlier, and expect to redeploy them on restart. I can think of 2 ways to make service.xml based deployment compatible with mbean persistence:

a. persistently save the modification timestamp of each *service.xml file, and reprocess it only if it has changed. So if you make no *service.xml changes, and stop/restart the server, the persistence service handles the mbean configuration, and the *service.xml files are ignored.

b. Change to format of the *service.xml files to indicate what operation needs to be done (insert, update, delete). Each script should be executed only once, ever. This is very similar to sql database scripts.

3. We keep a bunch of info about mbeans that is not in their state, mostly dependencies and which script they came from. Would it be more appropriate to move this more into the mbean server? Can the relation service be used for this kind of thing?

> 1. What do you think useful mbean persistence will
> look like?

Depends on what the user finds useful. I think two most common will be plain text files and database (for clustered configs).

> I have been thinking that it would
> probably look more or less like a *-service.xml file
> with one mbean in it, but I see your implementation
> in the book uses serialization.

Serialization is crap. That's not how to do the persistence right (there's no point in serializing the whole management info when all you need to do is serialize the attribute state for instance). That's another example where the definition is not separated from the runtime persisted state.

However, that's how RI does it. Also, it fit in two pages, so....


> a. persistently save the modification timestamp of
> each *service.xml file, and reprocess it only if it
> has changed. So if you make no *service.xml changes,
> and stop/restart the server, the persistence service
> handles the mbean configuration, and the *service.xml
> files are ignored.

you're still not separating the persisted state here. You're talking about having it in two different locations.


> b. Change to format of the *service.xml files to
> indicate what operation needs to be done (insert,
> update, delete). Each script should be executed only
> once, ever. This is very similar to sql database
> scripts.

???


> 3. We keep a bunch of info about mbeans that is not
> in their state, mostly dependencies and which script
> they came from. Would it be more appropriate to move
> this more into the mbean server? Can the relation
> service be used for this kind of thing?

somewhat a different issue but yes, I'd look into using the relation service for doing this, and make the necessary extensions to Adrian's implementation if the spec defined functionality is not enough. It's hard to tell since the RI implementation of this service was so bad, Adrians' is much better but it needs to be taken for a spin.

-- Juha