[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [glassfish-dev] GlassFish updates for the javax -> jakarta transition
|
Hi,
comment inline
On 1/12/20 5:22 PM, Russell Gold wrote:
On Jan 11, 2020, at 10:05 PM, Bill Shannon <bill.shannon@xxxxxxxxxx
<mailto:bill.shannon@xxxxxxxxxx>> wrote:
Russell Gold wrote on 1/11/20 5:36 PM:
[snip]
The ORB does not depend on Glassfish, so it would be difficult
automatically to use the same version, I suspect. But if the pfl-asm
dependency is removed from Glassfish, I can work on getting rid of it
completely. I believe that other parts of gmbal-pfl still need it.
Sorry, I'm not following what it is you think needs to be done here.
I have no idea whether GlassFish is using pfl-asm directly, although
certainly
it is using it indirectly because it's using the ORB and the ORB is
using it,
right?
A search of the build.xml files in Glassfish shows 5 usages each of
pfl-asm, pfl-tf-tools and pfl-basic-tools. I think we would like to
eliminate them, if possible.
one of the consumers of gmbal etc is Metro (do you remember the
webservices node in the GF admin console in v2/v3? - relevant code is
still present in webservices/jsr109-impl module but disabled/not used
since v4 I believe).
As for the gmbal usage in Metro - as long as at least gmbal related
APIs[1] are available, Metro will compile and should work fine since the
gmbal implementation (pfl*) is optional. There was a plan to replace
gmbal with something else there but that plan has never been given priority.
thanks,
--lukas
[1]: org.glassfish.gmbal:gmbal-api-only artifact which is ready in the
repo and only needs to be released so I can adopt it in jaxws-ri and
wsit (metro)
Currently, the ORB is built so that it should run under JDK11
(pfl-basic is an MR jar). Some additional work will be needed in
Glassfish to take advantage of that.
What kind of work would be needed in GlassFish?
How is pfl-basic related to orb-gmbal-pfl?
orb-gmbal-pfl used to be called, simply, pfl, and consists of a
number of projects, including some only used for testing. I’d like to
get rid of the latter. The important ones are pfl-basic and pfl-dynamic.
And those are in an MR jar that works in JDK 11?
So there's no need to get rid of pfl-basic or pfl-dynamic, right?
Correct.
In fact, I don't think this will need to be done, but we will need
the entire
ORB and RMI-IIOP support to work correctly in a JDK 11 runtime, as
part of
providing backward compatibility for those products that need it (e.g.,
WebLogic), including EJB interoperability support.
I’ve already done that work for WebLogic. Glassfish just needs to use
the updated APIs, I believe.
Is that work already in the Eclipse project?
Yes.
What's involved in converting GlassFish to use the updated APIs?
I’ll have to do some research on that point.
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/glassfish-dev