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

[Design of EJB 3.0] - Re: Unit Tests for Unbinding References from JNDI in EJB3 Pr

by ALRubinger

"jaikiran" wrote : I do see the test cases and the logs which show that each bean binds to the default business JNDI name and also a interface-specific JNDI name. But what exactly is the difference between the default and the interface specific bindings? This was put in place to support SessionContext.getInvokedBusinessInterface();. The default business (remote|local) binding supports all business (remote|local) interfaces declared by the bean. This is the legacy behaviour, and from this "getInvokedBusinessInterface" is non-deterministic; the Proxy can be cast to any of the Business interfaces at compile-time, but the runtime has no way of knowing which business interface was invoked. So we introduced the notion of a an "interface-specific" binding, which has the necessary information within the Proxy itself to allow the Container to know which business interface was invoked. Check out the (lengthy) method in JndiSessionRegistrarBase.bindEjb for details in the comments. "jaikiran" wrote : One more question - Once the bean is unbound from the JNDI registry using: | | Ejb3RegistrarLocator.locateRegistrar().unbind(statelessSessionContainer.getName()); | | Is the JBossMetaData present in the statelessSessionContainer (which got unbound) expected to still maintain the jndi names? Ex: Is the metadata.determineJndiName() expected to return the jndi name after the bean was unbound? Or is it expected to return null? Yep, it's just metadata and should remain intact. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159067#4159067 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159067

16 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBMETA-44, ws annotation processing for references

by alex.loubyansky＠jboss.com

I've modified the WebServiceRefHandler to add injectors to the container. http://jira.jboss.com/jira/browse/EJBTHREE-1424 So, the JBCTS-797 now passes with the latest not yet released EJB3 and metadata versions. Another issue in the ClientContainer was that the AnnotatedElement was lost during serialization. So, sref.getInjectionTargets() had to be used instead. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159065#4159065 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159065

16 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: ClientContainer injection

by alex.loubyansky＠jboss.com

I've modified the WebServiceRefHandler to add injectors to the container. http://jira.jboss.com/jira/browse/EJBTHREE-1424 So, the JBCTS-797 now passes with the latest not yet released EJB3 and metadata versions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159064#4159064 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159064

16 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Code style and other issues

by timfox

I'm still seeing code like: | if (foo) { | doSomething(); | } | Please don't use K & R style, that's not our project style. Don't do it! I must have said this many times now, I'm not sure why it's not sinking in. Also don't do this: | | if (x) | doSomething(); | Also please don't paste public methods into the private areas of files. Respect the different areas of files. Next time I see code like the above I'm just going to delete it :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159061#4159061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159061

16 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Complex Splitting, Enrichment and Routing of Huge Messages

by tfennelly

For details on one approach (set of approaches) to solving some of these issues with JBossESB, take a look at the "huge-split-enrich-transform-route" Quickstart (SVN - trunk). For those in a hurry: * README.html * Flash Demo View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159026#4159026 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159026

16 years, 2 months

1
0
0 / 0

[Design of POJO Server] - MainDeployer MBean methods in JBoss 5

by Wolfgang Knauf

Hi everybody, this post refers to bug http://jira.jboss.com/jira/browse/JBAS-5643 I know that the deployment was reworked, but I don't know which impacts this had on the MainDeployer MBean. At least it seems to be quite non-functional This is the state of the MainDeployer: -operation "listDeployed" and others just return nothing -"isDeployed (string)" works for a URL "file:/C:/temp/jboss-5.0.0.Beta4/server/default/deploy/KuchenZutatNM.ear", but not for "vfs:/C:/temp/jboss-5.0.0.Beta4/server/default/deploy/KuchenZutatNM.ear" -"undeploy" and others don't work for any of the above URLs, both result in a console output "21:11:45,890 WARN [MainDeployer] undeploy 'file:/C:/temp/jboss-5.0.0.Beta4/server/default/deploy/KuchenZutatNM.ear' : package not deployed" I created a small plugin for Eclipse WTP which tries to undeploy a module and waits for successful deployment of new modules, and this plugin does not work at all with JBoss 5. Probably I need to change it to use the new deployers, but I didn't find a hint to them. You can find it here: http://www.informatik.fh-wiesbaden.de/~knauf/public/ It is no important code, just some playing around and trying to improve the eclipse built in file based deployer. But as the main deployer is still present, it would make sense to make it working again or remove it completely. I call those methods: For undeployment (before deployed file is deleted by eclipse/ant): -"isDeployed" -"undeploy" For waiting for successful deployment after the file was copied by eclipse/ant: -"getDeployment", which does not seem to return anything. "DeploymentInfo" was replaced by some other class I think? -"listIncompletelyDeployed" (always empty) Hope someone can help. Thanks Wolfgang Knauf View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159017#4159017 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159017

16 years, 2 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Error in org.jboss.security.valve.SSOFederationRouter

by sohil.shah＠jboss.com

Thanks for the feedback Let me look into this bug fix. You can track it here http://jira.jboss.com/jira/browse/JBSSO-40 Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159013#4159013 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159013

16 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Unit Tests for Unbinding References from JNDI in EJB3 Pr

by jaikiran

Andrew, thanks very much for reviewing the test case. I have started incorporating the comments. "ALRubinger" wrote : | * Tests must check not only the default local and remote bind values, but also those of the interface-specific bindings | I do see the test cases and the logs which show that each bean binds to the default business JNDI name and also a interface-specific JNDI name. But what exactly is the difference between the default and the interface specific bindings? Let me know if i need to look up some document where this is explained. For example, in this bean what gets bound to the interface specific jndi name and the what gets bound to the default jndi name? @Stateless | @Local(MyStatelessLocal.class) | @Remote(MyStatelessRemote.class) | public class MyStateless30OnlyBean implements MyStatelessLocal, MyStatelessRemote | "ALRubinger" wrote : | * Already provided are SLSB and SFSB EJBs in the "common" test package; we can use these and do away with the ones specific to the "jndiregistrar" test package. | I'll start using the "common" EJBs. I introduced the beans in the "jndiregistrar" to keep these test cases in the jndiregistrar, self-contained. But looking at the EJBs in the "common" package, looks like they were meant to be used across test cases. "ALRubinger" wrote : | * The tests are checking for hardcoded JNDI bind values. Instead, should be checking against the same values used by Proxy; these are obtained from metadata: | | JBossSessionBeanMetaData md = statelessSessionContainer.getMetaData(); | | md.getLocalHomeJndiName(); // Local Home Binding | | md.getHomeJndiName(); // Remote Home Binding | | md.determineJndiName(); // Default Business Remote Binding | | md.determineLocalJndiName(); // Default Business Local Binding | | BusinessRemotesMetaData businessRemotes = md.getBusinessRemotes(); | | for(String businessRemoteInterfaceName : businessRemotes) | | { | | md.determineResolvedJndiName(businessRemoteInterfaceName); // Interface-specific business remote JNDI Binding | | } | | BusinessLocalsMetaData businessLocals = md.getBusinessLocals(); | | for(String businessLocalInterfaceName: businessLocals) | | { | | md.determineResolvedJndiName(businessLocalInterfaceName); // Interface-specific business local JNDI Binding | | } | Thanks! I wasn't aware of those APIs :) One more question - Once the bean is unbound from the JNDI registry using: Ejb3RegistrarLocator.locateRegistrar().unbind(statelessSessionContainer.getName()); Is the JBossMetaData present in the statelessSessionContainer (which got unbound) expected to still maintain the jndi names? Ex: Is the metadata.determineJndiName() expected to return the jndi name after the bean was unbound? Or is it expected to return null? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159007#4159007 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159007

16 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBMETA-44, ws annotation processing for references

by alessio.soldano＠jboss.com

"emuckenhuber" wrote : Okay - i have a prototype working for this.. just need to check again - maybe you can validate it then to make sure that i did not miss anything. Sure anonymous wrote : But ServiceReferenceHandlerMetaData cannot be defined over annotations just via the xml descriptors - right? Yes, I can confirm this. The ServiceReferenceHandlerMetaData (which is mapped to the JBossWS SPI UnifiedHandlerMetaData) is for JAX-RPC handlers declared in the standard J2EE1.4 descriptor. The ServiceReferenceHandlerChainMetaData (which is mapped to the JBossWS SPI UnifiedHandlerChainMetaData) is for JAX-WS handlers declared in the standard JavaEE5 descriptor. We then have the handlerChain attribute of the JBossWS SPI UnifiedServiceRefMetaData which is for the <handler-chain> element in the JBoss JavaEE5 descriptor or the file attribute of @HandlerChain annotation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158998#4158998 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158998

16 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: MessagingBuffer implementation leaking into MessageImpl

by timfox

If you add a factory method to create the actual buffer so the message doesn't know or care what actual type its creating. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158976#4158976 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158976

16 years, 2 months

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