[
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 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$
