Java

Glassfish V2 and Atlassian's Jira and Confluence

2007-04-23T22:28:00.000-07:00

Hi,

just want to let you know some great news about Glassfish V2. I am one of the lucky ones using Atlassian's collaboration tools Jira and Confluence. Until last week I've run the standalone versions which use tomcat. I had several mroe collaboration tools running on different servers which has been difficult to operate and administrate and wasted a lot of resources. Now I've deployed most of the stuff I need on Glassfish V2 b41c (running on JDK 1.6.0)
I've read the following blog Jira and Glassfish describing how to install and configure Jira. That was very helpful. Deploying Confluence is even easier. Everything is straigt forward. I had nothing to tweak. I am using Oracle and had to copy the ojdbc.jar into Glassfish's root lib. Then I've created the JDBC connection pool and resources. I used jdbc/ConfluenceDS and jdbc/JiraDS. Then I've edited the following files:

/confluence/WEB-INF/classes/confluence-init.properties.
.../entityengine.xml

And that was all. Since a few days the system is running like a charm.

There is still one tool left which currently does not run on Glassfish. It's Polarion's "svnwebclient". This is a very cool subversion web client which you can download here. Deployment works, but the configuration for the subversion repository is not being detected correctly. Therefore I've used Tomcat 6.

Java EE and SOA worlds are denying the existence of Jini

2007-02-13T22:58:00.000-08:00

Hi,

I've been desperately looking for a spec compliant way to call Jini Services out of a Stateless Session Bean (SLSB). I've been looking for some kind of SOAP proxy, too. Results: ZERO.
I can't believe that nobody had the need to call a Jini Service from a Java EE application before.
And also the SOA world does not seem to have any JBI components to allow Java EE applications to call such services.
Now me and my team are developing a JCA 1.5 compliant Jini Connector allowing SLSBs to call Jini Services. I will keep you in touch and probably we will open source the results.
The idea is to implement a Jini Service Proxy which is called by the connector. The proxy gets the information which service is to be called. This way we don't have any dependencies of any Jini Services in the connector. Only one dependency: the proxy service itself.

Cheers.

Glassfish and support and the community (solution for remote lookups of EJBs)

2006-12-05T22:48:00.000-08:00

Hi,
two days ago I've written in this blog about an issue regarding the remote lookup of EJBs. It's still not clear if it is a bug or not. Nevertheless I found a solution or workaround if you want so.
Before I present the solution I want to praise the Glassfish team (mainly Sun employess) and the community. They are very helpful and in this case they also have been very responsive.
On Monday I've opened a case in the issue tracker: https://glassfish.dev.java.net/issues/show_bug.cgi?id=1643
One hour later I got the first response. Someone asked for details and has given a few advices. The same day three other people contacted me and tried to help me and discussed the problem. Whereelse do you get such support? This was really very impressive. This gives a lot of confidence in using Glassfish even in production.

And here comes the solution or workaround:

1) If you have a session (target) bean as in my case, then give it a mappedName as followe:

@Stateless(mappedName="ejb/FooJNDI")

2) In my servlet (client) I had to declare the dependency as follows

import javax.ejb.EJB;

@EJB(name="ejb/Foo", beanInterface=Foo.class,
mappedName="corbaname:iiop::#ejb/FooJNDI")
public class BarBean ...{
public void someMethod() {
ctx = new InitialContext();
Foo foo = (Foo) ctx.lookup("java:comp/env/ejb/Foo");

Note host and port are target's host and port.

This solution/workaround is necessary to lookup beans located in different Glassfish containers which are e.g. on different host machines.

Cannot Locate Remote EJB From Servlet

2006-12-04T22:52:00.000-08:00

Hi,

since two days I fight with glassfish. I've opened an issue:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=1643

What I try to do sounds very simple and is working like a charm from standalone clients.

1.) Initialize InitialContext

InitialContext ic = null;
Properties props = new Properties();
props.setProperty(Context.INITIAL_CONTEXT_FACTORY, "com.sun.enterprise.naming.SerialInitContextFactory");
props.setProperty(Context.URL_PKG_PREFIXES, "com.sun.enterprise.naming");
props.setProperty(Context.STATE_FACTORIES, "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
props.setProperty("com.sun.appserv.iiop.endpoints","10.10.1.212:11237"); //env.put("com.sun.appserv.iiop.endpoints","host1:port1,host2:port2,...");
props.setProperty("org.omg.CORBA.ORBInitialHost", "devasws056.proemion.com");
props.setProperty("org.omg.CORBA.ORBInitialPort", "11237");
ic = new InitialContext(props);

2.) Locate EJB (3.0)

Object o = (MyBeanRemote) ic.lookup("com.ejbs.MyBeanRemote");

Where the standalone client works as expected I have difficulties in locating the ejb from a servlet. EJB and Servlet reside in different applications (different ear files) but are deployed on the appserver instance.

Currently I still get a NameNotFoundException on the server. I hope that I will find a solution soon. Luckily some people are trying to help me already. The glassfish team/community is very responsive.

I will inform you as soon as I have found a solution.

Glassfish Installation and Configuration (OC4J Migration)

2006-11-21T03:23:00.000-08:00

Hi,

today I've installed multiple application server domains and instances on different linux machines. I've used a script to simplify the work. Glassfish offers the command line interface (CLI) "asadmin" which enables rapid configuration and installation tasks.

Define some paths:

export PASSWORDFILE=~/glassfish/password
export DOMAIN_ROOTDIR=/shared/mydir/glassfish
export RESOURCEXML=~/glassfish/resource.xml

Define domain and instance name and configure ports

export ACTIVE_DOMAIN=CpDomain
export ACTIVE_DOMAIN_LC=cpDomain
export TARGET_HOST_USER=auser
export TARGET_HOST_DOMAIN=host.domain.com
export TARGET_HOST=${TARGET_HOST_USER}@${TARGET_HOST_DOMAIN}
export ADMIN_PORT=10048
export INSTANCE_PORT=10080
export JMS_PORT=10076
export DOMAIN_JMXPORT=10086
export ORB_LISTENER_PORT=10037
export HTTP_SSL_PORT=10081
export ORB_SSL_PORT=10038
export ORB_MUTUALAUTH_PORT=10039
export DEBUG_PORT=10090

And here you go:

# create password file
ssh $TARGET_HOST "echo \"AS_ADMIN_PASSWORD=adminadmin:AS_ADMIN_ADMINPASSWORD=adminadmin\" | tr \":\" \"\n\" > ${PASSWORDFILE}${ACTIVE_DOMAIN}"

# create domain
ssh $TARGET_HOST "${DOMAIN_ROOTDIR}/bin/asadmin create-domain \
--adminuser admin \
--passwordfile ${PASSWORDFILE}${ACTIVE_DOMAIN} \
--adminport ${ADMIN_PORT} \
--instanceport ${INSTANCE_PORT} \
--echo=true \
--domaindir ${DOMAIN_ROOTDIR}/domain${ACTIVE_DOMAIN} \
--domainproperties \
jms.port=${JMS_PORT}:\
domain.jmxPort=${DOMAIN_JMXPORT}:\
orb.listener.port=${ORB_LISTENER_PORT}:\
http.ssl.port=${HTTP_SSL_PORT}:\
orb.ssl.port=${ORB_SSL_PORT}:\
orb.mutualauth.port=${ORB_MUTUALAUTH_PORT} \
--savemasterpassword=true \
--checkports=true ${ACTIVE_DOMAIN_LC}"

# start domain
ssh $TARGET_HOST "${DOMAIN_ROOTDIR}/bin/asadmin start-domain \
--domaindir ${DOMAIN_ROOTDIR}/domain${ACTIVE_DOMAIN} \
--user admin \
--passwordfile ${PASSWORDFILE}${ACTIVE_DOMAIN} \
--debug=false \
${ACTIVE_DOMAIN_LC}"

# add jdbc resources
ssh $TARGET_HOST "${DOMAIN_ROOTDIR}/bin/asadmin add-resources --user admin --passwordfile ${PASSWORDFILE}${ACTIVE_DOMAIN} --host ${TARGET_HOST_DOMAIN} --port ${ADMIN_PORT} ${RESOURCEXML}"

# configure debug port and enable debug mode
ssh $TARGET_HOST "${DOMAIN_ROOTDIR}/bin/asadmin set --user admin --passwordfile ${PASSWORDFILE}${ACTIVE_DOMAIN} --host ${TARGET_HOST_DOMAIN} --port ${ADMIN_PORT} server.java-config.debug-options=\"-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=${DEBUG_PORT}\"; ${DOMAIN_ROOTDIR}/bin/asadmin set --user admin --passwordfile ${PASSWORDFILE}${ACTIVE_DOMAIN} --host ${TARGET_HOST_DOMAIN} --port ${ADMIN_PORT} server.java-config.debug-enabled=true"

# restart domain with debug mode
ssh $TARGET_HOST "${DOMAIN_ROOTDIR}/bin/asadmin stop-domain \
--domaindir ${DOMAIN_ROOTDIR}/domain${ACTIVE_DOMAIN} \
${ACTIVE_DOMAIN_LC}; \
${DOMAIN_ROOTDIR}/bin/asadmin start-domain \
--domaindir ${DOMAIN_ROOTDIR}/domain${ACTIVE_DOMAIN} \
--user admin \
--passwordfile ${PASSWORDFILE}${ACTIVE_DOMAIN} \
--debug=true \
${ACTIVE_DOMAIN_LC}"

OC4J to Glassfish Migration Pt. 2

2006-11-20T04:14:00.000-08:00

Today I had a breakthrough. All the problems I had have been related to wrong annotations. Instead of using @PersistenceContext to inject the EntityManager, i have used @Resource as shown in one of the many online tutorials.
Now I can access my Database through a stateless session bean (factory) using various finder methods.
Now I have learned a new unpleasant lesson. My database schema is quite complex with a lot of relations. Therefor lazy access is a must and all entities are annotated accordingly. And now the unpleasant thing: my java standalone client throws an exception. The reason is that because of the lazyness, the javaee client wrapper classes are not able to deserialize the pojos with relations to other entities correctly. The related attributes have not been transferred. The result is a ClassNotFound-Exception although all Pojo-classes are accessible.
It seems that I have to transfer the relevant data via the TransferObject pattern.

It would be nice to have some kind of helper class which would be able to fetch all relevant data for a special find.

Nevertheless I am very happy of the actual migration status. I will report about my next steps soon.

OC4J to Glassfish Migration

2006-11-19T07:25:00.000-08:00

Today I've done the next steps for migration.

I've downloaded the following bits:

Hibernate Core, 3.2.1 GA
Hibernate Annotations, 3.2.0 GA
Hibernate EntityManager, 3.2.0 GADownload
Hibernate Tools, 3.2 beta 8

and of course Glassfish:
GlassfishV1, UR1 Build 14
andGlassfishV2, Build 19

I've downloaded both just in case that I will need different versions for various experiments.

I started with GlassfishV2 and my application with entities generated by Hibernate Tools was not running out of the box. Deployment went through without any errors (great).

I've written a small standalone java application which uses an InitialContext to look for an ejb3 stateless session bean. The result is positive. Unluckily the first call of a finder method within the session bean produces a large exception stack trace.

Maybe I have to edit the server.policy file although no security exception has been thrown? Just a feeling. Despite the explanation in another blog I did not copy the hibernate libs into the global glassfish lib, but packaged the libraries within my ejb jar. Maybe I should try copying those files into the global glassfish lib? If this does not help I will use GlassfishV1, UR1 Build 14. If this still does not help I would downgrade the hibernate libs.

More to come another day.

Thinking about switching from Oracle Applicationserver to Glassfish

2006-11-18T08:12:00.000-08:00

Hi,

I'm responsible for developing a huge, innovative javaee application. Currently the application is running on the latest Oracle Application Server 10.x. I'm seriously thinking about switching to Glassfish.
The reason is that Glassfish seems to offer the best support for the latest standards and open source frameworks such as EJB3, JSF 1.2, JAX-WS, Hibernate and Spring.
The next days I will try to talk a little bit about the problems about switching to the latest Glassfish V2.