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

[Design of POJO Server] - Re: ReferenceMetaDataResolverDeployer is wrong

by adrian＠jboss.org

Also, I'm seeing a lot of this hackery in the new metadata. What's wrong with using OO? | private static String getJndiName(JBossEnterpriseBeanMetaData beanMD, boolean isLocal) | { | String jndiName = null; | if (isLocal) | { | // Validate that there is a local home associated with this bean | jndiName = beanMD.determineLocalJndiName(); | if (jndiName == null) | { | log.warn("LocalHome jndi name requested for: '" + beanMD.getEjbName() + "' but there is no LocalHome class"); | } | } | else | { | - if( beanMD.isEntity() ) | - { | - JBossEntityBeanMetaData md = (JBossEntityBeanMetaData) beanMD; | - jndiName = md.getJndiName(); | - } | - else if( beanMD.isSession()) | - { | - JBossSessionBeanMetaData md = (JBossSessionBeanMetaData) beanMD; | - jndiName = md.getHomeJndiName(); | - if(jndiName == null) | - jndiName = md.getJndiName(); | - } | + jndiName = md.resolveRemoteJndiName(); | } | return jndiName; | } | And move the if statements into the types? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4110188#4110188 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4110188

18 years

1
0
0 / 0

[Design of POJO Server] - Re: ReferenceMetaDataResolverDeployer is wrong

by adrian＠jboss.org

Also, shouldn't this be: | if(unresolvedPaths != null && unresolvedPaths.size() > 0) | - log.warn("Unresolved references exist in JBossMetaData: "+unresolvedPaths); | + throw new DeploymentException("Unresolved references exist in JBossMetaData: "+unresolvedPaths); | Why does it try to muddle on, only to fail later when creating the ejb containers? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4110185#4110185 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4110185

18 years

1
0
0 / 0

[Design of POJO Server] - AnnotationMergedView doesn't do AssemblyDescriptor

by wolfc

It calls AssemblyDescriptorMetaData.merge which is empty. The effect is that we have empty assembly descriptors in EJB 3 deployments. Working on it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4110182#4110182 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4110182

18 years

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: HOWTO: remove a deployment context that is in error?

by adrian＠jboss.org

"smcgowan(a)redhat.com" wrote : Similar behavior seen during deployment of: | org.jboss.test.messagedriven.test.*MessageDrivenUnitTestCase | and org.jboss.test.jbossmessaging.ra.Ra*UnitTestCase | when the test suite is run in its' entirety . These tests deploy successfully and pass when run singly as noted in: | http://jira.jboss.com/jira/browse/JBAS-4637#action_12390385 | I think you'll find the problem with the full testsuite is that things aren't getting undeployed properly because of previously failed tests. e.g. If a test deploys something then times out, it doesn't undeploy the test deployment. e.g.2. If the test is broken such that it doesn't undeploy in the event of a failure | deploy(...); | // do test | undeploy(...); // oops not in a finally block so doesn't happen when an error occurs | For the message driven tests (and many others) there is a testsuite/output/resources/jbossmessaging/test-destinations-full-service.xml that gets deployed for all tests that use the test queues/topics. This is clearly not getting undeployed somewhere: http://dev45.qa.atl.jboss.com:8585/hudson/view/JBoss%20AS/job/JBoss-AS-5.... "java.lang.IllegalStateException: Cannot set paging params when active" it's already active because it wasn't undeployed by a previous test. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4110181#4110181 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4110181

18 years

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Handling cluster state when network partitions occur

by manik.surtani＠jboss.com

Decided to provide a policy based approach here. When we get a JGroups notification of a merge, provide plugins that allow for: 1) Evict entire cluster state (useful with Hibernate) 2) Evict cache state of the losing sub-cluster 3) Throw exception, stop cache (useful if we need to force some manual cleanup) 4) Perform merging of disjointed subtrees. (Maybe later - this "plugin" could be released in future) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4110174#4110174 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4110174

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: bam, the next frontier

by tom.baeyens＠jboss.com

this is where the results should be detailed : http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsolePageReports View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4110171#4110171 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4110171

18 years

1
0
0 / 0

[Design of POJO Server] - ReferenceMetaDataResolverDeployer is wrong

by adrian＠jboss.org

The ReferenceMetaDataResolverDeployer (RMDRD) is wrong in that it updates the mapped-name/jndi-name with the resolved jndi-name. This breaks the reversability of the model and will also confuse things with the profile service. Example: I have ejb1 with jndi-name="ejb1jndiName" I have ejb2 with ejb-link="ejb1" The RMDRD will do EJBReference.setMappedName("ejb1JndiName"); | if(link != null) | target = findEjbLink(unit, link); | if(target == null) | unresolvedRefs.add(ref.getEjbRefName()+"/ejb-ref/"+link); | else | ref.setMappedName(target); | When the ManagedObjects are retrieved for this deployment, the EJBReferfence now has a mapped-name and so it will be saved and never re-resolved on a deploy from the profile service. If I then use the managed console (profile service) to change the jndi-name of ejb1 ejb1JndiName -> ejb1ChangedName the EJBReference is now invalid, but it won't be re-resolved because the mapped-name is not null. Instead what should be happening is that on the ResourceInjectionMetaData there should be: | private String resolvedJndiName; | | public String getResolvedJndiName() | { | return resolvedJndiName; | } | | @XmlTransient // not included in xml model | public void setResolvedJndiName(String jndiName) | { | this.resolvedJndiName = resolvedJndiName; | } | The RMDRD should setting the resolvedJndiName and the containers should be using getResolvedJndiName(), rather than getMapped/JndiName(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4110170#4110170 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4110170

18 years

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: HOWTO: remove a deployment context that is in error?

by smcgowan＠redhat.com

Similar behavior seen during deployment of: org.jboss.test.messagedriven.test.*MessageDrivenUnitTestCase and org.jboss.test.jbossmessaging.ra.Ra*UnitTestCase when the test suite is run in its' entirety . These tests deploy successfully and pass when run singly as noted in: http://jira.jboss.com/jira/browse/JBAS-4637#action_12390385 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4110165#4110165 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4110165

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: SVN Branching as Part of Build Process

by dimitris＠jboss.org

I believe dealing with our build system/maven limitations (and trying to fix them) is a different thing than the branching strategy. In the way you suggest the number of branches explodes. I'd normally go for the simplest solution, but maybe that's me. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4110152#4110152 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4110152

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: SVN Branching as Part of Build Process

by ALRubinger

It's an optional step that isolates the codebase from forward-moving development changes, and (I find) eases the process of tagging Beta1, Beta2 without incrementing the version number (as Maven will prompt as a default). Mostly, it's a matter of developer preference; I happen to find branching an essential organizational step as tagging off trunk I find confusing. I've been updating the Wiki page referenced in my original post as I employ this process for EJB3 External API and EJB3 Impl projects. This thread is precisely for this debate. :) S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4110150#4110150 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4110150

18 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums December 2007