ServiceLifeCycle

[johnr1111]

I created a web service implementing the ServiceLifeCycle interface. In doing some tests it appeared that the init and destroy were called on every single web service call. Is this really the case? It appears that the Servlets do not do this and only call the init when the object is first created and destroy when it's being unloaded or removed.

Using the latest released JBoss, it appears that for every call to a web service, the web service is created and destroyed, calling init and destroy for every method call.

I know the spec doesn't say how they have to be managed as its up to the container management, but this seems like a realy performance nightmare.

Can you help me clarify this behavior, so I know that this is currently how it is or if I have just configured something wrong or missed configuring something. I know the JBossWS stuff is still evolving.

[johnr1111]

I forgot to mention that the same war file acted correctly on other App Servers.

[thomas.diesler]

POJO endpoints are currently not pooled. The spec does not require that either.

[johnr1111]

Thank you so much for helping validate that. I did realize the spec left that very open. I just wanted to validate that it was the case and we were not just configured correctly.

Are there plans to provide the pooling. It seems like this could really cause some severe overhead problems when developers are doing things like establishing database connections, or gathering config information, or other things that have a good amount of overhead to get a service setup for the first time. I'm sure you fully understand.

Are there plans to add the pooling capability in the near future? Can you recommend a different approach that would allow us to accomplish the same abilities as pre-setup with init, but without being invokded for every method call?

Thanks for all the help.

[hbraun]

Why are you not using an EJB endpoint implementation?
It offers implicit pooling and lifecycle management.

[johnr1111]

Typically so does the jaxrpc based imlementations on a servlet. At this point we don't want to be committed to a full J2EE server, unless we have too. I am also wanting to stay pretty portable across the app servers.

At this point, given many of the other shortcomings that we have ran into with bugs, I think it will be easier to use GlassFish or the Sun App Server. They both resolved the three seperate bugs that we were waiting on. including this issue.

In the end I want to ensure our war files can run on any of the app servers. Tomcat and Axis are not there, which is why JBoss split off. I think JBoss WS is just early in it's lifecycle and will work these issues out as well.

I do appreciate the idea, we had considered it.