[tomcat-jakartaee-migration] branch master updated: Fix bug. Constant pool size is defined as u2

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git


The following commit(s) were added to refs/heads/master by this push:
     new abde81d  Fix bug. Constant pool size is defined as u2
abde81d is described below

commit abde81dfa60b1e390c82e4b30240a59ea1b0596e
Author: Mark Thomas <[hidden email]>
AuthorDate: Wed Feb 10 09:55:51 2021 +0000

    Fix bug. Constant pool size is defined as u2
   
    u2 is an unsigned 2-byte integer but short is a signed 2-byte integer.
    Therefore use int.
---
 src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java b/src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java
index 173ea8e..1b15652 100644
--- a/src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java
+++ b/src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java
@@ -49,7 +49,8 @@ public class ClassConverter implements Converter {
 
         // Loop through constant pool
         Constant[] constantPool = javaClass.getConstantPool().getConstantPool();
-        for (short i = 0; i < constantPool.length; i++) {
+        // Need an int as the maximum pool size is 2^16
+        for (int i = 0; i < constantPool.length; i++) {
             if (constantPool[i] instanceof ConstantUtf8) {
                 ConstantUtf8 c = (ConstantUtf8) constantPool[i];
                 String str = c.getBytes();


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[markt]

On 10/02/2021 09:56, [hidden email] wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>      new abde81d  Fix bug. Constant pool size is defined as u2
> abde81d is described below
>
> commit abde81dfa60b1e390c82e4b30240a59ea1b0596e
> Author: Mark Thomas <[hidden email]>
> AuthorDate: Wed Feb 10 09:55:51 2021 +0000
>
>     Fix bug. Constant pool size is defined as u2
>    
>     u2 is an unsigned 2-byte integer but short is a signed 2-byte integer.
>     Therefore use int.

FYI, I have finally got around to testing the migration tool with
Atlassian Jira. This is what uncovered the above bug.

I am still seeing a failure when I start Jira under Tomcat 10. I'm
currently investigating the root cause.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[markt]

On 10/02/2021 10:26, Mark Thomas wrote:

<snip/>

> I am still seeing a failure when I start Jira under Tomcat 10. I'm
> currently investigating the root cause.

I've fixed the simple issues and what I am left with is issues OSGi
metadata. I've made some progress but hit a brick wall.

Can one of the people more familiar with OSGI give me a pointer or two
on where the metadata might need fixing to fix this error:

ERROR: Bundle com.atlassian.plugin.osgi.bridge [1] Error starting
file:/home/mark/jira-jakarta/atlassian-jira/WEB-INF/osgi-framework-bundles/atlassian-plugins-osgi-bridge-5.3.11.jar
(org.osgi.framework.BundleException: Unable to resolve
com.atlassian.plugin.osgi.bridge [1](R 1.0): missing requirement
[com.atlassian.plugin.osgi.bridge [1](R 1.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.springframework.beans.factory.config)(version>=5.0.0))
[caused by: Unable to resolve org.apache.servicemix.bundles.spring-beans
[6](R 6.0): missing requirement
[org.apache.servicemix.bundles.spring-beans [6](R 6.0)]
osgi.wiring.package; (osgi.wiring.package=jakarta.inject)] Unresolved
requirements: [[com.atlassian.plugin.osgi.bridge [1](R 1.0)]
osgi.wiring.package;
(&(osgi.wiring.package=org.springframework.beans.factory.config)(version>=5.0.0))])
org.osgi.framework.BundleException: Unable to resolve
com.atlassian.plugin.osgi.bridge [1](R 1.0): missing requirement
[com.atlassian.plugin.osgi.bridge [1](R 1.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.springframework.beans.factory.config)(version>=5.0.0))
[caused by: Unable to resolve org.apache.servicemix.bundles.spring-beans
[6](R 6.0): missing requirement
[org.apache.servicemix.bundles.spring-beans [6](R 6.0)]
osgi.wiring.package; (osgi.wiring.package=jakarta.inject)] Unresolved
requirements: [[com.atlassian.plugin.osgi.bridge [1](R 1.0)]
osgi.wiring.package;
(&(osgi.wiring.package=org.springframework.beans.factory.config)(version>=5.0.0))]
        at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4149)
        at org.apache.felix.framework.Felix.startBundle(Felix.java:2119)
        at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
        at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
        at java.lang.Thread.run(Thread.java:748)


Thanks,

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Raymond Auge-3]

missing requirement
[org.apache.servicemix.bundles.spring-beans [6](R 6.0)]
osgi.wiring.package; (osgi.wiring.package=jakarta.inject)]

Is the jakarta.inject package exported by someone (in the framework)?

I'm not sure how JIRA sets up it's OSGi runtime.

Ray

On Wed, Feb 10, 2021 at 11:42 AM Mark Thomas <[hidden email]> wrote:

> On 10/02/2021 10:26, Mark Thomas wrote:
>
> <snip/>
>
> > I am still seeing a failure when I start Jira under Tomcat 10. I'm
> > currently investigating the root cause.
>
> I've fixed the simple issues and what I am left with is issues OSGi
> metadata. I've made some progress but hit a brick wall.
>
> Can one of the people more familiar with OSGI give me a pointer or two
> on where the metadata might need fixing to fix this error:
>
> ERROR: Bundle com.atlassian.plugin.osgi.bridge [1] Error starting
>
> file:/home/mark/jira-jakarta/atlassian-jira/WEB-INF/osgi-framework-bundles/atlassian-plugins-osgi-bridge-5.3.11.jar
> (org.osgi.framework.BundleException: Unable to resolve
> com.atlassian.plugin.osgi.bridge [1](R 1.0): missing requirement
> [com.atlassian.plugin.osgi.bridge [1](R 1.0)] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.springframework.beans.factory.config)(version>=5.0.0))
> [caused by: Unable to resolve org.apache.servicemix.bundles.spring-beans
> [6](R 6.0): missing requirement
> [org.apache.servicemix.bundles.spring-beans [6](R 6.0)]
> osgi.wiring.package; (osgi.wiring.package=jakarta.inject)] Unresolved
> requirements: [[com.atlassian.plugin.osgi.bridge [1](R 1.0)]
> osgi.wiring.package;
>
> (&(osgi.wiring.package=org.springframework.beans.factory.config)(version>=5.0.0))])
> org.osgi.framework.BundleException: Unable to resolve
> com.atlassian.plugin.osgi.bridge [1](R 1.0): missing requirement
> [com.atlassian.plugin.osgi.bridge [1](R 1.0)] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.springframework.beans.factory.config)(version>=5.0.0))
> [caused by: Unable to resolve org.apache.servicemix.bundles.spring-beans
> [6](R 6.0): missing requirement
> [org.apache.servicemix.bundles.spring-beans [6](R 6.0)]
> osgi.wiring.package; (osgi.wiring.package=jakarta.inject)] Unresolved
> requirements: [[com.atlassian.plugin.osgi.bridge [1](R 1.0)]
> osgi.wiring.package;
>
> (&(osgi.wiring.package=org.springframework.beans.factory.config)(version>=5.0.0))]
>         at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4149)
>         at org.apache.felix.framework.Felix.startBundle(Felix.java:2119)
>         at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
>         at
>
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
>         at java.lang.Thread.run(Thread.java:748)
>
>
> Thanks,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow

[markt]

On 10/02/2021 17:27, Raymond Auge wrote:
> missing requirement
> [org.apache.servicemix.bundles.spring-beans [6](R 6.0)]
> osgi.wiring.package; (osgi.wiring.package=jakarta.inject)]
>
> Is the jakarta.inject package exported by someone (in the framework)?
>
> I'm not sure how JIRA sets up it's OSGi runtime.

Thanks. That was one of my working theories. It is helpful to have it
confirmed.

I have spent some more time on this today without success. As far as I
can tell, I have converted every reference to javax.inject to jakarta
.inject but I am obviously missing something but I can't figure out
what. I think I am going to leave this for now.

I'll start on the 0.2.0 release shortly and then plan to think some more
about integration of this tool with Tomcat 10.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[remm]

On Thu, Feb 11, 2021 at 12:08 PM Mark Thomas <[hidden email]> wrote:

> On 10/02/2021 17:27, Raymond Auge wrote:
> > missing requirement
> > [org.apache.servicemix.bundles.spring-beans [6](R 6.0)]
> > osgi.wiring.package; (osgi.wiring.package=jakarta.inject)]
> >
> > Is the jakarta.inject package exported by someone (in the framework)?
> >
> > I'm not sure how JIRA sets up it's OSGi runtime.
>
> Thanks. That was one of my working theories. It is helpful to have it
> confirmed.
>
> I have spent some more time on this today without success. As far as I
> can tell, I have converted every reference to javax.inject to jakarta
> .inject but I am obviously missing something but I can't figure out
> what. I think I am going to leave this for now.
>
> I'll start on the 0.2.0 release shortly and then plan to think some more
> about integration of this tool with Tomcat 10.
>

+1 for the release.
If we're talking about its integration, I can help and/or do it.

Rémy


>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

[markt]

On 11/02/2021 14:39, Rémy Maucherat wrote:

> On Thu, Feb 11, 2021 at 12:08 PM Mark Thomas <[hidden email]> wrote:
>
>> On 10/02/2021 17:27, Raymond Auge wrote:
>>> missing requirement
>>> [org.apache.servicemix.bundles.spring-beans [6](R 6.0)]
>>> osgi.wiring.package; (osgi.wiring.package=jakarta.inject)]
>>>
>>> Is the jakarta.inject package exported by someone (in the framework)?
>>>
>>> I'm not sure how JIRA sets up it's OSGi runtime.
>>
>> Thanks. That was one of my working theories. It is helpful to have it
>> confirmed.
>>
>> I have spent some more time on this today without success. As far as I
>> can tell, I have converted every reference to javax.inject to jakarta
>> .inject but I am obviously missing something but I can't figure out
>> what. I think I am going to leave this for now.
>>
>> I'll start on the 0.2.0 release shortly and then plan to think some more
>> about integration of this tool with Tomcat 10.
>>
>
> +1 for the release.
> If we're talking about its integration, I can help and/or do it.

Thanks for the offer. I have the deployment approach about 95% complete
;). Maybe look at the runtime approach so we can compare?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[remm]

On Thu, Feb 11, 2021 at 3:47 PM Mark Thomas <[hidden email]> wrote:

> On 11/02/2021 14:39, Rémy Maucherat wrote:
> > On Thu, Feb 11, 2021 at 12:08 PM Mark Thomas <[hidden email]> wrote:
> >
> >> On 10/02/2021 17:27, Raymond Auge wrote:
> >>> missing requirement
> >>> [org.apache.servicemix.bundles.spring-beans [6](R 6.0)]
> >>> osgi.wiring.package; (osgi.wiring.package=jakarta.inject)]
> >>>
> >>> Is the jakarta.inject package exported by someone (in the framework)?
> >>>
> >>> I'm not sure how JIRA sets up it's OSGi runtime.
> >>
> >> Thanks. That was one of my working theories. It is helpful to have it
> >> confirmed.
> >>
> >> I have spent some more time on this today without success. As far as I
> >> can tell, I have converted every reference to javax.inject to jakarta
> >> .inject but I am obviously missing something but I can't figure out
> >> what. I think I am going to leave this for now.
> >>
> >> I'll start on the 0.2.0 release shortly and then plan to think some more
> >> about integration of this tool with Tomcat 10.
> >>
> >
> > +1 for the release.
> > If we're talking about its integration, I can help and/or do it.
>
> Thanks for the offer. I have the deployment approach about 95% complete
> ;). Maybe look at the runtime approach so we can compare?
>

I don't think the runtime option is a good plan for static resources. It
would be "ok" for classes which would avoid the JAR repackaging troubles,
however.

I'll add the ClassFileTransformer hook to ClassConverter before your
release, for experimentation with our WebappClassLoader. This won't convert
classloader resources though (URLClassLoader.getResourceAsStream).

Rémy


>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

[remm]

On Thu, Feb 11, 2021 at 3:47 PM Mark Thomas <[hidden email]> wrote:

> On 11/02/2021 14:39, Rémy Maucherat wrote:
> > On Thu, Feb 11, 2021 at 12:08 PM Mark Thomas <[hidden email]> wrote:
> >
> >> On 10/02/2021 17:27, Raymond Auge wrote:
> >>> missing requirement
> >>> [org.apache.servicemix.bundles.spring-beans [6](R 6.0)]
> >>> osgi.wiring.package; (osgi.wiring.package=jakarta.inject)]
> >>>
> >>> Is the jakarta.inject package exported by someone (in the framework)?
> >>>
> >>> I'm not sure how JIRA sets up it's OSGi runtime.
> >>
> >> Thanks. That was one of my working theories. It is helpful to have it
> >> confirmed.
> >>
> >> I have spent some more time on this today without success. As far as I
> >> can tell, I have converted every reference to javax.inject to jakarta
> >> .inject but I am obviously missing something but I can't figure out
> >> what. I think I am going to leave this for now.
> >>
> >> I'll start on the 0.2.0 release shortly and then plan to think some more
> >> about integration of this tool with Tomcat 10.
> >>
> >
> > +1 for the release.
> > If we're talking about its integration, I can help and/or do it.
>
> Thanks for the offer. I have the deployment approach about 95% complete
> ;). Maybe look at the runtime approach so we can compare?
>

Using the tool as a ClassFileTransformer works well (so this does not cover
classloader resources which need WebResource filtering, or static files),
except actually using the shaded JAR with Tomcat did not work and needed a
manifest tweak to drop its class-path.

Rémy


>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>