Freitag Dez 11, 2009

JEE5 EAR EJB Deplyoment

Today I found this wunderfull article about EJB Deploymen tin JEE5:

http://www.developer.com/java/ejb/article.php/10931_3670496_1/Packaging-EJB-3-Applications.htm

I think this article is helpfully for anyone how struggles with deployment strategies in JEE5 EARs.

I do this fight currently as I try to find out the best way to deploy the Imixs JEE Worklfow components in an enterprise application.... ;-)


 

 

Donnerstag Jul 09, 2009

Glassfish TimerService - Expunging timer after failed deliveries

On my glassfish installation I am running different TimerServices. In one I saw the problem that the TimerService stopped unexpected after running more than 20 hours. 

In this situations a exeption is logged by the server like this one:

[#|2009-07-09T03:10:56.375+0200|INFO|sun-appserver2.1|javax.enterprise.system.container.ejb|_ThreadID=15;_ThreadName=p: thread-pool-1; w: 4;'1@@1247059844937@@server@@domain1' 'TimedObject = ScheduledWorkflowServiceImplementation' 'Application = myapp.ear-1.3.4' 'BEING_DELIVERED' 'PERIODIC' 'Container ID = 81721584505847814' 'Wed Jul 08 15:30:44 CEST 2009' '600000' ;2;|EJB5119:Expunging timer ['1@@1247059844937@@server@@domain1' 'TimedObject = ScheduledWorkflowServiceImplementation' 'Application = myapp.ear-1.3.4' 'BEING_DELIVERED' 'PERIODIC' 'Container ID = 81721584505847814' 'Wed Jul 08 15:30:44 CEST 2009' '600000' ] after [2] failed deliveries|#]

There is a Bugreport concerning this issue:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=4634

and also this discussion thread:

http://forums.java.net/jive/thread.jspa?messageID=219367

arround this toppic.

Now I will test if changing the TimerService settings in the EJB Containterconfiguration will solve the problem.

First I will change the following Params

  • "Maximum Redeliveries" from "1" -> "16"
  • "Redelivery Interval" from 5000 -> 30000

 not sure if this will help....


Mittwoch Apr 15, 2009

Using @runas in EJB 3.0

Today I implemented a EJB where I used the @runas annotation the first time.

This annotation allows you to skip over the security settings in your EJB module. I use the Imixs IX JEE Workflow so I have to deal with the workflow IX Workflow roles. My new EJB should create a new workflow task triggered by a not authenticated user (anonymous). So my EJB need the workflow role "org.imixs.ACCESSLEVEL.AUTHORACCESS" to get access to the workflow model and the grant to create a new workitem. This can be decleared by the @runas annotation in the EJB implemenation


package org.imixs.business;

....
@Stateless
@DeclareRoles( { "org.imixs.ACCESSLEVEL.AUTHORACCESS" })
@RunAs("org.imixs.ACCESSLEVEL.AUTHORACCESS")
public class ContactServiceBean implements ContactService {

// Workflow Manager
@EJB
org.imixs.workflow.jee.ejb.WorkflowManager wm;
ItemCollection workItem = null;

/**
* This method creates a new Contact worktiem.
*/
public ItemCollection create() throws Exception {
// create emtpy workitem
workItem = wm.createWorkItem(INITIAL_PROCESS);
workItem.replaceItemValue("type", "contact");
return workItem;
}
.....
}

Next it is necessary (I am running on Glassfish server) to add a User Principal to the sun-ejb-jar.xml and also declare the pricipal:

sun-ejb-jar.xml:

 

 <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 EJB 3.0//EN" "http://www.sun.com/software/appserver/dtds/sun-ejb-jar_3_0-0.dtd">
<sun-ejb-jar>
<security-role-mapping>
<role-name>org.imixs.ACCESSLEVEL.READERACCESS</role-name>
<principal-name>org.imixs.ACCESSLEVEL.READERACCESS</principal-name>
</security-role-mapping>
<security-role-mapping>
<role-name>org.imixs.ACCESSLEVEL.AUTHORACCESS</role-name>
<principal-name>org.imixs.ACCESSLEVEL.AUTHORACCESS</principal-name>
</security-role-mapping>
<security-role-mapping>
<role-name>org.imixs.ACCESSLEVEL.EDITORACCESS</role-name>
<principal-name>org.imixs.ACCESSLEVEL.EDITORACCESS</principal-name>
</security-role-mapping>
<security-role-mapping>
<role-name>org.imixs.ACCESSLEVEL.MANAGERACCESS</role-name>
<group-name>IMIXS-WORKFLOW-Manager</group-name>
<principal-name>WorkflowScheduler</principal-name>
</security-role-mapping>
<enterprise-beans>
<ejb>
<ejb-name>ContactServiceBean</ejb-name>
<jndi-name>ejb/ShareyourworkContactServiceBean</jndi-name>
<principal><name>WorkflowScheduler</name></principal>
</ejb>
</enterprise-beans>
</sun-ejb-jar>


Now the principal "WorkflowScheduler" is named as a principal in my EJB declaration and is mapped to the role "org.imixs.ACCESSLEVEL.MANAGERACCESS" this user will be able to call my EJB methods. As this role is declared as a @runas role in my contactEJB the principal "WorkflowScheduler" will be used by the EJB container to run the methods in my ejb.


Sonntag Jul 06, 2008

using JNDI MailSession in Glassfish

Today I played around a long time figuring out how to lookup a Java Mail Session out of a EJB from Glassfish. This is the link which finaly helps me through:

http://forums.java.net/jive/thread.jspa?messageID=260133&#260133

before I read a lot of pages like:

https://glassfish.dev.java.net/javaee5/docs/DG/beaow.html

http://forums.java.net/jive/thread.jspa?messageID=265263&#265263

The problem for me was the lookup like thisone:

 Context ic = new InitialContext();
Session session = (Session)ic.lookup("java:comp/env/mail/testSession");

 To avoid a :

javax.naming.NameNotFoundException: No object bound to name java:comp/env/mail/testSession

 it is importend to add the right name mapping to the ejb-jar.xml and also to the sun-ejb-jar.xml

to the ejb-jar.xml add the following code to that EJB which makes the lookup:        

    <resource-ref>
        <res-ref-name>mail/testSession</res-ref-name>
        <res-type>javax.mail.Session</res-type>
        <res-auth>Container</res-auth>
        <res-sharing-scope>Shareable</res-sharing-scope>
    </resource-ref>

And to the sun-ejb-jar.xml file add the following to the same EJB

 <resource-ref>
        <res-ref-name>mail/testSession</res-ref-name>
        <jndi-name>testSession</jndi-name>
 </resource-ref>

Notice that this is only necessary to perform a jndi lookup. I think you can save oneself this using dependency injection using annotations (@ressource)