I forgot to mention that the same war file acted correctly on other App Servers.
POJO endpoints are currently not pooled. The spec does not require that either.
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.
Why are you not using an EJB endpoint implementation?
It offers implicit pooling and lifecycle management.
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.