Re: Javax to Jakarta Bytecode transformation progress
I like it - I've managed to follow what it's doing, and I imagine I could add further patches to it if needed :). Thank you for adding that. Much more scalable than my shading approach. Apologies for the poms in my working copy I forgot to revert before committing everything. Thanks for fixing it. Jon On Mon, Jun 15, 2020 at 11:10 PM David Blevins wrote: > > On Jun 15, 2020, at 9:23 AM, Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > > > > Thanks for this update. I've rebased the latest Eclipse Transformer code > > from upstream and will push that, and try a build with your PR. > > Thanks for the merge on PR 662, what did you think of the `src/patch/java` > concept and tomee-patch-plugin? Good, bad, ok-ish? > > > -David > > > > > > Jon > > > > On Mon, Jun 15, 2020 at 12:15 AM David Blevins > > wrote: > > > >> Ok, here's a quick status as to where I got. > >> > >> - Picked through our remaining ambiguous "javax" string references and > >> fixed them by checking in the affected file at the library version we're > >> using, then took a look at their master branch to see how they've > adapter > >> for the "jakarta" namespace and applied that fix to our copy. > >> > >> - Updated the tomee-patch-plugin to update strings in files and in the > >> case of JSF update the path of the file; there are some > >> '*-resources/javax.faces/" files. Those were all renamed. > >> > >> - Applied any bytecode transformations that the Eclipse Transformer > >> missed. Strings in annotation values were not being updated, nor were > any > >> module-info classes. After that there were a few small string tweaks it > >> probably could handle with the right configuration, but I just wanted to > >> get this over with so I put them in the tomee-patch-plugin for now. > >> > >> - Updated the tomee-patch-plugin to remove any signatures that are on > any > >> jars. > >> > >> The server boots and looks pretty good at least from a cursory > >> perspective. We need to do some more testing. > >> > >> Here's the PR which I think is ready to be merged so others can continue > >> down this path. > >> > >> - https://github.com/apache/tomee/pull/662 > >> > >> > >> -David > >> > >> > >
Re: Javax to Jakarta Bytecode transformation progress
> On Jun 15, 2020, at 9:23 AM, Jonathan Gallimore > wrote: > > Thanks for this update. I've rebased the latest Eclipse Transformer code > from upstream and will push that, and try a build with your PR. Thanks for the merge on PR 662, what did you think of the `src/patch/java` concept and tomee-patch-plugin? Good, bad, ok-ish? -David > > Jon > > On Mon, Jun 15, 2020 at 12:15 AM David Blevins > wrote: > >> Ok, here's a quick status as to where I got. >> >> - Picked through our remaining ambiguous "javax" string references and >> fixed them by checking in the affected file at the library version we're >> using, then took a look at their master branch to see how they've adapter >> for the "jakarta" namespace and applied that fix to our copy. >> >> - Updated the tomee-patch-plugin to update strings in files and in the >> case of JSF update the path of the file; there are some >> '*-resources/javax.faces/" files. Those were all renamed. >> >> - Applied any bytecode transformations that the Eclipse Transformer >> missed. Strings in annotation values were not being updated, nor were any >> module-info classes. After that there were a few small string tweaks it >> probably could handle with the right configuration, but I just wanted to >> get this over with so I put them in the tomee-patch-plugin for now. >> >> - Updated the tomee-patch-plugin to remove any signatures that are on any >> jars. >> >> The server boots and looks pretty good at least from a cursory >> perspective. We need to do some more testing. >> >> Here's the PR which I think is ready to be merged so others can continue >> down this path. >> >> - https://github.com/apache/tomee/pull/662 >> >> >> -David >> >> smime.p7s Description: S/MIME cryptographic signature
Re: Javax to Jakarta Bytecode transformation progress
Thanks for this update. I've rebased the latest Eclipse Transformer code from upstream and will push that, and try a build with your PR. Jon On Mon, Jun 15, 2020 at 12:15 AM David Blevins wrote: > Ok, here's a quick status as to where I got. > > - Picked through our remaining ambiguous "javax" string references and > fixed them by checking in the affected file at the library version we're > using, then took a look at their master branch to see how they've adapter > for the "jakarta" namespace and applied that fix to our copy. > > - Updated the tomee-patch-plugin to update strings in files and in the > case of JSF update the path of the file; there are some > '*-resources/javax.faces/" files. Those were all renamed. > > - Applied any bytecode transformations that the Eclipse Transformer > missed. Strings in annotation values were not being updated, nor were any > module-info classes. After that there were a few small string tweaks it > probably could handle with the right configuration, but I just wanted to > get this over with so I put them in the tomee-patch-plugin for now. > > - Updated the tomee-patch-plugin to remove any signatures that are on any > jars. > > The server boots and looks pretty good at least from a cursory > perspective. We need to do some more testing. > > Here's the PR which I think is ready to be merged so others can continue > down this path. > > - https://github.com/apache/tomee/pull/662 > > > -David > >
Re: Javax to Jakarta Bytecode transformation progress
Ok, here's a quick status as to where I got. - Picked through our remaining ambiguous "javax" string references and fixed them by checking in the affected file at the library version we're using, then took a look at their master branch to see how they've adapter for the "jakarta" namespace and applied that fix to our copy. - Updated the tomee-patch-plugin to update strings in files and in the case of JSF update the path of the file; there are some '*-resources/javax.faces/" files. Those were all renamed. - Applied any bytecode transformations that the Eclipse Transformer missed. Strings in annotation values were not being updated, nor were any module-info classes. After that there were a few small string tweaks it probably could handle with the right configuration, but I just wanted to get this over with so I put them in the tomee-patch-plugin for now. - Updated the tomee-patch-plugin to remove any signatures that are on any jars. The server boots and looks pretty good at least from a cursory perspective. We need to do some more testing. Here's the PR which I think is ready to be merged so others can continue down this path. - https://github.com/apache/tomee/pull/662 -David smime.p7s Description: S/MIME cryptographic signature
Re: Javax to Jakarta Bytecode transformation progress
> On Jun 11, 2020, at 9:12 PM, David Blevins wrote: > > Still some tweaks to do on getting the replacement into the jar, but so far > is looking really promising. > > The main goal was that any modifications we make to java files could be > tracked in the same TomEE branch that needs them. Ok, it's working now. Let's say we have the following in our module: - src/patch/java/org/apache/cxf/jaxb/JAXBContextInitializer.java We would see happy output like this: [INFO] --- tomee-patch-plugin:0.1-SNAPSHOT:run (default) @ apache-tomee --- [INFO] Compiling 1 source file to /Users/dblevins/work/apache/tomee/tomee/apache-tomee/target/patch-classes [INFO] Patching apache-tomee-plus-8.0.3-SNAPSHOT/lib/cxf-rt-databinding-jaxb-3.3.6.jar [INFO] Patching apache-tomee-plume-8.0.3-SNAPSHOT/lib/cxf-rt-databinding-jaxb-3.3.6.jar [INFO] Patching apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/cxf-rt-databinding-jaxb-3.3.6.jar [INFO] Applied 1 patches to 3 locations [INFO] Now let's say we have these files and `Anvil` doesn't match anything in any of our jars: - src/patch/java/org/acme/Anvil.java - src/patch/java/org/apache/cxf/jaxb/JAXBContextInitializer.java We would see a failed build with output like this: [INFO] --- tomee-patch-plugin:0.1-SNAPSHOT:run (default) @ apache-tomee --- [INFO] Compiling 2 source files to /Users/dblevins/work/apache/tomee/tomee/apache-tomee/target/patch-classes [INFO] Patching apache-tomee-plus-8.0.3-SNAPSHOT/lib/cxf-rt-databinding-jaxb-3.3.6.jar [INFO] Patching apache-tomee-plume-8.0.3-SNAPSHOT/lib/cxf-rt-databinding-jaxb-3.3.6.jar [INFO] Patching apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/cxf-rt-databinding-jaxb-3.3.6.jar [INFO] Applied 1 patches to 3 locations [ERROR] Failed to apply 1 patches [ERROR] org/acme/Anvil.class [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 01:17 min [INFO] Finished at: 2020-06-12T11:18:20-07:00 [INFO] [ERROR] Failed to execute goal org.apache.tomee.patch:tomee-patch-plugin:0.1-SNAPSHOT:run (default) on project apache-tomee: Execution default of goal org.apache.tomee.patch:tomee-patch-plugin:0.1-SNAPSHOT:run failed: Failed to apply 1 patches -> [Help 1] smime.p7s Description: S/MIME cryptographic signature
Re: Javax to Jakarta Bytecode transformation progress
> On Jun 10, 2020, at 7:58 PM, David Blevins wrote: > > I've gone ahead and created us a new repo and seeded it with the bytecode > scanning/transformation code that I've been working on to Scan/Transform > Maven Central. > > - > https://github.com/apache/tomee-patch-plugin/commit/2a06d9f081c1db05164286db9149ba17c30754dc > Ok, this is still a work in progress, but here's an early draft PR. - https://github.com/apache/tomee/pull/662 Effectively what the plugin will (hopefully) allow us to do is put a source file in like this one: - https://github.com/apache/tomee/pull/662/commits/c3474501b484cf7b6eee42da7d86635945eb45ee Then make the modifications you need: - https://github.com/apache/tomee/pull/662/commits/5385ce29cd68333224abedd97e2a75b59baf951f And the plugin will compile that class against the libraries in your zip and then it will find in the zip where that class lived and replace it. It does this recursively so it can find them in nested jars. The compile totally works -- code lifted from the Maven Compile Plugin, but with the classpath built from the zip Still some tweaks to do on getting the replacement into the jar, but so far is looking really promising. The main goal was that any modifications we make to java files could be tracked in the same TomEE branch that needs them. -David smime.p7s Description: S/MIME cryptographic signature
Re: Javax to Jakarta Bytecode transformation progress
Top-posting as cutting snippets out of the response I think paraphrases it inaccurately -- it's a good email. Net I agree with most points including the bottomline comment that there will definitely be edge cases we will not be able to support with the Eclipse Transformer -- namely patching in new codeblocks into existing bytecode. That on top of stomping out the bugs means we'd be unlikely to get to the end of this anytime soon. I've gone ahead and created us a new repo and seeded it with the bytecode scanning/transformation code that I've been working on to Scan/Transform Maven Central. - https://github.com/apache/tomee-patch-plugin/commit/2a06d9f081c1db05164286db9149ba17c30754dc The goal in my mind is that we have something into which we can put all the dirty hacks we want and be as unrestricted as possible to solve this problem as quickly and thoroughly as possible. I don't think this is code want to own long-term and any improvements should go into a mix of the Eclipse Transformer, Jkta or a more general-purposed location. But at least for the moment we'll have all the control we need to patch our zips using whatever custom code without having to be held up by what the "proper" abstraction is or any abstraction at all. We just get it to work and move on. I'm confident we can stomp out our edge cases quickly this way and may even have a perfectly running server under the jakarta namespace in time for some kind of release next week (if we want to do a release). -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com > On Jun 10, 2020, at 2:11 AM, Jonathan Gallimore > wrote: > > In terms of the technical aspects of doing the find/replace on non-class > files with the Transformer - its possible - it would require a (not huge) > change, but its possible. There are some specific cases that the > transformer handles already, such as XML schemas (and we have nothing > configured for that, so that wouldn't be a surprise if work is needed > there) and service loaders (which should be working ok). There may be other > challenges - one that I had to solve already was with servlet-api jar, > which contains properties files for localized strings, which are loaded as > resources from the classpath. These sat under javax - here's an example: > https://github.com/apache/tomcat/blob/9.0.x/java/javax/servlet/LocalStrings.properties. > The transformer rewrote the references in the code to jakarta.servlet > (great!) but didn't move the properties file - it left it under javax. I > solved that by adding another action to the transformer to deal with that: > https://github.com/tomitribe/transformer/blob/master/transformer/src/main/java/org/eclipse/transformer/action/impl/RelocateResourceActionImpl.java > . > > I'm not particularly surprised that there are edge cases that we can't > transform - I was expecting that, particularly in class loading logic where > there are matches on things like "javax.". I think there's a natural > temptation to add a rule which is simply "javax" -> "jakarta", but that > will likely break as much as it fixes as there are exceptions to the rule > with some stuff staying behind in javax. The issue I highlighted in > Eclipselink looks like a case we simply won't be able to transform without > a significant amount of complexity. Upgrading to a version where that is > fixed breaks the TomEE build entirely, as EclipseLink is then expecting > everything to be under jakarta. One option there might be to do a reverse > transformation on that one jar, add that to the build, and then include it > in the transformation to jakarta. I don't know if that sounds ridiculous > written down, but it certainly does in my head. I think we can simply grab > the current EclipseLink jar, and patch it slightly so it then transforms > nicely. We've patched various jars including JSTL and OpenJPA in the past. > I suspect I'll have this done and checked in today. > > Shooting for phase 1 perfection I think is tricky. Partly because when > doing this type of work, there are always edge cases that are hard to find > and fix, and partly because even if we achieved "perfection", there's still > no guarantee it would actually work. There are still replacements that > would break, and then there are other crazy issues like signed jars that > break the second you touch them (ecj, for example). > > I personally have already started booting the server, and actually trying > stuff. Moviefun is a fun example, as we have versions of it that cover > Servlets, JSPs, EJBs. JPA, and JAX-RS. I imagine testing some basic JAX-WS > wouldn't be a stretch. I uncovered the EclipseLink issue by actually > trying to run moviefun on the server, by hand. If we perfectly achieved the > phase 1 goal, we'd still have missed this reference, because the text > "javax" doesn't feature in that block of code. The references there are > "kotlin", "java", "x", and "persistence". So we'd still have needed to b
Re: Javax to Jakarta Bytecode transformation progress
In terms of the technical aspects of doing the find/replace on non-class files with the Transformer - its possible - it would require a (not huge) change, but its possible. There are some specific cases that the transformer handles already, such as XML schemas (and we have nothing configured for that, so that wouldn't be a surprise if work is needed there) and service loaders (which should be working ok). There may be other challenges - one that I had to solve already was with servlet-api jar, which contains properties files for localized strings, which are loaded as resources from the classpath. These sat under javax - here's an example: https://github.com/apache/tomcat/blob/9.0.x/java/javax/servlet/LocalStrings.properties. The transformer rewrote the references in the code to jakarta.servlet (great!) but didn't move the properties file - it left it under javax. I solved that by adding another action to the transformer to deal with that: https://github.com/tomitribe/transformer/blob/master/transformer/src/main/java/org/eclipse/transformer/action/impl/RelocateResourceActionImpl.java . I'm not particularly surprised that there are edge cases that we can't transform - I was expecting that, particularly in class loading logic where there are matches on things like "javax.". I think there's a natural temptation to add a rule which is simply "javax" -> "jakarta", but that will likely break as much as it fixes as there are exceptions to the rule with some stuff staying behind in javax. The issue I highlighted in Eclipselink looks like a case we simply won't be able to transform without a significant amount of complexity. Upgrading to a version where that is fixed breaks the TomEE build entirely, as EclipseLink is then expecting everything to be under jakarta. One option there might be to do a reverse transformation on that one jar, add that to the build, and then include it in the transformation to jakarta. I don't know if that sounds ridiculous written down, but it certainly does in my head. I think we can simply grab the current EclipseLink jar, and patch it slightly so it then transforms nicely. We've patched various jars including JSTL and OpenJPA in the past. I suspect I'll have this done and checked in today. Shooting for phase 1 perfection I think is tricky. Partly because when doing this type of work, there are always edge cases that are hard to find and fix, and partly because even if we achieved "perfection", there's still no guarantee it would actually work. There are still replacements that would break, and then there are other crazy issues like signed jars that break the second you touch them (ecj, for example). I personally have already started booting the server, and actually trying stuff. Moviefun is a fun example, as we have versions of it that cover Servlets, JSPs, EJBs. JPA, and JAX-RS. I imagine testing some basic JAX-WS wouldn't be a stretch. I uncovered the EclipseLink issue by actually trying to run moviefun on the server, by hand. If we perfectly achieved the phase 1 goal, we'd still have missed this reference, because the text "javax" doesn't feature in that block of code. The references there are "kotlin", "java", "x", and "persistence". So we'd still have needed to boot the server, and try it. I also have applications that test MVC, and connectors as well. They also use Hibernate which could be interesting. Short answer (and I understand if the above is too long!) is I'd like to see the 6053 hits, along with where they are, and we can discuss whether they need to be transformed, and if so, what rules we might apply in the transformer. Additionally, I think we're at the point where we ought to push some binaries and with the disclaimer that we know there's a good chance that lots of things might not work, but please can people kick the tyres anyway and report back. If we try and achieve phase 1 perfection, I fear phase 2 and actually trying the server are potentially a long way off. Jon On Wed, Jun 10, 2020 at 2:22 AM David Blevins wrote: > > On Jun 9, 2020, at 2:45 PM, David Blevins > wrote: > > > >> On Jun 6, 2020, at 3:26 PM, David Blevins > wrote: > >> > >> All total about 2508 hits. > >> > > > > With latest changes we're down to about 672 hits. > > > > - > https://github.com/dblevins/tomee-analysis/blob/6ee78178aa5dd55447943fd25cd5821f6159fc9e/README.adoc > > > > Ok, I expanded the search for potentially missed "javax" references to now > also search non class files. This gives us a few thousand more hits (6053 > total). Of them, 4980 are for javax.faces most across .tld, .js and .xsd > files. > > At this point, it's a little unclear how to proceed. There are actually > two problems: > > - Simple find/replace on all non-class files in a jar > - Doing it elegantly not offending the design of the Eclipse Transformer > > The trick I'm having is I personally have a tendency to code like this: > > Phase 1: code till the problem is completely solved including each
Re: Javax to Jakarta Bytecode transformation progress
> On Jun 9, 2020, at 2:45 PM, David Blevins wrote: > >> On Jun 6, 2020, at 3:26 PM, David Blevins wrote: >> >> All total about 2508 hits. >> > > With latest changes we're down to about 672 hits. > > - > https://github.com/dblevins/tomee-analysis/blob/6ee78178aa5dd55447943fd25cd5821f6159fc9e/README.adoc > Ok, I expanded the search for potentially missed "javax" references to now also search non class files. This gives us a few thousand more hits (6053 total). Of them, 4980 are for javax.faces most across .tld, .js and .xsd files. At this point, it's a little unclear how to proceed. There are actually two problems: - Simple find/replace on all non-class files in a jar - Doing it elegantly not offending the design of the Eclipse Transformer The trick I'm having is I personally have a tendency to code like this: Phase 1: code till the problem is completely solved including each and every edge case. Avoid as much design overhead as possible, at this point they're just handcuffs. Phase 2: once phase 1 is fully complete, take stock of the code and redesign it with the whole picture in mind. I feel like where we are at with the Eclipse Transformer is it's already firming up the design and we're not out of phase 1 yet. I could be wrong on that. My fear is that we spend the next few weeks feeding edge-cases in one at a time, each time treating the design as perfect trying to make as few design changes as possible, sometimes going a little out of our way to make that happen and this drags on. Alternatively, we could just get to the end of this in a hacked fashion, get the server to boot and completely run, and *then* see what changes we'd need to make to the Eclipse Transformer design to get it to do what we need. Jon, you're the only one with experience with the Eclipse Transformer, I'm very curious what you think. -David smime.p7s Description: S/MIME cryptographic signature
Re: Javax to Jakarta Bytecode transformation progress
> On Jun 6, 2020, at 3:26 PM, David Blevins wrote: > > All total about 2508 hits. > With latest changes we're down to about 672 hits. - https://github.com/dblevins/tomee-analysis/blob/6ee78178aa5dd55447943fd25cd5821f6159fc9e/README.adoc Still some easy string replacements with regard to bean validation I'll see if I can get cleared up. That should knock out 22 or so. -David smime.p7s Description: S/MIME cryptographic signature
Re: Javax to Jakarta Bytecode transformation progress
> On Jun 9, 2020, at 2:06 PM, Jonathan Gallimore
> wrote:
>
> Sorry, wrong link.
> https://github.com/eclipse-ee4j/eclipselink/blob/2.7.4/jpa/org.eclipse.persistence.jpa/src/org/eclipse/persistence/internal/jpa/metadata/accessors/objects/MetadataAsmFactory.java#L290-L318
>
> Specifically this:
>
> if (desc.startsWith("Ljava")) {
>char c = desc.charAt(5);
>//ignore annotations from 'java' namespace
>if (c == '/') {
>return null;
>}
>//ignore annotations from other then 'javax/persistence'
> namespace
>if (desc.regionMatches(5, "x/", 0, 2)) {
>if (desc.regionMatches(7, "persistence", 0,
> "persistence".length())) {
>isJPA = true;
>} else {
>return null;
>}
>}
>}
>
> Its quite hard to match "javax" there :-)
Does the Eclipse Transformer have the ability for us to slice in a second `if`
block to handle the jakarta version?
Seems like we're at the point where we're getting into edge-cases that can't be
resolved with rules (expected) and we might need some very very specific
modifications.
-David
>
> Jon
>
> On Tue, Jun 9, 2020 at 8:46 PM David Blevins
> wrote:
>
>>> On Jun 9, 2020, at 12:25 PM, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>>>
>>> Been digging into why the Jakarta-ized JPA entities don't work with
>>> EclipseLink. Think I found the answer:
>>>
>> https://github.com/eclipse-ee4j/eclipselink/blob/2.7.4/jpa/org.eclipse.persistence.jpa/src/org/eclipse/persistence/internal/jpa/metadata/accessors/objects/MetadataAsmFactory.java#L531-L561
>>
>> Can you describe what about that code block causes an issue? (wasn't
>> overtly obvious)
>>
>>
>> -David
>>
>>> On Tue, Jun 9, 2020 at 4:13 PM Jonathan Gallimore <
>>> jonathan.gallim...@gmail.com> wrote:
>>>
This looks correct now:
[CORP\jgallimore@a-2yv8q9r2zol44 output]$ grep -e
'visitOuterClass("javax' -r . | grep -v README.adoc
>> ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
"getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
>> ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
null, null);
>> ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
"findFactoryImplName", "()Ljava/lang/String;");
>> ./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
"getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
>> ./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
null, null);
>> ./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
"findFactoryImplName", "()Ljava/lang/String;");
>> ./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
"getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
>> ./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
null, null);
>> ./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
"findFactoryImplName", "()Ljava/lang/String;");
>> ./apache-tomee-webprofile-8.0.3-SNAPSHOT.zip/apache-tomee-webprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
"getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
>> ./apache-tomee-webprofile-8.0.3-SNAPSHOT.zip/apache
Re: Javax to Jakarta Bytecode transformation progress
Sorry, wrong link.
https://github.com/eclipse-ee4j/eclipselink/blob/2.7.4/jpa/org.eclipse.persistence.jpa/src/org/eclipse/persistence/internal/jpa/metadata/accessors/objects/MetadataAsmFactory.java#L290-L318
Specifically this:
if (desc.startsWith("Ljava")) {
char c = desc.charAt(5);
//ignore annotations from 'java' namespace
if (c == '/') {
return null;
}
//ignore annotations from other then 'javax/persistence'
namespace
if (desc.regionMatches(5, "x/", 0, 2)) {
if (desc.regionMatches(7, "persistence", 0,
"persistence".length())) {
isJPA = true;
} else {
return null;
}
}
}
Its quite hard to match "javax" there :-)
Jon
On Tue, Jun 9, 2020 at 8:46 PM David Blevins
wrote:
> > On Jun 9, 2020, at 12:25 PM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> >
> > Been digging into why the Jakarta-ized JPA entities don't work with
> > EclipseLink. Think I found the answer:
> >
> https://github.com/eclipse-ee4j/eclipselink/blob/2.7.4/jpa/org.eclipse.persistence.jpa/src/org/eclipse/persistence/internal/jpa/metadata/accessors/objects/MetadataAsmFactory.java#L531-L561
>
> Can you describe what about that code block causes an issue? (wasn't
> overtly obvious)
>
>
> -David
>
> > On Tue, Jun 9, 2020 at 4:13 PM Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> >> This looks correct now:
> >>
> >> [CORP\jgallimore@a-2yv8q9r2zol44 output]$ grep -e
> >> 'visitOuterClass("javax' -r . | grep -v README.adoc
> >>
> ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
> >> "getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
> >>
> ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
> >> null, null);
> >>
> ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
> >> "findFactoryImplName", "()Ljava/lang/String;");
> >>
> ./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
> >> "getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
> >>
> ./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
> >> null, null);
> >>
> ./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
> >> "findFactoryImplName", "()Ljava/lang/String;");
> >>
> ./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
> >> "getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
> >>
> ./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
> >> null, null);
> >>
> ./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
> >> "findFactoryImplName", "()Ljava/lang/String;");
> >>
> ./apache-tomee-webprofile-8.0.3-SNAPSHOT.zip/apache-tomee-webprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
> >> "getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
> >>
> ./apache-tomee-webprofile-8.0.3-SNAPSHOT.zip/apache-tomee-webprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
> >> null, null);
> >>
> >> Jon
> >>
> >> On Tue, Jun 9, 2020 at 3:01 PM Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com> wrote:
> >>
> >>> I definitely haven't caught them all, but it looks like a step forward
> at
> >>> least:
> >>>
> https://github.com/dblevins/tomee-analysis/
Re: Javax to Jakarta Bytecode transformation progress
> On Jun 9, 2020, at 12:25 PM, Jonathan Gallimore
> wrote:
>
> Been digging into why the Jakarta-ized JPA entities don't work with
> EclipseLink. Think I found the answer:
> https://github.com/eclipse-ee4j/eclipselink/blob/2.7.4/jpa/org.eclipse.persistence.jpa/src/org/eclipse/persistence/internal/jpa/metadata/accessors/objects/MetadataAsmFactory.java#L531-L561
Can you describe what about that code block causes an issue? (wasn't overtly
obvious)
-David
> On Tue, Jun 9, 2020 at 4:13 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
>> This looks correct now:
>>
>> [CORP\jgallimore@a-2yv8q9r2zol44 output]$ grep -e
>> 'visitOuterClass("javax' -r . | grep -v README.adoc
>> ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
>> "getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
>> ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
>> null, null);
>> ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
>> "findFactoryImplName", "()Ljava/lang/String;");
>> ./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
>> "getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
>> ./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
>> null, null);
>> ./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
>> "findFactoryImplName", "()Ljava/lang/String;");
>> ./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
>> "getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
>> ./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
>> null, null);
>> ./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
>> "findFactoryImplName", "()Ljava/lang/String;");
>> ./apache-tomee-webprofile-8.0.3-SNAPSHOT.zip/apache-tomee-webprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
>> "getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
>> ./apache-tomee-webprofile-8.0.3-SNAPSHOT.zip/apache-tomee-webprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
>> null, null);
>>
>> Jon
>>
>> On Tue, Jun 9, 2020 at 3:01 PM Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>>
>>> I definitely haven't caught them all, but it looks like a step forward at
>>> least:
>>> https://github.com/dblevins/tomee-analysis/commit/77bd1a6a812b49790e2a73ccd5a60a4074b47238
>>>
>>> Going to very specifically look at this case and see what's up:
>>> https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/util/JAXBSource%241-asmified.java#L27
>>>
>>> Jon
>>>
>>> On Tue, Jun 9, 2020 at 11:23 AM Jonathan Gallimore <
>>> jonathan.gallim...@gmail.com> wrote:
>>>
Thanks for this. I think I've found the bug in the Eclipse Transformer
and I'm working on fixing it now.
Jon
On Fri, Jun 5, 2020 at 8:50 PM David Blevins
wrote:
> Looks like both my scanning tool and the Eclipse Transformer are not
> picking up calls to outer classes. A couple examples:
>
> -
> https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/util/JAXBSource%241-asmified.java#L27
>
> -
> https://github.com/d
Re: Javax to Jakarta Bytecode transformation progress
Been digging into why the Jakarta-ized JPA entities don't work with
EclipseLink. Think I found the answer:
https://github.com/eclipse-ee4j/eclipselink/blob/2.7.4/jpa/org.eclipse.persistence.jpa/src/org/eclipse/persistence/internal/jpa/metadata/accessors/objects/MetadataAsmFactory.java#L531-L561
This is fixed in 3.0.0-M1, but that introduces other issues with our build.
I'm planning to patch the version we're currently using.
Jon
On Tue, Jun 9, 2020 at 4:13 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:
> This looks correct now:
>
> [CORP\jgallimore@a-2yv8q9r2zol44 output]$ grep -e
> 'visitOuterClass("javax' -r . | grep -v README.adoc
> ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
> "getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
> ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
> null, null);
> ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
> "findFactoryImplName", "()Ljava/lang/String;");
> ./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
> "getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
> ./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
> null, null);
> ./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
> "findFactoryImplName", "()Ljava/lang/String;");
> ./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
> "getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
> ./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
> null, null);
> ./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
> "findFactoryImplName", "()Ljava/lang/String;");
> ./apache-tomee-webprofile-8.0.3-SNAPSHOT.zip/apache-tomee-webprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
> "getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
> ./apache-tomee-webprofile-8.0.3-SNAPSHOT.zip/apache-tomee-webprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
> null, null);
>
> Jon
>
> On Tue, Jun 9, 2020 at 3:01 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
>> I definitely haven't caught them all, but it looks like a step forward at
>> least:
>> https://github.com/dblevins/tomee-analysis/commit/77bd1a6a812b49790e2a73ccd5a60a4074b47238
>>
>> Going to very specifically look at this case and see what's up:
>> https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/util/JAXBSource%241-asmified.java#L27
>>
>> Jon
>>
>> On Tue, Jun 9, 2020 at 11:23 AM Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>>
>>> Thanks for this. I think I've found the bug in the Eclipse Transformer
>>> and I'm working on fixing it now.
>>>
>>> Jon
>>>
>>> On Fri, Jun 5, 2020 at 8:50 PM David Blevins
>>> wrote:
>>>
Looks like both my scanning tool and the Eclipse Transformer are not
picking up calls to outer classes. A couple examples:
-
https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/util/JAXBSource%241-asmified.java#L27
-
https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT
Re: Javax to Jakarta Bytecode transformation progress
This looks correct now:
[CORP\jgallimore@a-2yv8q9r2zol44 output]$ grep -e 'visitOuterClass("javax'
-r . | grep -v README.adoc
./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
"getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
null, null);
./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
"findFactoryImplName", "()Ljava/lang/String;");
./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
"getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
null, null);
./apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
"findFactoryImplName", "()Ljava/lang/String;");
./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
"getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
null, null);
./apache-tomee-plus-8.0.3-SNAPSHOT.zip/apache-tomee-plus-8.0.3-SNAPSHOT/lib/wsdl4j-1.6.3.jar/javax/wsdl/factory/WSDLFactory$1-asmified.java:classWriter.visitOuterClass("javax/wsdl/factory/WSDLFactory",
"findFactoryImplName", "()Ljava/lang/String;");
./apache-tomee-webprofile-8.0.3-SNAPSHOT.zip/apache-tomee-webprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/Caching$CachingProviderRegistry$1-asmified.java:classWriter.visitOuterClass("javax/cache/Caching$CachingProviderRegistry",
"getCachingProviders", "(Ljava/lang/ClassLoader;)Ljava/lang/Iterable;");
./apache-tomee-webprofile-8.0.3-SNAPSHOT.zip/apache-tomee-webprofile-8.0.3-SNAPSHOT/lib/javaee-api-8.0-4.jar/javax/cache/expiry/Duration$1-asmified.java:classWriter.visitOuterClass("javax/cache/expiry/Duration",
null, null);
Jon
On Tue, Jun 9, 2020 at 3:01 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:
> I definitely haven't caught them all, but it looks like a step forward at
> least:
> https://github.com/dblevins/tomee-analysis/commit/77bd1a6a812b49790e2a73ccd5a60a4074b47238
>
> Going to very specifically look at this case and see what's up:
> https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/util/JAXBSource%241-asmified.java#L27
>
> Jon
>
> On Tue, Jun 9, 2020 at 11:23 AM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
>> Thanks for this. I think I've found the bug in the Eclipse Transformer
>> and I'm working on fixing it now.
>>
>> Jon
>>
>> On Fri, Jun 5, 2020 at 8:50 PM David Blevins
>> wrote:
>>
>>> Looks like both my scanning tool and the Eclipse Transformer are not
>>> picking up calls to outer classes. A couple examples:
>>>
>>> -
>>> https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/util/JAXBSource%241-asmified.java#L27
>>>
>>> -
>>> https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/ContextFinder$2-asmified.java#L27
>>>
>>>
>>>
>>> --
>>> David Blevins
>>> http://twitter.com/dblevins
>>> http://www.tomitribe.com
>>>
>>> > On Jun 5, 2020, at 12:31 PM, David Blevins
>>> wrote:
>>> >
>>> > Here's the diff of the changed bytecode from revision
>>> d429ba420dbdba7ea07c6a0c91f3135ef2343f28
>>> >
>>> > -
>>> https://github.com/dblevins/tomee-analysis/commit/b6026b56eaad3a19c8a3bd89eb5c92620dd5b5d7
>>> >
>>> > Haven't had a chance to pick through it.
>>> >
>>> > --
>>> > David Blevins
>>> > http://twitter.com/dblevins
>>> > http://www.tomit
Re: Javax to Jakarta Bytecode transformation progress
I definitely haven't caught them all, but it looks like a step forward at least: https://github.com/dblevins/tomee-analysis/commit/77bd1a6a812b49790e2a73ccd5a60a4074b47238 Going to very specifically look at this case and see what's up: https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/util/JAXBSource%241-asmified.java#L27 Jon On Tue, Jun 9, 2020 at 11:23 AM Jonathan Gallimore < jonathan.gallim...@gmail.com> wrote: > Thanks for this. I think I've found the bug in the Eclipse Transformer and > I'm working on fixing it now. > > Jon > > On Fri, Jun 5, 2020 at 8:50 PM David Blevins > wrote: > >> Looks like both my scanning tool and the Eclipse Transformer are not >> picking up calls to outer classes. A couple examples: >> >> - >> https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/util/JAXBSource%241-asmified.java#L27 >> >> - >> https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/ContextFinder$2-asmified.java#L27 >> >> >> >> -- >> David Blevins >> http://twitter.com/dblevins >> http://www.tomitribe.com >> >> > On Jun 5, 2020, at 12:31 PM, David Blevins >> wrote: >> > >> > Here's the diff of the changed bytecode from revision >> d429ba420dbdba7ea07c6a0c91f3135ef2343f28 >> > >> > - >> https://github.com/dblevins/tomee-analysis/commit/b6026b56eaad3a19c8a3bd89eb5c92620dd5b5d7 >> > >> > Haven't had a chance to pick through it. >> > >> > -- >> > David Blevins >> > http://twitter.com/dblevins >> > http://www.tomitribe.com >> > >> >> On Jun 5, 2020, at 12:26 PM, Jonathan Gallimore < >> jonathan.gallim...@gmail.com> wrote: >> >> >> >> Deployed Moviefun. EJBs now scanned ok... now have an issue with >> >> EclipseLink. We're still moving forward... >> >> >> >> 05-Jun-2020 20:23:21.976 INFO [main] >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke Deployment of web >> >> application directory >> >> [/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/ROOT] >> has >> >> finished in [161] ms >> >> 05-Jun-2020 20:23:22.011 INFO [main] >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke Starting >> ProtocolHandler >> >> ["http-nio-8080"] >> >> 05-Jun-2020 20:23:22.028 INFO [main] >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke Server startup in >> [48,389] >> >> milliseconds >> >> [EL Info]: 2020-06-05 >> 20:23:27.156--ServerSession(1764341773)--EclipseLink, >> >> version: Eclipse Persistence Services - 2.7.4.v20190115-ad5b7c6b2a >> >> [EL Info]: 2020-06-05 >> >> >> 20:23:27.215--ServerSession(1764341773)--/file:/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/moviefun/WEB-INF/classes/_movie-unit >> >> login successful >> >> [EL Warning]: 2020-06-05 20:23:27.27--The collection of metamodel >> types is >> >> empty. Model classes may not have been found during entity search for >> Java >> >> SE and some Java EE container managed persistence units. Please verify >> >> that your entity classes are referenced in persistence.xml using either >> >> elements or a global >> >> false element >> >> 05-Jun-2020 20:23:27.309 SEVERE [http-nio-8080-exec-1] >> >> >> org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException >> >> EjbTransactionUtil.handleSystemException: Object: >> >> org.superbiz.moviefun.Movie@55c019e0 is not a known Entity type. >> >> java.lang.IllegalArgumentException: Object: >> >> org.superbiz.moviefun.Movie@55c019e0 is not a known Entity type. >> >> at >> >> >> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4326) >> >> at >> >> >> org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:596) >> >> at >> >> >> org.apache.openejb.persistence.JtaEntityManager.persist(JtaEntityManager.java:193) >> >> at org.superbiz.moviefun.MoviesBean.addMovie(MoviesBean.java:42) >> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >> at >> >> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >> at >> >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> at java.lang.reflect.Method.invoke(Method.java:498) >> >> at >> >> >> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205) >> >> at >> >> >> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186) >> >> at >> >> >> org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:191) >> >> at >> >> >> org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:102) >> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ
Re: Javax to Jakarta Bytecode transformation progress
Thanks for this. I think I've found the bug in the Eclipse Transformer and I'm working on fixing it now. Jon On Fri, Jun 5, 2020 at 8:50 PM David Blevins wrote: > Looks like both my scanning tool and the Eclipse Transformer are not > picking up calls to outer classes. A couple examples: > > - > https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/util/JAXBSource%241-asmified.java#L27 > > - > https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/ContextFinder$2-asmified.java#L27 > > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > > > On Jun 5, 2020, at 12:31 PM, David Blevins > wrote: > > > > Here's the diff of the changed bytecode from revision > d429ba420dbdba7ea07c6a0c91f3135ef2343f28 > > > > - > https://github.com/dblevins/tomee-analysis/commit/b6026b56eaad3a19c8a3bd89eb5c92620dd5b5d7 > > > > Haven't had a chance to pick through it. > > > > -- > > David Blevins > > http://twitter.com/dblevins > > http://www.tomitribe.com > > > >> On Jun 5, 2020, at 12:26 PM, Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > >> > >> Deployed Moviefun. EJBs now scanned ok... now have an issue with > >> EclipseLink. We're still moving forward... > >> > >> 05-Jun-2020 20:23:21.976 INFO [main] > >> sun.reflect.DelegatingMethodAccessorImpl.invoke Deployment of web > >> application directory > >> [/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/ROOT] > has > >> finished in [161] ms > >> 05-Jun-2020 20:23:22.011 INFO [main] > >> sun.reflect.DelegatingMethodAccessorImpl.invoke Starting ProtocolHandler > >> ["http-nio-8080"] > >> 05-Jun-2020 20:23:22.028 INFO [main] > >> sun.reflect.DelegatingMethodAccessorImpl.invoke Server startup in > [48,389] > >> milliseconds > >> [EL Info]: 2020-06-05 > 20:23:27.156--ServerSession(1764341773)--EclipseLink, > >> version: Eclipse Persistence Services - 2.7.4.v20190115-ad5b7c6b2a > >> [EL Info]: 2020-06-05 > >> > 20:23:27.215--ServerSession(1764341773)--/file:/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/moviefun/WEB-INF/classes/_movie-unit > >> login successful > >> [EL Warning]: 2020-06-05 20:23:27.27--The collection of metamodel types > is > >> empty. Model classes may not have been found during entity search for > Java > >> SE and some Java EE container managed persistence units. Please verify > >> that your entity classes are referenced in persistence.xml using either > >> elements or a global > >> false element > >> 05-Jun-2020 20:23:27.309 SEVERE [http-nio-8080-exec-1] > >> > org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException > >> EjbTransactionUtil.handleSystemException: Object: > >> org.superbiz.moviefun.Movie@55c019e0 is not a known Entity type. > >> java.lang.IllegalArgumentException: Object: > >> org.superbiz.moviefun.Movie@55c019e0 is not a known Entity type. > >> at > >> > org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4326) > >> at > >> > org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:596) > >> at > >> > org.apache.openejb.persistence.JtaEntityManager.persist(JtaEntityManager.java:193) > >> at org.superbiz.moviefun.MoviesBean.addMovie(MoviesBean.java:42) > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >> at > >> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > >> at > >> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >> at java.lang.reflect.Method.invoke(Method.java:498) > >> at > >> > org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205) > >> at > >> > org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186) > >> at > >> > org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:191) > >> at > >> > org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:102) > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >> at > >> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > >> at > >> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >> at java.lang.reflect.Method.invoke(Method.java:498) > >> at > >> > org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205) > >> at > >> > org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186) > >> at > >> > org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:85) > >> at > >> > org.apache.openejb.core.stateless.
Re: Help wanted (Re: Javax to Jakarta Bytecode transformation progress)
Hello David,
thanks for explications .
I'm see this part of OpenWebBeans : )
--
*Daniel Dias dos Santos*
Java Developer
SouJava & JCP Member
GitHub: https://github.com/Daniel-Dos
Linkedin: www.linkedin.com/in/danieldiasjava
Twitter: http://twitter.com/danieldiasjava
Em dom., 7 de jun. de 2020 às 16:24, David Blevins
escreveu:
> Hey Daniel!
>
> We'd need to search in the source code for this related project. Using
> OpenWebBeans as an example it, the report shows four uses of "javax." that
> need some investigation. One of them is:
>
> - methodVisitor.visitLdcInsn("javax.");
> org/apache/webbeans/proxy/AbstractProxyFactory:335
>
> The above output basically means somewhere in OpenWebBeans source there's
> a class called "org.apache.webbeans.proxy.AbstractProxyFactory" In that
> class there's some logic that uses "javax." in a string.
>
> Investigating that basically entails:
>
> - Find in github were OpenWebBeans source lives
> - Find the git tag associated with the version we're using
> - Find the file AbstractProxyFactory.java file
> - Find the line that has "javax." as a string
> - Update the ticket with a link to that line (all the line numbers down
> the left in github's source view are links)
>
> And then separately, try and see if you can figure out what that code is
> doing and if it's something that might be affected by the javax-to-jakarta
> rename.
>
> For example if the string is being used in an `if` block that has some
> logic like "if the class starts with javax., we need to treat it
> separately", then possibly the code would need to be adjusted to, "if the
> class starts with javax. or jakarta., we need to treat it separately."
>
> Now there's no part of the task that involves updating the code. Those of
> us who are familiar with ASM and bytecode manipulation could handle that.
> But if we divide and conquer on the investigation side, those of us who do
> have bytecode manipulation skills can be heads-down on that while others
> are doing the work associated with investigating code that might need to be
> bytecode modified.
>
> In actuality this is kind of a code-review task and very much could help
> to have several perspectives on what the code might be doing and thoughts
> on if it needs to be updated and how. It could be smart to find the code,
> post the link with some initial thoughts and then ask "here's what I see,
> what do others think?"
>
> Ultimately, we'll all need to be very confident of what the updated code
> should look like (if changes are needed) in order to do any bytecode
> modification.
>
> That whole process will likely take input from a few of us and likely the
> project itself, but we do need some brave souls to get the process started
> for each item that needs investigation.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Jun 7, 2020, at 11:38 AM, Daniel Dias Dos Santos <
> daniel.dias.analist...@gmail.com> wrote:
> >
> > Hello David,
> >
> > a doubt.
> > this process of investigation of the items reported, is for searching
> > within the TomEE code or the dependencies that it uses.
> > for example, for OpenWebBeans, search the code for this project.
> >
> > thank you .
> > --
> >
> > *Daniel Dias dos Santos*
> > Java Developer
> > SouJava & JCP Member
> > GitHub: https://github.com/Daniel-Dos
> > Linkedin: www.linkedin.com/in/danieldiasjava
> > Twitter: http://twitter.com/danieldiasjava
> >
> >
> > Em dom., 7 de jun. de 2020 às 15:08, David Blevins <
> david.blev...@gmail.com>
> > escreveu:
> >
> >> Ok, everyone. If you're looking for a concrete way to help we have
> >> several "needs a pair of eyes" tasks.
> >>
> >> The short version of the tasks:
> >>
> >> - Locate the source code in github and see if you can find the file and
> >> line number of the indicated "javax" references.
> >> - Post the github links to file & line number to jira ticket
> >> - Bonus, see if you can figure out what the code is doing (at least a
> >> little) and update the ticket
> >>
> >> See the slightly longer description here:
> >>
> >> - https://issues.apache.org/jira/browse/TOMEE-2839
> >>
> >> These are the things that need investigation:
> >>
> >> - BatchEE uses of "javax"
> >> https://issues.apache.org/jira/browse/TOMEE-2840
> >>
> >> - CXF uses of "javax"
> >> https://issues.apache.org/jira/browse/TOMEE-2841
> >>
> >> - Eclipselink uses of "javax"
> >> https://issues.apache.org/jira/browse/TOMEE-2842
> >>
> >> - Jackson uses "javax.xml."
> >> https://issues.apache.org/jira/browse/TOMEE-2838
> >>
> >> - Mojarra uses of "javax"
> >> https://issues.apache.org/jira/browse/TOMEE-2843
> >>
> >> - MyFaces use of "javax"
> >> https://issues.apache.org/jira/browse/TOMEE-2844
> >>
> >> - OpenWebBeans uses of "javax"
> >> https://issues.apache.org/jira/browse/TOMEE-2845
> >>
> >>
> >> Any help is incredibly welcome. Questions are even more welcome. I
> tried
> >> to keep this email short-ish so people woul
Re: Help wanted (Re: Javax to Jakarta Bytecode transformation progress)
On my side of the fence it's pretty clear we will end up with some edge cases
that won't be handled by the Eclipse Transformer; we will definitely end up
with some transformations that are pretty specific to a line or two of code in
a specific class. We'll likely need to handle those by doing another pass with
a more specialized transformer.
I'll see what I can do about creating a tool that can catch those edgecases and
fix them.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Jun 7, 2020, at 12:24 PM, David Blevins wrote:
>
> Hey Daniel!
>
> We'd need to search in the source code for this related project. Using
> OpenWebBeans as an example it, the report shows four uses of "javax." that
> need some investigation. One of them is:
>
> - methodVisitor.visitLdcInsn("javax.");
> org/apache/webbeans/proxy/AbstractProxyFactory:335
>
> The above output basically means somewhere in OpenWebBeans source there's a
> class called "org.apache.webbeans.proxy.AbstractProxyFactory" In that class
> there's some logic that uses "javax." in a string.
>
> Investigating that basically entails:
>
> - Find in github were OpenWebBeans source lives
> - Find the git tag associated with the version we're using
> - Find the file AbstractProxyFactory.java file
> - Find the line that has "javax." as a string
> - Update the ticket with a link to that line (all the line numbers down the
> left in github's source view are links)
>
> And then separately, try and see if you can figure out what that code is
> doing and if it's something that might be affected by the javax-to-jakarta
> rename.
>
> For example if the string is being used in an `if` block that has some logic
> like "if the class starts with javax., we need to treat it separately", then
> possibly the code would need to be adjusted to, "if the class starts with
> javax. or jakarta., we need to treat it separately."
>
> Now there's no part of the task that involves updating the code. Those of us
> who are familiar with ASM and bytecode manipulation could handle that. But
> if we divide and conquer on the investigation side, those of us who do have
> bytecode manipulation skills can be heads-down on that while others are doing
> the work associated with investigating code that might need to be bytecode
> modified.
>
> In actuality this is kind of a code-review task and very much could help to
> have several perspectives on what the code might be doing and thoughts on if
> it needs to be updated and how. It could be smart to find the code, post the
> link with some initial thoughts and then ask "here's what I see, what do
> others think?"
>
> Ultimately, we'll all need to be very confident of what the updated code
> should look like (if changes are needed) in order to do any bytecode
> modification.
>
> That whole process will likely take input from a few of us and likely the
> project itself, but we do need some brave souls to get the process started
> for each item that needs investigation.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>> On Jun 7, 2020, at 11:38 AM, Daniel Dias Dos Santos
>> wrote:
>>
>> Hello David,
>>
>> a doubt.
>> this process of investigation of the items reported, is for searching
>> within the TomEE code or the dependencies that it uses.
>> for example, for OpenWebBeans, search the code for this project.
>>
>> thank you .
>> --
>>
>> *Daniel Dias dos Santos*
>> Java Developer
>> SouJava & JCP Member
>> GitHub: https://github.com/Daniel-Dos
>> Linkedin: www.linkedin.com/in/danieldiasjava
>> Twitter: http://twitter.com/danieldiasjava
>>
>>
>> Em dom., 7 de jun. de 2020 às 15:08, David Blevins
>> escreveu:
>>
>>> Ok, everyone. If you're looking for a concrete way to help we have
>>> several "needs a pair of eyes" tasks.
>>>
>>> The short version of the tasks:
>>>
>>> - Locate the source code in github and see if you can find the file and
>>> line number of the indicated "javax" references.
>>> - Post the github links to file & line number to jira ticket
>>> - Bonus, see if you can figure out what the code is doing (at least a
>>> little) and update the ticket
>>>
>>> See the slightly longer description here:
>>>
>>> - https://issues.apache.org/jira/browse/TOMEE-2839
>>>
>>> These are the things that need investigation:
>>>
>>> - BatchEE uses of "javax"
>>> https://issues.apache.org/jira/browse/TOMEE-2840
>>>
>>> - CXF uses of "javax"
>>> https://issues.apache.org/jira/browse/TOMEE-2841
>>>
>>> - Eclipselink uses of "javax"
>>> https://issues.apache.org/jira/browse/TOMEE-2842
>>>
>>> - Jackson uses "javax.xml."
>>> https://issues.apache.org/jira/browse/TOMEE-2838
>>>
>>> - Mojarra uses of "javax"
>>> https://issues.apache.org/jira/browse/TOMEE-2843
>>>
>>> - MyFaces use of "javax"
>>> https://issues.apache.org/jira/browse/TOMEE-2844
>>>
>>> - OpenWebBeans uses of "javax"
>>> https://issues.apache.org/ji
Re: Help wanted (Re: Javax to Jakarta Bytecode transformation progress)
Hey Daniel!
We'd need to search in the source code for this related project. Using
OpenWebBeans as an example it, the report shows four uses of "javax." that need
some investigation. One of them is:
- methodVisitor.visitLdcInsn("javax.");
org/apache/webbeans/proxy/AbstractProxyFactory:335
The above output basically means somewhere in OpenWebBeans source there's a
class called "org.apache.webbeans.proxy.AbstractProxyFactory" In that class
there's some logic that uses "javax." in a string.
Investigating that basically entails:
- Find in github were OpenWebBeans source lives
- Find the git tag associated with the version we're using
- Find the file AbstractProxyFactory.java file
- Find the line that has "javax." as a string
- Update the ticket with a link to that line (all the line numbers down the
left in github's source view are links)
And then separately, try and see if you can figure out what that code is doing
and if it's something that might be affected by the javax-to-jakarta rename.
For example if the string is being used in an `if` block that has some logic
like "if the class starts with javax., we need to treat it separately", then
possibly the code would need to be adjusted to, "if the class starts with
javax. or jakarta., we need to treat it separately."
Now there's no part of the task that involves updating the code. Those of us
who are familiar with ASM and bytecode manipulation could handle that. But if
we divide and conquer on the investigation side, those of us who do have
bytecode manipulation skills can be heads-down on that while others are doing
the work associated with investigating code that might need to be bytecode
modified.
In actuality this is kind of a code-review task and very much could help to
have several perspectives on what the code might be doing and thoughts on if it
needs to be updated and how. It could be smart to find the code, post the link
with some initial thoughts and then ask "here's what I see, what do others
think?"
Ultimately, we'll all need to be very confident of what the updated code should
look like (if changes are needed) in order to do any bytecode modification.
That whole process will likely take input from a few of us and likely the
project itself, but we do need some brave souls to get the process started for
each item that needs investigation.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Jun 7, 2020, at 11:38 AM, Daniel Dias Dos Santos
> wrote:
>
> Hello David,
>
> a doubt.
> this process of investigation of the items reported, is for searching
> within the TomEE code or the dependencies that it uses.
> for example, for OpenWebBeans, search the code for this project.
>
> thank you .
> --
>
> *Daniel Dias dos Santos*
> Java Developer
> SouJava & JCP Member
> GitHub: https://github.com/Daniel-Dos
> Linkedin: www.linkedin.com/in/danieldiasjava
> Twitter: http://twitter.com/danieldiasjava
>
>
> Em dom., 7 de jun. de 2020 às 15:08, David Blevins
> escreveu:
>
>> Ok, everyone. If you're looking for a concrete way to help we have
>> several "needs a pair of eyes" tasks.
>>
>> The short version of the tasks:
>>
>> - Locate the source code in github and see if you can find the file and
>> line number of the indicated "javax" references.
>> - Post the github links to file & line number to jira ticket
>> - Bonus, see if you can figure out what the code is doing (at least a
>> little) and update the ticket
>>
>> See the slightly longer description here:
>>
>> - https://issues.apache.org/jira/browse/TOMEE-2839
>>
>> These are the things that need investigation:
>>
>> - BatchEE uses of "javax"
>> https://issues.apache.org/jira/browse/TOMEE-2840
>>
>> - CXF uses of "javax"
>> https://issues.apache.org/jira/browse/TOMEE-2841
>>
>> - Eclipselink uses of "javax"
>> https://issues.apache.org/jira/browse/TOMEE-2842
>>
>> - Jackson uses "javax.xml."
>> https://issues.apache.org/jira/browse/TOMEE-2838
>>
>> - Mojarra uses of "javax"
>> https://issues.apache.org/jira/browse/TOMEE-2843
>>
>> - MyFaces use of "javax"
>> https://issues.apache.org/jira/browse/TOMEE-2844
>>
>> - OpenWebBeans uses of "javax"
>> https://issues.apache.org/jira/browse/TOMEE-2845
>>
>>
>> Any help is incredibly welcome. Questions are even more welcome. I tried
>> to keep this email short-ish so people would read, but that just means
>> there's a lot of good questions waiting to be asked :)
>>
>> Ask away :)
>>
>>
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>>
>>> On Jun 6, 2020, at 3:26 PM, David Blevins
>> wrote:
>>>
>>> Ok, I think I finally have a report that is useful to consume. What I
>> did was grep the asmified bytecode for "javax", wrote a second regex to
>> filter out false matches, then collected, filtered duplicates and sorted
>> the remaining:
>>>
>>> -
>> https://github.com/dblevins/tomee-analysis/tree/3da78d1282d19
Re: Help wanted (Re: Javax to Jakarta Bytecode transformation progress)
Hello David, a doubt. this process of investigation of the items reported, is for searching within the TomEE code or the dependencies that it uses. for example, for OpenWebBeans, search the code for this project. thank you . -- *Daniel Dias dos Santos* Java Developer SouJava & JCP Member GitHub: https://github.com/Daniel-Dos Linkedin: www.linkedin.com/in/danieldiasjava Twitter: http://twitter.com/danieldiasjava Em dom., 7 de jun. de 2020 às 15:08, David Blevins escreveu: > Ok, everyone. If you're looking for a concrete way to help we have > several "needs a pair of eyes" tasks. > > The short version of the tasks: > > - Locate the source code in github and see if you can find the file and > line number of the indicated "javax" references. > - Post the github links to file & line number to jira ticket > - Bonus, see if you can figure out what the code is doing (at least a > little) and update the ticket > > See the slightly longer description here: > > - https://issues.apache.org/jira/browse/TOMEE-2839 > > These are the things that need investigation: > > - BatchEE uses of "javax" >https://issues.apache.org/jira/browse/TOMEE-2840 > > - CXF uses of "javax" >https://issues.apache.org/jira/browse/TOMEE-2841 > > - Eclipselink uses of "javax" >https://issues.apache.org/jira/browse/TOMEE-2842 > > - Jackson uses "javax.xml." >https://issues.apache.org/jira/browse/TOMEE-2838 > > - Mojarra uses of "javax" >https://issues.apache.org/jira/browse/TOMEE-2843 > > - MyFaces use of "javax" >https://issues.apache.org/jira/browse/TOMEE-2844 > > - OpenWebBeans uses of "javax" >https://issues.apache.org/jira/browse/TOMEE-2845 > > > Any help is incredibly welcome. Questions are even more welcome. I tried > to keep this email short-ish so people would read, but that just means > there's a lot of good questions waiting to be asked :) > > Ask away :) > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > > > On Jun 6, 2020, at 3:26 PM, David Blevins > wrote: > > > > Ok, I think I finally have a report that is useful to consume. What I > did was grep the asmified bytecode for "javax", wrote a second regex to > filter out false matches, then collected, filtered duplicates and sorted > the remaining: > > > > - > https://github.com/dblevins/tomee-analysis/tree/3da78d1282d19cd5e710cdfd5ef174e80c909b2d > > > > From a bytecode perspective I see a few scenarios which aren't covered: > > > > - Outer class references > > - Switch case with Enums > > - module-info import/export > > > > From a string perspective the big areas: > > > > - Bean validation message keys in annotations > > - JSF references to /javax.faces.resource and "javax_faces" > > - Several ambiguous references to "javax." > > > > After that there are several smaller occurrences. > > > > All total about 2508 hits. > > > > Now the big question, how to fix them :) > > > > > > -- > > David Blevins > > http://twitter.com/dblevins > > http://www.tomitribe.com > > > >> On Jun 5, 2020, at 12:50 PM, David Blevins > wrote: > >> > >> Looks like both my scanning tool and the Eclipse Transformer are not > picking up calls to outer classes. A couple examples: > >> > >> - > https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/util/JAXBSource%241-asmified.java#L27 > >> > >> - > https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/ContextFinder$2-asmified.java#L27 > >> > >> > >> > >> -- > >> David Blevins > >> http://twitter.com/dblevins > >> http://www.tomitribe.com > >> > >>> On Jun 5, 2020, at 12:31 PM, David Blevins > wrote: > >>> > >>> Here's the diff of the changed bytecode from revision > d429ba420dbdba7ea07c6a0c91f3135ef2343f28 > >>> > >>> - > https://github.com/dblevins/tomee-analysis/commit/b6026b56eaad3a19c8a3bd89eb5c92620dd5b5d7 > >>> > >>> Haven't had a chance to pick through it. > >>> > >>> -- > >>> David Blevins > >>> http://twitter.com/dblevins > >>> http://www.tomitribe.com > >>> > On Jun 5, 2020, at 12:26 PM, Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > > Deployed Moviefun. EJBs now scanned ok... now have an issue with > EclipseLink. We're still moving forward... > > 05-Jun-2020 20:23:21.976 INFO [main] > sun.reflect.DelegatingMethodAccessorImpl.invoke Deployment of web > application directory > [/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/ROOT] > has > finished in [161] ms > 05-Jun-2020 20:23:22.011 INFO [main] > sun.reflect.DelegatingMethodAccessorImpl.invoke Starting > ProtocolHandler > ["http-nio-8080"] > 05-Jun-2020 20:23:22.028 INFO [main] > sun.reflect.DelegatingMethodAccessorImpl.invoke Server startup in > [48,389] > milli
Help wanted (Re: Javax to Jakarta Bytecode transformation progress)
Ok, everyone. If you're looking for a concrete way to help we have several "needs a pair of eyes" tasks. The short version of the tasks: - Locate the source code in github and see if you can find the file and line number of the indicated "javax" references. - Post the github links to file & line number to jira ticket - Bonus, see if you can figure out what the code is doing (at least a little) and update the ticket See the slightly longer description here: - https://issues.apache.org/jira/browse/TOMEE-2839 These are the things that need investigation: - BatchEE uses of "javax" https://issues.apache.org/jira/browse/TOMEE-2840 - CXF uses of "javax" https://issues.apache.org/jira/browse/TOMEE-2841 - Eclipselink uses of "javax" https://issues.apache.org/jira/browse/TOMEE-2842 - Jackson uses "javax.xml." https://issues.apache.org/jira/browse/TOMEE-2838 - Mojarra uses of "javax" https://issues.apache.org/jira/browse/TOMEE-2843 - MyFaces use of "javax" https://issues.apache.org/jira/browse/TOMEE-2844 - OpenWebBeans uses of "javax" https://issues.apache.org/jira/browse/TOMEE-2845 Any help is incredibly welcome. Questions are even more welcome. I tried to keep this email short-ish so people would read, but that just means there's a lot of good questions waiting to be asked :) Ask away :) -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com > On Jun 6, 2020, at 3:26 PM, David Blevins wrote: > > Ok, I think I finally have a report that is useful to consume. What I did > was grep the asmified bytecode for "javax", wrote a second regex to filter > out false matches, then collected, filtered duplicates and sorted the > remaining: > > - > https://github.com/dblevins/tomee-analysis/tree/3da78d1282d19cd5e710cdfd5ef174e80c909b2d > > From a bytecode perspective I see a few scenarios which aren't covered: > > - Outer class references > - Switch case with Enums > - module-info import/export > > From a string perspective the big areas: > > - Bean validation message keys in annotations > - JSF references to /javax.faces.resource and "javax_faces" > - Several ambiguous references to "javax." > > After that there are several smaller occurrences. > > All total about 2508 hits. > > Now the big question, how to fix them :) > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > >> On Jun 5, 2020, at 12:50 PM, David Blevins wrote: >> >> Looks like both my scanning tool and the Eclipse Transformer are not picking >> up calls to outer classes. A couple examples: >> >> - >> https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/util/JAXBSource%241-asmified.java#L27 >> >> - >> https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/ContextFinder$2-asmified.java#L27 >> >> >> >> -- >> David Blevins >> http://twitter.com/dblevins >> http://www.tomitribe.com >> >>> On Jun 5, 2020, at 12:31 PM, David Blevins wrote: >>> >>> Here's the diff of the changed bytecode from revision >>> d429ba420dbdba7ea07c6a0c91f3135ef2343f28 >>> >>> - >>> https://github.com/dblevins/tomee-analysis/commit/b6026b56eaad3a19c8a3bd89eb5c92620dd5b5d7 >>> >>> Haven't had a chance to pick through it. >>> >>> -- >>> David Blevins >>> http://twitter.com/dblevins >>> http://www.tomitribe.com >>> On Jun 5, 2020, at 12:26 PM, Jonathan Gallimore wrote: Deployed Moviefun. EJBs now scanned ok... now have an issue with EclipseLink. We're still moving forward... 05-Jun-2020 20:23:21.976 INFO [main] sun.reflect.DelegatingMethodAccessorImpl.invoke Deployment of web application directory [/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/ROOT] has finished in [161] ms 05-Jun-2020 20:23:22.011 INFO [main] sun.reflect.DelegatingMethodAccessorImpl.invoke Starting ProtocolHandler ["http-nio-8080"] 05-Jun-2020 20:23:22.028 INFO [main] sun.reflect.DelegatingMethodAccessorImpl.invoke Server startup in [48,389] milliseconds [EL Info]: 2020-06-05 20:23:27.156--ServerSession(1764341773)--EclipseLink, version: Eclipse Persistence Services - 2.7.4.v20190115-ad5b7c6b2a [EL Info]: 2020-06-05 20:23:27.215--ServerSession(1764341773)--/file:/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/moviefun/WEB-INF/classes/_movie-unit login successful [EL Warning]: 2020-06-05 20:23:27.27--The collection of metamodel types is empty. Model classes may not have been found during entity search for Java SE and some Java EE container managed persistence units. Please verify that your entity classes are referenced in persistence.xml using either elements or a global
Re: Javax to Jakarta Bytecode transformation progress
Ok, I think I finally have a report that is useful to consume. What I did was grep the asmified bytecode for "javax", wrote a second regex to filter out false matches, then collected, filtered duplicates and sorted the remaining: - https://github.com/dblevins/tomee-analysis/tree/3da78d1282d19cd5e710cdfd5ef174e80c909b2d From a bytecode perspective I see a few scenarios which aren't covered: - Outer class references - Switch case with Enums - module-info import/export From a string perspective the big areas: - Bean validation message keys in annotations - JSF references to /javax.faces.resource and "javax_faces" - Several ambiguous references to "javax." After that there are several smaller occurrences. All total about 2508 hits. Now the big question, how to fix them :) -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com > On Jun 5, 2020, at 12:50 PM, David Blevins wrote: > > Looks like both my scanning tool and the Eclipse Transformer are not picking > up calls to outer classes. A couple examples: > > - > https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/util/JAXBSource%241-asmified.java#L27 > > - > https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/ContextFinder$2-asmified.java#L27 > > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > >> On Jun 5, 2020, at 12:31 PM, David Blevins wrote: >> >> Here's the diff of the changed bytecode from revision >> d429ba420dbdba7ea07c6a0c91f3135ef2343f28 >> >> - >> https://github.com/dblevins/tomee-analysis/commit/b6026b56eaad3a19c8a3bd89eb5c92620dd5b5d7 >> >> Haven't had a chance to pick through it. >> >> -- >> David Blevins >> http://twitter.com/dblevins >> http://www.tomitribe.com >> >>> On Jun 5, 2020, at 12:26 PM, Jonathan Gallimore >>> wrote: >>> >>> Deployed Moviefun. EJBs now scanned ok... now have an issue with >>> EclipseLink. We're still moving forward... >>> >>> 05-Jun-2020 20:23:21.976 INFO [main] >>> sun.reflect.DelegatingMethodAccessorImpl.invoke Deployment of web >>> application directory >>> [/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/ROOT] has >>> finished in [161] ms >>> 05-Jun-2020 20:23:22.011 INFO [main] >>> sun.reflect.DelegatingMethodAccessorImpl.invoke Starting ProtocolHandler >>> ["http-nio-8080"] >>> 05-Jun-2020 20:23:22.028 INFO [main] >>> sun.reflect.DelegatingMethodAccessorImpl.invoke Server startup in [48,389] >>> milliseconds >>> [EL Info]: 2020-06-05 20:23:27.156--ServerSession(1764341773)--EclipseLink, >>> version: Eclipse Persistence Services - 2.7.4.v20190115-ad5b7c6b2a >>> [EL Info]: 2020-06-05 >>> 20:23:27.215--ServerSession(1764341773)--/file:/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/moviefun/WEB-INF/classes/_movie-unit >>> login successful >>> [EL Warning]: 2020-06-05 20:23:27.27--The collection of metamodel types is >>> empty. Model classes may not have been found during entity search for Java >>> SE and some Java EE container managed persistence units. Please verify >>> that your entity classes are referenced in persistence.xml using either >>> elements or a global >>> false element >>> 05-Jun-2020 20:23:27.309 SEVERE [http-nio-8080-exec-1] >>> org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException >>> EjbTransactionUtil.handleSystemException: Object: >>> org.superbiz.moviefun.Movie@55c019e0 is not a known Entity type. >>> java.lang.IllegalArgumentException: Object: >>> org.superbiz.moviefun.Movie@55c019e0 is not a known Entity type. >>> at >>> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4326) >>> at >>> org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:596) >>> at >>> org.apache.openejb.persistence.JtaEntityManager.persist(JtaEntityManager.java:193) >>> at org.superbiz.moviefun.MoviesBean.addMovie(MoviesBean.java:42) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:498) >>> at >>> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205) >>> at >>> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186) >>> at >>> org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:191) >>> at >>> org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:102) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >
Re: Javax to Jakarta Bytecode transformation progress
Looks like both my scanning tool and the Eclipse Transformer are not picking up calls to outer classes. A couple examples: - https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/util/JAXBSource%241-asmified.java#L27 - https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-plume-8.0.3-SNAPSHOT.zip/apache-tomee-plume-8.0.3-SNAPSHOT/lib/jakarta.xml.bind-api-2.3.2.jar/jakarta/xml/bind/ContextFinder$2-asmified.java#L27 -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com > On Jun 5, 2020, at 12:31 PM, David Blevins wrote: > > Here's the diff of the changed bytecode from revision > d429ba420dbdba7ea07c6a0c91f3135ef2343f28 > > - > https://github.com/dblevins/tomee-analysis/commit/b6026b56eaad3a19c8a3bd89eb5c92620dd5b5d7 > > Haven't had a chance to pick through it. > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > >> On Jun 5, 2020, at 12:26 PM, Jonathan Gallimore >> wrote: >> >> Deployed Moviefun. EJBs now scanned ok... now have an issue with >> EclipseLink. We're still moving forward... >> >> 05-Jun-2020 20:23:21.976 INFO [main] >> sun.reflect.DelegatingMethodAccessorImpl.invoke Deployment of web >> application directory >> [/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/ROOT] has >> finished in [161] ms >> 05-Jun-2020 20:23:22.011 INFO [main] >> sun.reflect.DelegatingMethodAccessorImpl.invoke Starting ProtocolHandler >> ["http-nio-8080"] >> 05-Jun-2020 20:23:22.028 INFO [main] >> sun.reflect.DelegatingMethodAccessorImpl.invoke Server startup in [48,389] >> milliseconds >> [EL Info]: 2020-06-05 20:23:27.156--ServerSession(1764341773)--EclipseLink, >> version: Eclipse Persistence Services - 2.7.4.v20190115-ad5b7c6b2a >> [EL Info]: 2020-06-05 >> 20:23:27.215--ServerSession(1764341773)--/file:/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/moviefun/WEB-INF/classes/_movie-unit >> login successful >> [EL Warning]: 2020-06-05 20:23:27.27--The collection of metamodel types is >> empty. Model classes may not have been found during entity search for Java >> SE and some Java EE container managed persistence units. Please verify >> that your entity classes are referenced in persistence.xml using either >> elements or a global >> false element >> 05-Jun-2020 20:23:27.309 SEVERE [http-nio-8080-exec-1] >> org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException >> EjbTransactionUtil.handleSystemException: Object: >> org.superbiz.moviefun.Movie@55c019e0 is not a known Entity type. >> java.lang.IllegalArgumentException: Object: >> org.superbiz.moviefun.Movie@55c019e0 is not a known Entity type. >> at >> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4326) >> at >> org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:596) >> at >> org.apache.openejb.persistence.JtaEntityManager.persist(JtaEntityManager.java:193) >> at org.superbiz.moviefun.MoviesBean.addMovie(MoviesBean.java:42) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at >> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205) >> at >> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186) >> at >> org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:191) >> at >> org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:102) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at >> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205) >> at >> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186) >> at >> org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:85) >> at >> org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:252) >> at >> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:212) >> at >> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265) >> at >> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260) >> at >> org.apache.openejb.core.ivm
Re: Javax to Jakarta Bytecode transformation progress
Here's the diff of the changed bytecode from revision d429ba420dbdba7ea07c6a0c91f3135ef2343f28 - https://github.com/dblevins/tomee-analysis/commit/b6026b56eaad3a19c8a3bd89eb5c92620dd5b5d7 Haven't had a chance to pick through it. -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com > On Jun 5, 2020, at 12:26 PM, Jonathan Gallimore > wrote: > > Deployed Moviefun. EJBs now scanned ok... now have an issue with > EclipseLink. We're still moving forward... > > 05-Jun-2020 20:23:21.976 INFO [main] > sun.reflect.DelegatingMethodAccessorImpl.invoke Deployment of web > application directory > [/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/ROOT] has > finished in [161] ms > 05-Jun-2020 20:23:22.011 INFO [main] > sun.reflect.DelegatingMethodAccessorImpl.invoke Starting ProtocolHandler > ["http-nio-8080"] > 05-Jun-2020 20:23:22.028 INFO [main] > sun.reflect.DelegatingMethodAccessorImpl.invoke Server startup in [48,389] > milliseconds > [EL Info]: 2020-06-05 20:23:27.156--ServerSession(1764341773)--EclipseLink, > version: Eclipse Persistence Services - 2.7.4.v20190115-ad5b7c6b2a > [EL Info]: 2020-06-05 > 20:23:27.215--ServerSession(1764341773)--/file:/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/moviefun/WEB-INF/classes/_movie-unit > login successful > [EL Warning]: 2020-06-05 20:23:27.27--The collection of metamodel types is > empty. Model classes may not have been found during entity search for Java > SE and some Java EE container managed persistence units. Please verify > that your entity classes are referenced in persistence.xml using either > elements or a global > false element > 05-Jun-2020 20:23:27.309 SEVERE [http-nio-8080-exec-1] > org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException > EjbTransactionUtil.handleSystemException: Object: > org.superbiz.moviefun.Movie@55c019e0 is not a known Entity type. > java.lang.IllegalArgumentException: Object: > org.superbiz.moviefun.Movie@55c019e0 is not a known Entity type. > at > org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4326) > at > org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:596) > at > org.apache.openejb.persistence.JtaEntityManager.persist(JtaEntityManager.java:193) > at org.superbiz.moviefun.MoviesBean.addMovie(MoviesBean.java:42) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205) > at > org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186) > at > org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:191) > at > org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:102) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205) > at > org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186) > at > org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:85) > at > org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:252) > at > org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:212) > at > org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265) > at > org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260) > at > org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:89) > at > org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:349) > at > org.superbiz.moviefun.MoviesBean$$LocalBeanProxy.addMovie(org/superbiz/moviefun/MoviesBean.java) > at org.apache.jsp.setup_jsp._jspService(setup_jsp.java:154) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:71) > at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:741) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:477) > at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329) > at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:741) > at > org.apache.catalina.core.Ap
Re: Javax to Jakarta Bytecode transformation progress
Deployed Moviefun. EJBs now scanned ok... now have an issue with EclipseLink. We're still moving forward... 05-Jun-2020 20:23:21.976 INFO [main] sun.reflect.DelegatingMethodAccessorImpl.invoke Deployment of web application directory [/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/ROOT] has finished in [161] ms 05-Jun-2020 20:23:22.011 INFO [main] sun.reflect.DelegatingMethodAccessorImpl.invoke Starting ProtocolHandler ["http-nio-8080"] 05-Jun-2020 20:23:22.028 INFO [main] sun.reflect.DelegatingMethodAccessorImpl.invoke Server startup in [48,389] milliseconds [EL Info]: 2020-06-05 20:23:27.156--ServerSession(1764341773)--EclipseLink, version: Eclipse Persistence Services - 2.7.4.v20190115-ad5b7c6b2a [EL Info]: 2020-06-05 20:23:27.215--ServerSession(1764341773)--/file:/home/jgallimore/srv/apache-tomee-plume-8.0.3-SNAPSHOT/webapps/moviefun/WEB-INF/classes/_movie-unit login successful [EL Warning]: 2020-06-05 20:23:27.27--The collection of metamodel types is empty. Model classes may not have been found during entity search for Java SE and some Java EE container managed persistence units. Please verify that your entity classes are referenced in persistence.xml using either elements or a global false element 05-Jun-2020 20:23:27.309 SEVERE [http-nio-8080-exec-1] org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException EjbTransactionUtil.handleSystemException: Object: org.superbiz.moviefun.Movie@55c019e0 is not a known Entity type. java.lang.IllegalArgumentException: Object: org.superbiz.moviefun.Movie@55c019e0 is not a known Entity type. at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4326) at org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:596) at org.apache.openejb.persistence.JtaEntityManager.persist(JtaEntityManager.java:193) at org.superbiz.moviefun.MoviesBean.addMovie(MoviesBean.java:42) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205) at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186) at org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:191) at org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205) at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186) at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:85) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:252) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:212) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:89) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:349) at org.superbiz.moviefun.MoviesBean$$LocalBeanProxy.addMovie(org/superbiz/moviefun/MoviesBean.java) at org.apache.jsp.setup_jsp._jspService(setup_jsp.java:154) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:71) at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:741) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:477) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329) at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:741) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.openejb.server.httpd.EEFilter.doFilter(EEFilter.java:65) at org.apache.catalina.core.ApplicationFilte
Re: Javax to Jakarta Bytecode transformation progress
Ok, got to a point where the server boots without error and I can load the JSP for the root page. There's one issue where ecj.jar is signed, and whatever the transformer is doing (apparently nothing apart from changing the manifest) breaks the signature. Removing the signing is necessary to allow the JSP compilation to work. I'll try and find some way to exclude that jar. I'm just pushing the transformer and plugin and committing my changes. I'll then try booting up some other samples like moviefun. Jon On Fri, Jun 5, 2020 at 1:38 PM Jonathan Gallimore < jonathan.gallim...@gmail.com> wrote: > With the latest changes, here's the results: > > Path javax uses total > ./openejb-core-8.0.3-SNAPSHOT.jar 475 > ./catalina.jar 120 > ./activemq-client-5.15.12.jar 9 > ./openjpa-3.1.0.jar 3 > ./openejb-webservices-8.0.3-SNAPSHOT.jar 35 > ./javaee-api-8.0-4.jar 1127 > total affected 2% (6 of 207 scanned) 1769 > > I think this looks worse than it actually is. The specific references > found under javax are: > > javax.enterprise.deploy.model.DDBean > javax.enterprise.deploy.model.DDBeanRoot > javax.enterprise.deploy.model.DeployableObject > javax.enterprise.deploy.model.exceptions.DDBeanCreateException > javax.enterprise.deploy.model.XpathEvent > javax.enterprise.deploy.model.XpathListener > javax.enterprise.deploy.shared.ActionType > javax.enterprise.deploy.shared.CommandType > javax.enterprise.deploy.shared.DConfigBeanVersionType > javax.enterprise.deploy.shared.factories.DeploymentFactoryManager > javax.enterprise.deploy.shared.ModuleType > javax.enterprise.deploy.shared.StateType > javax.enterprise.deploy.spi.DConfigBean > javax.enterprise.deploy.spi.DConfigBeanRoot > javax.enterprise.deploy.spi.DeploymentConfiguration > javax.enterprise.deploy.spi.DeploymentManager > javax.enterprise.deploy.spi.exceptions.BeanNotFoundException > javax.enterprise.deploy.spi.exceptions.ClientExecuteException > javax.enterprise.deploy.spi.exceptions.ConfigurationException > > javax.enterprise.deploy.spi.exceptions.DConfigBeanVersionUnsupportedException > javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException > javax.enterprise.deploy.spi.exceptions.InvalidModuleException > javax.enterprise.deploy.spi.exceptions.OperationUnsupportedException > javax.enterprise.deploy.spi.exceptions.TargetException > javax.enterprise.deploy.spi.factories.DeploymentFactory > javax.enterprise.deploy.spi.status.ClientConfiguration > javax.enterprise.deploy.spi.status.DeploymentStatus > javax.enterprise.deploy.spi.status.ProgressEvent > javax.enterprise.deploy.spi.status.ProgressListener > javax.enterprise.deploy.spi.status.ProgressObject > javax.enterprise.deploy.spi.Target > javax.enterprise.deploy.spi.TargetModuleID > javax.management.j2ee.ListenerRegistration > javax.management.j2ee.Management > javax.management.j2ee.ManagementHome > javax.management.j2ee.statistics.BoundaryStatistic > javax.management.j2ee.statistics.BoundedRangeStatistic > javax.management.j2ee.statistics.CountStatistic > javax.management.j2ee.statistics.EJBStats > javax.management.j2ee.statistics.JCAConnectionPoolStats > javax.management.j2ee.statistics.JCAConnectionStats > javax.management.j2ee.statistics.JDBCConnectionPoolStats > javax.management.j2ee.statistics.JDBCConnectionStats > javax.management.j2ee.statistics.JMSConnectionStats > javax.management.j2ee.statistics.JMSConsumerStats > javax.management.j2ee.statistics.JMSEndpointStats > javax.management.j2ee.statistics.JMSProducerStats > javax.management.j2ee.statistics.JMSSessionStats > javax.management.j2ee.statistics.RangeStatistic > javax.management.j2ee.statistics.SessionBeanStats > javax.management.j2ee.statistics.Statistic > javax.management.j2ee.statistics.Stats > javax.management.j2ee.statistics.TimeStatistic > javax.persistence.Embeddable > javax.persistence.Entity > javax.persistence.MappedSuperclass > javax.xml.registry.BulkResponse > javax.xml.registry.BusinessLifeCycleManager > javax.xml.registry.BusinessQueryManager > javax.xml.registry.CapabilityProfile > javax.xml.registry.Connection > javax.xml.registry.ConnectionFactory > javax.xml.registry.ConnectionFactoryClass > javax.xml.registry.DeclarativeQueryManager > javax.xml.registry.FederatedConnection > javax.xml.registry.infomodel.Association > javax.xml.registry.infomodel.Classification > javax.xml.registry.infomodel.ClassificationScheme > javax.xml.registry.infomodel.Concept > javax.xml.registry.infomodel.EmailAddress > javax.xml.registry.infomodel.ExtensibleObject > javax.xml.registry.infomodel.ExternalIdentifier > javax.xml.registry.infomodel.ExternalLink > javax.xml.registry.infomodel.ExtrinsicObject > javax.xml.registry.infomodel.InternationalString > javax.xml.registry.infomodel.Key > javax.xml.registry.infomodel.LocalizedString > javax.xml.registry.infomodel.Organization > javax.xml.registry.infomodel.PersonName > javax.xml.registry.infomodel.PostalAddress > javax.xml.registry.infomodel.RegistryEntry > javax.xml.registry.infomodel.Reg
Re: Javax to Jakarta Bytecode transformation progress
With the latest changes, here's the results: Path javax uses total ./openejb-core-8.0.3-SNAPSHOT.jar 475 ./catalina.jar 120 ./activemq-client-5.15.12.jar 9 ./openjpa-3.1.0.jar 3 ./openejb-webservices-8.0.3-SNAPSHOT.jar 35 ./javaee-api-8.0-4.jar 1127 total affected 2% (6 of 207 scanned) 1769 I think this looks worse than it actually is. The specific references found under javax are: javax.enterprise.deploy.model.DDBean javax.enterprise.deploy.model.DDBeanRoot javax.enterprise.deploy.model.DeployableObject javax.enterprise.deploy.model.exceptions.DDBeanCreateException javax.enterprise.deploy.model.XpathEvent javax.enterprise.deploy.model.XpathListener javax.enterprise.deploy.shared.ActionType javax.enterprise.deploy.shared.CommandType javax.enterprise.deploy.shared.DConfigBeanVersionType javax.enterprise.deploy.shared.factories.DeploymentFactoryManager javax.enterprise.deploy.shared.ModuleType javax.enterprise.deploy.shared.StateType javax.enterprise.deploy.spi.DConfigBean javax.enterprise.deploy.spi.DConfigBeanRoot javax.enterprise.deploy.spi.DeploymentConfiguration javax.enterprise.deploy.spi.DeploymentManager javax.enterprise.deploy.spi.exceptions.BeanNotFoundException javax.enterprise.deploy.spi.exceptions.ClientExecuteException javax.enterprise.deploy.spi.exceptions.ConfigurationException javax.enterprise.deploy.spi.exceptions.DConfigBeanVersionUnsupportedException javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException javax.enterprise.deploy.spi.exceptions.InvalidModuleException javax.enterprise.deploy.spi.exceptions.OperationUnsupportedException javax.enterprise.deploy.spi.exceptions.TargetException javax.enterprise.deploy.spi.factories.DeploymentFactory javax.enterprise.deploy.spi.status.ClientConfiguration javax.enterprise.deploy.spi.status.DeploymentStatus javax.enterprise.deploy.spi.status.ProgressEvent javax.enterprise.deploy.spi.status.ProgressListener javax.enterprise.deploy.spi.status.ProgressObject javax.enterprise.deploy.spi.Target javax.enterprise.deploy.spi.TargetModuleID javax.management.j2ee.ListenerRegistration javax.management.j2ee.Management javax.management.j2ee.ManagementHome javax.management.j2ee.statistics.BoundaryStatistic javax.management.j2ee.statistics.BoundedRangeStatistic javax.management.j2ee.statistics.CountStatistic javax.management.j2ee.statistics.EJBStats javax.management.j2ee.statistics.JCAConnectionPoolStats javax.management.j2ee.statistics.JCAConnectionStats javax.management.j2ee.statistics.JDBCConnectionPoolStats javax.management.j2ee.statistics.JDBCConnectionStats javax.management.j2ee.statistics.JMSConnectionStats javax.management.j2ee.statistics.JMSConsumerStats javax.management.j2ee.statistics.JMSEndpointStats javax.management.j2ee.statistics.JMSProducerStats javax.management.j2ee.statistics.JMSSessionStats javax.management.j2ee.statistics.RangeStatistic javax.management.j2ee.statistics.SessionBeanStats javax.management.j2ee.statistics.Statistic javax.management.j2ee.statistics.Stats javax.management.j2ee.statistics.TimeStatistic javax.persistence.Embeddable javax.persistence.Entity javax.persistence.MappedSuperclass javax.xml.registry.BulkResponse javax.xml.registry.BusinessLifeCycleManager javax.xml.registry.BusinessQueryManager javax.xml.registry.CapabilityProfile javax.xml.registry.Connection javax.xml.registry.ConnectionFactory javax.xml.registry.ConnectionFactoryClass javax.xml.registry.DeclarativeQueryManager javax.xml.registry.FederatedConnection javax.xml.registry.infomodel.Association javax.xml.registry.infomodel.Classification javax.xml.registry.infomodel.ClassificationScheme javax.xml.registry.infomodel.Concept javax.xml.registry.infomodel.EmailAddress javax.xml.registry.infomodel.ExtensibleObject javax.xml.registry.infomodel.ExternalIdentifier javax.xml.registry.infomodel.ExternalLink javax.xml.registry.infomodel.ExtrinsicObject javax.xml.registry.infomodel.InternationalString javax.xml.registry.infomodel.Key javax.xml.registry.infomodel.LocalizedString javax.xml.registry.infomodel.Organization javax.xml.registry.infomodel.PersonName javax.xml.registry.infomodel.PostalAddress javax.xml.registry.infomodel.RegistryEntry javax.xml.registry.infomodel.RegistryObject javax.xml.registry.infomodel.RegistryPackage javax.xml.registry.infomodel.Service javax.xml.registry.infomodel.ServiceBinding javax.xml.registry.infomodel.Slot javax.xml.registry.infomodel.SpecificationLink javax.xml.registry.infomodel.TelephoneNumber javax.xml.registry.infomodel.URIValidator javax.xml.registry.infomodel.User javax.xml.registry.infomodel.Versionable javax.xml.registry.InvalidRequestException javax.xml.registry.JAXRException javax.xml.registry.JAXRResponse javax.xml.registry.LifeCycleManager javax.xml.registry.Query javax.xml.registry.QueryManager javax.xml.registry.RegistryException javax.xml.registry.RegistryService javax.xml.registry.UnsupportedCapabilityException javax.xml.rpc.Call javax.xml.rpc.encoding.Deserializer javax.xml.rpc.encoding.Deserialize
Re: Javax to Jakarta Bytecode transformation progress
Awesome, thanks David. Looks like my last rule set was a little too aggressive. I'm running with this list now and will post the results. Jon On Thu, Jun 4, 2020 at 8:39 PM David Blevins wrote: > I'll try and submit this as a PR to the jakarta.ee website, but here's > the exact list: > > - https://gist.github.com/dblevins/9a6d4b1c90986a4116dd738c9e5ef212 > > Short answer is `javax.management.j2ee` should not be migrated and is > unfortunately in a broken state. The solution in a "true" Jakarta EE 9 > release would be to remove it. > > I'm not too sure what the right solution is for the bytecode approach. > There are two other broken packages, javax.xml.registry and javax.xml.rpc. > I know we don't support those APIs, but I don't know if we have code that > still touches javax.xml.rpc. > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > > > On Jun 4, 2020, at 9:05 AM, Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > > > > Fixed this by migrating javax.management.j2ee, but leaving > > javax.management. > > > > Now I have this error: > > > > 04-Jun-2020 17:03:37.671 SEVERE [main] > > > org.apache.catalina.startup.ContextConfig.processServletContainerInitializers > > Failed to detect ServletContainerInitializers for context with name [] > > java.io.IOException: java.lang.ClassNotFoundException: > > com.sun.faces.config.FacesInitializeropeExtension > > at > > > org.apache.catalina.startup.WebappServiceLoader.loadServices(WebappServiceLoader.java:235) > > at > > > org.apache.catalina.startup.WebappServiceLoader.load(WebappServiceLoader.java:203) > > at > > > org.apache.catalina.startup.ContextConfig.processServletContainerInitializers(ContextConfig.java:1672) > > at > > > org.apache.catalina.startup.OpenEJBContextConfig.processServletContainerInitializers(OpenEJBContextConfig.java:488) > > at > > > org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1137) > > at > > > org.apache.catalina.startup.OpenEJBContextConfig.webConfig(OpenEJBContextConfig.java:411) > > at > > > org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:774) > > at > > > org.apache.catalina.startup.OpenEJBContextConfig.configureStart(OpenEJBContextConfig.java:124) > > at > > > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:301) > > at > > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) > > at > > > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5052) > > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > at > > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717) > > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) > > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) > > at > > > org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1133) > > at > > > org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1866) > > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > > at > > > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) > > at > > > java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) > > at > > > org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1045) > > at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:429) > > at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1576) > > at > > > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309) > > at > > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) > > at > > > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) > > at > org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) > > at > > > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:936) > > at > > > org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) > > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > at > > > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384) > > at > > > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374) > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > > at > > > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) > > at > > > java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134) > > at > > > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909) > > at > > > org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262) > > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > at > > > org.apache.catalin
Re: Javax to Jakarta Bytecode transformation progress
> On Jun 3, 2020, at 12:20 PM, Jonathan S. Fisher wrote: > > I'm just curious, could this be done at runtime with a Java Agent? I don't know what the capabilities of the Eclipse Transformer are, but definitely the Java Agent API does expose the right hooks that would allow a transformer to be wired in at runtime. It does slow classloading which is the majority of startup time, but it definitely would be achievable and not terribly difficult to write if you already have the bytecode transformation code. -David > On Wed, Jun 3, 2020 at 12:54 PM David Blevins > wrote: > >> Significantly better. Can you check that in? >> >> >> What I'm imagining to make it easier to digest the breadth of data: >> >> - run the asmifier on the unmodified zip >> - check every file into *github* >> - run the asmifier on the modified zip >> - check that in and create a PR >> - we can then pick through the PR to see what's happening >> >> >> -- >> David Blevins >> http://twitter.com/dblevins >> http://www.tomitribe.com >> >>> On Jun 3, 2020, at 10:45 AM, Jonathan Gallimore < >> jonathan.gallim...@gmail.com> wrote: >>> >>> Made some progress by adjusting the rules - here's the latest counts (not >>> including string references): >>> >>> Path javax uses total >>> ./opensaml-xmlsec-api-3.3.1.jar 2 >>> ./opensaml-soap-api-3.3.1.jar 5 >>> ./java-support-7.3.0.jar 12 >>> ./opensaml-saml-impl-3.3.1.jar 7 >>> ./opensaml-core-3.3.1.jar 5 >>> ./opensaml-profile-api-3.3.1.jar 1 >>> ./opensaml-saml-api-3.3.1.jar 7 >>> >>> And if we include string references: >>> >>> Path javax uses total >>> ./servlet-api.jar 26 >>> ./jakarta.activation-1.2.1.jar 2 >>> ./jsp-api.jar 13 >>> ./bval-jsr-2.0.3.jar 1 >>> ./taglibs-standard-impl-1.2.5.jar 17 >>> ./openejb-core-8.0.3-SNAPSHOT.jar 41 >>> ./cxf-core-3.3.6.jar 48 >>> ./catalina.jar 135 >>> ./cxf-rt-security-saml-3.3.6.jar 7 >>> ./cxf-rt-bindings-soap-3.3.6.jar 5 >>> ./taglibs-standard-jstlel-1.2.5.jar 1 >>> ./opensaml-xmlsec-api-3.3.1.jar 2 >>> ./opensaml-security-api-3.3.1.jar 2 >>> ./jakarta.xml.bind-api-2.3.2.jar 5 >>> ./taglibs-standard-spec-1.2.5.jar 11 >>> ./openejb-jee-8.0.3-SNAPSHOT.jar 1 >>> ./openwebbeans-impl-2.0.12.jar 4 >>> ./saaj-impl-1.5.1.jar 7 >>> ./opensaml-soap-api-3.3.1.jar 5 >>> ./jasper.jar 36 >>> ./jakarta.faces-2.3.14.jar 165 >>> ./openejb-client-8.0.3-SNAPSHOT.jar 1 >>> ./tomcat-util-scan.jar 1 >>> ./openjpa-3.1.0.jar 80 >>> ./cxf-rt-rs-security-oauth2-3.3.6.jar 1 >>> ./java-support-7.3.0.jar 12 >>> ./cxf-rt-frontend-jaxws-3.3.6.jar 74 >>> ./cxf-rt-transports-http-3.3.6.jar 10 >>> ./opensaml-saml-impl-3.3.1.jar 7 >>> ./catalina-ssi.jar 4 >>> ./cxf-rt-ws-security-3.3.6.jar 15 >>> ./javaee-api-8.0-4.jar 47 >>> ./tomee-catalina-8.0.3-SNAPSHOT.jar 1 >>> ./opensaml-core-3.3.1.jar 5 >>> ./cxf-rt-ws-addr-3.3.6.jar 4 >>> ./eclipselink-2.7.4.jar 177 >>> ./opensaml-profile-api-3.3.1.jar 1 >>> ./tomcat-coyote.jar 23 >>> ./opensaml-saml-api-3.3.1.jar 7 >>> ./cxf-rt-frontend-jaxrs-3.3.6.jar 3 >>> >>> This is looking a lot better. >>> >>> Jon >>> >>> On Wed, Jun 3, 2020 at 6:06 PM David Blevins >>> wrote: >>> > On Jun 3, 2020, at 9:03 AM, Jonathan Gallimore < jonathan.gallim...@gmail.com> wrote: > > Just wanted to follow up with some details on how I'm getting the >> numbers > below. I'm using this tool: https://github.com/tomitribe/jkta So people have a heads-up on that tool, I'm currently working on the Tomitribe side with Sonatype to scan all of Maven Central for uses of >> the affected javax packages. We'll be building a reporting site to share >> the data with everyone. I mention that just in case people get excited and think, "wow, we could help a lot of people with a tool like that!" >> Agree and covered :) "Go big or go home" as they say :) I unfortunately won't be able to go into much more detail. I'll just >> say we're all very excited and we hope to make the javax-to-jakarta >> transition as survivable as possible. > Once TomEE is built, I'm extracting the zip, changing to the lib >> folder, > and running the following commands: > > for f in *.jar; do java -jar > ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar $f > $f.tsv; done > for f in *.jar; do java -jar > ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar > --include-strings=true $f > $f.strings.tsv; done > java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir . > > jars.tsv > java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir > --include-strings=true . > jars.strings.tsv > > The goal to see what the gaps are from the transformation process and close > those gaps. I'll dig in and see what I can find. I've had my nose deep in ASM for a few weeks now, so we'll see if helps. -David >> >> > > -- > Jonathan | exabr...@gmail.com > Pessimists, see a
Re: Javax to Jakarta Bytecode transformation progress
I'll try and submit this as a PR to the jakarta.ee website, but here's the exact list: - https://gist.github.com/dblevins/9a6d4b1c90986a4116dd738c9e5ef212 Short answer is `javax.management.j2ee` should not be migrated and is unfortunately in a broken state. The solution in a "true" Jakarta EE 9 release would be to remove it. I'm not too sure what the right solution is for the bytecode approach. There are two other broken packages, javax.xml.registry and javax.xml.rpc. I know we don't support those APIs, but I don't know if we have code that still touches javax.xml.rpc. -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com > On Jun 4, 2020, at 9:05 AM, Jonathan Gallimore > wrote: > > Fixed this by migrating javax.management.j2ee, but leaving > javax.management. > > Now I have this error: > > 04-Jun-2020 17:03:37.671 SEVERE [main] > org.apache.catalina.startup.ContextConfig.processServletContainerInitializers > Failed to detect ServletContainerInitializers for context with name [] > java.io.IOException: java.lang.ClassNotFoundException: > com.sun.faces.config.FacesInitializeropeExtension > at > org.apache.catalina.startup.WebappServiceLoader.loadServices(WebappServiceLoader.java:235) > at > org.apache.catalina.startup.WebappServiceLoader.load(WebappServiceLoader.java:203) > at > org.apache.catalina.startup.ContextConfig.processServletContainerInitializers(ContextConfig.java:1672) > at > org.apache.catalina.startup.OpenEJBContextConfig.processServletContainerInitializers(OpenEJBContextConfig.java:488) > at > org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1137) > at > org.apache.catalina.startup.OpenEJBContextConfig.webConfig(OpenEJBContextConfig.java:411) > at > org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:774) > at > org.apache.catalina.startup.OpenEJBContextConfig.configureStart(OpenEJBContextConfig.java:124) > at > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:301) > at > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) > at > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5052) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717) > at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) > at > org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1133) > at > org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1866) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) > at > java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) > at > org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1045) > at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:429) > at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1576) > at > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309) > at > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) > at > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) > at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) > at > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:936) > at > org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384) > at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) > at > java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134) > at > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909) > at > org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.StandardService.startInternal(StandardService.java:421) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at org.apache.catalina.startup.Catalina.start(Catalina.java:633) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invok
Re: Javax to Jakarta Bytecode transformation progress
Fixed this by migrating javax.management.j2ee, but leaving javax.management. Now I have this error: 04-Jun-2020 17:03:37.671 SEVERE [main] org.apache.catalina.startup.ContextConfig.processServletContainerInitializers Failed to detect ServletContainerInitializers for context with name [] java.io.IOException: java.lang.ClassNotFoundException: com.sun.faces.config.FacesInitializeropeExtension at org.apache.catalina.startup.WebappServiceLoader.loadServices(WebappServiceLoader.java:235) at org.apache.catalina.startup.WebappServiceLoader.load(WebappServiceLoader.java:203) at org.apache.catalina.startup.ContextConfig.processServletContainerInitializers(ContextConfig.java:1672) at org.apache.catalina.startup.OpenEJBContextConfig.processServletContainerInitializers(OpenEJBContextConfig.java:488) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1137) at org.apache.catalina.startup.OpenEJBContextConfig.webConfig(OpenEJBContextConfig.java:411) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:774) at org.apache.catalina.startup.OpenEJBContextConfig.configureStart(OpenEJBContextConfig.java:124) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:301) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5052) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1133) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1866) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1045) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:429) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1576) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:936) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:421) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:633) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) Caused by: java.lang.ClassNotFoundException: com.sun.faces.config.FacesInitializeropeExtension at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1365) at org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(TomEEWebappClassLoader.java:209) at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1188) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at org.apache.catalina.startup.WebappServiceLoader.loadServices(WebappServiceLoader.java:232) ... 49 more Which I believe i
Re: Javax to Jakarta Bytecode transformation progress
Next problem:
[CORP\jgallimore@a-2yv8q9r2zol44 bin]$ ./catalina.sh run
Using CATALINA_BASE:
/home/jgallimore/dev/tomee/tomee/apache-tomee/target/tmp/apache-tomee-plume-8.0.3-SNAPSHOT
Using CATALINA_HOME:
/home/jgallimore/dev/tomee/tomee/apache-tomee/target/tmp/apache-tomee-plume-8.0.3-SNAPSHOT
Using CATALINA_TMPDIR:
/home/jgallimore/dev/tomee/tomee/apache-tomee/target/tmp/apache-tomee-plume-8.0.3-SNAPSHOT/temp
Using JRE_HOME:/home/jgallimore/Apps/jdk8u252-b09
Using CLASSPATH:
/home/jgallimore/dev/tomee/tomee/apache-tomee/target/tmp/apache-tomee-plume-8.0.3-SNAPSHOT/bin/bootstrap.jar:/home/jgallimore/dev/tomee/tomee/apache-tomee/target/tmp/apache-tomee-plume-8.0.3-SNAPSHOT/bin/tomcat-juli.jar
04-Jun-2020 16:21:51.803 INFO [main]
org.apache.openejb.persistence.PersistenceBootstrap.getDefaultProvider
Default JPA Provider changed to
org.eclipse.persistence.jpa.PersistenceProvider specified by
jar:file:/home/jgallimore/dev/tomee/tomee/apache-tomee/target/tmp/apache-tomee-plume-8.0.3-SNAPSHOT/lib/openejb-core-eclipselink-8.0.3-SNAPSHOT.jar!/META-INF/org.apache.openejb.persistence.PersistenceBootstrap.provider
java.lang.NoClassDefFoundError: jakarta/management/NotificationEmitter
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at
org.apache.catalina.startup.Catalina.createStartDigester(Catalina.java:294)
at org.apache.catalina.startup.Catalina.load(Catalina.java:559)
at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:303)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:473)
Caused by: java.lang.ClassNotFoundException:
jakarta.management.NotificationEmitter
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
... 20 more
Should javax.management not be moved to jakarta, or is it a split package?
We definitely carry some javax.management classes in our .jar files:
[CORP\jgallimore@a-2yv8q9r2zol44 lib]$ find . -name "*.jar" -exec jar tf
"{}" \; | grep javax/management
javax/management/
javax/management/NotificationInfo.class
javax/management/NotificationInfos.class
javax/management/MBean.class
javax/management/Description.class
javax/management/ManagedOperation.class
javax/management/ManagedAttribute.class
javax/management/
javax/management/j2ee/
javax/management/j2ee/ListenerRegistration.class
javax/management/j2ee/Management.class
javax/management/j2ee/ManagementHome.class
javax/management/j2ee/statistics/
javax/management/j2ee/statistics/BoundaryStatistic.class
javax/management/j2ee/statistics/BoundedRangeStatistic.class
javax/management/j2ee/statistics/CountStatistic.class
javax/management/j2ee/statistics/EJBStats.class
javax/management/j2ee/statistics/EntityBeanStats.class
javax/management/j2ee/statistics/JavaMailStats.class
javax/management/j2ee/statistics/JCAConnectionPoolStats.class
javax/management/j2ee/statistics/JCAConnectionStats.class
javax/management/j2ee/statistics/JCAStats.class
javax/management/j2ee/statistics/JDBCConnectionPoolStats.class
javax/management/j2ee/statistics/JDBCConnectionStats.class
javax/management/j2ee/statistics/JDBCStats.class
javax/management/j2ee/statistics/JMSConnectionStats.class
javax/management/j2ee/statistics/JMSConsumerStats.class
javax/management/j2ee/statistics/JMSEndpointStats.class
javax/management/j2ee/statistics/JMSProducerStats.class
javax/management/j2ee/statistics/JMSSessionStats.class
javax/management/j2ee/statistics/JMSStats.class
javax/management/j2ee/statistics/JTAStats.class
javax/management/j2ee/statistics/JVMStats.class
javax/management/j2ee/statistics/MessageDrivenBeanStats.class
javax/management/j2ee/statistics/RangeStatistic.class
javax/management/j2ee/statistics/ServletStats.class
javax/management/j2ee/statistics/SessionBeanStats.class
javax/management/j2ee/statistics/StatefulSessionBeanStats.class
javax/management/j2ee/statistics/StatelessSessionBeanStats.class
javax/management/j2ee/statistics/Statistic.class
javax/management/j2ee/statistics/Stats.
Re: Javax to Jakarta Bytecode transformation progress
Ok, I'm now down to (and this includes string references): Path javax uses total ./openjpa-3.1.0.jar 3 ./javaee-api-8.0-4.jar 1 ./eclipselink-2.7.4.jar 1 The strings themselves are: javax.persistence.Entity javax.persistence.Embeddable javax.persistence.MappedSuperclass javax.xml.ws.RespectBindingFeature javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory Last one likely failed on the equals sign. Not sure why the others were missed yet. Jon On Thu, Jun 4, 2020 at 12:58 PM Jonathan Gallimore < jonathan.gallim...@gmail.com> wrote: > These look like the strings that need to be replaced: > > javax.activation.addreverse > javax.activation.debug > javax.ejb.embeddable.appName > javax.ejb.embeddable.modules > javax.ejb.embeddable.provider > javax.enterprise.context.conversation > javax.enterprise.inject.allowProxying.classes > javax.enterprise.resource.webcontainer.jsf. > javax.faces.behavior.Ajax > javax.faces.behavior.event > javax.faces.contract.xml > javax.faces.converter.BigDecimalConverter.DECIMAL > javax.faces.converter.BigIntegerConverter.BIGINTEGER > javax.faces.converter.BooleanConverter.BOOLEAN > javax.faces.converter.ByteConverter.BYTE > javax.faces.converter.CharacterConverter.CHARACTER > javax.faces.converter.DateTimeConverter.DATE > javax.faces.converter.DateTimeConverter.DATETIME > javax.faces.converter.DateTimeConverter.TIME > javax.faces.converter.DoubleConverter.DOUBLE > javax.faces.converter.EnumConverter.ENUM > javax.faces.converter.EnumConverter.ENUM_NO_CLASS > javax.faces.converter.FloatConverter.FLOAT > javax.faces.converter.IntegerConverter.INTEGER > javax.faces.converter.LongConverter.LONG > javax.faces.converter.NumberConverter.CURRENCY > javax.faces.converter.NumberConverter.NUMBER > javax.faces.converter.NumberConverter.PATTERN > javax.faces.converter.NumberConverter.PERCENT > javax.faces.converter.ShortConverter.SHORT > javax.faces.converter.STRING > javax.faces.encodedURL > javax.faces.ensureOverriddenInvocation > javax.faces.error.xhtml > javax.faces.partial.event > javax.faces.partial.execute > javax.faces.partial.render > javax.faces.partial.resetValues > javax.faces.passthrough.Element > javax.faces.private.BEANS_VALIDATION_AVAILABLE > javax.faces.request.charset > javax.faces.resource.localePrefix > javax.faces.resource.Script > javax.faces.resource.Stylesheet > javax.faces.source > javax.faces.validator.beanValidator.ValidatorFactory > javax.faces.visit.SKIP_ITERATION > javax.persistence.bean.manager > javax.persistence.cache.retrieveMode > javax.persistence.cacheRetrieveMode > javax.persistence.cache.storeMode > javax.persistence.cacheStoreMode > javax.persistence.database-major-version > javax.persistence.database-minor-version > javax.persistence.database-product-name > javax.persistence.dataSource > javax.persistence.Embeddable > javax.persistence.Entity > javax.persistence.fetchgraph > javax.persistence.jdbc.driver > javax.persistence.jdbc.password > javax.persistence.jdbc.url > javax.persistence.jdbc.user > javax.persistence.jtaDataSource > javax.persistence.loadgraph > javax.persistence.lock > javax.persistence.lock.scope > javax.persistence.lock.timeout > javax.persistence.MappedSuperclass > javax.persistence.nonJtaDataSource > javax.persistence.provider > javax.persistence.query > javax.persistence.query.timeout > javax.persistence.schema-generation.connection > javax.persistence.schema-generation.create-database-schemas > javax.persistence.schema-generation.create-script-source > javax.persistence.schema-generation.create-source > javax.persistence.schema-generation.database.action > javax.persistence.schema-generation.drop-script-source > javax.persistence.schema-generation.drop-source > javax.persistence.schema-generation.scripts.action > javax.persistence.schema-generation.scripts.create-target > javax.persistence.schema-generation.scripts.drop-target > javax.persistence.sharedCache.mode > javax.persistence.sql-load-script-source > javax.persistence.transactionType > javax.persistence.validation.factory > javax.persistence.validation.group.pre-persist > javax.persistence.validation.group.pre-remove > javax.persistence.validation.group.pre-update > javax.persistence.validation.mode > javax.security.jacc.policy.provider > javax.servlet.async.context_path > javax.servlet.async.mapping > javax.servlet.async.path_info > javax.servlet.async.query_string > javax.servlet.async.request_uri > javax.servlet.async.servlet_path > javax.servlet.context.orderedLibs > javax.servlet.context.tempdir > javax.servlet.error.exception > javax.servlet.error.exception_type > javax.servlet.error.message > javax.servlet.error.request_uri > javax.servlet.error.servlet_name > javax.servlet.error.status_code > javax.servlet.forward.context_path > javax.servlet.forward.mapping > javax.servlet.forward.path_info > javax.servlet.forward.query_string > javax.servlet.forward.request_uri > javax.servlet.forward.servlet_path > javax.servlet.http.registerSession >
Re: Javax to Jakarta Bytecode transformation progress
These look like the strings that need to be replaced: javax.activation.addreverse javax.activation.debug javax.ejb.embeddable.appName javax.ejb.embeddable.modules javax.ejb.embeddable.provider javax.enterprise.context.conversation javax.enterprise.inject.allowProxying.classes javax.enterprise.resource.webcontainer.jsf. javax.faces.behavior.Ajax javax.faces.behavior.event javax.faces.contract.xml javax.faces.converter.BigDecimalConverter.DECIMAL javax.faces.converter.BigIntegerConverter.BIGINTEGER javax.faces.converter.BooleanConverter.BOOLEAN javax.faces.converter.ByteConverter.BYTE javax.faces.converter.CharacterConverter.CHARACTER javax.faces.converter.DateTimeConverter.DATE javax.faces.converter.DateTimeConverter.DATETIME javax.faces.converter.DateTimeConverter.TIME javax.faces.converter.DoubleConverter.DOUBLE javax.faces.converter.EnumConverter.ENUM javax.faces.converter.EnumConverter.ENUM_NO_CLASS javax.faces.converter.FloatConverter.FLOAT javax.faces.converter.IntegerConverter.INTEGER javax.faces.converter.LongConverter.LONG javax.faces.converter.NumberConverter.CURRENCY javax.faces.converter.NumberConverter.NUMBER javax.faces.converter.NumberConverter.PATTERN javax.faces.converter.NumberConverter.PERCENT javax.faces.converter.ShortConverter.SHORT javax.faces.converter.STRING javax.faces.encodedURL javax.faces.ensureOverriddenInvocation javax.faces.error.xhtml javax.faces.partial.event javax.faces.partial.execute javax.faces.partial.render javax.faces.partial.resetValues javax.faces.passthrough.Element javax.faces.private.BEANS_VALIDATION_AVAILABLE javax.faces.request.charset javax.faces.resource.localePrefix javax.faces.resource.Script javax.faces.resource.Stylesheet javax.faces.source javax.faces.validator.beanValidator.ValidatorFactory javax.faces.visit.SKIP_ITERATION javax.persistence.bean.manager javax.persistence.cache.retrieveMode javax.persistence.cacheRetrieveMode javax.persistence.cache.storeMode javax.persistence.cacheStoreMode javax.persistence.database-major-version javax.persistence.database-minor-version javax.persistence.database-product-name javax.persistence.dataSource javax.persistence.Embeddable javax.persistence.Entity javax.persistence.fetchgraph javax.persistence.jdbc.driver javax.persistence.jdbc.password javax.persistence.jdbc.url javax.persistence.jdbc.user javax.persistence.jtaDataSource javax.persistence.loadgraph javax.persistence.lock javax.persistence.lock.scope javax.persistence.lock.timeout javax.persistence.MappedSuperclass javax.persistence.nonJtaDataSource javax.persistence.provider javax.persistence.query javax.persistence.query.timeout javax.persistence.schema-generation.connection javax.persistence.schema-generation.create-database-schemas javax.persistence.schema-generation.create-script-source javax.persistence.schema-generation.create-source javax.persistence.schema-generation.database.action javax.persistence.schema-generation.drop-script-source javax.persistence.schema-generation.drop-source javax.persistence.schema-generation.scripts.action javax.persistence.schema-generation.scripts.create-target javax.persistence.schema-generation.scripts.drop-target javax.persistence.sharedCache.mode javax.persistence.sql-load-script-source javax.persistence.transactionType javax.persistence.validation.factory javax.persistence.validation.group.pre-persist javax.persistence.validation.group.pre-remove javax.persistence.validation.group.pre-update javax.persistence.validation.mode javax.security.jacc.policy.provider javax.servlet.async.context_path javax.servlet.async.mapping javax.servlet.async.path_info javax.servlet.async.query_string javax.servlet.async.request_uri javax.servlet.async.servlet_path javax.servlet.context.orderedLibs javax.servlet.context.tempdir javax.servlet.error.exception javax.servlet.error.exception_type javax.servlet.error.message javax.servlet.error.request_uri javax.servlet.error.servlet_name javax.servlet.error.status_code javax.servlet.forward.context_path javax.servlet.forward.mapping javax.servlet.forward.path_info javax.servlet.forward.query_string javax.servlet.forward.request_uri javax.servlet.forward.servlet_path javax.servlet.http.registerSession javax.servlet.include.context_path javax.servlet.include.mapping javax.servlet.include.path_info javax.servlet.include.query_string javax.servlet.include.request_uri javax.servlet.include.servlet_path javax.servlet.jsp.functions.allowed javax.servlet.jsp.jspApplication javax.servlet.jsp.jspConfig javax.servlet.jsp.jspException javax.servlet.jsp.jspOut javax.servlet.jsp.jspPage javax.servlet.jsp.jspPageContext javax.servlet.jsp.jspRequest javax.servlet.jsp.jspResponse javax.servlet.jsp.jspSession javax.servlet.jsp.jstl.fmt.fallbackLocale javax.servlet.jsp.jstl.fmt.locale javax.servlet.jsp.jstl.fmt.localizationContext javax.servlet.jsp.jstl.fmt.request.charset javax.servlet.jsp.jstl.fmt.timeZone javax.servlet.jsp.jstl.sql.dataSource javax.servlet.jsp.jstl.sql.maxRows javax.servlet.request.ciphe
Re: Javax to Jakarta Bytecode transformation progress
Ok, the last commit I pushed this morning seems to have cleared these references up altogether. My latest run of the jkta code shows no code references left. David, can you re-run your analysis and check? For the string references, here's the latest data: Path javax uses total ./servlet-api.jar 26 ./jakarta.activation-1.2.1.jar 2 ./jsp-api.jar 13 ./bval-jsr-2.0.3.jar 1 ./taglibs-standard-impl-1.2.5.jar 17 ./openejb-core-8.0.3-SNAPSHOT.jar 41 ./cxf-core-3.3.6.jar 48 ./catalina.jar 135 ./cxf-rt-security-saml-3.3.6.jar 7 ./cxf-rt-bindings-soap-3.3.6.jar 5 ./taglibs-standard-jstlel-1.2.5.jar 1 ./opensaml-security-api-3.3.1.jar 2 ./jakarta.xml.bind-api-2.3.2.jar 5 ./taglibs-standard-spec-1.2.5.jar 11 ./openejb-jee-8.0.3-SNAPSHOT.jar 1 ./openwebbeans-impl-2.0.12.jar 4 ./saaj-impl-1.5.1.jar 7 ./jasper.jar 36 ./jakarta.faces-2.3.14.jar 165 ./openejb-client-8.0.3-SNAPSHOT.jar 1 ./tomcat-util-scan.jar 1 ./openjpa-3.1.0.jar 80 ./cxf-rt-rs-security-oauth2-3.3.6.jar 1 ./cxf-rt-frontend-jaxws-3.3.6.jar 74 ./cxf-rt-transports-http-3.3.6.jar 10 ./catalina-ssi.jar 4 ./cxf-rt-ws-security-3.3.6.jar 15 ./javaee-api-8.0-4.jar 47 ./tomee-catalina-8.0.3-SNAPSHOT.jar 1 ./cxf-rt-ws-addr-3.3.6.jar 4 ./eclipselink-2.7.4.jar 177 ./tomcat-coyote.jar 23 ./cxf-rt-frontend-jaxrs-3.3.6.jar 3 Going to dig into what these actually are. I'm expecting that we'll be able to do the replacements of these with the transformer too. Jon On Thu, Jun 4, 2020 at 10:48 AM Jonathan Gallimore < jonathan.gallim...@gmail.com> wrote: > These are the references I'm seeing to update: > > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-xmlsec-api-3.3.1.jar/org/opensaml/xmlsec/signature/support/SignatureValidationProvider.adoc: > - javax.annotation.concurrent.ThreadSafe - 1 > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-xmlsec-api-3.3.1.jar/org/opensaml/xmlsec/signature/support/SignerProvider.adoc: > - javax.annotation.concurrent.ThreadSafe - 1 > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-soap-api-3.3.1.jar/org/opensaml/soap/client/SOAPClient.adoc: > - javax.annotation.concurrent.ThreadSafe - 1 > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-soap-api-3.3.1.jar/org/opensaml/soap/client/http/PipelineFactoryHttpSOAPClient.adoc: > - javax.annotation.concurrent.ThreadSafe - 1 > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-soap-api-3.3.1.jar/org/opensaml/soap/client/http/AbstractPipelineHttpSOAPClient.adoc: > - javax.annotation.concurrent.ThreadSafe - 1 > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-soap-api-3.3.1.jar/org/opensaml/soap/client/http/HttpSOAPRequestParameters.adoc: > - javax.annotation.concurrent.ThreadSafe - 1 > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-soap-api-3.3.1.jar/org/opensaml/soap/client/http/HttpSOAPClient.adoc: > - javax.annotation.concurrent.ThreadSafe - 1 > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/logic/TrimOrNullStringFunction.adoc: > - javax.annotation.concurrent.ThreadSafe - 1 > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/logic/TransformAndCheckFunction.adoc: > - javax.annotation.concurrent.ThreadSafe - 1 > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/xml/SchemaBuilder.adoc: > - javax.annotation.concurrent.NotThreadSafe - 1 > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/xml/SimpleNamespaceContext.adoc: > - javax.annotation.concurrent.ThreadSafe - 1 > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/xml/BasicParserPool.adoc: > - javax.annotation.concurrent.ThreadSafe - 1 > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/collection/IndexingObjectStore.adoc: > - javax.annotation.concurrent.ThreadSafe - 1 > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/collection/LazyList.adoc: > - javax.annotation.concurrent.NotThreadSafe - 1 > ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/collection/LazySet.adoc: > - ja
Re: Javax to Jakarta Bytecode transformation progress
These are the references I'm seeing to update: ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-xmlsec-api-3.3.1.jar/org/opensaml/xmlsec/signature/support/SignatureValidationProvider.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-xmlsec-api-3.3.1.jar/org/opensaml/xmlsec/signature/support/SignerProvider.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-soap-api-3.3.1.jar/org/opensaml/soap/client/SOAPClient.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-soap-api-3.3.1.jar/org/opensaml/soap/client/http/PipelineFactoryHttpSOAPClient.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-soap-api-3.3.1.jar/org/opensaml/soap/client/http/AbstractPipelineHttpSOAPClient.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-soap-api-3.3.1.jar/org/opensaml/soap/client/http/HttpSOAPRequestParameters.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-soap-api-3.3.1.jar/org/opensaml/soap/client/http/HttpSOAPClient.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/logic/TrimOrNullStringFunction.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/logic/TransformAndCheckFunction.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/xml/SchemaBuilder.adoc: - javax.annotation.concurrent.NotThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/xml/SimpleNamespaceContext.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/xml/BasicParserPool.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/collection/IndexingObjectStore.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/collection/LazyList.adoc: - javax.annotation.concurrent.NotThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/collection/LazySet.adoc: - javax.annotation.concurrent.NotThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/collection/LazyMap.adoc: - javax.annotation.concurrent.NotThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/collection/ClassToInstanceMultiMap.adoc: - javax.annotation.concurrent.NotThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/security/Type4UUIDIdentifierGenerationStrategy.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/security/AccessControlService.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-saml-impl-3.3.1.jar/org/opensaml/saml/saml2/assertion/impl/BearerSubjectConfirmationValidator.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/opensaml-saml-impl-3.3.1.jar/org/opensaml/saml/saml2/assertion/impl/AudienceRestrictionConditionValidator.adoc: - javax.annotation.concurrent.ThreadSafe - 1 ./apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHO
Re: Javax to Jakarta Bytecode transformation progress
> Looks like there might be an issue with `javax.annotation.concurrent.ThreadSafe`, otherwise it's very close. Yep, there's a rule missing for that, which I'll add, and regenerate. Currently going through the outputt here to see if there are other packages missing. Jon On Thu, Jun 4, 2020 at 9:21 AM David Blevins wrote: > Alright, a more detailed analysis up here: > > - https://github.com/dblevins/tomee-analysis > > Here's the diff. Mostly shows good changes: > > - > https://github.com/dblevins/tomee-analysis/commit/a83424fed4f120224c55f90c790990732edcbc9b > > The index pages show remaining javax references: > > - > https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/README.adoc > > - > https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/collection/ClassToInstanceMultiMap.adoc > > Looks like there might be an issue with > `javax.annotation.concurrent.ThreadSafe`, otherwise it's very close. > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > > > On Jun 3, 2020, at 2:31 PM, Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > > > > Everything I've got so far is committed. The build should produce > > additional artifacts witha jakartaee9 classifier in the > tomee/Apache-tomee > > module. > > > > The PR idea sounds interesting. Happy to work on that tomorrow. > > > > Jon > > > > > > On Wed, 3 Jun 2020, 18:54 David Blevins, > wrote: > > > >> Significantly better. Can you check that in? > >> > >> > >> What I'm imagining to make it easier to digest the breadth of data: > >> > >> - run the asmifier on the unmodified zip > >> - check every file into *github* > >> - run the asmifier on the modified zip > >> - check that in and create a PR > >> - we can then pick through the PR to see what's happening > >> > >> > >> -- > >> David Blevins > >> http://twitter.com/dblevins > >> http://www.tomitribe.com > >> > >>> On Jun 3, 2020, at 10:45 AM, Jonathan Gallimore < > >> jonathan.gallim...@gmail.com> wrote: > >>> > >>> Made some progress by adjusting the rules - here's the latest counts > (not > >>> including string references): > >>> > >>> Path javax uses total > >>> ./opensaml-xmlsec-api-3.3.1.jar 2 > >>> ./opensaml-soap-api-3.3.1.jar 5 > >>> ./java-support-7.3.0.jar 12 > >>> ./opensaml-saml-impl-3.3.1.jar 7 > >>> ./opensaml-core-3.3.1.jar 5 > >>> ./opensaml-profile-api-3.3.1.jar 1 > >>> ./opensaml-saml-api-3.3.1.jar 7 > >>> > >>> And if we include string references: > >>> > >>> Path javax uses total > >>> ./servlet-api.jar 26 > >>> ./jakarta.activation-1.2.1.jar 2 > >>> ./jsp-api.jar 13 > >>> ./bval-jsr-2.0.3.jar 1 > >>> ./taglibs-standard-impl-1.2.5.jar 17 > >>> ./openejb-core-8.0.3-SNAPSHOT.jar 41 > >>> ./cxf-core-3.3.6.jar 48 > >>> ./catalina.jar 135 > >>> ./cxf-rt-security-saml-3.3.6.jar 7 > >>> ./cxf-rt-bindings-soap-3.3.6.jar 5 > >>> ./taglibs-standard-jstlel-1.2.5.jar 1 > >>> ./opensaml-xmlsec-api-3.3.1.jar 2 > >>> ./opensaml-security-api-3.3.1.jar 2 > >>> ./jakarta.xml.bind-api-2.3.2.jar 5 > >>> ./taglibs-standard-spec-1.2.5.jar 11 > >>> ./openejb-jee-8.0.3-SNAPSHOT.jar 1 > >>> ./openwebbeans-impl-2.0.12.jar 4 > >>> ./saaj-impl-1.5.1.jar 7 > >>> ./opensaml-soap-api-3.3.1.jar 5 > >>> ./jasper.jar 36 > >>> ./jakarta.faces-2.3.14.jar 165 > >>> ./openejb-client-8.0.3-SNAPSHOT.jar 1 > >>> ./tomcat-util-scan.jar 1 > >>> ./openjpa-3.1.0.jar 80 > >>> ./cxf-rt-rs-security-oauth2-3.3.6.jar 1 > >>> ./java-support-7.3.0.jar 12 > >>> ./cxf-rt-frontend-jaxws-3.3.6.jar 74 > >>> ./cxf-rt-transports-http-3.3.6.jar 10 > >>> ./opensaml-saml-impl-3.3.1.jar 7 > >>> ./catalina-ssi.jar 4 > >>> ./cxf-rt-ws-security-3.3.6.jar 15 > >>> ./javaee-api-8.0-4.jar 47 > >>> ./tomee-catalina-8.0.3-SNAPSHOT.jar 1 > >>> ./opensaml-core-3.3.1.jar 5 > >>> ./cxf-rt-ws-addr-3.3.6.jar 4 > >>> ./eclipselink-2.7.4.jar 177 > >>> ./opensaml-profile-api-3.3.1.jar 1 > >>> ./tomcat-coyote.jar 23 > >>> ./opensaml-saml-api-3.3.1.jar 7 > >>> ./cxf-rt-frontend-jaxrs-3.3.6.jar 3 > >>> > >>> This is looking a lot better. > >>> > >>> Jon > >>> > >>> On Wed, Jun 3, 2020 at 6:06 PM David Blevins > >>> wrote: > >>> > > On Jun 3, 2020, at 9:03 AM, Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > > > > Just wanted to follow up with some details on how I'm getting the > >> numbers > > below. I'm using this tool: https://github.com/tomitribe/jkta > > So people have a heads-up on that tool, I'm currently working on the > Tomitribe side with Sonatype to scan all of Maven Central for uses of > >> the > affected javax packages. We'll be building a reporting site to share > >> the > data with everyone. I mention that just in case people get excited > and > think, "wow, we could help a lot of peopl
Re: Javax to Jakarta Bytecode transformation progress
Alright, a more detailed analysis up here: - https://github.com/dblevins/tomee-analysis Here's the diff. Mostly shows good changes: - https://github.com/dblevins/tomee-analysis/commit/a83424fed4f120224c55f90c790990732edcbc9b The index pages show remaining javax references: - https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/README.adoc - https://github.com/dblevins/tomee-analysis/blob/master/apache-tomee-microprofile-8.0.3-SNAPSHOT.zip/apache-tomee-microprofile-8.0.3-SNAPSHOT/lib/java-support-7.3.0.jar/net/shibboleth/utilities/java/support/collection/ClassToInstanceMultiMap.adoc Looks like there might be an issue with `javax.annotation.concurrent.ThreadSafe`, otherwise it's very close. -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com > On Jun 3, 2020, at 2:31 PM, Jonathan Gallimore > wrote: > > Everything I've got so far is committed. The build should produce > additional artifacts witha jakartaee9 classifier in the tomee/Apache-tomee > module. > > The PR idea sounds interesting. Happy to work on that tomorrow. > > Jon > > > On Wed, 3 Jun 2020, 18:54 David Blevins, wrote: > >> Significantly better. Can you check that in? >> >> >> What I'm imagining to make it easier to digest the breadth of data: >> >> - run the asmifier on the unmodified zip >> - check every file into *github* >> - run the asmifier on the modified zip >> - check that in and create a PR >> - we can then pick through the PR to see what's happening >> >> >> -- >> David Blevins >> http://twitter.com/dblevins >> http://www.tomitribe.com >> >>> On Jun 3, 2020, at 10:45 AM, Jonathan Gallimore < >> jonathan.gallim...@gmail.com> wrote: >>> >>> Made some progress by adjusting the rules - here's the latest counts (not >>> including string references): >>> >>> Path javax uses total >>> ./opensaml-xmlsec-api-3.3.1.jar 2 >>> ./opensaml-soap-api-3.3.1.jar 5 >>> ./java-support-7.3.0.jar 12 >>> ./opensaml-saml-impl-3.3.1.jar 7 >>> ./opensaml-core-3.3.1.jar 5 >>> ./opensaml-profile-api-3.3.1.jar 1 >>> ./opensaml-saml-api-3.3.1.jar 7 >>> >>> And if we include string references: >>> >>> Path javax uses total >>> ./servlet-api.jar 26 >>> ./jakarta.activation-1.2.1.jar 2 >>> ./jsp-api.jar 13 >>> ./bval-jsr-2.0.3.jar 1 >>> ./taglibs-standard-impl-1.2.5.jar 17 >>> ./openejb-core-8.0.3-SNAPSHOT.jar 41 >>> ./cxf-core-3.3.6.jar 48 >>> ./catalina.jar 135 >>> ./cxf-rt-security-saml-3.3.6.jar 7 >>> ./cxf-rt-bindings-soap-3.3.6.jar 5 >>> ./taglibs-standard-jstlel-1.2.5.jar 1 >>> ./opensaml-xmlsec-api-3.3.1.jar 2 >>> ./opensaml-security-api-3.3.1.jar 2 >>> ./jakarta.xml.bind-api-2.3.2.jar 5 >>> ./taglibs-standard-spec-1.2.5.jar 11 >>> ./openejb-jee-8.0.3-SNAPSHOT.jar 1 >>> ./openwebbeans-impl-2.0.12.jar 4 >>> ./saaj-impl-1.5.1.jar 7 >>> ./opensaml-soap-api-3.3.1.jar 5 >>> ./jasper.jar 36 >>> ./jakarta.faces-2.3.14.jar 165 >>> ./openejb-client-8.0.3-SNAPSHOT.jar 1 >>> ./tomcat-util-scan.jar 1 >>> ./openjpa-3.1.0.jar 80 >>> ./cxf-rt-rs-security-oauth2-3.3.6.jar 1 >>> ./java-support-7.3.0.jar 12 >>> ./cxf-rt-frontend-jaxws-3.3.6.jar 74 >>> ./cxf-rt-transports-http-3.3.6.jar 10 >>> ./opensaml-saml-impl-3.3.1.jar 7 >>> ./catalina-ssi.jar 4 >>> ./cxf-rt-ws-security-3.3.6.jar 15 >>> ./javaee-api-8.0-4.jar 47 >>> ./tomee-catalina-8.0.3-SNAPSHOT.jar 1 >>> ./opensaml-core-3.3.1.jar 5 >>> ./cxf-rt-ws-addr-3.3.6.jar 4 >>> ./eclipselink-2.7.4.jar 177 >>> ./opensaml-profile-api-3.3.1.jar 1 >>> ./tomcat-coyote.jar 23 >>> ./opensaml-saml-api-3.3.1.jar 7 >>> ./cxf-rt-frontend-jaxrs-3.3.6.jar 3 >>> >>> This is looking a lot better. >>> >>> Jon >>> >>> On Wed, Jun 3, 2020 at 6:06 PM David Blevins >>> wrote: >>> > On Jun 3, 2020, at 9:03 AM, Jonathan Gallimore < jonathan.gallim...@gmail.com> wrote: > > Just wanted to follow up with some details on how I'm getting the >> numbers > below. I'm using this tool: https://github.com/tomitribe/jkta So people have a heads-up on that tool, I'm currently working on the Tomitribe side with Sonatype to scan all of Maven Central for uses of >> the affected javax packages. We'll be building a reporting site to share >> the data with everyone. I mention that just in case people get excited and think, "wow, we could help a lot of people with a tool like that!" >> Agree and covered :) "Go big or go home" as they say :) I unfortunately won't be able to go into much more detail. I'll just >> say we're all very excited and we hope to make the javax-to-jakarta >> transition as survivable as possible. > Once TomEE is built, I'm extracting the zip, changing to the lib >> folder, > and running the following commands: > > for f in *.jar; do java -jar > ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar $f > $f.tsv; done > for f in *.jar; do java -jar > ~/dev
Re: Javax to Jakarta Bytecode transformation progress
Everything I've got so far is committed. The build should produce additional artifacts witha jakartaee9 classifier in the tomee/Apache-tomee module. The PR idea sounds interesting. Happy to work on that tomorrow. Jon On Wed, 3 Jun 2020, 18:54 David Blevins, wrote: > Significantly better. Can you check that in? > > > What I'm imagining to make it easier to digest the breadth of data: > > - run the asmifier on the unmodified zip > - check every file into *github* > - run the asmifier on the modified zip > - check that in and create a PR > - we can then pick through the PR to see what's happening > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > > > On Jun 3, 2020, at 10:45 AM, Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > > > > Made some progress by adjusting the rules - here's the latest counts (not > > including string references): > > > > Path javax uses total > > ./opensaml-xmlsec-api-3.3.1.jar 2 > > ./opensaml-soap-api-3.3.1.jar 5 > > ./java-support-7.3.0.jar 12 > > ./opensaml-saml-impl-3.3.1.jar 7 > > ./opensaml-core-3.3.1.jar 5 > > ./opensaml-profile-api-3.3.1.jar 1 > > ./opensaml-saml-api-3.3.1.jar 7 > > > > And if we include string references: > > > > Path javax uses total > > ./servlet-api.jar 26 > > ./jakarta.activation-1.2.1.jar 2 > > ./jsp-api.jar 13 > > ./bval-jsr-2.0.3.jar 1 > > ./taglibs-standard-impl-1.2.5.jar 17 > > ./openejb-core-8.0.3-SNAPSHOT.jar 41 > > ./cxf-core-3.3.6.jar 48 > > ./catalina.jar 135 > > ./cxf-rt-security-saml-3.3.6.jar 7 > > ./cxf-rt-bindings-soap-3.3.6.jar 5 > > ./taglibs-standard-jstlel-1.2.5.jar 1 > > ./opensaml-xmlsec-api-3.3.1.jar 2 > > ./opensaml-security-api-3.3.1.jar 2 > > ./jakarta.xml.bind-api-2.3.2.jar 5 > > ./taglibs-standard-spec-1.2.5.jar 11 > > ./openejb-jee-8.0.3-SNAPSHOT.jar 1 > > ./openwebbeans-impl-2.0.12.jar 4 > > ./saaj-impl-1.5.1.jar 7 > > ./opensaml-soap-api-3.3.1.jar 5 > > ./jasper.jar 36 > > ./jakarta.faces-2.3.14.jar 165 > > ./openejb-client-8.0.3-SNAPSHOT.jar 1 > > ./tomcat-util-scan.jar 1 > > ./openjpa-3.1.0.jar 80 > > ./cxf-rt-rs-security-oauth2-3.3.6.jar 1 > > ./java-support-7.3.0.jar 12 > > ./cxf-rt-frontend-jaxws-3.3.6.jar 74 > > ./cxf-rt-transports-http-3.3.6.jar 10 > > ./opensaml-saml-impl-3.3.1.jar 7 > > ./catalina-ssi.jar 4 > > ./cxf-rt-ws-security-3.3.6.jar 15 > > ./javaee-api-8.0-4.jar 47 > > ./tomee-catalina-8.0.3-SNAPSHOT.jar 1 > > ./opensaml-core-3.3.1.jar 5 > > ./cxf-rt-ws-addr-3.3.6.jar 4 > > ./eclipselink-2.7.4.jar 177 > > ./opensaml-profile-api-3.3.1.jar 1 > > ./tomcat-coyote.jar 23 > > ./opensaml-saml-api-3.3.1.jar 7 > > ./cxf-rt-frontend-jaxrs-3.3.6.jar 3 > > > > This is looking a lot better. > > > > Jon > > > > On Wed, Jun 3, 2020 at 6:06 PM David Blevins > > wrote: > > > >>> On Jun 3, 2020, at 9:03 AM, Jonathan Gallimore < > >> jonathan.gallim...@gmail.com> wrote: > >>> > >>> Just wanted to follow up with some details on how I'm getting the > numbers > >>> below. I'm using this tool: https://github.com/tomitribe/jkta > >> > >> So people have a heads-up on that tool, I'm currently working on the > >> Tomitribe side with Sonatype to scan all of Maven Central for uses of > the > >> affected javax packages. We'll be building a reporting site to share > the > >> data with everyone. I mention that just in case people get excited and > >> think, "wow, we could help a lot of people with a tool like that!" > Agree > >> and covered :) "Go big or go home" as they say :) > >> > >> I unfortunately won't be able to go into much more detail. I'll just > say > >> we're all very excited and we hope to make the javax-to-jakarta > transition > >> as survivable as possible. > >> > >>> Once TomEE is built, I'm extracting the zip, changing to the lib > folder, > >>> and running the following commands: > >>> > >>> for f in *.jar; do java -jar > >>> ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar $f > $f.tsv; > >> done > >>> for f in *.jar; do java -jar > >>> ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar > >>> --include-strings=true $f > $f.strings.tsv; done > >>> java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir . > > >>> jars.tsv > >>> java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir > >>> --include-strings=true . > jars.strings.tsv > >>> > >>> The goal to see what the gaps are from the transformation process and > >> close > >>> those gaps. > >> > >> I'll dig in and see what I can find. I've had my nose deep in ASM for a > >> few weeks now, so we'll see if helps. > >> > >> > >> -David > >> > >> > >
Re: Javax to Jakarta Bytecode transformation progress
I'm just curious, could this be done at runtime with a Java Agent? On Wed, Jun 3, 2020 at 12:54 PM David Blevins wrote: > Significantly better. Can you check that in? > > > What I'm imagining to make it easier to digest the breadth of data: > > - run the asmifier on the unmodified zip > - check every file into *github* > - run the asmifier on the modified zip > - check that in and create a PR > - we can then pick through the PR to see what's happening > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > > > On Jun 3, 2020, at 10:45 AM, Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > > > > Made some progress by adjusting the rules - here's the latest counts (not > > including string references): > > > > Path javax uses total > > ./opensaml-xmlsec-api-3.3.1.jar 2 > > ./opensaml-soap-api-3.3.1.jar 5 > > ./java-support-7.3.0.jar 12 > > ./opensaml-saml-impl-3.3.1.jar 7 > > ./opensaml-core-3.3.1.jar 5 > > ./opensaml-profile-api-3.3.1.jar 1 > > ./opensaml-saml-api-3.3.1.jar 7 > > > > And if we include string references: > > > > Path javax uses total > > ./servlet-api.jar 26 > > ./jakarta.activation-1.2.1.jar 2 > > ./jsp-api.jar 13 > > ./bval-jsr-2.0.3.jar 1 > > ./taglibs-standard-impl-1.2.5.jar 17 > > ./openejb-core-8.0.3-SNAPSHOT.jar 41 > > ./cxf-core-3.3.6.jar 48 > > ./catalina.jar 135 > > ./cxf-rt-security-saml-3.3.6.jar 7 > > ./cxf-rt-bindings-soap-3.3.6.jar 5 > > ./taglibs-standard-jstlel-1.2.5.jar 1 > > ./opensaml-xmlsec-api-3.3.1.jar 2 > > ./opensaml-security-api-3.3.1.jar 2 > > ./jakarta.xml.bind-api-2.3.2.jar 5 > > ./taglibs-standard-spec-1.2.5.jar 11 > > ./openejb-jee-8.0.3-SNAPSHOT.jar 1 > > ./openwebbeans-impl-2.0.12.jar 4 > > ./saaj-impl-1.5.1.jar 7 > > ./opensaml-soap-api-3.3.1.jar 5 > > ./jasper.jar 36 > > ./jakarta.faces-2.3.14.jar 165 > > ./openejb-client-8.0.3-SNAPSHOT.jar 1 > > ./tomcat-util-scan.jar 1 > > ./openjpa-3.1.0.jar 80 > > ./cxf-rt-rs-security-oauth2-3.3.6.jar 1 > > ./java-support-7.3.0.jar 12 > > ./cxf-rt-frontend-jaxws-3.3.6.jar 74 > > ./cxf-rt-transports-http-3.3.6.jar 10 > > ./opensaml-saml-impl-3.3.1.jar 7 > > ./catalina-ssi.jar 4 > > ./cxf-rt-ws-security-3.3.6.jar 15 > > ./javaee-api-8.0-4.jar 47 > > ./tomee-catalina-8.0.3-SNAPSHOT.jar 1 > > ./opensaml-core-3.3.1.jar 5 > > ./cxf-rt-ws-addr-3.3.6.jar 4 > > ./eclipselink-2.7.4.jar 177 > > ./opensaml-profile-api-3.3.1.jar 1 > > ./tomcat-coyote.jar 23 > > ./opensaml-saml-api-3.3.1.jar 7 > > ./cxf-rt-frontend-jaxrs-3.3.6.jar 3 > > > > This is looking a lot better. > > > > Jon > > > > On Wed, Jun 3, 2020 at 6:06 PM David Blevins > > wrote: > > > >>> On Jun 3, 2020, at 9:03 AM, Jonathan Gallimore < > >> jonathan.gallim...@gmail.com> wrote: > >>> > >>> Just wanted to follow up with some details on how I'm getting the > numbers > >>> below. I'm using this tool: https://github.com/tomitribe/jkta > >> > >> So people have a heads-up on that tool, I'm currently working on the > >> Tomitribe side with Sonatype to scan all of Maven Central for uses of > the > >> affected javax packages. We'll be building a reporting site to share > the > >> data with everyone. I mention that just in case people get excited and > >> think, "wow, we could help a lot of people with a tool like that!" > Agree > >> and covered :) "Go big or go home" as they say :) > >> > >> I unfortunately won't be able to go into much more detail. I'll just > say > >> we're all very excited and we hope to make the javax-to-jakarta > transition > >> as survivable as possible. > >> > >>> Once TomEE is built, I'm extracting the zip, changing to the lib > folder, > >>> and running the following commands: > >>> > >>> for f in *.jar; do java -jar > >>> ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar $f > $f.tsv; > >> done > >>> for f in *.jar; do java -jar > >>> ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar > >>> --include-strings=true $f > $f.strings.tsv; done > >>> java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir . > > >>> jars.tsv > >>> java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir > >>> --include-strings=true . > jars.strings.tsv > >>> > >>> The goal to see what the gaps are from the transformation process and > >> close > >>> those gaps. > >> > >> I'll dig in and see what I can find. I've had my nose deep in ASM for a > >> few weeks now, so we'll see if helps. > >> > >> > >> -David > >> > >> > > -- Jonathan | exabr...@gmail.com Pessimists, see a jar as half empty. Optimists, in contrast, see it as half full. Engineers, of course, understand the glass is twice as big as it needs to be.
Re: Javax to Jakarta Bytecode transformation progress
Significantly better. Can you check that in? What I'm imagining to make it easier to digest the breadth of data: - run the asmifier on the unmodified zip - check every file into *github* - run the asmifier on the modified zip - check that in and create a PR - we can then pick through the PR to see what's happening -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com > On Jun 3, 2020, at 10:45 AM, Jonathan Gallimore > wrote: > > Made some progress by adjusting the rules - here's the latest counts (not > including string references): > > Path javax uses total > ./opensaml-xmlsec-api-3.3.1.jar 2 > ./opensaml-soap-api-3.3.1.jar 5 > ./java-support-7.3.0.jar 12 > ./opensaml-saml-impl-3.3.1.jar 7 > ./opensaml-core-3.3.1.jar 5 > ./opensaml-profile-api-3.3.1.jar 1 > ./opensaml-saml-api-3.3.1.jar 7 > > And if we include string references: > > Path javax uses total > ./servlet-api.jar 26 > ./jakarta.activation-1.2.1.jar 2 > ./jsp-api.jar 13 > ./bval-jsr-2.0.3.jar 1 > ./taglibs-standard-impl-1.2.5.jar 17 > ./openejb-core-8.0.3-SNAPSHOT.jar 41 > ./cxf-core-3.3.6.jar 48 > ./catalina.jar 135 > ./cxf-rt-security-saml-3.3.6.jar 7 > ./cxf-rt-bindings-soap-3.3.6.jar 5 > ./taglibs-standard-jstlel-1.2.5.jar 1 > ./opensaml-xmlsec-api-3.3.1.jar 2 > ./opensaml-security-api-3.3.1.jar 2 > ./jakarta.xml.bind-api-2.3.2.jar 5 > ./taglibs-standard-spec-1.2.5.jar 11 > ./openejb-jee-8.0.3-SNAPSHOT.jar 1 > ./openwebbeans-impl-2.0.12.jar 4 > ./saaj-impl-1.5.1.jar 7 > ./opensaml-soap-api-3.3.1.jar 5 > ./jasper.jar 36 > ./jakarta.faces-2.3.14.jar 165 > ./openejb-client-8.0.3-SNAPSHOT.jar 1 > ./tomcat-util-scan.jar 1 > ./openjpa-3.1.0.jar 80 > ./cxf-rt-rs-security-oauth2-3.3.6.jar 1 > ./java-support-7.3.0.jar 12 > ./cxf-rt-frontend-jaxws-3.3.6.jar 74 > ./cxf-rt-transports-http-3.3.6.jar 10 > ./opensaml-saml-impl-3.3.1.jar 7 > ./catalina-ssi.jar 4 > ./cxf-rt-ws-security-3.3.6.jar 15 > ./javaee-api-8.0-4.jar 47 > ./tomee-catalina-8.0.3-SNAPSHOT.jar 1 > ./opensaml-core-3.3.1.jar 5 > ./cxf-rt-ws-addr-3.3.6.jar 4 > ./eclipselink-2.7.4.jar 177 > ./opensaml-profile-api-3.3.1.jar 1 > ./tomcat-coyote.jar 23 > ./opensaml-saml-api-3.3.1.jar 7 > ./cxf-rt-frontend-jaxrs-3.3.6.jar 3 > > This is looking a lot better. > > Jon > > On Wed, Jun 3, 2020 at 6:06 PM David Blevins > wrote: > >>> On Jun 3, 2020, at 9:03 AM, Jonathan Gallimore < >> jonathan.gallim...@gmail.com> wrote: >>> >>> Just wanted to follow up with some details on how I'm getting the numbers >>> below. I'm using this tool: https://github.com/tomitribe/jkta >> >> So people have a heads-up on that tool, I'm currently working on the >> Tomitribe side with Sonatype to scan all of Maven Central for uses of the >> affected javax packages. We'll be building a reporting site to share the >> data with everyone. I mention that just in case people get excited and >> think, "wow, we could help a lot of people with a tool like that!" Agree >> and covered :) "Go big or go home" as they say :) >> >> I unfortunately won't be able to go into much more detail. I'll just say >> we're all very excited and we hope to make the javax-to-jakarta transition >> as survivable as possible. >> >>> Once TomEE is built, I'm extracting the zip, changing to the lib folder, >>> and running the following commands: >>> >>> for f in *.jar; do java -jar >>> ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar $f > $f.tsv; >> done >>> for f in *.jar; do java -jar >>> ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar >>> --include-strings=true $f > $f.strings.tsv; done >>> java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir . > >>> jars.tsv >>> java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir >>> --include-strings=true . > jars.strings.tsv >>> >>> The goal to see what the gaps are from the transformation process and >> close >>> those gaps. >> >> I'll dig in and see what I can find. I've had my nose deep in ASM for a >> few weeks now, so we'll see if helps. >> >> >> -David >> >> smime.p7s Description: S/MIME cryptographic signature
Re: Javax to Jakarta Bytecode transformation progress
Made some progress by adjusting the rules - here's the latest counts (not including string references): Path javax uses total ./opensaml-xmlsec-api-3.3.1.jar 2 ./opensaml-soap-api-3.3.1.jar 5 ./java-support-7.3.0.jar 12 ./opensaml-saml-impl-3.3.1.jar 7 ./opensaml-core-3.3.1.jar 5 ./opensaml-profile-api-3.3.1.jar 1 ./opensaml-saml-api-3.3.1.jar 7 And if we include string references: Path javax uses total ./servlet-api.jar 26 ./jakarta.activation-1.2.1.jar 2 ./jsp-api.jar 13 ./bval-jsr-2.0.3.jar 1 ./taglibs-standard-impl-1.2.5.jar 17 ./openejb-core-8.0.3-SNAPSHOT.jar 41 ./cxf-core-3.3.6.jar 48 ./catalina.jar 135 ./cxf-rt-security-saml-3.3.6.jar 7 ./cxf-rt-bindings-soap-3.3.6.jar 5 ./taglibs-standard-jstlel-1.2.5.jar 1 ./opensaml-xmlsec-api-3.3.1.jar 2 ./opensaml-security-api-3.3.1.jar 2 ./jakarta.xml.bind-api-2.3.2.jar 5 ./taglibs-standard-spec-1.2.5.jar 11 ./openejb-jee-8.0.3-SNAPSHOT.jar 1 ./openwebbeans-impl-2.0.12.jar 4 ./saaj-impl-1.5.1.jar 7 ./opensaml-soap-api-3.3.1.jar 5 ./jasper.jar 36 ./jakarta.faces-2.3.14.jar 165 ./openejb-client-8.0.3-SNAPSHOT.jar 1 ./tomcat-util-scan.jar 1 ./openjpa-3.1.0.jar 80 ./cxf-rt-rs-security-oauth2-3.3.6.jar 1 ./java-support-7.3.0.jar 12 ./cxf-rt-frontend-jaxws-3.3.6.jar 74 ./cxf-rt-transports-http-3.3.6.jar 10 ./opensaml-saml-impl-3.3.1.jar 7 ./catalina-ssi.jar 4 ./cxf-rt-ws-security-3.3.6.jar 15 ./javaee-api-8.0-4.jar 47 ./tomee-catalina-8.0.3-SNAPSHOT.jar 1 ./opensaml-core-3.3.1.jar 5 ./cxf-rt-ws-addr-3.3.6.jar 4 ./eclipselink-2.7.4.jar 177 ./opensaml-profile-api-3.3.1.jar 1 ./tomcat-coyote.jar 23 ./opensaml-saml-api-3.3.1.jar 7 ./cxf-rt-frontend-jaxrs-3.3.6.jar 3 This is looking a lot better. Jon On Wed, Jun 3, 2020 at 6:06 PM David Blevins wrote: > > On Jun 3, 2020, at 9:03 AM, Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > > > > Just wanted to follow up with some details on how I'm getting the numbers > > below. I'm using this tool: https://github.com/tomitribe/jkta > > So people have a heads-up on that tool, I'm currently working on the > Tomitribe side with Sonatype to scan all of Maven Central for uses of the > affected javax packages. We'll be building a reporting site to share the > data with everyone. I mention that just in case people get excited and > think, "wow, we could help a lot of people with a tool like that!" Agree > and covered :) "Go big or go home" as they say :) > > I unfortunately won't be able to go into much more detail. I'll just say > we're all very excited and we hope to make the javax-to-jakarta transition > as survivable as possible. > > > Once TomEE is built, I'm extracting the zip, changing to the lib folder, > > and running the following commands: > > > > for f in *.jar; do java -jar > > ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar $f > $f.tsv; > done > > for f in *.jar; do java -jar > > ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar > > --include-strings=true $f > $f.strings.tsv; done > > java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir . > > > jars.tsv > > java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir > > --include-strings=true . > jars.strings.tsv > > > > The goal to see what the gaps are from the transformation process and > close > > those gaps. > > I'll dig in and see what I can find. I've had my nose deep in ASM for a > few weeks now, so we'll see if helps. > > > -David > >
Re: Javax to Jakarta Bytecode transformation progress
> On Jun 3, 2020, at 9:03 AM, Jonathan Gallimore > wrote: > > Just wanted to follow up with some details on how I'm getting the numbers > below. I'm using this tool: https://github.com/tomitribe/jkta So people have a heads-up on that tool, I'm currently working on the Tomitribe side with Sonatype to scan all of Maven Central for uses of the affected javax packages. We'll be building a reporting site to share the data with everyone. I mention that just in case people get excited and think, "wow, we could help a lot of people with a tool like that!" Agree and covered :) "Go big or go home" as they say :) I unfortunately won't be able to go into much more detail. I'll just say we're all very excited and we hope to make the javax-to-jakarta transition as survivable as possible. > Once TomEE is built, I'm extracting the zip, changing to the lib folder, > and running the following commands: > > for f in *.jar; do java -jar > ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar $f > $f.tsv; done > for f in *.jar; do java -jar > ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar > --include-strings=true $f > $f.strings.tsv; done > java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir . > > jars.tsv > java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir > --include-strings=true . > jars.strings.tsv > > The goal to see what the gaps are from the transformation process and close > those gaps. I'll dig in and see what I can find. I've had my nose deep in ASM for a few weeks now, so we'll see if helps. -David smime.p7s Description: S/MIME cryptographic signature
Re: Javax to Jakarta Bytecode transformation progress
very good Jon : ) -- *Daniel Dias dos Santos* Java Developer SouJava & JCP Member GitHub: https://github.com/Daniel-Dos Linkedin: www.linkedin.com/in/danieldiasjava Twitter: http://twitter.com/danieldiasjava Em qua., 3 de jun. de 2020 às 13:05, Jonathan Gallimore < jonathan.gallim...@gmail.com> escreveu: > I should clarify, the output I pasted is from these commands: > > java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir . > > jars.tsv > java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir > --include-strings=true . > jars.strings.tsv > > and the first 2 commands provide the data down to the class level for the > individual jars. > > Jon > > On Wed, Jun 3, 2020 at 5:03 PM Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > > > Just wanted to follow up with some details on how I'm getting the numbers > > below. I'm using this tool: https://github.com/tomitribe/jkta > > > > Once TomEE is built, I'm extracting the zip, changing to the lib folder, > > and running the following commands: > > > > for f in *.jar; do java -jar > > ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar $f > $f.tsv; > done > > for f in *.jar; do java -jar > > ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar > > --include-strings=true $f > $f.strings.tsv; done > > java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir . > > > jars.tsv > > java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir > > --include-strings=true . > jars.strings.tsv > > > > The goal to see what the gaps are from the transformation process and > > close those gaps. > > > > Jon > > > > On Wed, Jun 3, 2020 at 4:36 PM Jonathan Gallimore < > > jonathan.gallim...@gmail.com> wrote: > > > >> HI folks > >> > >> I've been working on doing this translation on the bytecode of the built > >> artifacts. This is done as part of the Maven build, and the "jakartaee9" > >> artifacts are installed as part of the tomee/apache-tomee module. > >> > >> After running a scan of javax references afterwards, we have the > >> following javax counts: > >> > >> Path javax uses total > >> ./openejb-core-8.0.3-SNAPSHOT.jar 895 > >> ./cxf-core-3.3.6.jar 2 > >> ./catalina.jar 125 > >> ./cxf-rt-bindings-soap-3.3.6.jar 430 > >> ./opensaml-xmlsec-api-3.3.1.jar 2 > >> ./saaj-impl-1.5.1.jar 2110 > >> ./opensaml-soap-api-3.3.1.jar 5 > >> ./jakarta.faces-2.3.14.jar 36 > >> ./openejb-client-8.0.3-SNAPSHOT.jar 230 > >> ./openejb-webservices-8.0.3-SNAPSHOT.jar 139 > >> ./java-support-7.3.0.jar 12 > >> ./cxf-rt-frontend-jaxws-3.3.6.jar 2223 > >> ./opensaml-saml-impl-3.3.1.jar 7 > >> ./cxf-rt-ws-security-3.3.6.jar 285 > >> ./javaee-api-8.0-4.jar 1948 > >> ./opensaml-core-3.3.1.jar 5 > >> ./cxf-rt-ws-addr-3.3.6.jar 10 > >> ./eclipselink-2.7.4.jar 268 > >> ./opensaml-profile-api-3.3.1.jar 1 > >> ./tomee-common-8.0.3-SNAPSHOT.jar 12 > >> ./opensaml-saml-api-3.3.1.jar 7 > >> ./openejb-cxf-8.0.3-SNAPSHOT.jar 70 > >> > >> And including string references: > >> > >> Path javax uses total > >> ./servlet-api.jar 26 > >> ./jakarta.activation-1.2.1.jar 2 > >> ./jsp-api.jar 13 > >> ./bval-jsr-2.0.3.jar 2 > >> ./taglibs-standard-impl-1.2.5.jar 17 > >> ./openejb-core-8.0.3-SNAPSHOT.jar 943 > >> ./cxf-core-3.3.6.jar 52 > >> ./catalina.jar 262 > >> ./cxf-rt-security-saml-3.3.6.jar 7 > >> ./cxf-rt-bindings-soap-3.3.6.jar 435 > >> ./taglibs-standard-jstlel-1.2.5.jar 1 > >> ./opensaml-xmlsec-api-3.3.1.jar 2 > >> ./opensaml-security-api-3.3.1.jar 2 > >> ./jakarta.xml.bind-api-2.3.2.jar 5 > >> ./taglibs-standard-spec-1.2.5.jar 11 > >> ./openejb-jee-8.0.3-SNAPSHOT.jar 1 > >> ./openwebbeans-impl-2.0.12.jar 7 > >> ./saaj-impl-1.5.1.jar 2123 > >> ./opensaml-soap-api-3.3.1.jar 5 > >> ./jasper.jar 36 > >> ./jakarta.faces-2.3.14.jar 201 > >> ./openejb-client-8.0.3-SNAPSHOT.jar 231 > >> ./tomcat-util-scan.jar 1 > >> ./openjpa-3.1.0.jar 80 > >> ./openejb-webservices-8.0.3-SNAPSHOT.jar 151 > >> ./cxf-rt-rs-security-oauth2-3.3.6.jar 1 > >> ./java-support-7.3.0.jar 12 > >> ./cxf-rt-frontend-jaxws-3.3.6.jar 2301 > >> ./cxf-rt-transports-http-3.3.6.jar 10 > >> ./opensaml-saml-impl-3.3.1.jar 7 > >> ./catalina-ssi.jar 4 > >> ./cxf-rt-ws-security-3.3.6.jar 300 > >> ./javaee-api-8.0-4.jar 2003 > >> ./tomee-catalina-8.0.3-SNAPSHOT.jar 2 > >> ./opensaml-core-3.3.1.jar 5 > >> ./cxf-rt-wsdl-3.3.6.jar 4 > >> ./cxf-rt-ws-addr-3.3.6.jar 14 > >> ./eclipselink-2.7.4.jar 447 > >> ./opensaml-profile-api-3.3.1.jar 1 > >> ./tomee-common-8.0.3-SNAPSHOT.jar 12 > >> ./tomcat-coyote.jar 23 > >> ./opensaml-saml-api-3.3.1.jar 7 > >> ./cxf-rt-frontend-jaxrs-3.3.6.jar 3 > >> ./openejb-cxf-8.0.3-SNAPSHOT.jar 70 > >> > >> Ideally, we want to get these down to 0. I have excluded jars that have > 0 > >> references already. > >> > >> I'm currently digging into the references that haven't been converted in > >> the openejb-core jar, and it looks like stuff under javax.enterprise > hasn't > >> shifted over, suggesting an issue with my rules for the transformation > >> that. Going to try an
Re: Javax to Jakarta Bytecode transformation progress
I should clarify, the output I pasted is from these commands: java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir . > jars.tsv java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir --include-strings=true . > jars.strings.tsv and the first 2 commands provide the data down to the class level for the individual jars. Jon On Wed, Jun 3, 2020 at 5:03 PM Jonathan Gallimore < jonathan.gallim...@gmail.com> wrote: > Just wanted to follow up with some details on how I'm getting the numbers > below. I'm using this tool: https://github.com/tomitribe/jkta > > Once TomEE is built, I'm extracting the zip, changing to the lib folder, > and running the following commands: > > for f in *.jar; do java -jar > ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar $f > $f.tsv; done > for f in *.jar; do java -jar > ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar > --include-strings=true $f > $f.strings.tsv; done > java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir . > > jars.tsv > java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir > --include-strings=true . > jars.strings.tsv > > The goal to see what the gaps are from the transformation process and > close those gaps. > > Jon > > On Wed, Jun 3, 2020 at 4:36 PM Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > >> HI folks >> >> I've been working on doing this translation on the bytecode of the built >> artifacts. This is done as part of the Maven build, and the "jakartaee9" >> artifacts are installed as part of the tomee/apache-tomee module. >> >> After running a scan of javax references afterwards, we have the >> following javax counts: >> >> Path javax uses total >> ./openejb-core-8.0.3-SNAPSHOT.jar 895 >> ./cxf-core-3.3.6.jar 2 >> ./catalina.jar 125 >> ./cxf-rt-bindings-soap-3.3.6.jar 430 >> ./opensaml-xmlsec-api-3.3.1.jar 2 >> ./saaj-impl-1.5.1.jar 2110 >> ./opensaml-soap-api-3.3.1.jar 5 >> ./jakarta.faces-2.3.14.jar 36 >> ./openejb-client-8.0.3-SNAPSHOT.jar 230 >> ./openejb-webservices-8.0.3-SNAPSHOT.jar 139 >> ./java-support-7.3.0.jar 12 >> ./cxf-rt-frontend-jaxws-3.3.6.jar 2223 >> ./opensaml-saml-impl-3.3.1.jar 7 >> ./cxf-rt-ws-security-3.3.6.jar 285 >> ./javaee-api-8.0-4.jar 1948 >> ./opensaml-core-3.3.1.jar 5 >> ./cxf-rt-ws-addr-3.3.6.jar 10 >> ./eclipselink-2.7.4.jar 268 >> ./opensaml-profile-api-3.3.1.jar 1 >> ./tomee-common-8.0.3-SNAPSHOT.jar 12 >> ./opensaml-saml-api-3.3.1.jar 7 >> ./openejb-cxf-8.0.3-SNAPSHOT.jar 70 >> >> And including string references: >> >> Path javax uses total >> ./servlet-api.jar 26 >> ./jakarta.activation-1.2.1.jar 2 >> ./jsp-api.jar 13 >> ./bval-jsr-2.0.3.jar 2 >> ./taglibs-standard-impl-1.2.5.jar 17 >> ./openejb-core-8.0.3-SNAPSHOT.jar 943 >> ./cxf-core-3.3.6.jar 52 >> ./catalina.jar 262 >> ./cxf-rt-security-saml-3.3.6.jar 7 >> ./cxf-rt-bindings-soap-3.3.6.jar 435 >> ./taglibs-standard-jstlel-1.2.5.jar 1 >> ./opensaml-xmlsec-api-3.3.1.jar 2 >> ./opensaml-security-api-3.3.1.jar 2 >> ./jakarta.xml.bind-api-2.3.2.jar 5 >> ./taglibs-standard-spec-1.2.5.jar 11 >> ./openejb-jee-8.0.3-SNAPSHOT.jar 1 >> ./openwebbeans-impl-2.0.12.jar 7 >> ./saaj-impl-1.5.1.jar 2123 >> ./opensaml-soap-api-3.3.1.jar 5 >> ./jasper.jar 36 >> ./jakarta.faces-2.3.14.jar 201 >> ./openejb-client-8.0.3-SNAPSHOT.jar 231 >> ./tomcat-util-scan.jar 1 >> ./openjpa-3.1.0.jar 80 >> ./openejb-webservices-8.0.3-SNAPSHOT.jar 151 >> ./cxf-rt-rs-security-oauth2-3.3.6.jar 1 >> ./java-support-7.3.0.jar 12 >> ./cxf-rt-frontend-jaxws-3.3.6.jar 2301 >> ./cxf-rt-transports-http-3.3.6.jar 10 >> ./opensaml-saml-impl-3.3.1.jar 7 >> ./catalina-ssi.jar 4 >> ./cxf-rt-ws-security-3.3.6.jar 300 >> ./javaee-api-8.0-4.jar 2003 >> ./tomee-catalina-8.0.3-SNAPSHOT.jar 2 >> ./opensaml-core-3.3.1.jar 5 >> ./cxf-rt-wsdl-3.3.6.jar 4 >> ./cxf-rt-ws-addr-3.3.6.jar 14 >> ./eclipselink-2.7.4.jar 447 >> ./opensaml-profile-api-3.3.1.jar 1 >> ./tomee-common-8.0.3-SNAPSHOT.jar 12 >> ./tomcat-coyote.jar 23 >> ./opensaml-saml-api-3.3.1.jar 7 >> ./cxf-rt-frontend-jaxrs-3.3.6.jar 3 >> ./openejb-cxf-8.0.3-SNAPSHOT.jar 70 >> >> Ideally, we want to get these down to 0. I have excluded jars that have 0 >> references already. >> >> I'm currently digging into the references that haven't been converted in >> the openejb-core jar, and it looks like stuff under javax.enterprise hasn't >> shifted over, suggesting an issue with my rules for the transformation >> that. Going to try and work through some of these with bigger numbers and >> see what I can do. >> >> Jon >> >>
Re: Javax to Jakarta Bytecode transformation progress
Just wanted to follow up with some details on how I'm getting the numbers below. I'm using this tool: https://github.com/tomitribe/jkta Once TomEE is built, I'm extracting the zip, changing to the lib folder, and running the following commands: for f in *.jar; do java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar $f > $f.tsv; done for f in *.jar; do java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage jar --include-strings=true $f > $f.strings.tsv; done java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir . > jars.tsv java -jar ~/dev/jkta/target/jkta-0.11-SNAPSHOT-shaded.jar usage dir --include-strings=true . > jars.strings.tsv The goal to see what the gaps are from the transformation process and close those gaps. Jon On Wed, Jun 3, 2020 at 4:36 PM Jonathan Gallimore < jonathan.gallim...@gmail.com> wrote: > HI folks > > I've been working on doing this translation on the bytecode of the built > artifacts. This is done as part of the Maven build, and the "jakartaee9" > artifacts are installed as part of the tomee/apache-tomee module. > > After running a scan of javax references afterwards, we have the following > javax counts: > > Path javax uses total > ./openejb-core-8.0.3-SNAPSHOT.jar 895 > ./cxf-core-3.3.6.jar 2 > ./catalina.jar 125 > ./cxf-rt-bindings-soap-3.3.6.jar 430 > ./opensaml-xmlsec-api-3.3.1.jar 2 > ./saaj-impl-1.5.1.jar 2110 > ./opensaml-soap-api-3.3.1.jar 5 > ./jakarta.faces-2.3.14.jar 36 > ./openejb-client-8.0.3-SNAPSHOT.jar 230 > ./openejb-webservices-8.0.3-SNAPSHOT.jar 139 > ./java-support-7.3.0.jar 12 > ./cxf-rt-frontend-jaxws-3.3.6.jar 2223 > ./opensaml-saml-impl-3.3.1.jar 7 > ./cxf-rt-ws-security-3.3.6.jar 285 > ./javaee-api-8.0-4.jar 1948 > ./opensaml-core-3.3.1.jar 5 > ./cxf-rt-ws-addr-3.3.6.jar 10 > ./eclipselink-2.7.4.jar 268 > ./opensaml-profile-api-3.3.1.jar 1 > ./tomee-common-8.0.3-SNAPSHOT.jar 12 > ./opensaml-saml-api-3.3.1.jar 7 > ./openejb-cxf-8.0.3-SNAPSHOT.jar 70 > > And including string references: > > Path javax uses total > ./servlet-api.jar 26 > ./jakarta.activation-1.2.1.jar 2 > ./jsp-api.jar 13 > ./bval-jsr-2.0.3.jar 2 > ./taglibs-standard-impl-1.2.5.jar 17 > ./openejb-core-8.0.3-SNAPSHOT.jar 943 > ./cxf-core-3.3.6.jar 52 > ./catalina.jar 262 > ./cxf-rt-security-saml-3.3.6.jar 7 > ./cxf-rt-bindings-soap-3.3.6.jar 435 > ./taglibs-standard-jstlel-1.2.5.jar 1 > ./opensaml-xmlsec-api-3.3.1.jar 2 > ./opensaml-security-api-3.3.1.jar 2 > ./jakarta.xml.bind-api-2.3.2.jar 5 > ./taglibs-standard-spec-1.2.5.jar 11 > ./openejb-jee-8.0.3-SNAPSHOT.jar 1 > ./openwebbeans-impl-2.0.12.jar 7 > ./saaj-impl-1.5.1.jar 2123 > ./opensaml-soap-api-3.3.1.jar 5 > ./jasper.jar 36 > ./jakarta.faces-2.3.14.jar 201 > ./openejb-client-8.0.3-SNAPSHOT.jar 231 > ./tomcat-util-scan.jar 1 > ./openjpa-3.1.0.jar 80 > ./openejb-webservices-8.0.3-SNAPSHOT.jar 151 > ./cxf-rt-rs-security-oauth2-3.3.6.jar 1 > ./java-support-7.3.0.jar 12 > ./cxf-rt-frontend-jaxws-3.3.6.jar 2301 > ./cxf-rt-transports-http-3.3.6.jar 10 > ./opensaml-saml-impl-3.3.1.jar 7 > ./catalina-ssi.jar 4 > ./cxf-rt-ws-security-3.3.6.jar 300 > ./javaee-api-8.0-4.jar 2003 > ./tomee-catalina-8.0.3-SNAPSHOT.jar 2 > ./opensaml-core-3.3.1.jar 5 > ./cxf-rt-wsdl-3.3.6.jar 4 > ./cxf-rt-ws-addr-3.3.6.jar 14 > ./eclipselink-2.7.4.jar 447 > ./opensaml-profile-api-3.3.1.jar 1 > ./tomee-common-8.0.3-SNAPSHOT.jar 12 > ./tomcat-coyote.jar 23 > ./opensaml-saml-api-3.3.1.jar 7 > ./cxf-rt-frontend-jaxrs-3.3.6.jar 3 > ./openejb-cxf-8.0.3-SNAPSHOT.jar 70 > > Ideally, we want to get these down to 0. I have excluded jars that have 0 > references already. > > I'm currently digging into the references that haven't been converted in > the openejb-core jar, and it looks like stuff under javax.enterprise hasn't > shifted over, suggesting an issue with my rules for the transformation > that. Going to try and work through some of these with bigger numbers and > see what I can do. > > Jon > >
Javax to Jakarta Bytecode transformation progress
HI folks I've been working on doing this translation on the bytecode of the built artifacts. This is done as part of the Maven build, and the "jakartaee9" artifacts are installed as part of the tomee/apache-tomee module. After running a scan of javax references afterwards, we have the following javax counts: Path javax uses total ./openejb-core-8.0.3-SNAPSHOT.jar 895 ./cxf-core-3.3.6.jar 2 ./catalina.jar 125 ./cxf-rt-bindings-soap-3.3.6.jar 430 ./opensaml-xmlsec-api-3.3.1.jar 2 ./saaj-impl-1.5.1.jar 2110 ./opensaml-soap-api-3.3.1.jar 5 ./jakarta.faces-2.3.14.jar 36 ./openejb-client-8.0.3-SNAPSHOT.jar 230 ./openejb-webservices-8.0.3-SNAPSHOT.jar 139 ./java-support-7.3.0.jar 12 ./cxf-rt-frontend-jaxws-3.3.6.jar 2223 ./opensaml-saml-impl-3.3.1.jar 7 ./cxf-rt-ws-security-3.3.6.jar 285 ./javaee-api-8.0-4.jar 1948 ./opensaml-core-3.3.1.jar 5 ./cxf-rt-ws-addr-3.3.6.jar 10 ./eclipselink-2.7.4.jar 268 ./opensaml-profile-api-3.3.1.jar 1 ./tomee-common-8.0.3-SNAPSHOT.jar 12 ./opensaml-saml-api-3.3.1.jar 7 ./openejb-cxf-8.0.3-SNAPSHOT.jar 70 And including string references: Path javax uses total ./servlet-api.jar 26 ./jakarta.activation-1.2.1.jar 2 ./jsp-api.jar 13 ./bval-jsr-2.0.3.jar 2 ./taglibs-standard-impl-1.2.5.jar 17 ./openejb-core-8.0.3-SNAPSHOT.jar 943 ./cxf-core-3.3.6.jar 52 ./catalina.jar 262 ./cxf-rt-security-saml-3.3.6.jar 7 ./cxf-rt-bindings-soap-3.3.6.jar 435 ./taglibs-standard-jstlel-1.2.5.jar 1 ./opensaml-xmlsec-api-3.3.1.jar 2 ./opensaml-security-api-3.3.1.jar 2 ./jakarta.xml.bind-api-2.3.2.jar 5 ./taglibs-standard-spec-1.2.5.jar 11 ./openejb-jee-8.0.3-SNAPSHOT.jar 1 ./openwebbeans-impl-2.0.12.jar 7 ./saaj-impl-1.5.1.jar 2123 ./opensaml-soap-api-3.3.1.jar 5 ./jasper.jar 36 ./jakarta.faces-2.3.14.jar 201 ./openejb-client-8.0.3-SNAPSHOT.jar 231 ./tomcat-util-scan.jar 1 ./openjpa-3.1.0.jar 80 ./openejb-webservices-8.0.3-SNAPSHOT.jar 151 ./cxf-rt-rs-security-oauth2-3.3.6.jar 1 ./java-support-7.3.0.jar 12 ./cxf-rt-frontend-jaxws-3.3.6.jar 2301 ./cxf-rt-transports-http-3.3.6.jar 10 ./opensaml-saml-impl-3.3.1.jar 7 ./catalina-ssi.jar 4 ./cxf-rt-ws-security-3.3.6.jar 300 ./javaee-api-8.0-4.jar 2003 ./tomee-catalina-8.0.3-SNAPSHOT.jar 2 ./opensaml-core-3.3.1.jar 5 ./cxf-rt-wsdl-3.3.6.jar 4 ./cxf-rt-ws-addr-3.3.6.jar 14 ./eclipselink-2.7.4.jar 447 ./opensaml-profile-api-3.3.1.jar 1 ./tomee-common-8.0.3-SNAPSHOT.jar 12 ./tomcat-coyote.jar 23 ./opensaml-saml-api-3.3.1.jar 7 ./cxf-rt-frontend-jaxrs-3.3.6.jar 3 ./openejb-cxf-8.0.3-SNAPSHOT.jar 70 Ideally, we want to get these down to 0. I have excluded jars that have 0 references already. I'm currently digging into the references that haven't been converted in the openejb-core jar, and it looks like stuff under javax.enterprise hasn't shifted over, suggesting an issue with my rules for the transformation that. Going to try and work through some of these with bigger numbers and see what I can do. Jon
