users@glassfish.java.net

3 issues using Glassfish

From: Filippo Diotalevi <filippo.diotalevi_at_gmail.com>
Date: Fri, 10 Nov 2006 14:54:03 +0100

Hi,
  I'm using Glassfish V1 UR1 for a project. The complete (development)
environment is:
Ubunty 6.04 + Glassfish 6.06 + (external) Open Message Broker + PostgreSQL 8.09

Everything is going quite well, but I'm observing 3 different issues.
I'd be grateful if anyone of you could tell me if they're bugs or if
they are simply misconfigurations of my environment. Obviously, if you
need further details or a more precise test cases I can try to detail
better these issues.

1) I've got a session ejb which uses (creates) the timer service. The
timer service is injected into the ejb:
{
  @Resource TimerService timerService;

  public void createTimer(long intervalDuration) {
    timerService.createTimer(intervalDuration, intervalDuration,
"Created new timer");
  }
}

The createTimer method is called by a ServletContextListener.
At application server startup, I have an exception because the ejb
container cannot resolve the resource TimerService. It seems to me
that the ServletContextListener executes the createTimer method
*before* the AS initializes the TimerService. Is it possible?
I haven't seen this behavior with Glassfish build-48. If I deploy the
application while the AS is still running, I don't see this error.

2) (This is a minor issue, but disturbing during development)
If I configure an external JMS_HOST and this host is down or not
reachable, the startup of the application is extremely slow. Not only
the startup of the AS, but the first time I access a web page of my
application it takes *some minutes* for the AS to show it.

The server.log shows some exceptions:
[#|2006-11-10T14:33:09.255+0100|WARNING|sun-appserver-pe9.0|javax.jms|_ThreadID=10;_ThreadName=main;_RequestID=37b23e2f-6cf8-4f97-95aa-a1ff11f37629;|[I500]:
Caught JVM Exception: java.net.ConnectException: Connection refused|#]

3) This is a really disturbing bug.
I have two ears deployed in my domain. Let's call them A.ear and B.ear.
Now I choose to redeploy B.ear, so I click on redeploy but
erroneously I choose A.ear.
The administrative web applications correctly signal the error: I
cannot deploy A.ear again (in fact I cannot have 2 web applications
with the same context root)
So I click on cancel, and now the Enterprise Applications page shows 2
ears deployed, whose names are:
- A.ear
- null
Now every operation (undeploy, redeploy) I try to do on the 'null' ear causes
- a nullpointer exception
- the death of the servlet container thread
It is impossible to undeploy the 'null' application with the asamind
command as well.


Ok, that's all. Anyone experiencing the same problems?

-- 
Filippo Diotalevi
filippo.diotalevi_at_gmail.com
http://www.diotalevi.com/weblog
http://www.jugmilano.it