Hi Denis,
Thanks for the feedback.
Denis Robert wrote:
> Everywhere in the Grizzly support, it seems that
> org.apache.coyote.Adapter was used in place of
> com.sun.grizzly.tcp.Adapter. That includes the ContainerProvider and the
> GrizzlyContainer, at least.
>
I will look into this (probably by passing it on to the Grizzly experts
for some additional advice on how to improve it!). We wrote this a while
back and have not updated it.
> Also, no attempt has been made to catch exceptions when a
> ContainerProvider throws one (in the case of the jaxws
> ProviderContainerProvider, which throws a ClassDefNotFound exception on
> the missing Coyote Adapter class, instead of simply returning null,
> which is what the ContainerFactory expects).
>
Ooops! i just committed a fix for that, should be available in the
latest build real soon. Basically any provider that cannot be loaded
will be ignored (a warning will be logged).
> So right now, only the Lightweight container works, and then only in
> certain circumstances (it hangs on a simple Hello World resource when I
> run it in prod, but it doesn't in Debug; a sure sign of deadlock).
Hmm... a number of people have used the Lightweight container on
Solaris/Windows and SE 5/6 without any issues. But i do recall that
there might be an issue on the Mac.
What is your platform and version of Jersey? Is it handling multiple
concurrent request? Any information on where it is hanging?
> I
> haven't tried the jaxws ContainerProvider, because I simply don't see
> the point.
JAX-WS has been a use-case amongst many containers to support but from
my implementation experience with this i agree with you. It uses the LW
HTTP container and limits what HTTP information can be obtained. IMHO it
is redundant.
> Grizzly, being a Glassfish technology, should be supported
> sooned rather than later.
>
I agree. Especially if we want to experiment with Comet support.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109