Posts Tagged ‘EJB’

David Blevins, a veteran in open-source Java EE and founder of projects like OpenEJB and TomEE, showcased Apache TomEE. With over a decade in specifications like EJB and CDI, David positioned TomEE as a bridge for Tomcat users seeking Java EE capabilities.

He polled the audience, revealing widespread Tomcat use alongside other servers, highlighting the migration pain TomEE addresses. David described TomEE as Tomcat enhanced with Java EE, unzipping Tomcat, adding Apache projects like OpenJPA and CXF, then certifying the bundle.

Emphasizing small size, certification, and Tomcat fidelity, David outlined distributions: Web Profile (minimal specs), JAX-RS (adding REST), and Plus (including JMS, JAX-WS).

Understanding the Web Profile

David clarified the Java EE 6 Web Profile, a subset of 12 specs from the full 24, excluding outdated ones like CORBA and CMP. This acknowledges Java EE’s growth, focusing on essentials for modern apps.

He noted exclusions like JAX-RS (added in EE 7) and inclusions like JavaMail in TomEE’s Web Profile for practicality. David projected EE 7’s profile reductions, potentially enabling full-profile TomEE certification.

Demonstrating TomEE in Action

In a live demo, David set up TomEE in Eclipse using Tomcat adapters, creating a servlet with EJB injection and JPA. He deployed seamlessly, showcasing CDI, transactions, and web services, all within Tomcat’s familiar environment.

David highlighted TomEE’s lightweight footprint—under 30MB—booting quickly with low memory. He integrated tools like Arquillian for testing, demonstrating in-container and embedded modes.

Advanced Features and Configuration

David explored clustering with Hazelcast, enabling session replication without code changes. He discussed production readiness, citing users like OpenShift and Jelastic.

Configuration innovations include flat XML-properties hybrids, human-readable times (e.g., “2 minutes”), and dynamic resource creation. David showed overriding via command-line or properties, extending for custom objects injectable via @Resource.

Error handling stands out: TomEE collects all deployment issues before failing, providing detailed, multi-level feedback to accelerate fixes.

Community and Future Directions

Celebrating TomEE’s first year, David shared growth metrics—surging commits and mailing lists—inviting contributions. He mentioned production adopters praising its simplicity and performance.

David announced a logo contest, encouraging participation. In Q&A, he affirmed production use, low memory needs, and solid components like OpenJPA.

Overall, David’s talk positioned TomEE as an empowering evolution for Tomcat loyalists, blending familiarity with Java EE power.

Links:

• David Blevins on LinkedIn
• David Blevins on Twitter/X
• Tomitribe website
• Apache TomEE website

Case

I ogten have to redeploy my JEE application on JOnAS. Basically, I stopped the server, copied the files (EAR, JAR, etc.), then started up again the server. I was fed up with implementing this method.
How to speed up?

Solution

Below is a proposal of solution, without any pretention (I am not fond of JOnAS…), based on an Ant script running under Maven. The code is commented, in a summary: build the EAR (or JAR, WAR, etc.), then copy it to JOnAS deploy folder, undeploy the beans, check which beans are still deployed, deploy the new version of the beans, check which beans are deployed:

[xml] <build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>copyToJonas</id>
<phase>install</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<property name="jonas.root" value="${env.JONAS_ROOT}"/>
<property name="jonas.base" value="${env.JONAS_BASE}"/>
<echo>Copy files</echo>
<copy todir="${jonas.base}/deploy" overwrite="true">
<fileset dir="${build.directory}/">
<include name="*.*ar"/>
</fileset>
</copy>
<echo>Undeploy beans</echo>
<exec executable="${jonas.root}/bin/jonas.bat">
<arg line="admin -r ${jonas.base}/deploy/${artifactId}-${version}.${packaging}"/>
</exec>
<echo>Currently deployed beans:</echo>
<exec executable="${jonas.root}/bin/jonas.bat">
<arg line="admin -j"/>
</exec>
<echo>Deploy beans:</echo>
<exec executable="${jonas.root}/bin/jonas.bat">
<arg line="admin -a ${jonas.base}/deploy/${artifactId}-${version}.${packaging}"/>
</exec>
<echo>Currently deployed beans:</echo>
<exec executable="${jonas.root}/bin/jonas.bat">
<arg line="admin -j"/>
</exec>
</target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>[/xml]

At first glance I assume I should swap the phases of copying file and undeploying beans. Anyway, this scripts works for me and allows to redeploy after each mvn clean install 😉

Case

On generating Locals and Remotes of EJBs (let’s say JonathanBean) to be deployed on JOnAS, the GenIC raises:
[java]GenIC.fatalError : GenIC fatal error: Cannot read the Deployment Descriptors from /foo/goo/jonathan-server.jar: Method foo of interface lalou.jonathan.JonathanLocal should NOT throw RemoteException[/java]

Within the EJB2, the method foo is declared to be Local and to throw RemoteException

Quickfix

The error is explicit.

A Local EJB cannot throw RemoteException.
Especially, the considered method can be declared with the right XDocLet tag, ie:

[java]* @ejb.interface-method view-type="remote"[/java]

but can with neither:
[java]* @ejb.interface-method view-type="both"[/java]

nor:
[java]* @ejb.interface-method view-type="local"[/java]

As a quickfix, I suggest to surround with a try/catch block a throw a RuntimeException if needed.

On server side:

an EJB2 packaged in a JAR within an EAR, deployed on JOnAS 5.

On client side:

java.lang.ClassNotFoundException: org.ow2.jonas_gen.com.clam.indice.api.interfaces.JOnASHelloWorldService150707405Home_Stub (no security manager: RMI class loader disabled)]

Explanation:

This means there is some kind of issue with generated Stubs on client side. Should check whether the Stubs depended on are available in classpath.

Abstract

How to set dynamically the URL used by a HttpInvokerProxyFactoryBean in a Spring-deployed WAR?

Detailed Case

I have to deploy a GWT/GXT application, calling two distant services:
a remote EJB
a service accessed through Spring Remoting

Here is the Spring configuration file I firstly used:

[xml]
<util:properties id="jndiProperties" location="classpath:jndi.properties"/>
<jee:remote-slsb id="myRemoteEJBService" jndi-name="ejb.remote.myRemoteService"
business-interface="lalou.jonathan.myRemoteEJBService"
environment-ref="jndiProperties" cache-home="false"
lookup-home-on-startup="false" refresh-home-on-connect-failure="true" />

<bean id="mySpringRemoteService"
class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
<property name="serviceInterface"
value="lalou.jonathan.services.mySpringRemoteService" />
<property name="serviceUrl" value="${spring.remote.service.url}"/>
</bean>
[/xml]

Unhappily, even though the remote EJB is retrieved (which proves that the jndi file is available in the classpath and rightly loaded), the Spring Remote service is not. I had to write the URL in hard in the configuration file… This is not very efficient when you work in a large team, with different production and testings environments!

This is the log when myRemoteEJBService bean is loaded:
[java]2010-08-17 16:05:42,937 DEBUG support.DefaultListableBeanFactory – Creating shared instance of singleton bean ‘myRemoteEJBService’
2010-08-17 16:05:42,937 DEBUG support.DefaultListableBeanFactory – Creating instance of bean ‘myRemoteEJBService’
2010-08-17 16:05:42,937 DEBUG support.DefaultListableBeanFactory – Eagerly caching bean ‘myRemoteEJBService’ to allow for resolving potential circular references
2010-08-17 16:05:42,937 DEBUG support.DefaultListableBeanFactory – Returning cached instance of singleton bean ‘jndiProperties’
2010-08-17 16:05:42,937 DEBUG support.DefaultListableBeanFactory – Invoking afterPropertiesSet() on bean with name ‘myRemoteEJBService’
2010-08-17 16:05:42,937 DEBUG framework.JdkDynamicAopProxy – Creating JDK dynamic proxy: target source is EmptyTargetSource: no target class, static
2010-08-17 16:05:42,953 DEBUG support.DefaultListableBeanFactory – Finished creating instance of bean ‘myRemoteEJBService'[/java]

That is the log when mySpringRemoteService is loaded:
[java]2010-08-17 16:05:42,968 DEBUG support.DefaultListableBeanFactory – Creating shared instance of singleton bean ‘mySpringRemoteService’
2010-08-17 16:05:42,968 DEBUG support.DefaultListableBeanFactory – Creating instance of bean ‘mySpringRemoteService’
2010-08-17 16:05:42,984 DEBUG support.DefaultListableBeanFactory – Eagerly caching bean ‘mySpringRemoteService’ to allow for resolving potential circular references
2010-08-17 16:05:43,234 DEBUG support.DefaultListableBeanFactory – Invoking afterPropertiesSet() on bean with name ‘mySpringRemoteService’
2010-08-17 16:05:43,250 DEBUG framework.JdkDynamicAopProxy – Creating JDK dynamic proxy: target source is EmptyTargetSource: no target class, static
2010-08-17 16:05:43,250 DEBUG support.DefaultListableBeanFactory – Finished creating instance of bean ‘mySpringRemoteService'[/java]

You can notice that no mention to jndiProperties appears. Here is the key of the problem: jndiProperties is considered as a bean among others, which cannot be accessed easyly from the HttpInvokerProxyFactoryBean.

Fix

To fix the issue, you have to add an actual property holder in Spring XML configuration file, ie after:

[xml]<util:properties id="jndiProperties" location="classpath:jndi.properties"/>[/xml]

add an instanciation of PropertyPlaceholderConfigurer:

[xml]<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location" value="classpath:jndi.properties"/>
</bean>[/xml]

Abstract

Let’s assume you have followed the article “Basic RPC call with GWT“. Now you would like to call an actual EJB 2 as remote, via a Spring lookup.
Let’s say: you have an EJB MyEntrepriseComponentEJB, which implements an interface MyEntrepriseComponent. This EJB, generates a remote MyEntrepriseComponentRemote.

Entry Point

In myApplication.gwt.xml entry point file, after the line:

[xml]<inherits name=’com.google.gwt.user.User’/>[/xml]

add the block:

[xml]
<inherits name=’com.google.gwt.user.User’ />
<inherits name="com.google.gwt.i18n.I18N" />
<inherits name="com.google.gwt.http.HTTP" />[/xml]

Add the line:

[xml]<servlet path=’/fooService.do’/>[/xml]

Client

Under the *.gwt.client folder:

Update the service interface. Only the annotation parameter is amended:

[java]@RemoteServiceRelativePath("services/fooService")
public interface FooService extends RemoteService {
public String getHelloFoo(String fooName);
}[/java]

You have nothing to modify in asynchronous call interface (FooServiceAsync).

Server

Under the *.gwt.server folder, update the implementation for service interface:

Change the super-class, replacing RemoteServiceServlet with GWTSpringController:

[java]public class FooServiceImpl extends GWTSpringController implements FooService {
public FooServiceImpl() {
// init
}
}
[/java]

Add new field and its getter/setter:

[java]// retrieved via Spring
private myEntrepriseComponent myEntrepriseComponent;

public myEntrepriseComponent getMyEntrepriseComponent() {
return myEntrepriseComponent;
}

public void setmyEntrepriseComponent(myEntrepriseComponent _myEntrepriseComponent) {
myEntrepriseComponent = _myEntrepriseComponent;
}[/java]

Write the actual call to EJB service:

[java]
public String getHelloFoo(String fooName) {
return myEntrepriseComponent.getMyDataFromDB();
}
}[/java]

web.xml

Fill the web.xml file:

[xml]<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>

<!– Spring –>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<servlet>
<servlet-name>gwt-controller</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>gwt-controller</servlet-name>
<url-pattern>/myApplication/services/*</url-pattern>
</servlet-mapping>

<!– Default page to serve –>
<welcome-file-list>
<welcome-file>MyApplicationGwt.html</welcome-file>
</welcome-file-list>

</web-app>
[/xml]

JNDI

Add a jndi.properties file in src/resources folder:

[java]
java.naming.provider.url=t3://localhost:12345
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.security.principal=yourLogin
java.naming.security.credentials=yourPassword
weblogic.jndi.enableDefaultUser=true[/java]

These properties will be used by Spring to lookup the remote EJB. The last option is very important, otherwise you may happen to face issues with EJB if they were deployed under WebLogic.

WEB-INF

In the WEB-INF folder, add an applicationContext.xml file:

[xml]<?xml version="1.0" encoding="UTF-8"?>
<beans>

<util:properties id="jndiProperties" location="classpath:jndi.properties" />

<jee:remote-slsb id="myEntrepriseComponentService"
jndi-name="ejb.jonathan.my-entreprise-component"
business-interface="lalou.jonathan.myApplication.services.myEntrepriseComponent"
environment-ref="jndiProperties" cache-home="false"
lookup-home-on-startup="false" refresh-home-on-connect-failure="true" />

</beans>[/xml]

Add a gwt-controller-servlet.xml file:

[xml]<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd">

<bean>
<property name="order" value="0" />
<property name="mappings">
<value>
/fooService=fooServiceImpl
</value>
</property>
</bean>

<bean id="fooServiceImpl"
class="lalou.jonathan.myApplication.web.gwt.server.FooServiceImpl">
<property name="myEntrepriseComponent" ref="myEntrepriseComponentService" />
</bean>
</beans>
[/xml]

Of course, if your servlet mapping name in web.xml is comoEstasAmigo, then rename gwt-controller-servlet.xml as comoEstasAmigo-servlet.xml 😉

Build and deploy

Now you can compile, package your war and deploy under Tomcat or WebLogic. WebLogic server may raise an error:
java.rmi.AccessException: [EJB:010160]Security Violation: User: '<anonymous>' has insufficient permission to access EJB
This error is related to the rights required to call a method on the EJB. Indeed, two levels of rights are used by WebLogic: firstly to lookup / instanciate the EJB (cf. the property java.naming.security.principal we set sooner), and another to call the method itself. In this second case, WebLogic requires an authentication (think of what you do when you login an web application deployed: your login and rights are kept for all the session) to grant the rights. I wish to handle this subject in a future post.

NB: thanks to David Chau and Didier Girard from SFEIR, Sachin from Mumbai team and PYC from NYC.

Recent history

BEA WebLogic 9.0, 9.1 and 9.2 were released from 2007: the main features were: a new console, WLST (WebLogic ScriptingTool), deployment plans, WebLogic Diagnostic Framework (WLDF), new security providers (RDBMS, SAML 1.1, etc.), JMS performance improvements, support of Java EE 4, JDK 5, Spring, OpenJPA, Kodo, etc.

Since this date, some events happened:

• Oracle bought Sun (2009)
• Oracle released WebLogic 10.3 (2008)
• Oracle bought BEA (2008)

WebLogic Server 10 General Features

• Developer productivity ehancements
  • JDK 6, Java EE 5
  • Support of EJB3 and JPA
  • BEA enhancements
• Web Services: more annotations, less XML
  • JAX-RPC Web Services Enhancements
  • JAX-WS 2.0 Web Services Implementation
• Misc:
  • Better administration console
  • Auto-Record of Admin Console actions as WLST scripts
  • Automatic JTA Transaction Recovery Service (TRS) migration
  • SNMP 3.0
  • Production Application Redeployment enhancements
  • Clustering – Unicast messaging (in addition to Multicast)

Programmer Perspective

• New persistence engine: TopLink
• OEPE (Oracle Entreprise Pack for Eclipse): sequence of tools and plugins for Eclipse: remote deployment, debugging,  editors for weblogic.xml and weblogic-application.xml, wizards, facets, Weblogic ClientGen, WSDLC and JAXB wizards
• Optimizations for Spring integration and certication
• Web 2.0:
  • Ajax / Dojo client support
  • Http publish / submit engine for collaborative applications:
    • Bayeux protocol
    • data exchange within applications over persistent connections
    • scalability for Dojo clients
• Ad-hoc tools for:
  • Oracle Database
  • Spring
  • JAX-WS webservices

Lightweight WebLogic Server

WebLogic 10 offers a light weight server:

• Install only “core” WebLogic server
• Optionally, startup other services (JDBC, EJB, JMS, etc.)
• FastSwap: modify classes without requiring redeployment.

Architect Perspective

Architects have to consider WebLogic as a complete suite, and not only WebLogic Server:

• Oracle RAC integration: Connectivity to RAC with load balancing, failover, transactions
• Enterprise Messaging with JMS: High performance and reliable JMS messaging engine “built-in”
• ActiveCache with Coherence*Web and EJB/JPA: Coherence Data Grid caching included and integrated
• Operations Automation: Tools for automating management of applications and servers
• Operations Insight: Tools for diagnosing problems in development and production
• Other features
  • Development tools: Choice of tools for developer productivity
  • Web Services: Enterprise Web Services for SOA
  • TopLink: Persist application data to stores with performance and productivity. It works in a way similar to Hibernate L2 cache.
  • Spring: Enable flexible choice of dev frameworks with same WebLogic QOS

Production and Support Perspective

WebLogic 10 provides a tool: JRockit Mission Control

• monitors more than 150 parameters:
• CPU
  • memory
  • leaks
  • latency spikes
  • threads
  • object references
  • JDBC connections
  • JMS
  • pools
  • clusters
  • configuration files
  • etc.
• allows to compare WebLogic domains
• Runtime Analyzer: runtime capture for offline analysis, Garbage Collector analysis, etc.

Coherence – ActiveCache

Coherence is the Data Grid offered by Oracle. It allows to store Java objects in memory, and share them between all instances. From a certain viewpoint, Coherence looks like the GigaSpaces.

Roadmap for Future WebLogic Releases

• Support of Java EE 6 (ratified by the community in last December)
• OSGi deployment
• More native integration for WebLogic Server – Coherence – Oracle Database
• JRockit Flight Recorder for constant record
• Virtualization
• More integration with Maven, Hudson and Cruise Control
• Shared Library: use the same JAR for many applications, rather than packing the same JAR in different EARs.
• On long term:
  • IDE
    • NetBeans to be oriented onto J2ME development
    • JDevelopper to remain Oracle strategic IDE
    • Contributions to Eclipse to go on
  • JRockit and Sun HotSpot JVMs to be merged.

Case

On redeploying the application myFooApplication, this error appears:

[EJB:011055]Error deploying the EJB 'myFooSession(Application: foo-ejbfoo-ear, EJBComponent: foo-foo-services-ejb-0-DEV.jar)', the JNDI name 'ejb.foo.foo-session-bean' is already in use. You must set a different JNDI name in the weblogic-ejb-jar.xml deployment descriptor for this EJB before it can be deployed.

Fix

• Stop the server
• Delete all files and folders in ${WL_HOME}\servers\myFooApplication.
• Restart the server

You may encounter an error [Deployer:149163]. In this case, I suggest you to consult the related article: The domain edit lock is owned by another session in exclusive mode – hence this deployment operation cannot proceed

Case

• let’s consider an EJB Bean AnimalBean, linked to a table JL_Animal
• let’s have a human understandable name for the Pojo, let’s say: Animal
• let an EJB entity have following finders:

[java]
* @ejb.finder
* signature = "Collection findByBirthDate(java.lang.Integer birthDate)"
* query = "SELECT OBJECT(o) FROM AnimalBean AS o WHERE o.birthDate = ?1"
*
* @ejb.finder
* signature = "Collection findByCountryAndBirthDate(java.lang.String from,java.lang.Integer birthDate)"
* query = "SELECT OBJECT(o) FROM AnimalBean AS o WHERE o.country = ?1 AND o.birthDate = ?2"[/java]

Read the rest of this entry »

Error:

javax.ejb.EJBException: EJB Exception: : org.hibernate.id.IdentifierGenerationException: ids for this class must be manually assigned before calling save():

Fix: You must assign the primary-key (which is probably a composite-id) before saving the object.