-
1. Re: POJOizing(TM) the naming services
adrian.brock Mar 1, 2006 6:47 AM (in response to starksm64)"scott.stark@jboss.org" wrote:
I would like to put together a project plan that identifies what we need to get done before we tear down and rebuild jboss5 in the image of the MC.
Can you make your mind up? ;-)
So far in the ongoing JBossMC strategy we have gone from:
1) Use JBossMC/ServiceController facade in JBoss5
2) POJO Server
3) Tripoli
4) Standalone JBossMC release for embedded EJB3
5) Embeddable JBossMC generalizing EJB3 work
6) back to (1) in this post
The biggest stumbling block to using MC based services in JBoss5 is
making POJOs JMX manageable.
There is a prototype for this in Aspects, but I'd like to get the AOP integration
work finished in the "Embeddable MC" before we cutover JBoss5 to it.
We already agreed that we would use UnifiedClassLoader3 for the classloader
so the only other issue is writing the ServiceController facade JMX model over the MC's
controller. -
2. Re: POJOizing(TM) the naming services
adrian.brock Mar 1, 2006 6:50 AM (in response to starksm64)"adrian@jboss.org" wrote:
writing the ServiceController facade JMX model over the MC's
controller.
I can do this now if you are only interested in POJOs and MBeans taking part
in the same dependency space/granularity. -
3. Re: POJOizing(TM) the naming services
starksm64 Mar 1, 2006 11:54 AM (in response to starksm64)"adrian@jboss.org" wrote:
Can you make your mind up? ;-)
So far in the ongoing JBossMC strategy we have gone from:
1) Use JBossMC/ServiceController facade in JBoss5
2) POJO Server
3) Tripoli
4) Standalone JBossMC release for embedded EJB3
5) Embeddable JBossMC generalizing EJB3 work
6) back to (1) in this post
These are all parallel uses as I see it. What I'm really looking for is population of this task http://jira.jboss.com/jira/browse/JBAS-63 (MicroContainer work for JBoss-5.0.0 Alpha) with which of the N is going to be the approach for the alpha. If it's 1(or 3 since I have no idea what that is and I like the unknown), let's set that in stone(jira) and define/link the related tasks so we can get an alpha out. -
4. Re: POJOizing(TM) the naming services
starksm64 Mar 1, 2006 12:05 PM (in response to starksm64)Two classes in the server org.jboss.naming.* (NamingService, HttpNamingContextFactory), org.jboss.naming.interceptors.*, and org.jboss.naming.client.java.* are really integration classes around the detached invoker stuff. The NamingService could be broken up into a pojo with an xmbean deployment that handles the detached invoker stuff via interceptors, but the rest are pure integration addons that really don't belong in naming. So there will be a few naming integration classes in the server module. I need to look at how much different the configuration of the NamingService would be to see if that would be too disruptive a change for 4.0.4.
-
5. Re: POJOizing(TM) the naming services
adrian.brock Mar 1, 2006 12:29 PM (in response to starksm64)"scott.stark@jboss.org" wrote:
[
These are all parallel uses as I see it.
Yes, they also overlap and will eventually converge, but which is the priority?
The MC/JMX dependency integration of JBoss5 (ServiceController)
or the pure MC suitable for embedding/standalone use.
What I'm really looking for is population of this task http://jira.jboss.com/jira/browse/JBAS-63 (MicroContainer work for JBoss-5.0.0 Alpha) with which of the N is going to be the approach for the alpha. If it's 1(or 3 since I have no idea what that is and I like the unknown), let's set that in stone(jira) and define/link the related tasks so we can get an alpha out.
Ok. I've added the main ones.
I don't know whether we have a task for the MetaData Repository or the
AOP ProxyAdvisor.
If we do then these need to be linked to that task. -
6. Re: POJOizing(TM) the naming services
starksm64 Mar 1, 2006 1:19 PM (in response to starksm64)I don't see MetaData Repository or the AOP ProxyAdvisor so those tasks are needed.
I would like the alpha to include the new VDF framework, so these tasks along with related deployers should be added:
http://jira.jboss.com/jira/browse/JBAS-2380 (VFS Aspect for deployments)
http://jira.jboss.com/jira/browse/JBMICROCONT-57 (Add VFS prototype for review/testing)
http://jira.jboss.com/jira/browse/JBMICROCONT-6 (Virtual Deployment Framework)
jboss5 with an mc core, and vdf I think is a good alpha. Some class loading abstraction may be needed as well? Attacking class loaders, profile service should define the next release. -
7. Re: POJOizing(TM) the naming services
adrian.brock Mar 2, 2006 7:01 AM (in response to starksm64)Ok. I've added the missing tasks for the metadata repository and AOP proxy
and linked some stuff together to give a better view of the dependencies.
I'll flesh this out a bit more once I've completed my 4.0.4 testing.
I thought we were going to use UnifiedClassLoader3 for the initial rev?
There is this task on defining a proper integration api
http://jira.jboss.com/jira/browse/JBMICROCONT-31
i.e. one that does not depend upon the implementation choice. -
8. Re: POJOizing(TM) the naming services
starksm64 Mar 2, 2006 12:59 PM (in response to starksm64)"adrian@jboss.org" wrote:
I thought we were going to use UnifiedClassLoader3 for the initial rev?
There is this task on defining a proper integration api
http://jira.jboss.com/jira/browse/JBMICROCONT-31
i.e. one that does not depend upon the implementation choice.
Yes we did, and JBMICROCONT-31 getting pulled in via the JBMICROCONT-7(Classloading deployer) is satifies the abstraction issue.