September 2007 - jboss-dev-forums

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by scott.stark＠jboss.org

With a change to the MCDependencyPolicy to include the | public void addJNDIName(String name, ClassLoader loader) | ... | public void addDependency(DemandMetaData dependency) | { | dependencies.add(dependency); | } | and an override in JBoss5DependencyPolicy to use a JndiDemandMetaData: | public class JBoss5DependencyPolicy extends MCDependencyPolicy | { | ... | @Override | public void addJNDIName(String name, ClassLoader loader) | { | this.addDependency(new JndiDemandMetaData(name, loader)); | } | the webservice test that was failing in JBCTS-645 is passing. I have checked this changes into the ejb3 project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083127#4083127 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083127

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: More build problems.

by scott.stark＠jboss.org

Ok, I must have had those from the 2_0 build so my maven build looked ok. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083116#4083116 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083116

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by scott.stark＠jboss.org

Looking at this in more detail, a KernelRegistryPlugin does not seem the correct way to handle this. The JNDIKernelRegistryPlugin is shared instance getting called by the kernel to resolve a name for a DemandDependency, but the registry value is not just a function of the name. Its a function of the name and the dependee's class loader. Two ejb deployments can have a reference to the same jndi name, but will have different values on lookup due to deserialization of the value using different class loaders. There needs to be a custom DemandMetaData implementation that has a DependencyItem implementation that combines the jndi name and class loader to use for resolution during lookup. I'll see if I can get this working. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083114#4083114 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083114

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: More build problems.

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : I did update the trunk eclipse classpath files with the same dependencies as the 2_0 branch. Yes but not the maven build so none of the references existed in my local repository. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083112#4083112 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083112

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by wolfc

Using the container class loader sounds like a solid solution. Ah misunderstanding. I was talking about EJB business interfaces, not Java interfaces. EJB A doesn't define an import for a specific version. It only defines that it wants to use business interface X. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083105#4083105 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083105

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: More build problems.

by scott.stark＠jboss.org

I did update the trunk eclipse classpath files with the same dependencies as the 2_0 branch. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083104#4083104 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083104

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failure on XAResourceRecoveryTest

by mark.little＠jboss.com

Ah, OK. Glad it was sorted out. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083078#4083078 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083078

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by scott.stark＠jboss.org

In the current implementation, the InjectionHandler.addJNDIDependency(InjectionContainer container, String jndiName) needs to pass down the container.getClassLoader for use in the lookup as the thread context class loader. I'm looking at validating this fixes the current problem. In terms of your example of multiple sources of a class, this has to be resolved based on what the deployments import/export. The deployments that source X will have to declare the class/version it exports. The deployment which consumes X will have an import statement that is matched up to a source. In the absence of an import that more specifically matches the A.jar export of X, the X found in the B.ear class loading domain should be resolved as the matching source. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083072#4083072 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083072

17 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: How to create a maven dependency for external project th

by pgier

There isn't currently a standard procedure for this, as far as I know. I created this wiki page a while back and I guess option 3 is what you want. http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenThirdPartyJars If you just want to deploy the existing jars from the ant repo, then you can just use the maven deploy plugin "mvn deploy:deploy-file" to deploy the jar, and generate a basic pom and metadata. If you need to patch a new version that doesn't exist in the ant repository, then I think we can follow the same basic conventions that we do now. Just deploy the bin and source jars with a modified version number. Maybe we should have a separate jar in the repository that contains just the patches. So a structure something like this: | /oswego-concurrent/1.3.4-jboss/oswego-concurrent-1.3.4-jboss.jar | .../oswego-concurrent-1.3.4-jboss-sources.jar | .../oswego-concurrent-1.3.4-jboss-patch.jar | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083070#4083070 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083070

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Unspecified XAException error code.

by adrian＠jboss.org

NOTE: Also you don't want to use XA_RMERR as this will stop the TM from recovering (retrying the commit of) the transaction in the event of a transient connection failure. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083047#4083047 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083047

17 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2007