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

[Design of EJB 3.0] - Re: Plug-able default JNDI binding policy

by gavin.king＠jboss.com

Not sure if an annotation is really useful. Makes most sense in jboss.xml or jboss-app.xml. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101492#4101492 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101492

18 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Plug-able default JNDI binding policy

by ALRubinger

Would also make sense to determine what properties in a deployment might be interesting to a developer implementing a binding strategy, and pass this in: String getJndiName(SomeNewEjb3DeploymentTO) ..giving the TO instance members: * deploymentName * ejbName * isLocal * isHome * isService * isStateful * deploymentType * beanType ...anything else? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101491#4101491 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101491

18 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: NewProcessInstanceFacade bug?

by burrsutter

Is this the specific issue with having the "key" show up within jBPM. It has been suggested that the jBPM API we are using will "eat" the key even if we successfully passed it along. And thank you very much for your help in this area!!! Burr View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101489#4101489 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101489

18 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Plug-able default JNDI binding policy

by ALRubinger

+1. Current implementation is dependent on packaging, which, while ensuring namespace-based unique values, immediately breaks all applications once JAR names change, are placed into an EAR, etc. Bean providers must currently override default names using their own homebaked solution; I'd heavily made use of LocalBinding/RemoteBinding on every EJB just for this purpose. Pluggable policy would address this in one fell swoop. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101486#4101486 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101486

18 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Plug-able default JNDI binding policy

by bdecoste

This is something we've discussed in the past, but it's come up again. I propose that we create a plug-able default jbndi policy. It's becoming clear that no matter what we choose for a default policy, somebody doesn't like it. SEAM is having problems with embedded in multiple wars and would like the default policy to be warName/bean/Name. I don't think it would be that much work - maybe a day or 2. The jndi code is fairly isolated now. Here's what we would need to do - create the policy api. Probably just 1 method like | String getJndiBinding(String deploymentName, String beanName, boolean | isLocal, isHome); | - create an impl for the current policy - create an annotation like @JndiPolicy for setting the policy impl - modify ejb3-interceptors-aop.xml to default the default policy - modify the jboss.xml schema and code to add the new annotation Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101485#4101485 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101485

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: 2.0.0.Beta6 release

by alesj

"alesj" wrote : "scott.stark(a)jboss.org" wrote : vfs is independent of the mc project so it can be released when its ready. | | | OK. | Will let you know if I succeed with filling in the VFS's '..' tests. | Meant to write when, not if. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101484#4101484 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101484

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: 2.0.0.Beta6 release

by alesj

"scott.stark(a)jboss.org" wrote : vfs is independent of the mc project so it can be released when its ready. | OK. Will let you know if I succeed with filling in the VFS's '..' tests. "scott.stark(a)jboss.org" wrote : | Would need to see that both the reflection and javassist MethodInfo implementation support isBridge to add it. Let's leave it then. Until it's at least present in JDK. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101483#4101483 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101483

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: 2.0.0.Beta6 release

by scott.stark＠jboss.org

vfs is independent of the mc project so it can be released when its read. Would need to see that both the reflection and javassist MethodInfo implementation support isBridge to add it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101480#4101480 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101480

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: 2.0.0.Beta6 release

by alesj

Can you wait till Sunday? At least with VFS. I'll try to push in '..' changes over the weekend. btw: should we add then isBridge to MethodInfo and use it in AbstractBeanInfoFactory? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101477#4101477 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101477

18 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - New Build Artifact - EJB3 External API

by ALRubinger

I've added a new artifact to the EJB3 build script, producing: jboss-ejb3-ext-api.jar ...whose intent is to expose any classes needed by a bean provider for development (compilation) of EJB3 and JBoss-specific extensions. To develop EJB3 applications on JBoss, all that should be required on the build CP is this library and jboss-javaee.jar Currently the external API is limited to all annotations (minus the Impls), Stateful Cache support, and RemoteProxyFactory (as is currently required for compilation). The key here is ensuring that we don't expose any implementation internals to the bean provider, externalizing out as interfaces whenever possible but providing enough support for custom implementations. Testing the validity of this JAR is proving difficult; the test suite itself tests many internals and cannot compile against the external API alone. How can we ensure that we're providing everything necessary for an external API in this JAR? Separate source tree of test EJBs compiled against the Ext API and jboss-javaee.jar alone? The alternative is the status quo I used to employ as a bean provider - grabbing internals from JARs under ejb3.deployer and using those for compilation. This must be completed for Beta 3. http://jira.jboss.com/jira/browse/EJBTHREE-1099 S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101476#4101476 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101476

18 years, 2 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 November 2007