May 2008 - jboss-dev-forums - Jboss List Archives

[Design of EJB 3.0] - Re: Annotated EJB References in MappedReferenceMetadataDeplo

by scott.stark＠jboss.org

With the current 1.0.0.Beta13 release of metadata and updates to MappedReferenceMetadataDeployer, the @EJB(home) and @EJB(localBusiness) resolve to: | 2008-05-07 22:43:48,807 DEBUG [org.jboss.deployment.MappedReferenceMetaDataResolverDeployer] (RMI TCP Connection(4)-127.0.0.1) Processing unit=ejbthree1154.jar, | structure:ejbthree1154.jar+EjbEndpoint:ejbName=TestBean,ejbClass=org.jboss.ejb3.test.ejbthree1154.TestBean | ,home=org.jboss.ejb3.test.ejbthree1154.TestRemoteHome,BusinessLocals: [org.jboss.ejb3.test.ejbthree1154.TestLocalBusiness],BusinessRemotes: [org.jboss.ejb3.test.ejbthree1154.TestRemoteBusiness] | +EjbEndpoint:ejbName=DelegateBean,ejbClass=org.jboss.ejb3.test.ejbthree1154.Dele | gateBean,BusinessRemotes: [org.jboss.ejb3.test.ejbthree1154.DelegateRemoteBusiness] | ++@EJB(home) -> mappedName=null| resolvedJndiName=TestBean/localHome | ++@EJB(localBusiness) -> mappedName=null| resolvedJndiName=TestBean/org.jboss.ejb3.test.ejbthree1154.TestLocalBusiness | as determined by the new determineResolvedJndiName(iface) method on the JBossEnterpriseBeanMetaData, but the bindings for the interfaces on the bean are: | +- TestBean (class: org.jnp.interfaces.NamingContext) | | +- remoteHome (proxy: $Proxy128 implements interface org.jboss.ejb3.test.ejbthree1154.TestRemoteHome) | | +- local (proxy: $Proxy129 implements interface org.jboss.ejb3.test.ejbthree1154.TestLocalBusiness,interface org.jboss.ejb3.proxy.JBossProxy) | | +- remote (proxy: $Proxy126 implements interface org.jboss.ejb3.proxy.JBossProxy,interface org.jboss.ejb3.test.ejbthree1154.TestRemoteBusiness) | | +- localHome (proxy: $Proxy131 implements interface org.jboss.ejb3.test.ejbthree1154.TestLocalHome) | The logic for the BasicJndiBindingPolicy is to use the /local, /localHome, /remote and /remoteHome suffixes for the interfaces matching the metadata getLocal(), getLocalHome(), getRemote() and getHome() values. All others are bound under a suffix equal to the interface name. Here org.jboss.ejb3.test.ejbthree1154.TestLocalBusiness is a BusinessLocal interface rather than the getLocal() value so its expected to be bound under TestBean/org.jboss.ejb3.test.ejbthree1154.TestLocalBusiness rather than TestBean/local. So what happens when there is a getLocal() and BusinessLocal interfaces? Either the default binding policy needs to be updated or the proxy layer needs to use the new determineResolvedJndiName(iface, summary) method to get the jndi name to use. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149303#4149303 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4149303

17 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Potential enhancement to jbpm

by brittm

Ronald, Of course, you would have to implement code to reject re-deployment of a process definition that tried to deploy with a version number that was already in use for that definition name, but other scenarios would require some thought--would you stop deployment of a definition just because its version number is lower than the greatest currently deployed version? (someone might intentionally want to re-deploy and use an earlier release. Then, how would jBPM know that the earlier release number is the definition it should be using?) Personally, I think its cleaner, safer, and more flexible to just let jBPM continue managing the version_ field itself, and give the developer a separate field to version their process definition's content. I suppose we're really talking about two different things: the jBPM version_ field is versioning deployments, whereas the developer is versioning content. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149288#4149288 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4149288

17 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Build broken with new AIO tests

by clebert.suconic＠jboss.com

There are few leaks on the testcases where the Journals and files are not closed, what will cause few messages like: "Can't Initialize AIO" I have fixed that on the testsuite.. and I should commit this tomorrow by the end of the day. (I have to make some tests with some other commits I'm doing, so that's why I'm not doing it now). For now please just ignore those messages. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149284#4149284 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4149284

17 years, 11 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Mavenization

by darran.lofthouse＠jboss.com

I have managed to build trunk of JBossWS and use the ant script to use Maven to deploy to the different JBossAS versions but I am not sure what the process is to run the full testsuite - is this covered anywhere? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149252#4149252 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4149252

17 years, 11 months

1
0
0 / 0

[Design of JBossCache] - Re: new eviction region issues

by manik.surtani＠jboss.com

I agree, I think it is fair that the eviction algorithm sees all nodes as having the same creation timestamp for preexisting nodes. But going back to the whole thing of programmatic creation of eviction regions - I'm pretty sure this is an "unintentional" feature. :-) I can see how it can be useful and ought to be a real feature, but the way evictions work (as you can see from this thread) it is clearly not designed to be configured on the fly. Let's think about what we need to add to eviction configuration to make it dynamic - so far we just have the issue of pre-existing nodes. Anything else? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149244#4149244 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4149244

17 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: DeploymentScopeBaseName from JAR prepending JNDI Name

by ALRubinger

Scott's fixes have led to ~113 regressions resolved in EJB3 TestSuite: http://jboss.hudson.alrubinger.com/job/EJB3_Plugin_AS_TRUNK/116/ S, ALR[/url] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149241#4149241 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4149241

17 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: @Service and @Consumer in metadata

by alex.loubyansky＠jboss.com

Actually, I didn't think about optimization. In case of jboss.xml, every bean there can be identified by the ejb-name, other metadata components that need filling in some details can also be identified by their names. So, parsing jboss.xml alone we can get EJBs and then merge them with the spec ones. In case of annotations, it's different in the sense that looking only at the jboss annotations we can't identify an EJB or any other metadata component. I.e. the JBoss5Creator would still need to look at the spec annotations. So, I thought why not combine the processing of both. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149233#4149233 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4149233

17 years, 11 months

1
0
0 / 0

[Design of JBossCache] - Re: new eviction region issues

by bstansberry＠jboss.com

For the EJB3 SFSB cache I do something similar to what Sancheski describes. I realize now it works OK because that cache has useRegionBasedMarshalling=true, so even though the cache is started the region is empty when I programatically add the eviction region config. That's kind of a fortunate fluke though; being able to programatically add the region without requiring region-based marshalling would be nice. Without region-based marshalling, there could be pre-existing nodes. I wouldn't worry about the # of preexisting nodes exceeding maxNodes issue. The first time the eviction thread runs, it will take care of it; it's the job of eviction processing to worry about that. Re: every pre-existing node having the same timestamp in the eviction queue, oh well. Don't see any way around that without storing a creation timestamp in each node, which IMO is big time overkill. The main thing is making sure the policy knows about all nodes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149213#4149213 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4149213

17 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: DeploymentScopeBaseName from JAR prepending JNDI Name

by scott.stark＠jboss.org

Whoops, didn't read the logic carefully enough. Now its null if its not an ear. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149194#4149194 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4149194

17 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: DeploymentScopeBaseName from JAR prepending JNDI Name

by scott.stark＠jboss.org

I changed the JBoss5DeploymentScope to use an empty "" base name if the deployment is not an ear, so that should help with legacy expectations for the jndi name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149193#4149193 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4149193

17 years, 11 months

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 May 2008