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

[Design of EJB 3.0] - Re: ClientContainer injection

by scott.stark＠jboss.org

Only the server side handlers should be using the encInjections Map as this is for Class level annotations that go into the container enc. They should not be used in the client side ClientContaner environment. I have removed the encInjections from ClientContainer and am testing this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158838#4158838 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158838

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: ClientContainer injection

by alex.loubyansky＠jboss.com

Ok, thanks. So should the handlers add injectors they create to the container's List getInjectors() or Map<String, Map<AccessibleObject, Injector>> getEncInjections()? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158837#4158837 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158837

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: ClientContainer injection

by scott.stark＠jboss.org

Ok, I'm wrong in that the handlers still populate the injectors for the static field/method usage. There is no BeanContainer on the client side, so there never is an instance to inject into. The EncInjectors should not be used however. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158835#4158835 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158835

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: ClientContainer injection

by scott.stark＠jboss.org

Injectors are not used on the client. Any handler using the EncInjectors needs to be replaced on the client with one that does not. I'm going to remove all of the injector usage in the client and add exceptions to catch where it might be called. The enc setup happens on the server and the client simply references that prebuilt context through its java: url handler. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158833#4158833 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158833

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: ClientContainer injection

by alex.loubyansky＠jboss.com

Correction for the following: alexey wrote : | In loadXml(), a handler adds itself to the ClientContainer's list of handlers (so, later it gets inject call, see above). Of course, it doesn't add itself. Each handler creates the corresponding injector and adds it to the ClientContainer's list of injectors. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158832#4158832 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158832

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - ClientContainer injection

by alex.loubyansky＠jboss.com

Looks very confusing to me. This is what I see: this is what happens in the ctor of ClientContainer: first it calls processMetaData() which populates the list of injectors and then inject() is called on each injector: ... | processMetadata(null); | | for(Injector injector : injectors) | { | log.debug("injector: " + injector); | injector.inject((Object) null); | } | ... How can anything be injected into null? (except static) processMetaData does the following: handlers.add(new ClientEJBHandler<RemoteEnvironment>()); | handlers.add(new DependsHandler<RemoteEnvironment>()); | handlers.add(new JndiInjectHandler<RemoteEnvironment>()); | handlers.add(new PersistenceUnitHandler<RemoteEnvironment>()); | handlers.add(new ClientResourceHandler<RemoteEnvironment>(this.mainClass)); | handlers.add(new WebServiceRefHandler<RemoteEnvironment>()); | | for (InjectionHandler<RemoteEnvironment> handler : handlers) | handler.loadXml(xml, this); | In loadXml(), a handler adds itself to the ClientContainer's list of handlers (so, later it gets inject call, see above). But this is true only for the handlers that are in the jbossas/trunk, i.e. ClientEJBHandler and ClientResourceHandle. Other handlers (in the ejb3 project) add injectors to ClientContainer's encInjections which I don't see being used after that. Map<String, Map<AccessibleObject, Injector>> getEncInjections() Further, the following handlers in their loadXml() call ClientContainer.getEncInjectors() which is public Map<String, EncInjector> getEncInjectors() | { | throw new IllegalStateException("ENC setup happens on the server"); | } - JndiInjectHandler - PersistenceUnitHandler So, these are not going to work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158831#4158831 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158831

16 years, 3 months

1
0
0 / 0

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

by alessio.soldano＠jboss.com

Hi Emanuel, "emuckenhuber" wrote : | This also requires the processing of @HandlerChain? e.g.: | | | | @WebServiceRef | | @HandlerChain(file = "handler-chains.xml") | | | | Where the file contains the handler-chains like this file: https://svn.jboss.org/repos/jbossws/framework/trunk/testsuite/test/java/o... | | Which would be represented by ServiceReferenceHandlerChainsMetaData? | | I also looked briefly at processing ServiceReferenceHandlerMetaData, but this does not seem to be possible with annotations - or am i missing something? Generally speaking this use case (@HandlerChain on a service ref) should of course be supported. As far as I can see we don't have a testcase for this yet, thus I think I'll start creating one. I'll look at this more in deep tomorrow. Need to understand whether the processing you talk about is actually required or not, since the jbossws service ref binder seems to use the UnifiedServiceRefMetaData's String handlerChain attribute and read directly the @HandlerChain from the annotated element you provide us. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158826#4158826 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158826

16 years, 3 months

1
0
0 / 0

[Design of Security on JBoss] - Re: SecurityContext inherited by threads on the serverside

by scott.stark＠jboss.org

In the past it was configurable with a system property. See how the org.jboss.security.SecurityAssociation.ThreadLocal property affects whether or not the SecurityAssocation uses ThreadLocal or InheritableThreadLocal stores. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158807#4158807 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158807

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - test message

by blake.bowers＠jboss.com

please disregard View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158791#4158791 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158791

16 years, 3 months

1
0
0 / 0

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

by ALRubinger

Some notes regarding Jaikiran's patch now attached to EJBTHREE-1420: * Overall, the test looks good and follows the proper setup. :) * Needs LGPL Headers and Copyright info (these should be in the Eclipse templates I'd send along) * Tests must check not only the default local and remote bind values, but also those of the interface-specific bindings * 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. * 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 | } The important thing is that the test setup looks great. :) S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158786#4158786 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158786

16 years, 3 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