[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-dev] Issues supporting applications written in the javax and jakarta namespaces (was [jakartaee-platform-dev] [External] : Re: Standardizing new TCK packages)
|
On 1/11/22 9:47 PM, David Blevins wrote:
The topic really was very specifically, should application developers be writing their own custom application code inside the jakarta.* namespace and expect that to work?
They should not and they must not be forbidden to at the same time.
wrt MOXy handling of the
jakarta.xml.ws.wsaddressing.W3CEndpointReference is a bug regardless of
what the answer to your question is. XML WS spec requires the the XML
Binding to handle - marshal/unmarshal - this class properly on many
places and that is not the case even though MOXy claims to be the CI for
the XML Binding specification. Marshal/unmarshal operation for the
jakarta.xml.ws.wsaddressing.W3CEndpointReference class is called from
the outside of the jakarta package namespace.
In this particular context, XML Binding spec/impl should and the jaxb-ri
(another CI for the XML Binding) actually does treat XML WS spec as a
(part of) the application or better as a part of the XML Binding
application (formerly JAXB application) as is defined by the XML Binding
spec.
How should the TCK test in the XML-Binding TCK for this scenario - XML
Binding application in the jakarta package namespace to cover the usage
by XML WS spec project - look like if it is explicitly forbidden to use
'jakarta.*' namespace there in TCKs? How can the platfrom level test be
written? Should the XML Binding spec be updated to explicitly not allow
jakarta.* classes in XML Binding applications? How is XML WS spec
supposed to reflect that if so?
I do strongly believe that restricting what tests can or can not do
and/or where they must or must not be - at the owner of the jakarta
package namespace level - is a really bad idea. It may make sense at the
lowest level - directly in particular specs (platform is not that) - as
they are the best to know expected usage. These specs should also NOT
cross the boundaries of the platform defined packages if they are part
of it (ie jakarta.mvc package should be treated by all specs included in
the platform and corresponding implementations as a custom application
as long as MVC spec is not part of the platform). The same applies to
implementations unless they know for sure there is nothing of their
interest in the jakarta namespace.
thanks,
--lukas
If the answer is no, then the links I point out are not bugs. It also means we should not write applications in that namespace in our TCK.
If the answer is yes, then the links are definitely bugs and TCKs would be find and perhaps even expected to create apps in the jakarta.* namespace.
-David
On Jan 11, 2022, at 12:21 AM, Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:
On 1/11/22 12:52 AM, David Blevins wrote:
Begin forwarded message:
From: Lukas Jungmann <lukas.jungmann@xxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [External] : Re: Standardizing new TCK packages (was:package prefixes for Jakarta Batch TCK-related classes?org.eclipse.ee4j.batch ?)
Date: January 10, 2022 at 11:12:05 AM PST
To: jakartaee-platform-dev@xxxxxxxxxxx
Reply-To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
On 1/10/22 7:08 PM, Emily Jiang via jakartaee-platform-dev wrote:
The reasoning was mentioned in this mailing list thread as part of conversation.
I'm sorry but I got lost in the thread at the point where it was said that _some_ implementations are having hard times optimizing themselves. If that is the problem, then, IMHO, implementations should be fixed as they are usually those the best knowing the real "why" for what are they doing. I believe that what they are doing is not correct in 100% cases and it is possibly just a matter of time till someone files an issue for some of those corner-cases for which the "optimization" is wrong.
I pointed this particular example out twice, moving it here in hopes it might be better seen.
EclipseLink is one of the implementations I pointed out that would most likely not be able to handle users developing applications *in* the javax or jakarta namespaces.
Should or should not other specifications, not just applications, be allowed to define persistence managed objects or generally be allowed to depend on other specs?
Here are the lines that are suspect:
- https://urldefense.com/v3/__https://github.com/eclipse-ee4j/eclipselink/blob/master/moxy/org.eclipse.persistence.moxy/src/main/java/org/eclipse/persistence/jaxb/javamodel/reflection/JavaClassImpl.java*L390-L392__;Iw!!ACWV5N9M2RV99hQ!YJXvij8r5EDr_x2kien12mx7PQhHCH0xZyiQcUCeVlsbBCdFv_9LE2sgkRYdDL2kD7A$
- https://urldefense.com/v3/__https://github.com/eclipse-ee4j/eclipselink/blame/master/jpa/org.eclipse.persistence.jpa/src/main/java/org/eclipse/persistence/internal/jpa/deployment/JavaSECMPInitializer.java*L345__;Iw!!ACWV5N9M2RV99hQ!YJXvij8r5EDr_x2kien12mx7PQhHCH0xZyiQcUCeVlsbBCdFv_9LE2sgkRYdtOy3ZaY$
- https://urldefense.com/v3/__https://github.com/eclipse-ee4j/eclipselink/blob/master/moxy/org.eclipse.persistence.moxy/src/main/java/org/eclipse/persistence/jaxb/rs/MOXyJsonProvider.java*L761-L763__;Iw!!ACWV5N9M2RV99hQ!YJXvij8r5EDr_x2kien12mx7PQhHCH0xZyiQcUCeVlsbBCdFv_9LE2sgkRYdjI35Fb8$
I don't know if these in fact do cause issues if someone attempts to create original application code inside the javax or jakarta namespaces. I do know that when we attempted to use the Eclipse Transformer on EclipseLink these were some of the areas that prevented the new jakarta APIs from working and caused most the JPA TCK to fail (sort of the reverse problem).
I personally don't think it's an issue as people should not be developing their own code and putting it in the javax or jakarta namespaces. If we allowed TCKs, which contain applications, to use the jakarta namespace, there might be an issue.
If people think this is an issue, I can file it in the Github issue tracker.
IMHO all of these are bugs and failing TCKs are being correct when they point it out.
Wrt MOXy/XML Binding - jakarta.xml.ws.wsaddressing.W3CEndpointReference defined by the XML WS spec is the one not being handled correctly
Wrt JPA/Persistence - I am not aware of any other _existing_ spec defining persistence managed objects but that does not mean that one should not be allowed to create or extend one.
Side note, does this class also need to get updated to account for the jakarta namespace?
- https://urldefense.com/v3/__https://github.com/eclipse-ee4j/eclipselink/blob/master/jpa/org.eclipse.persistence.jpars.server/src/main/java/org/eclipse/persistence/jpa/rs/PersistenceFactoryBase.java*L145__;Iw!!ACWV5N9M2RV99hQ!YJXvij8r5EDr_x2kien12mx7PQhHCH0xZyiQcUCeVlsbBCdFv_9LE2sgkRYdUVzngx8$
yes, this class was forgotten to be updated.
thanks,
--lukas
-David
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!ACWV5N9M2RV99hQ!YJXvij8r5EDr_x2kien12mx7PQhHCH0xZyiQcUCeVlsbBCdFv_9LE2sgkRYdGfoLqfQ$
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!ACWV5N9M2RV99hQ!ayTTZW2_nuWpSdoVny-F7QkCMZB6NfPAVmCYDTwV3CXgVLcIqAzdde6l8VPbCHlXdAg$
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!ACWV5N9M2RV99hQ!ayTTZW2_nuWpSdoVny-F7QkCMZB6NfPAVmCYDTwV3CXgVLcIqAzdde6l8VPbCHlXdAg$
