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

[Design of POJO Server] - Re: [jboss-metadata] No ResourceProcessor for JBoss50Creator

by scott.stark＠jboss.org

Any type not handled by the AbstractResourceProcessor.resourceRefTypes is a ResourceEnvironmentReferencesMetaData. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166034#4166034 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166034

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] No ResourceProcessor for JBoss50Creator

by scott.stark＠jboss.org

SessionContext is the resource type, so what do you mean? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166033#4166033 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166033

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] No ResourceProcessor for JBoss50Creator

by ALRubinger

The static initializer does not account for javax.ejb.SessionContext (or any of javax.ejb.*), which is my injection target. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166029#4166029 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166029

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] No ResourceProcessor for JBoss50Creator

by scott.stark＠jboss.org

org.jboss.metadata.annotation.creator.jboss.AbstractComponentProcessor adds all resource processors, and this is subclasses by all ejb processors. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166027#4166027 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166027

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] No ResourceProcessor for JBoss50Creator

by ALRubinger

Ah, found "org.jboss.metadata.annotation.creator.Resource*Processor". Looking like it might need to be hooked in more, I'll play around with it. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166026#4166026 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166026

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: appclient remote home regression

by scott.stark＠jboss.org

"ALRubinger" wrote : | Should like look more like: | | | | // Determine the jndi name for the reference interface | | String iface = getInterface(ref); | | String containerJndiName = target.getBeanMetaData().determineResolvedJndiName(iface); | | if(containerJndiName != null) | | ref.setResolvedJndiName(containerJndiName); | | | | ? | Yes, otherwise info is being thrown away. If I make that change the 1x_50 tests pass, but the ejb2x based tests start failing. I'm looking at why now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166024#4166024 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166024

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - [jboss-metadata] No ResourceProcessor for JBoss50Creator?

by ALRubinger

Using JBoss50Creator to obtain metadata, I'm not seeing ResourceReferencesMetaData get populated. A cursory look shows no ResourceProcessor under org.jboss.metadata.annotation.creator.ejb. What's the status of the JBoss50Creator? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166023#4166023 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166023

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: appclient remote home regression

by ALRubinger

"scott.stark(a)jboss.org" wrote : So the MappedReferenceMetaDataResolverDeployer ends up doing: | | | // Determine the jndi name for the reference interface | | String iface = getInterface(ref); | | //LegacyEjb3JndiPolicy policy = new LegacyEjb3JndiPolicy(); | | String containerJndiName = target.getBeanMetaData().determineJndiName(); | | if(containerJndiName != null) | | ref.setResolvedJndiName(containerJndiName); | | Should like look more like: | // Determine the jndi name for the reference interface | String iface = getInterface(ref); | String containerJndiName = target.getBeanMetaData().determineResolvedJndiName(iface); | if(containerJndiName != null) | ref.setResolvedJndiName(containerJndiName); | ? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165992#4165992 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165992

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: appclient remote home regression

by ALRubinger

"scott.stark(a)jboss.org wrote : The issue is that the MappedReferenceMetaDataResolverDeployer will have to resolve the ejb-ref differently based on whether the target ejb is a 2.x or 3.x. We should have this info available in the binding policy, so I need to see what is going on with not using it. I guess its just that the server specified binding policy is not in synch with the current ejb3 behavior. The binding policy should know whether the target is EJB2 or EJB3? Nah, it's just a policy! This is why I'd moved the policies away from the object model; at deployment we can now attach a binding policy to an EJB, and from then on the caller (Mapped Reference Deployer) doesn't need to choose (because it can do so incorrectly). So far as the server binding policy being out of sync w/ EJB3 handling...they should both be pointing to the same thing at this point. See code below. Or am I missing somewhere else? "scott.stark(a)jboss.org wrote : Is the ejb3 proxy layer using the deployment binding policy for all proxies yet? Looking at the code this does not appear to be the case. Yes, the Binding Policy is added at deploy-time via: http://anonsvn.jboss.org/repos/jbossas/trunk/server/src/main/org/jboss/ej... ..and is picked up transparently by the code currently in EJB3 Core (I'm integrating EJB3 Proxy now). From BaseSessionProxyFactory.bindEjb: // Bind the proxy itself | log.debug("Binding proxy for " + getContainer().getEjbName() + " in JNDI at " + this.getJndiName()); | Util.rebind(getContainer().getInitialContext(), this.getJndiName(), proxy); | | // Bind a proxy per business interface | //TODO This ugly block should be using polymorphism, but I'll allow it as the proxy mechanism | // is going to be replaced entirely by EJB3 Proxy soon | JBossSessionBeanMetaData smd = (JBossSessionBeanMetaData) container.getXml(); | BusinessRemotesMetaData remotes = smd.getBusinessRemotes(); | BusinessLocalsMetaData locals = smd.getBusinessLocals(); | Set<String> businessInterfaces = new HashSet<String>(); | boolean isLocal = this.isLocal(); | if (!isLocal) | { | if (remotes != null) | { | businessInterfaces.addAll(remotes); | } | } | else | { | if (locals != null) | { | businessInterfaces.addAll(locals); | } | } | for (String businessInterface : businessInterfaces) | { | String jndiName = JbossSessionBeanJndiNameResolver.resolveJndiName(smd, businessInterface); | log.debug("Binding proxy for " + getContainer().getEjbName() + ", interface " + businessInterface | + " in JNDI at " + jndiName); | if (Proxy.isProxyClass(proxy.getClass())) | { | for (Class<?> in : proxy.getClass().getInterfaces()) | { | log.debug("Proxy Interface for JNDI Name " + jndiName + ": " + in); | } | } | Util.rebind(this.getContainer().getInitialContext(), jndiName, proxy); | } View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165991#4165991 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165991

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: What replaces determineResolvedJndiName?

by ALRubinger

For EJB3, these are effectively replaced by the JBoss*PolicyDecorator, which overrides "get*JndiName" methods. Also, you may use the JBoss*BeanJndiNameResolver's static methods. @see ResolveJndiNameDecoratorUnitTestCase.testResolvedJndiNamesWithKnownIfaces. For EJB2...nothing yet. I'd planned on also decorating EJB2 beans with a LegacyEjbJndiPolicy (in the same way EJB3 is), but it was agreed that we should leave EJB2 as-is for the time being. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165985#4165985 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165985

17 years, 8 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 July 2008