You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2021/03/13 07:57:22 UTC
Why is jakarta forbidden?
Hi,
Likely more a question for David: why is jakarta considered as a forbidden
package (
https://github.com/apache/openwebbeans/commit/6ede81da26a4a65dc0c88fda7e438f29114fea37)
?
To explain why I ask: jakarta is a module as any other, and we shouldn't
get abused by the presence of javax just before which is there for the java
*se* part of javax api and not EE one so not sure I get the rational there,
any test/sample I can run to understand?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Re: Why is jakarta forbidden?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Awesome :), so let's release now we support java 16 OOTB :)
about the config: the reason it is there is not only jakarta - even if it
triggers it - but all cases where the original jar package is forbidden,
can be endorsed lib on java 8, some validated package (with some 3rd party
lib), some particular native libs (now we can run libs as .so) and so on.
So think it makes sense to keep it, in particular because its cost is not
very high and even from a strict jvm point of view we are incomplete (don't
forget now the jdk uses jdk.xxx to dev early features user can rely on and
we totally don't cover this case OOTB). So overall: this flag is intended
to be used ;). Longer term we can desire to make it a real SPI - the flag
moving to the default impl - to control the proxy package+name and ease the
"defineclass" but right now it is a bit overkill, let's wait java XX which
locks even more the JVM ;).
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 17 mars 2021 à 01:01, David Blevins <da...@gmail.com> a
écrit :
> > On Mar 16, 2021, at 4:56 PM, David Blevins <da...@gmail.com>
> wrote:
> >
> > The results after the OWB upgrade and prior to this weekend's changes
> were less than 10k passing.
>
> For clarity, the reason things worked before the OWB upgrade is we had
> AbstractProxyFactory patched. I deleted that after Mark upgraded us to the
> main branch:
>
> -
> https://github.com/apache/tomee-jakarta/commit/8883f220104c45be102f4dc339956a09a3ff6e72
>
> Now it appears we don't need a patch or a flag which is very very awesome!
>
>
> -David
>
>
Re: Why is jakarta forbidden?
Posted by David Blevins <da...@gmail.com>.
> On Mar 16, 2021, at 4:56 PM, David Blevins <da...@gmail.com> wrote:
>
> The results after the OWB upgrade and prior to this weekend's changes were less than 10k passing.
For clarity, the reason things worked before the OWB upgrade is we had AbstractProxyFactory patched. I deleted that after Mark upgraded us to the main branch:
- https://github.com/apache/tomee-jakarta/commit/8883f220104c45be102f4dc339956a09a3ff6e72
Now it appears we don't need a patch or a flag which is very very awesome!
-David
Re: Why is jakarta forbidden?
Posted by David Blevins <da...@gmail.com>.
> On Mar 15, 2021, at 2:16 PM, David Blevins <da...@gmail.com> wrote:
>
>> On Mar 15, 2021, at 9:27 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>>
>> Hi,
>>
>> Added a configuration for the packages - since we can hit that with some
>> "specific" jars and some signed ones:
>> https://issues.apache.org/jira/browse/OWB-1377
>> Didn't get a change to run TCK setup but proxied the jakarta package
>> several times so if anyone has enough resources to work on a reproducer I
>> would be happy to refine this particular case if needed.
>> In the mean time I guess tomee can set up the configuration in
>> conf/system.properties and maybe fix its shade.
>
> I tried this flag out locally and it appears to work, so I've uploaded new snapshots and have kicked off a full run and will report back.
>
> Interestingly, it worked locally now without the flag so it appears something related might have been fixed in one of the changes over the weekend. After the above run is done, I'll do another with the flag off. If it works equally well, I'll also report as if it's fine it's probably better to delete the flag.
>
> Definitely, it's most ideal if no flag is needed as we are producing *-jakarta.jars and best case scenario is they work without any needed flags.
It does appear that after this weekend's changes things now work with or without this new flag. Jakarta EE 9 test results are 32142 passing with the flag and 32140 without the flag. The results after the OWB upgrade and prior to this weekend's changes were less than 10k passing.
I'd recommend doing the release as things are now and then maybe we should remove the flag just so we have less to maintain. Once flags like this are out there for a year, it's impossible to ever delete them as you never know who is using them or how they'll be impacted.
-David
Re: Why is jakarta forbidden?
Posted by David Blevins <da...@gmail.com>.
> On Mar 15, 2021, at 9:27 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Hi,
>
> Added a configuration for the packages - since we can hit that with some
> "specific" jars and some signed ones:
> https://issues.apache.org/jira/browse/OWB-1377
> Didn't get a change to run TCK setup but proxied the jakarta package
> several times so if anyone has enough resources to work on a reproducer I
> would be happy to refine this particular case if needed.
> In the mean time I guess tomee can set up the configuration in
> conf/system.properties and maybe fix its shade.
I tried this flag out locally and it appears to work, so I've uploaded new snapshots and have kicked off a full run and will report back.
Interestingly, it worked locally now without the flag so it appears something related might have been fixed in one of the changes over the weekend. After the above run is done, I'll do another with the flag off. If it works equally well, I'll also report as if it's fine it's probably better to delete the flag.
Definitely, it's most ideal if no flag is needed as we are producing *-jakarta.jars and best case scenario is they work without any needed flags.
Should know more tomorrow.
-David
Re: Why is jakarta forbidden?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
Added a configuration for the packages - since we can hit that with some
"specific" jars and some signed ones:
https://issues.apache.org/jira/browse/OWB-1377
Didn't get a change to run TCK setup but proxied the jakarta package
several times so if anyone has enough resources to work on a reproducer I
would be happy to refine this particular case if needed.
In the mean time I guess tomee can set up the configuration in
conf/system.properties and maybe fix its shade.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le sam. 13 mars 2021 à 19:40, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
> Hi David,
>
> are you able to reproduce it in a test?
> Concretely proxies can be created for jakarta classes, you can validate it
> with this trivial test:
>
> @Test
> public void jakartaProxyTest()
> {
> final WebBeansContext webBeansContext = new WebBeansContext();
> final NormalScopeProxyFactory pf = new NormalScopeProxyFactory(webBeansContext);
> final Object proxy = pf.createNormalScopeProxy(new OwbBean<CompletionListener>() {
> @Override
> public Set<Type> getTypes() {
> return null;
> }
>
> @Override
> public Set<Annotation> getQualifiers() {
> return null;
> }
>
> @Override
> public Class<? extends Annotation> getScope() {
> return ApplicationScoped.class;
> }
>
> @Override
> public String getName() {
> return null;
> }
>
> @Override
> public boolean isNullable() {
> return false;
> }
>
> @Override
> public Set<InjectionPoint> getInjectionPoints() {
> return null;
> }
>
> @Override
> public Class<?> getBeanClass() {
> return null; // this is what we test
> }
>
> @Override
> public Set<Class<? extends Annotation>> getStereotypes() {
> return null;
> }
>
> @Override
> public boolean isAlternative() {
> return false;
> }
>
> @Override
> public CompletionListener create(final CreationalContext<CompletionListener> context) {
> return null;
> }
>
> @Override
> public void destroy(final CompletionListener instance, final CreationalContext<CompletionListener> context) {
>
> }
>
> @Override
> public Producer<CompletionListener> getProducer() {
> return null;
> }
>
> @Override
> public WebBeansType getWebBeansType() {
> return null;
> }
>
> @Override
> public Class<CompletionListener> getReturnType() {
> return CompletionListener.class;
> }
>
> @Override
> public void setSpecializedBean(boolean specialized) {
>
> }
>
> @Override
> public boolean isSpecializedBean() {
> return false;
> }
>
> @Override
> public void setEnabled(boolean enabled) {
>
> }
>
> @Override
> public boolean isEnabled() {
> return false;
> }
>
> @Override
> public String getId() {
> return null;
> }
>
> @Override
> public boolean isPassivationCapable() {
> return false;
> }
>
> @Override
> public boolean isDependent() {
> return false;
> }
>
> @Override
> public WebBeansContext getWebBeansContext() {
> return null;
> }
> });
> assertNotNull(proxy);
> System.out.println(asList(proxy.getClass().getDeclaredFields()));
> }
>
> This method only affects in which package the proxy is created so it must
> be useless and revertable.
>
> Also tested the runtime and it works too it seems so would be great to at
> least add one unit test of the breaking change if real or fix the actual
> issue and revert this if the source is something else (like jakarta jar
> endorsing the jvm or so which is not normal).
>
> Can you help to refine it please?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le sam. 13 mars 2021 à 18:46, David Blevins <da...@gmail.com> a
> écrit :
>
>> > On Mar 12, 2021, at 11:57 PM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>> >
>> > Hi,
>> >
>> > Likely more a question for David: why is jakarta considered as a
>> forbidden
>> > package (
>> >
>> https://github.com/apache/openwebbeans/commit/6ede81da26a4a65dc0c88fda7e438f29114fea37
>> )
>> > ?
>> >
>> > To explain why I ask: jakarta is a module as any other, and we shouldn't
>> > get abused by the presence of javax just before which is there for the
>> java
>> > *se* part of javax api and not EE one so not sure I get the rational
>> there,
>> > any test/sample I can run to understand?
>>
>> A javax-to-jakarta namespace switch in bytecode doesn't appear to work
>> without this change. For TomEE 9 80% of the TCK will fail with due to
>> deployment errors.
>>
>> If you revert this change locally and rebuild these repos
>>
>> - https://github.com/apache/tomee
>> - https://github.com/apache/tomee-jakarta
>>
>> here's a tck test that shows it:
>>
>> ./runtests --web tomee-plume
>> com.sun.ts.tests.ejb30.lite.appexception.singleton.annotated
>>
>> That script is in this branch. Here's also the TCK download URL.
>>
>> - https://github.com/apache/tomee-tck/tree/jakartaee9-tck
>> -
>> https://download.eclipse.org/jakartaee/platform/9/jakarta-jakartaeetck-9.0.2.zip
>>
>> Wherever the TCK is unpacked you add this to your ~/.m2/settings.xml.
>> Here are my settings for reference:
>>
>> <profile>
>> <id>jakartaee-tck</id>
>> <activation>
>> <activeByDefault>true</activeByDefault>
>> </activation>
>> <properties>
>>
>> <jakartaee9.cts.home>/Users/dblevins/work/tcks/jakartaeetck-9.0.2</jakartaee9.cts.home>
>>
>> <jakartaee9.ri.home>/Users/dblevins/work/tcks/glassfish6/glassfish</jakartaee9.ri.home>
>> </properties>
>> </profile>
>>
>> The final thing to get setup is copy an Ant install into this location of
>> the TCK.
>>
>> - jakartaeetck-9.0.2/tools/ant/
>>
>> Here's how mine looks:
>>
>> $ ls /Users/dblevins/work/tcks/jakartaeetck-9.0.2/tools/ant
>> CONTRIBUTORS LICENSE WHATSNEW
>> etc lib
>> INSTALL NOTICE bin
>> fetch.xml manual
>> KEYS README contributors.xml
>> get-m2.xml patch.xml
>>
>> Use Java 8 as the TCK itself doesn't run with Java 11 yet.
>>
>>
>> -David
>>
>>
Re: Why is jakarta forbidden?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi David,
are you able to reproduce it in a test?
Concretely proxies can be created for jakarta classes, you can validate it
with this trivial test:
@Test
public void jakartaProxyTest()
{
final WebBeansContext webBeansContext = new WebBeansContext();
final NormalScopeProxyFactory pf = new
NormalScopeProxyFactory(webBeansContext);
final Object proxy = pf.createNormalScopeProxy(new
OwbBean<CompletionListener>() {
@Override
public Set<Type> getTypes() {
return null;
}
@Override
public Set<Annotation> getQualifiers() {
return null;
}
@Override
public Class<? extends Annotation> getScope() {
return ApplicationScoped.class;
}
@Override
public String getName() {
return null;
}
@Override
public boolean isNullable() {
return false;
}
@Override
public Set<InjectionPoint> getInjectionPoints() {
return null;
}
@Override
public Class<?> getBeanClass() {
return null; // this is what we test
}
@Override
public Set<Class<? extends Annotation>> getStereotypes() {
return null;
}
@Override
public boolean isAlternative() {
return false;
}
@Override
public CompletionListener create(final
CreationalContext<CompletionListener> context) {
return null;
}
@Override
public void destroy(final CompletionListener instance, final
CreationalContext<CompletionListener> context) {
}
@Override
public Producer<CompletionListener> getProducer() {
return null;
}
@Override
public WebBeansType getWebBeansType() {
return null;
}
@Override
public Class<CompletionListener> getReturnType() {
return CompletionListener.class;
}
@Override
public void setSpecializedBean(boolean specialized) {
}
@Override
public boolean isSpecializedBean() {
return false;
}
@Override
public void setEnabled(boolean enabled) {
}
@Override
public boolean isEnabled() {
return false;
}
@Override
public String getId() {
return null;
}
@Override
public boolean isPassivationCapable() {
return false;
}
@Override
public boolean isDependent() {
return false;
}
@Override
public WebBeansContext getWebBeansContext() {
return null;
}
});
assertNotNull(proxy);
System.out.println(asList(proxy.getClass().getDeclaredFields()));
}
This method only affects in which package the proxy is created so it must
be useless and revertable.
Also tested the runtime and it works too it seems so would be great to at
least add one unit test of the breaking change if real or fix the actual
issue and revert this if the source is something else (like jakarta jar
endorsing the jvm or so which is not normal).
Can you help to refine it please?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le sam. 13 mars 2021 à 18:46, David Blevins <da...@gmail.com> a
écrit :
> > On Mar 12, 2021, at 11:57 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > Hi,
> >
> > Likely more a question for David: why is jakarta considered as a
> forbidden
> > package (
> >
> https://github.com/apache/openwebbeans/commit/6ede81da26a4a65dc0c88fda7e438f29114fea37
> )
> > ?
> >
> > To explain why I ask: jakarta is a module as any other, and we shouldn't
> > get abused by the presence of javax just before which is there for the
> java
> > *se* part of javax api and not EE one so not sure I get the rational
> there,
> > any test/sample I can run to understand?
>
> A javax-to-jakarta namespace switch in bytecode doesn't appear to work
> without this change. For TomEE 9 80% of the TCK will fail with due to
> deployment errors.
>
> If you revert this change locally and rebuild these repos
>
> - https://github.com/apache/tomee
> - https://github.com/apache/tomee-jakarta
>
> here's a tck test that shows it:
>
> ./runtests --web tomee-plume
> com.sun.ts.tests.ejb30.lite.appexception.singleton.annotated
>
> That script is in this branch. Here's also the TCK download URL.
>
> - https://github.com/apache/tomee-tck/tree/jakartaee9-tck
> -
> https://download.eclipse.org/jakartaee/platform/9/jakarta-jakartaeetck-9.0.2.zip
>
> Wherever the TCK is unpacked you add this to your ~/.m2/settings.xml.
> Here are my settings for reference:
>
> <profile>
> <id>jakartaee-tck</id>
> <activation>
> <activeByDefault>true</activeByDefault>
> </activation>
> <properties>
>
> <jakartaee9.cts.home>/Users/dblevins/work/tcks/jakartaeetck-9.0.2</jakartaee9.cts.home>
>
> <jakartaee9.ri.home>/Users/dblevins/work/tcks/glassfish6/glassfish</jakartaee9.ri.home>
> </properties>
> </profile>
>
> The final thing to get setup is copy an Ant install into this location of
> the TCK.
>
> - jakartaeetck-9.0.2/tools/ant/
>
> Here's how mine looks:
>
> $ ls /Users/dblevins/work/tcks/jakartaeetck-9.0.2/tools/ant
> CONTRIBUTORS LICENSE WHATSNEW
> etc lib
> INSTALL NOTICE bin
> fetch.xml manual
> KEYS README contributors.xml
> get-m2.xml patch.xml
>
> Use Java 8 as the TCK itself doesn't run with Java 11 yet.
>
>
> -David
>
>
Re: Why is jakarta forbidden?
Posted by David Blevins <da...@gmail.com>.
> On Mar 12, 2021, at 11:57 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Hi,
>
> Likely more a question for David: why is jakarta considered as a forbidden
> package (
> https://github.com/apache/openwebbeans/commit/6ede81da26a4a65dc0c88fda7e438f29114fea37)
> ?
>
> To explain why I ask: jakarta is a module as any other, and we shouldn't
> get abused by the presence of javax just before which is there for the java
> *se* part of javax api and not EE one so not sure I get the rational there,
> any test/sample I can run to understand?
A javax-to-jakarta namespace switch in bytecode doesn't appear to work without this change. For TomEE 9 80% of the TCK will fail with due to deployment errors.
If you revert this change locally and rebuild these repos
- https://github.com/apache/tomee
- https://github.com/apache/tomee-jakarta
here's a tck test that shows it:
./runtests --web tomee-plume com.sun.ts.tests.ejb30.lite.appexception.singleton.annotated
That script is in this branch. Here's also the TCK download URL.
- https://github.com/apache/tomee-tck/tree/jakartaee9-tck
- https://download.eclipse.org/jakartaee/platform/9/jakarta-jakartaeetck-9.0.2.zip
Wherever the TCK is unpacked you add this to your ~/.m2/settings.xml. Here are my settings for reference:
<profile>
<id>jakartaee-tck</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<jakartaee9.cts.home>/Users/dblevins/work/tcks/jakartaeetck-9.0.2</jakartaee9.cts.home>
<jakartaee9.ri.home>/Users/dblevins/work/tcks/glassfish6/glassfish</jakartaee9.ri.home>
</properties>
</profile>
The final thing to get setup is copy an Ant install into this location of the TCK.
- jakartaeetck-9.0.2/tools/ant/
Here's how mine looks:
$ ls /Users/dblevins/work/tcks/jakartaeetck-9.0.2/tools/ant
CONTRIBUTORS LICENSE WHATSNEW etc lib
INSTALL NOTICE bin fetch.xml manual
KEYS README contributors.xml get-m2.xml patch.xml
Use Java 8 as the TCK itself doesn't run with Java 11 yet.
-David