Hello everybody,
Together with Mark I was able to solve my issues. However, I would like to
send it to everyone, so that if anybody has this problem again, they can
use this thread as a reference.
So, to remind you again, I have a special Tomcat based environment, where
the only manipulation I can bring is via the application deployment. That
is, I can't add any jars to the tomcat/lib directory, nor I can touch the
server configuration. At the same time I would like to use CDI.
So, in the above described conditions, I *can* have CDI if the following
dependencies declared in pom.xml:
<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>org.apache.openwebbeans</groupId>
<artifactId>openwebbeans-spi</artifactId>
<version>${owb.version}</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.openwebbeans</groupId>
<artifactId>openwebbeans-impl</artifactId>
<version>${owb.version}</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.openwebbeans</groupId>
<artifactId>openwebbeans-web</artifactId>
<version>${owb.version}</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.openwebbeans</groupId>
<artifactId>openwebbeans-tomcat7</artifactId>
<version>${owb.version}</version>
<scope>runtime</scope></dependency>
This will bring the power of CDI (injection, interceptors, etc.) to all my
classes, but the Servlets. If I don't want to touch tomcat/lib, then in
order to get the closes to the Java EE dev experience, I had to use
Deltaspike's BeanManager. So, I needed some more dependencies in my pom.xml:
<dependency>
<groupId>org.apache.deltaspike.core</groupId>
<artifactId>deltaspike-core-api</artifactId>
<version>${deltaspike.version}</version>
</dependency>
<dependency>
<groupId>org.apache.deltaspike.core</groupId>
<artifactId>deltaspike-core-impl</artifactId>
<version>${deltaspike.version}</version>
<scope>runtime</scope>
</dependency>
And then in the Servlet's init method I could do things like that:
@Override
public void init() throws ServletException {
recorder =
BeanProvider.getContextualReference(ServiceMethodInvocationRecorder.class,
false);
dataImporter =
BeanProvider.getContextualReference(DataImporter.class, false);
dataSummarizer =
BeanProvider.getContextualReference(DataSummarizer.class, false);
}
The final requirement that I had, was to have the entity manager produced
by CDI and not by some hand crafted class of mine. So, here Mark proposed
another Deltaspike extension:
<dependency>
<groupId>org.apache.deltaspike.modules</groupId>
<artifactId>deltaspike-jpa-module-api</artifactId>
<version>${deltaspike.version}</version>
</dependency>
<dependency>
<groupId>org.apache.deltaspike.modules</groupId>
<artifactId>deltaspike-jpa-module-impl</artifactId>
<version>${deltaspike.version}</version>
<scope>runtime</scope>
</dependency>
And the following producer class:
@ApplicationScoped
public class EntityManagerProducer {
@Inject
@PersistenceUnitName("perf-servicetest-local")
private EntityManagerFactory entityManagerFactory;
@Produces
@RequestScoped
public EntityManager buildEntityManager() {
return entityManagerFactory.createEntityManager();
}
public void dispose(@Disposes EntityManager entityManager) {
entityManager.close();
}
}
Note that the scope of the factory method of the entity manager is Request.
This seemed to be very important.
Afterwards, there is nothing special in injecting the entity manager: you
do it via the @Inject annotation in the beans and via Deltaspike's
BeanManager in Servlets.
Another important concern in such non-managed environments is that there is
one central place where transactions are started and commited/rolled back.
In my case this is the servlet, which controls the boundaries and delegates
the business logic to the beans that the BeanManager created for it:
private void exportData() {
entityManager.getTransaction().begin();
try {
recorder.exportDataToOtherSource(dataImporter);
entityManager.getTransaction().commit();
} finally {
if (entityManager.getTransaction().isActive()) {
entityManager.getTransaction().rollback();
}
}
}
So, great thanks again to Mark for his tremendous support!
Cheers,
Ivan
On Mon, Jan 5, 2015 at 7:13 PM, Mark Struberg <[email protected]> wrote:
> Hi Ivan!
> Sorry, simply forgot about it. Will look at it today.
> Thanks for remembering me ;)
>
> LieGrue,
> strub
>
>
> On Monday, 5 January 2015, 16:54, Ivan St. Ivanov <
> [email protected]> wrote:
>
>
>
> Hi folks,
>
> Happy New Year! :)
>
> Did you manage to take a look at my sample app?
>
> Thanks,
> Ivan
>
> On Tue, Dec 23, 2014 at 2:31 PM, Ivan St. Ivanov <[email protected]
> > wrote:
>
> Hi,
>
> Thanks everybody for your quick answer!
>
> It's not on github. I have attached the sources to this mail.
>
> Regards,
> Ivan
>
> On Tue, Dec 23, 2014 at 1:19 PM, Ludovic Pénet <[email protected]> wrote:
>
> Quick question : do you have a beans.xml file ?
>
> Ludovic
>
> Le 23 décembre 2014 10:05:26 UTC+01:00, "Ivan St. Ivanov" <ivan.st.
> [email protected]> a écrit :
>
> Hello,
>
> I have a question about integrating OpenWebBeans with a pure Tomcat server.
>
> I looked for some solutions in the internet and here is what I did with my
> project:
>
> First I added some dependencies to the pom.xml:
>
> <*dependency*>
> <*groupId*>javax.enterprise</*groupId*>
> <*artifactId*>cdi-api</*artifactId*>
> <*version*>1.2</*version*>
> </*dependency*>
> <*dependency*>
> <*groupId*>org.apache.openwebbeans</*groupId*>
> <*artifactId*>openwebbeans-spi</*artifactId*>
> <*version*>1.2.7</*version*>
> </*dependency*>
> <*dependency*>
> <*groupId*>org.apache.openwebbeans</*groupId*>
> <*artifactId*>openwebbeans-impl</*artifactId*>
> <*version*>1.2.7</*version*>
> </*dependency*>
> <*dependency*>
> <*groupId*>org.apache.openwebbeans</*groupId*>
> <*artifactId*>openwebbeans-web</*artifactId*>
> <*version*>1.2.7</*version*>
> </*dependency*>
>
> Having them, I was able to compile and deploy my project, however the
> dependency injection simply did not work.
>
> Then I additionally added the following dependency:
>
> <*dependency*>
> <*groupId*>org.apache.openwebbeans</*groupId*>
> <*artifactId*>openwebbeans-tomcat7</*artifactId*>
> <*version*>1.2.7</*version*>
> </*dependency*>
>
>
> And also created context.xml file under the src/main/webapp/META-INF
> folder of my app with the following content:
>
> <*Context*>
> <
> *Listener className=
> "org.apache.webbeans.web.tomcat7.ContextLifecycleListener" */>
> </*Context*>
>
> However, this time I had deployment issue:
>
> Dec 22, 2014 6:54:28 PM org.apache.tomcat.util.digester.Digester
> startElement
> SEVERE: Begin event threw exception
> java.lang.ClassNotFoundException:
> org.apache.webbeans.web.tomcat.ContextLifecycleListener
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at
> org.apache.tomcat.util.digester.ObjectCreateRule.begin(ObjectCreateRule.java:144)
> at
> org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1288)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509)
>
> I tried to tackle that with adding the OWB jars in the tomcat/lib folder.
> But gave it up after the fifth ClassNotFoundError. It is not an option for
> me anyway: I am not in control of the productive server, so I cannot touch
> its lib directory.
>
> I also looked in the OpenWebBeans samples, but they don't even package the
> jars with them.
>
> Can anyone share their experience with me?
>
> Thanks a lot!
> Ivan
>
>
>
>
> --
> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
>
> |
> | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
> |
>
>
>
>
>
>
