Hi Reza,
Stripes Injection Enricher supports CDI.
However for those using Stripes Framework with Java EE 5 that is not an
option.
We are already doing a lookup behind the scenes as I've described in a
previous mail, both in Stripes Injection Enricher and in JBoss Arquillian:
https://github.com/samaxes/stripes-injection-enricher/blob/master/src/main/java/com/samaxes/stripes/enricher/EJBInjectionEnricher.java
https://github.com/arquillian/arquillian-core/blob/master/testenrichers/ejb/src/main/java/org/jboss/arquillian/testenricher/ejb/EJBInjectionEnricher.java
Best,
--
Samuel Santos
http://www.samaxes.com/
On Wed, Feb 15, 2012 at 1:51 AM, Reza Rahman <reza_rahman_at_lycos.com> wrote:
> Again, you can either do this through straight CDI or writing a simple
> CDI extension. Otherwise, your stuck trying to resolve the JNDI name and
> doing a look-up behind the scenes (not rocket science either really).
>
>
> On 2/14/2012 8:04 PM, Samuel Santos wrote:
>
> Hi David,
>
> Yes, perform @EJB injection without having to specify the full JNDI name
> (i.e. @EJB(lookup = "FULL_JNDI_NAME")) on objects inside the container
> that are *not* managed by it.
> That is why we need plugins like Stripes Injection Enricher that I
> mentioned earlier.
>
> Best,
>
> --
> Samuel Santos
> http://www.samaxes.com/
>
>
> On Wed, Feb 15, 2012 at 12:32 AM, Reza Rahman <reza_rahman_at_lycos.com>wrote:
>
>> You can use CDI to do this.
>>
>>
>> On 2/14/2012 7:29 PM, David Blevins wrote:
>>
>>> Hi Samuel,
>>>
>>> To make sure I'm understanding correctly, it looks like what you really
>>> want is to perform @EJB injection on objects running inside the container.
>>> Is that more or less the high-level goal?
>>>
>>>
>>> -David
>>>
>>> On Feb 10, 2012, at 10:51 AM, Samuel Santos wrote:
>>>
>>> Hi Marina,
>>>>
>>>> Judging from your reply, my text was not clear enough.
>>>> I apologize for that, English is not my first language.
>>>> I will try to exemplify it using code.
>>>>
>>>> Lets say that the project has the following structure:
>>>>
>>>> EAR
>>>> |-- EJBJAR
>>>> | |-- FooService.java
>>>> | `-- FooServiceBean.java
>>>> `-- WAR
>>>> |-- BarActionBean.java
>>>> |-- WEB-INF
>>>> | `-- web.xml
>>>>
>>>> Guessing JNDI names as we do in Stripes Injection Enricher [1] or in
>>>> JBoss Arquillian [2] will not allow us to inject an EJB in
>>>> BarActionBean.java like this:
>>>> class BarActionBean {
>>>> @EJB
>>>> FooService fooService;
>>>> }
>>>>
>>>> We must always specify the lookup or mappedName elements of the @EJB
>>>> annotation:
>>>> class BarActionBean {
>>>> @EJB(lookup =
>>>> "java:global/EAR/EJBJAR/FooServiceBean!com.foo.bar.FooService")
>>>> // or @EJB(lookup = "java:global/EAR/EJBJAR/FooServiceBean")
>>>> // or @EJB(lookup =
>>>> "java:app/EJBJAR/FooServiceBean!com.foo.bar.FooService")
>>>> // or @EJB(lookup = "java:app/EJBJAR/FooServiceBean")
>>>> FooService fooService;
>>>> }
>>>>
>>>> What I'm trying to suggest is to have a standard allowing us to
>>>> configure a project (in this example the WAR archive) to lookup for EJBs in
>>>> external modules.
>>>>
>>>> Either by defining them in the deployment descriptor:
>>>> <jndi-lookup>
>>>> <modules>
>>>> <module>EJBJAR</module>
>>>> <module>FOOJAR</module>
>>>> <module>BARJAR</module>
>>>> <module>...</module>
>>>> </modules>
>>>> </jndi-lookup>
>>>>
>>>> Or in a properties file (e.g. jndi.properties):
>>>> jndi.lookup.modules=EJBJAR,FOOJAR,BARJAR,...
>>>>
>>>> That way we can read those configurations and lookup for the EJBs in
>>>> that particular modules without defining the entire JNDI name each time we
>>>> need to inject an EJB.
>>>>
>>>> [1]
>>>> https://github.com/samaxes/stripes-injection-enricher/blob/master/src/main/java/com/samaxes/stripes/enricher/EJBInjectionEnricher.java
>>>> [2]
>>>> https://github.com/arquillian/arquillian-core/blob/master/testenrichers/ejb/src/main/java/org/jboss/arquillian/testenricher/ejb/EJBInjectionEnricher.java
>>>>
>>>> Thank you and best regards,
>>>>
>>>> --
>>>> Samuel Santos
>>>> http://www.samaxes.com/
>>>>
>>>>
>>>> On Fri, Feb 10, 2012 at 2:37 AM, Marina Vatkina<
>>>> marina.vatkina_at_oracle.com> wrote:
>>>> Samuel,
>>>>
>>>> EJB spec (see 4.4.1.1java:app and 4.4.1.2java:module) is clear that you
>>>> should use "java:app/ModuleName" to access beans in other modules in your
>>>> EAR file and "java:module/BeanName" to access beans in the same EJB module.
>>>>
>>>> Best,
>>>> -marina
>>>>
>>>>
>>>> Samuel Santos wrote:
>>>> Hi all,
>>>>
>>>> I find the Global JNDI Namespace, and finally having portable names
>>>> across different containers, a really neat feature.
>>>> However, it still is not easy to inject EJB from different modules
>>>> inside an EAR archive.
>>>>
>>>> I'm working on a small open source project [1] to support @EJB, @Inject
>>>> and @Resource standard Java EE annotations on Stripes Framework [2] using
>>>> portable JNDI names.
>>>> As you can see by looking at the code [1], I'm using
>>>> context.lookup("java:app/AppName") and
>>>> context.lookup("java:module/ModuleName") to build the JNDI names to lookup.
>>>>
>>>> Unfortunately it only works as long as you are injecting EJBs inside
>>>> the same module where it is.
>>>> If you have an EAR with two modules, one WAR and one EJB, and try to
>>>> inject an EJB in a class inside the WAR, the code will not work.
>>>> We have to define the full JNDI name in the mappedName or lookup
>>>> elements of the @EJB annotation every time we are injecting a session bean
>>>> in a class inside the WAR archive.
>>>>
>>>> I believe it is the role of the EJB spec to make this easier.
>>>> Can we define a way to configure projects to lookup for JNDI names in
>>>> other modules (e.g. by defining/enumerating them in web.xml or other
>>>> deployment descriptor)?
>>>>
>>>> [1]
>>>> https://github.com/samaxes/stripes-injection-enricher/blob/master/src/main/java/com/samaxes/stripes/enricher/EJBInjectionEnricher.java
>>>> [2] http://www.stripesframework.org
>>>>
>>>> Thanks and best regards,
>>>>
>>>> --
>>>> Samuel Santos
>>>> http://www.samaxes.com/
>>>>
>>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2012.0.1913 / Virus Database: 2112/4809 - Release Date: 02/14/12
>>>
>>>
>>>
>>>
>>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2112/4809 - Release Date: 02/14/12
>
>
>