February 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: OSGi integration

by scott.stark＠jboss.org

There is no need for the osgi interfaces in the barely started ucl refactoring. I only included those to get a feel for how different the ucl was from the osgi bundle notion. I would have extracted those interfaces once its clear what was needed. That is how I would continue the ucl refactoring. Alternatively you could already start with two versions: the BundleClassLoader impl in the osgi integration layer that delegates to new ULR/UCL, and the new ULR/UCL that supports the BundleClassLoader along with whatever else we need. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021142#4021142 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021142

19 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[Design of JBoss ESB] - New mailing lists

by mark.little＠jboss.com

We have set up some new mailing lists that readers of this forum may find useful. esb-commits https://lists.jboss.org/mailman/listinfo/esb-commits svn commit announcements will go here. esb-dev https://lists.jboss.org/mailman/listinfo/esb-dev talk to the developers of JBossESB or others interested in developing on or with the ESB. This is not a replacement for this forum: it is meant to compliment the forum. esb-issues https://lists.jboss.org/mailman/listinfo/esb-issues JIRA issue announcements. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021089#4021089 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021089

19 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository

by weston.price＠jboss.com

I should have mentioned that the new deployers/MBean etc can happily exist side by side with the XSL deployer and older MBeans. Obviously the two deployers can't be run simultaneously, but you can simply swap them out if necessary. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021073#4021073 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021073

19 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[Design of JBoss ESB] - Re: Using Eclipse to work on JBossESB?

by mark.little＠jboss.com

Good point. I've added it to the developers.txt file. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021035#4021035 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021035

19 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Support for cross-cluster HAJNDI list operations

by schaefera

>From my point of view the HAJNDI tree does not make much sense except for components that are only available on a subset of nodes within the cluster. In my case that would be HA-JMS because it can only run as a HA-Singleton. This means that the HAJNDI tree cannot use the shortcut of just using the local JNDI tree because it may or may not be the Master node. What I do not understand is the fact that by default nothing is bound to the HAJNDI. This means that when I need to lookup a HA-JMS object inside the cluster I will lookup the object every time (at least that is the case for 4.0.4 and 4.05) even though that is an expensive remote lookup over the entire cluster (in the worst case) and that on every lookup because the found object is not cached inside the TreeHead, isn't it. -Andy View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020992#4020992 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020992

19 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: Build System Meeting Agenda for Feb 15

by scott.stark＠jboss.org

common-core, common-logging-spi, ..., jbossxb you mean? Certainly jbossxb will be released separately. I would expect common-logging-jdk and common-logging-log4j can be released separately. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020949#4020949 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020949

19 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: Using Eclipse to work on JBossESB?

by kukeltje

ahh... most probably it is. I'll check that out tomorrow (it's now 0400 (am that is)) in the Netherlands. Thanks (should/could be in the developer read me or something, or is it and did I miss it?)) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020936#4020936 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020936

19 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2007