Lloyd Chambers wrote:
> Sahoo,
>
> Yes, this is really true and Jerome is in the loop.
Very surprising...
> The decision can be revisited of course.
>
> In the end, there are no changes at all to the standard classes,
> except that we define them elsewhere and then extend eg:
>
> package javax.management.j2ee.statistics;
> public interface ServletStats extends
> org.glassfish.j2ee.statistics.ServletStats {
> }
Sorry, this is NOT allowed as far as I know. We can NOT change signature
of any spec controlled class like
javax.management.j2ee.statistics.ServletStats such that it becomes
incompatible with the spec. Extending from a different class can be can
make it incompatible, IMO. Please check with someone like Bill who can
give you most definitive answer on this regard before checking in your
changes. Or, you can just run CTS signature matching tests to verify
yourself.
>
> This allows any momdule to use effectively the same interfaces, but
> without a dependency on javax.ejb.
>
> We are between a rock and a hard place here: we want to use Stats and
> Statistics, but this is not acceptable because of the dependency on
> javax.ejb in javax.management.j2ee.
>
> No implementation is involved in Stats and Statistics.
>
> As another point, I just discovered that there is already a
> javax.management.j2ee module under admin currently. I was not aware
> of this, I thought it had been removed prior to prelude.
Actually, I knew I had written such a module and had subsequently moved
it to a different directory. When I saw your review request, I did try
to find out the old module, but somehow could not extract the info from
fisheye logs. Thanks for detecting the existing module. Use it, but
hopefully you shall not change the spec classes in an incompatible way.
Thanks,
Sahoo