Rick,
Sorry for joining this conversation late. I do like the idea of detecting the server platform similar to how the database platform is detected. In the case of the database platform we have physical connection details from which we can make a determination. In the case of the server it has been difficult to identify that you are in the container versus on the class path of the container. Its the later case that prevented my earlier work in this area.
In the case of WebLogic the server team did some work to include the server platform if it was not already in the PU properties. That way it was automatically populated for us when we were bootstrapping a container managed EMF.
The situations I believe you need to account for are:
- Avoid incorrectly assuming you are in a container when you are not. In the end I was looking at the acquired initial context to see where EclipseLink is actually being run.
- Do not override a user provided server platform at any time. Some users want to extend a platform or provide their own for specific cases.
- Allow for an EMF to be created within a container where a server platform integration is not wanted - fringe case but does come up occasionally.
I hope this helps,
Doug
Attached below is a prototype patch with a similar(yet lighter weight) approach. With this approach each app server can implement a lightweight detector that makes sense for a given platform. The patch includes a detector that is able to detect both Liberty and Full profile. The code is structured as such to minimize changes to EntityManagerSetupImpl to keep main line code paths the same.
Let me know what you think about this approach.
Thanks, Rick
<platform.detector.v2.patch>_______________________________________________ eclipselink-dev mailing list eclipselink-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
|