[Design the new POJO MicroContainer] - Re: OSGi integration
by alesj
"scott.stark(a)jboss.org" wrote : Being able to support osgi deployments is the only real plan. What I started was an osgi bundle implementation on top of the vfs as a replacement for the unified class loader.
|
"bill.burke(a)jboss.com" wrote : This means we will have to refactor our UCL layer to support their classloader notions.
"scott.stark(a)jboss.org" wrote : The class versioning in osgi comes from the bundle
| class loader, and its really a package level versioning. We will have an
| osgi compatible class loader in the mc/jboss5."
Ok, so there was not a clear understanding. But it doesn't hurt to have both options (current impl with delegation to existing OSGi framework and new UCL layer) ;-).
So basically we want to have a whole new CL layer with versioning on packages available, e.g.:
| Export-Package: org.osgi.util.tracker;version=1.3
| Import-Package: com.acme.foo;version="[1.23, 2)"
|
And this is what was already started by Scott.
Why the need of using OSGi interfaces - Bundle, Activator, ... ?
How do we start this UCL refactoring?
Once we have this, I think service lookup / registry via Class instance (or ClassName + version) is trivial, since MC at state machine level ([Abstract]Controller) is (String) name unaware - name is plain Object (eq. via hash).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021090#4021090
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021090
19 years, 1 month
[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository
by weston.price@jboss.com
Prior to the TCK mess starting up I was nearing completion on both the Repository and the Programmatic Deployment stuff. To recap:
1) New JAXP based parser was created to handle parsing the *-ds.xml file format
2)RARMetaDataRepository was constructed to hold RAR, MCF, ActivationSpec and AdminObject metadata
3)Two new deployers (ManagedConnectionFactoryDeployer and ManagedConnectionFactoryParserDeployer) were created.
4)The RARDeployment MBean (the older guy) was refactored as a DynamicMBean that takes the MetaData as a value to it's constructor. In this manner. Nice thing is all those attributes that were previously null in the JMX console now actually show something useful ;-)
The only real drawback I can see in this approach is the JAXP parsing stuff. Clearly this is not the most elegant way to go, but I wanted something that was fast, independent and portable. Introducting a DataBinding mechanism at a later time is no big deal since the parser is injected into the ParserDeployer via the MC.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021071#4021071
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021071
19 years, 1 month
[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Support for cross-cluster HAJNDI list operations
by schaefera
In my http://www.madplanet.com/weblog/blog/schaefa/Madplanetcom/2007/02/22/Does... recent blog entry I discussed the topic in more details but here is my design for a HAJNDI revamp:
In my view the HAJNDI tree should be populated whenever an entry is made to a JNDI server on a node in a cluster. The HAJNDI tree would cache the JNDI NameClassPair and the nodes on which it can be found but not the content of the entry. If a HAJNDI deregister the entries from this node are removed. During a lookup it would search the nodes until if can retrieve the desired objects from one node. If a node is unavailable it could be put to the back of the list. The HAJNDI list() method would return an enumeration of the cached NameClassPair without any duplication by the nodes.
In the lifetime of a regular application the deployment is happening rarely but the lookup and list methods are called many times. So the overhead of publishing a JNDI binding/unbinding over the entire cluster is much smaller than the time spent on the lookups and listings.
The last point here would be what happens when a node is temporarily separated from the cluster. Then a deployment could be done on this node or another node on the rest of the cluster. The only fix I see is that HAJNDI needs a way to replicate its structure with other HAJNDI servers when they are out of sync. RIght now I do not know how this can be done or what event would trigger that but it should be possible.
-Andy
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020999#4020999
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020999
19 years, 1 month