JBossDeveloper

"scott.stark@jboss.org" wrote:
So a runtime update from the perspective of achieving the semantic of having the service running with that change in effect may require logic in addition to just setting the property. This is also related to the transaction/bulk update issue. Generally you don't want a service immeadiately reacting to a single property update. A service also does not in general know how to correctly deal with cycling to apply updates. For example, if the detached invoker listening port is changed from 4444 to 14444 and all active requests should succeed, some aspect(s) is going to have to handle this. This is really a service dependency issue.

"scott.stark@jboss.org" wrote:
A problem related to this dependency issue is that the dependency is all the defines that the 4444 port has anything to do with the ejb container. The 4444 invoker can be used by services other than the ejb container as well. I don't know how to deal with this arbitrary wiring of services together from the perspective of an admin console tool. To start with we will just provide the service to console mappings, but at some point the ejb container console should be a composition of portlets generated based on metadata exposed by profile service based on the wiring of the service dependencies. This also has to work when the server is not even running.

Guys, before we start playing humtpy again,
please read the other threads on this subject.

You are mixing implementation details with contract. Again!

To reiterate, the profile service is just a (possibly versioned) list of
deployments.
How it is implemented is upto the "user":
* Simple static list
* Directories ala JBoss4
* IDE based
* More complicated versioning over a database
* Something else
but management tools should deal with one contract.

If the management tools attempts versioning where it is not supported
it won't get it.
* Give me a list of versions - answer only the current version
* Rollback to last version - operation not supported
Similary for transacted deployments.

All this talk about ports, etc. is rubbish. A port is a piece of policy
that is (only technically) a part of the profile because it is defined in a deployment.

Like I said before. If the management tool wants to define the versioning
then it should implement the profile service. Or at least that part of it.

Can someone who understands the details draft this up on the Wiki as a unified proposal and then the discussion can center around it? I've seen many threads go by, half of which I sort of understood. Most really seem to go too far too fast rather than KISS and grow. I can doco something but my thoughts are a magnitude simpler and single-minded. I'd like to see this with a JB4 focus at first rather than a JB5 (easier to grow forward rather than backward). I also think we can drop JB3 because whether you realize it now or not, JB3 will be EOL by the time we had this ready for JB3.

The problem is that nobody knows the details.
Somebody has got to sit down and work it out.

We have the high level requirements (AFAIK).

Besides what I said above:

I just want to have the basic infrastructure that can be
used as a facade to implement JSR77/88 (in an aspectized way
such that developers don't have to think too hard about
how their modifications affect it)
with plugins for value added behaviour.

The details are in how to define those plugins
and write the aspects that enable a model for JSR77/88 exposure.

I'd expect our management tools to bypass the facade and use the "better"
profile service directly.

thirdparty -> jsr88 -> profile service -> plugins -> deployers
us -> profile service -> plugins -> deployers

Here is my "hacky" approach

MainDeployerEx

keeps a list of deployed URLs

SARDeployerEx
calls setConfigUrl(String) on every MBean deployed

AOP
MBean class files add setConfigUrl
Add interceptor to attributes with @save

Interceptor:
When a property is updated, Main deployer is notified to ignore deployment, JAXB is used on the descriptor, the attribute is added or changed, Main deployer is notified to allow further deployments.

Me thinks that would take care of unwrapped MBean deployments. Proper VFS and JARUpdaterThingyMBean could handle wrapped deployments. If we wanted that to go into a repository with pluggable backend, that shouldn't be really hard to implement.

All the developer does is mark his attributes with @save or presumably could add something similar to XMBean descriptor for non-jdk5.

Ok. I can help with that.

Lets get the stupid question out of the way: you would like to see the "JBossON abstraction" of what exactly?

Thanks

Here is a start. Is this the sort of thing you want? In my mind the most important pieces here are the definitions, use cases and cross-cutting requirements. The API should allow a mgmt console to implement the requirements listed below. The API below is obviously very simple but hopefully will be a starting point for discussion, the key thing is ensuring that whatever we work towards still meets the requirements.
At the moment the API and requ's deal with the single server level, so the next extension would be for me to update it to include concepts of Domain, i.e. multiple Servers and also adding requirments related to versioning and Service dependencies. I can flesh this out but I want to know if this is inline with what you were thinking.

Cheers
Charles



Definitions:
Server:- single instance of the MC
Service:- concept that is at a higher level than Beans, represents things users of the System care about, e.g. Web App, Enterprise App, DataSource, EJB Container, JBoss Messaging, JMS Queue.


Use Cases:
An administrator uses a Management Tool to:-

U1) List the Services which are deployed in the Server
a) List the types of Services which are deployed in the Server
b) List all the Services of a particular type which are deployed in the Server
U2) List the Properties of a Service and their current values
U3) Update a Property of a Service.
U4) See the current state of a Service
U5) Add Services to the System
U6) Remove Services from the System
U7) Stop Services which are currently running in the Server
U8) Start Services which are current deployed in the Server but are stopped



Cross-cutting requirements:
C1) Changes to Services should be persistent across Server restarts.
C2) Virtually all operations should work whether the Server is running or not. Obviously trying to start a Service will fail if the Server is not running, but updates to properties, should work fine and be picked up when the Server starts up again.
C3) Handle concurrent access, e.g. if you call getServices() with the intention of updating a Service, then somebody else calls update(Service) before you do, then your call should fail with an appropriate exception.
C4) When making multiple calls to update the Server we should support basic transaction semantics, e.g. when making two updates, if the second fails the first one should be "rolled back".


Possible API and corresponding requirement #:
U1) List MgmtAPI.getServices()
a) List MgmtAPI.getServiceTypes()
b) List MgmtAPI.getServices(ServiceType)

U2) List Service.getProperties()
String Property.getName()
Object Property.getValue()
Map Property.getMetaInfo()

U3) Property = new Property(String name, Object value)
Service.setProperty(Property)
MgmtAPI.update(Service)

U4) ServiceState Service.getState()

U5) ServiceState MgmtAPI.add(Service)

U6) ServiceState MgmtAPI.remove(Service)

U7) ServiceState MgmtAPI.stop(Service)

U8) ServiceState MgmtAPI.start(Service)

C4) tx = MgmtAPI.beginTransaction();
MgmtAPI.add(Service)
MgmtAPI.update(Service)
MgmtAPI.start(Service)
tx.commit()

Looks just like existing service controller in 4.x

"charles.crouch@jboss.com" wrote:
Here is a start. Is this the sort of thing you want?

Use Cases:
An administrator uses a Management Tool to:-

U1) List the Services which are deployed in the Server
a) List the types of Services which are deployed in the Server
b) List all the Services of a particular type which are deployed in the Server
U2) List the Properties of a Service and their current values
U3) Update a Property of a Service.
U4) See the current state of a Service
U5) Add Services to the System
U6) Remove Services from the System
U7) Stop Services which are currently running in the Server
U8) Start Services which are current deployed in the Server but are stopped