Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jsonb-dev] [jakartaee-platform-dev] [jaxrs-dev] [External] : Re: Jakarta TCK package naming convention



Le lun. 24 janv. 2022 à 17:40, Jan Westerkamp <jan.westerkamp@xxxxxxx> a écrit :
@Romain: please see comments inline

Am 24.01.22 um 15:19 schrieb Romain Manni-Bucau:



Le lun. 24 janv. 2022 à 15:03, Jan Westerkamp <jan.westerkamp@xxxxxxx> a écrit :
@Romain: I added my comments to yours inline too:

Am 24.01.22 um 10:40 schrieb Romain Manni-Bucau:
@Jan: commented inline but overall I think what you are stating is not accurate.


Le lun. 24 janv. 2022 à 10:36, Jan Westerkamp <jan.westerkamp@xxxxxxx> a écrit :
Romain,

regarding your short story:

I think this is a misinterpretation of the spec by you (and others):

Applications can and in some cases are allowed to use the jakarta.* namespace (or javax.*), especially TCKs are for the last! And this is for very good reason, too (Lukas explained that in detail).

Well, it is explicitly forbidden since at least 10 years but if you can see a paragraph saying the opposite - meaning the spec contradicts itself (happens sadly) - it could be refined.
It was also respected by the TCK until the javax->jakarta migration missed this point in a "too fast" migration.

It is not - for good reasons:

Regarding common applications, your are not allowed to use i.e. because of the trademark, naming conflicts etc. Instead developers should use a namespace reflecting their project organisation.

But i.e. the TCK is allowed to use it!


No since TCK must respect the spec and the spec stated it is forbidden so as written numerous times, the application part (embedded in an application) of TCK must not.

Scott S. pointed this our already, it is NOT forbidden in the spec and as far as i know there is no TCK test available, that ensures an implementation to do something else.


There was 2 quotations from the spec stating it is forbidden so no real discussion on that. Fact TCK don't test it is not a proof too (JPA spec can show you that TCK are not a proof of respect of the spec to cite only one spec ;)).
 


And for common applications the user is allowed to add jakarta.* stuff too - i.e. to add jakarta specs, that are not included in the implementation already.


Yes while not deployed in any application archive (which means no literally).
Why not as part of the app package? As an application developer I want do decide where to add functionality - as part the platform implementation or my application.

Cause it is forbidden, as simple as this. The spec spirit is "infrastructure"/"container"/ vs "application" separation in terms of packages.

"As an application developer I want do decide where to add functionality - as part the platform implementation or my application."

No, as an application developer, JakartaEE (JavaEE) only materializes the application part, rest is not specified nor materialized in the spec - because vendors are too heteroclites and there are tons of options - so it does not exist for a JakartaEE user (it does for a container vendor user indeed but it is out of topic there).
 
 

Filtering misconfigured user applications (by adding components already provided by the implementation) to run them is not a good reason for filtering the hole root namespace.


Once again, as mentionned, there are technical reasons to enforce that and the first one is to ensure the jakarta namespace is not corrupted by user code nor vulnerable from applications (even if this part can evolve with recent java versions).

Now I am curious: What are the exact technical reasons?


Ensuring the specs are the expected ones (container ones), ensuring the classes are available during the whole deployment (ie before the app is even fully loaded which is not the case of application classes), ensuring the user can't hack the container, ensuring the container is compatible with the spec versions and likely a few more I'm forgetting.
As soon as you allow the application to provide spec jars you violate it and start to get troubles (you become in an unspecified and invalid state to summarize it).
 

To ensure quality at low cost, I want to fail fast. As an application developer preventing misconfiguration, I need to do the before the deployment of the app - at compile time within the IDE. May be you can add a check for me in the implementation too - but I don't want to run an overloaded, misconfigured app without notable feedback (fail to run the app at best). And I want to be able to add things as an expert via my app - when I know what I am doing.


This is perfectly compatible but it enters into vendor area and not JakartaEE scope (the common part if you want).
As explained, TomEE - for example - enabled that. Default is to respect the spec and harnessed run, ie the user compiled against the ee-api jar of the target instance in provided scope so has no surprise and can't compile/test code incompatible. In advanced mode you can put a spec and force tomee to use it instead of the container one - indeed it is limited to a set of spec, not all can support that feature.
 

I can add vulnerabilities at any part the app or an app container runtime. Therefore hardening need to be done and depending on a security analysis. When you talk about situations where the Security Manager can sill be used: It's capabilities are limited, but need fine grained configuration only (as part of the hardening).


It is not really about security manager, it is never used and will be dropped. It is more about not loading the 8th level transitive dep of your build project which brings jakarta.foo.bar and override (child first) the container one so the implementation of the container is no more available (classloader tree/graph rule) and your application is only partially deployed or it is properly deployed but with a classloading graph wiring which is unsupported and untested by your vendor...unspecified and untested so bad for user *by default*.
 


 

At the moment there is only one platform implementation mentioned in the threads (TomEE), that has problems with that (please add more):

No, all servers do it, even "subservers" (partial support of EE like Tomcat) and even libs (all JPA implementations for ex).
The scope is globally "if there is any work with proxying and classloader" so it covers most of the implementations even if some can be fully contextual theorically - but I know none doing it this way.
 

TomEE
(OpenLiberty ?)

Not sure it is enforced at openliberty - should if it is servlet compatible at least ;) - but from what I have tested it is random when you mix both and OSGi seems to play his role until you configure it explicitly so without checking more deeply I'd say it is in between by design but not generally enabling too.
Once again, there is no real way to make *all* spec working together without forcing all EE stack to be in the same loader and the app parent loader must provide it so at the end you must prevent the app to load it in general - once again some cases can enable to be loaded from the app, TomEE enabled to load jaxrs 2 from the app before when JAXRS 1 was still the default in, same for jsonp/jsonb - but generally speaking it can't work if you also respect the flat classloader for the app - and openliberty is not better than others there since it inherit from EE classloading.
To give you a quick summary: look how EAR are broken and vendors worked around their classloading, it is the same if you don't respect this spec restriction.

I am not saying: Hey app developers, do what you want to - especially not for the legal aspects and maintainability.

But in edge cases like your provided use case to patch an existing implementation version or create a hotfix it is valid to do so within jakarta.*.


Never said the opposite and it is fine to enable it at vendor level as mentionned. What wouldn't be fine is to open the door in the spec to do it portably since there is no way to guarantee it works in the spec due to its construction (or it would require to define very deeply the classloading - which is out of topic for this thread btw - and sounds like not the best option for "tomorrow" since everybody is becoming "flat classpath" - and not JPMS but literally "flat classpath" so if EE must invest time in defining any classloading compatibilty I'd say it would be about it more than anything else (but indeed it is my opinion and we kind of quit this thread topic so will not go way further on it).
 


 

The following component spec implementations are mentioned to might have problems (please add more):

EclipseLink
CXF
OpenWebBeans

The original decision was made to split the TCK into parts, that fit into the spec project - therefore I strongly recommend to drop it in jakarta.[spec].* (some ? put it in jakarta.[spec].tck.*), where it belongs to.

As explained you cant start with jakarta so decision is more about what you put before, not what you put after which is already done and does not need to involve more work.
Yes, you can! (see above)
 

Best,
Jan


Am 22.01.22 um 13:13 schrieb Romain Manni-Bucau:
Hi Markus,

The references and explanations are higher - at the beginning - in this thread. Long story short: platform assumes api package is not provided by the apps so tck simulating an app must not use it by spec.


Le sam. 22 janv. 2022 à 11:50, Markus Karg <markus@xxxxxxxxxxxxxxx> a écrit :

Can you please publish that rule on a place that we can link to?

Also it would be great to hear why it is forbidden for us to stick with jakarta.* for TCK tests.

-Markus

 

 

Von: jakartaee-platform-dev [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] Im Auftrag von David Blevins
Gesendet: Freitag, 21. Januar 2022 23:26
An: jakartaee-platform developer discussions
Cc: jsonb-dev@xxxxxxxxxxx; jakartaee-tck-dev@xxxxxxxxxxx; jaxrs developer discussions; jsonp developer discussions
Betreff: Re: [jakartaee-platform-dev] [jaxrs-dev] [External] : Re: Jakarta TCK package naming convention

 

The LJC is the current elected Participant Member of the Specification Committee and voted +1.  Of the binding votes from members of the Specification Committee who did not abstain, the vote did pass by super majority.

 

Using that namespace is still optional, however.  The only requirement is not to use jakarta.* for TCK tests.

 



On Jan 21, 2022, at 2:12 PM, Markus Karg <markus@xxxxxxxxxxxxxxx> wrote:

 

I cannot see that a concensus was actually found. iJUG is voting against this decision.

-Markus Karg

iJUG Vice Embassador at Eclipse Foundation

 

Von: jaxrs-dev [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] Im Auftrag von Emily Jiang via jaxrs-dev
Gesendet: Dienstag, 18. Januar 2022 19:39
An: jakartaee-platform developer discussions
Cc: Emily Jiang; jsonp developer discussions; Scott Stark; jakartaee-tck-dev@xxxxxxxxxxx; jaxrs developer discussions; jsonb-dev@xxxxxxxxxxx
Betreff: Re: [jaxrs-dev] [jakartaee-platform-dev] [External] : Re: Jakarta TCK package naming convention

 

Just provide a quick update on this thread. We discussed the TCK namespace again at today's Jakarta Platform call. The conclusion for the tck namespace is as follows.

o   General agreement that ‘jakarta’ namespace (starting with ‘jakarta’) must be avoided in EE10 TCKs

o   Any non-’jakarta’ namespace is ok for EE10

p.s. I started a vote to get one TCK package namespace (ee.jakarta.tck.[spec]) approved by the Jakarta spec committee, which will be concluded tomorrow. I will share the result then. If that package name is approved, it  can be used to replace the jakarta.* in EE 10 TCKs.

 

Thanks

Emily

 

On Fri, Jan 14, 2022 at 11:31 AM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:

Hi Scott,

Thanks for sharing your thoughts! You are heard:o. I see you have concerns with the new package of ee.jakarta.tck.[spec]. From my understanding, ee.jakarta is trying to say Jakarta EE. Jakarta EE includes the part of SE  e.g. Jakarta CDI is under Jakarta EE but it also contains the part CDI SE, When it comes to names, it is almost impossible to make everyone happy. It is like people's names. Different people might have different opinions towards a particular name. If we clearly document ee.jakarta means Jakarta EE and it carries no other meaning, it might clarify some doubts. 

What do other people think?

 

Thanks

Emily

 

 

 

 

On Thu, Jan 13, 2022 at 12:17 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:

 

On Thu, Jan 13, 2022, 6:28 AM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:

Hi Scott,

The name change impacts the new tests starting with jakarta.* (polls were used to figure out a name). The overall TCK buckets should not be affected. As for the voting schedule, it was suggested on the mailing list but no one objected. Besides, we need to come to a quick conclusion due to the Jakarta EE 10 train, so the survey was shorter than others. 

 

Hi Emily, 

 

People were still trying to be heard that seemed to be ignored during the discussion.

 

Also the vote ended before we reached a conclusion on which problem needs to be solved.

 

I agree that this mostly impacts new Standalone TCKs but IMO the most popular choice doesn't sound right appropriate for Standalone TCKs that test both SE + EE. :(

 

Anyway, do you agree that TCKs only should avoid using jakarta as the initial package prefix?  

 

I'm not personally against picking a standard TCK package name prefix for new TCK tests.  

 

One possible package name prefix could be <spec>.tck but I am sure there other options like the ones you mentioned that don't have EE in them that could be meaningful for both SE + EE.

 

Thanks for listening to my feedback :)

 

Scott

 

 

Thanks

Emily

 

 L

On Thu, Jan 13, 2022 at 9:44 AM Scott Marlow <smarlow@xxxxxxxxxx> wrote:

In summary, we should avoid using Jakarta as the first prefix in the package name of certain non spec api classes like TCKs.  The reason being that some EE implementations may be filtering spec api classes by simply checking for "jakarta.*" classes as part of application deployment processing.  

 

I'm still unsure of the EE 10 schedule cost for this change. I suggest that we make the package change after other TCK changes are merged so that there is less delay caused by this change (e.g. goal being to minimize breaking other in progress TCK work).  

 

In future community polls, we should allow more time for input so that more community users can participate.    

 

I'm not sure if the choice to use ee.jakarta.tck.[spec] will help any Standalone TCKs but if yes, you now have the option to use it.  Historically, we use EE for Jakarta EE TCK tests but not consistently, even less consistently now since all newly added tests might start with EE.

 

Hope this helps,

 

Scott

On Wed, Jan 12, 2022, 5:06 PM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:

Thank you all for who have voted!  Survey result from the community for the TCK package names is as follows.

29 responses:

package name: votes

==================

ee.jakarta.tck.[spec]: 14

tck.jakarta.[spec]: 7

org.eclipse.jakarta.tck.[spec]: 8

org.jakartatck.[spec]: 0

 

The clear winner is ee.jakarta.tck.[spec]. The NEW Jakarta TCKs in Jakarta EE 10 can start adopting this package name if their current package names are jakarta.*. 

 

To make this vote formal, I was asked to start a ballot on the Spec committee to get this community-chosen package name ee.jakarta.tck.* formally approved by the committee. I'll start that process momentarily. 

 

Thanks

Emily

 

 

On Wed, Jan 12, 2022 at 10:00 PM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:

Thank you all for who have voted!  Survey result from the community for the TCK package names is as follows.

29 responses:

package name: votes

==================

ee.jakarta.tck.[spec]: 14

tck.jakarta.[spec]: 7

org.eclipse.jakarta.tck.[spec]: 8

org.jakartatck.[spec]: 0

 

The clear winner is ee.jakarta.tck.[spec]. The NEW Jakarta TCKs in Jakarta EE 10 can start adopting this package name if their current package names are jakarta.*. 

 

To make this vote formal, I was asked to start a ballot on the Spec committee to get this community-chosen package name ee.jakarta.tck.* formally approved by the committee. I'll start that process momentarily. 

 

Thanks

Emily

 

On Tue, Jan 11, 2022 at 9:38 PM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:

Hi Lukas,

Do we know how long one needs to wait to get recommended package name OR 
is it expected that the project teams choose something and repeat the 
exercise for EE 11 once the recommendation/requirement is in place?

The vote will be closed on 9:21am Pacific Wednesday 12th Jan. You can find the current response here. You can already see the potential winner there. By the way, if you choose something not starting with jakarta.*, you can stick to it for future releases. The new naming convention applies to the new TCKs from Jakarta EE 11 onwards. Any existing TCKs are not required to be updated.

 

Thanks

Emily

 

 

On Tue, Jan 11, 2022 at 7:51 PM Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:

On 1/11/22 7:51 PM, Scott Marlow wrote:
> 
> On 1/11/22 1:04 PM, Scott Stark wrote:
>> The issue for EE10 is if TCKs are delivering application deployments 
>> under the jakarta.* package namespace, which implementation will 
>> challenge this as invalid?
>>
>> Historically (Jakarta EE 9 and earlier), tck deployments were under a 
>> vendor specific package namespace, com.sun.*, org.jboss.*, etc.
>>
>> The short term issue is whether the use of jakarta.* package 
>> deployments is going to cause problems with getting sufficient 
>> compatible implementations certified.
> 
> https://github.com/eclipse-ee4j/jaxrs-api/issues/1081 asks for input on 
> the schedule impact of changing the new RESTful Web Services TCK tests 
> from jakarta package to something that doesn't start with the jakarta 
> package.
> 
> I'm curious what the schedule impact would be for the new JSON Binding + 
> JSON Processing TCKs to not use the jakarta package name in test classes?

If you ask me and assuming current target (end of Feb), then from the 
high level perspective, there are still about 6 weeks to do the work 
which looks fine, even though it is not clear to what exactly the 
package is expected to be changed yet. Just keep in mind that those who 
are expected to do the work are supposed to handle other projects 
(specs, impls, TCKs) as well, so more time they spend on this, less time 
they'll have for other stuff and that other stuff may not meet the 
currently defined deadline.

Do we know how long one needs to wait to get recommended package name OR 
is it expected that the project teams choose something and repeat the 
exercise for EE 11 once the recommendation/requirement is in place?

thanks,
--lukas



> 
> Scott
>>
>>
>> On Jan 11, 2022 at 6:28:25 AM, Romain Manni-Bucau 
>> <rmannibucau@xxxxxxxxx> wrote:
>>> I can agree with all you said but still the problem is there so 
>>> conclusion is still TCK must change of packaging at some point.
>>> So discussion points are:
>>>
>>> 1. when
>>> 2. how to mitigate next release certification if 1 is after next release
>>> 3. which package
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau 
>>> <https://urldefense.com/v3/__https://twitter.com/rmannibucau__;!!ACWV5N9M2RV99hQ!fos1sjDRXC7c7ttwcR9-SuXqknQp-7MecLj6f9lfpCH8vS_koSV3USrIrLZJcpM0YTU$> 
>>> | Blog 
>>> <https://urldefense.com/v3/__https://rmannibucau.metawerx.net/__;!!ACWV5N9M2RV99hQ!fos1sjDRXC7c7ttwcR9-SuXqknQp-7MecLj6f9lfpCH8vS_koSV3USrIrLZJeOaq3W8$> | 
>>> Old Blog 
>>> <https://urldefense.com/v3/__http://rmannibucau.wordpress.com__;!!ACWV5N9M2RV99hQ!fos1sjDRXC7c7ttwcR9-SuXqknQp-7MecLj6f9lfpCH8vS_koSV3USrIrLZJ-r8kkFQ$> 
>>> | Github 
>>> <https://urldefense.com/v3/__https://github.com/rmannibucau__;!!ACWV5N9M2RV99hQ!fos1sjDRXC7c7ttwcR9-SuXqknQp-7MecLj6f9lfpCH8vS_koSV3USrIrLZJrAnLuVE$> | 
>>> LinkedIn 
>>> <https://urldefense.com/v3/__https://www.linkedin.com/in/rmannibucau__;!!ACWV5N9M2RV99hQ!fos1sjDRXC7c7ttwcR9-SuXqknQp-7MecLj6f9lfpCH8vS_koSV3USrIrLZJ4gPkq8o$> | 
>>> Book 
>>> <https://urldefense.com/v3/__https://www.packtpub.com/application-development/java-ee-8-high-performance__;!!ACWV5N9M2RV99hQ!fos1sjDRXC7c7ttwcR9-SuXqknQp-7MecLj6f9lfpCH8vS_koSV3USrIrLZJecqVzg0$>
>>>
>>>
>>> Le mar. 11 janv. 2022 à 13:19, Lukas Jungmann 
>>> <lukas.jungmann@xxxxxxxxxx> a écrit :
>>>
>>>     On 1/11/22 12:21 PM, Romain Manni-Bucau wrote:
>>>     >
>>>     >
>>>     >
>>>     > Le mar. 11 janv. 2022 à 11:28, Lukas Jungmann
>>>     <lukas.jungmann@xxxxxxxxxx
>>>     > <mailto:lukas.jungmann@xxxxxxxxxx>> a écrit :
>>>     >
>>>     >     to me "should not" != "must not" based on RFC 2119/8174; a
>>>     >     recommendation is not a requirement per se. But it's
>>>     evident I'm still
>>>     >     missing something.
>>>     >
>>>     >
>>>     > Right _for servlet part_,  but what does it change?
>>>     > Well, read it as it is "implementations should do", they can or
>>>     not as
>>>     > you point out but they are highly encourage to, so TCK must
>>>     assume they
>>>     > do, so we didn't move forward AFAIK.
>>>
>>>     TCKs must be able to handle both cases as both are valid based on
>>>     the
>>>     current wording. They are not the ones to assume anything, they
>>>     are the
>>>     ones to expect things to happen or not to happen based on current
>>>     definitions. Ideally, TCKs only follow changes in definitions,
>>>     not the
>>>     other way around.
>>>
>>>     Also note that there is a difference between "Jakarta classes" and
>>>     "Jakarta Platform classes" and this differentiation should be kept.
>>>     Currently, MVC, NoSQL or even some TCKs are "Jakarta classes" but
>>>     not
>>>     "Jakarta Platform classes" (given both groups are using jakarta
>>>     package
>>>     namespace).
>>>
>>>
>>>     --lukas
>>>
>>
>> _______________________________________________
>> jakartaee-platform-dev mailing list
>> jakartaee-platform-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> 
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!fos1sjDRXC7c7ttwcR9-SuXqknQp-7MecLj6f9lfpCH8vS_koSV3USrIrLZJSw1XQBU$

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev



-- 

Thanks
Emily


 

-- 

Thanks
Emily


 

-- 

Thanks
Emily


 

-- 

Thanks
Emily



-- 

Thanks
Emily



-- 

Thanks
Emily

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev




Back to the top