Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Adding extension points to EclipseLink
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



On Mon, Dec 15, 2014 at 4:36 PM, Rick Curtis <curtisr7@xxxxxxxxx> wrote:
After thinking about this some more over the weekend, I'm going to back away from the patch I posted last week. Rather using jndi names to try to determine what platform we're running on, I'm going to try another approach. I'll try to post a patch tomorrow.

Thanks,
Rick

On Fri, Dec 12, 2014 at 2:33 PM, Rick Curtis <curtisr7@xxxxxxxxx> wrote:
Thanks for the idea, but that feels like more of a work around than a solution. I'd prefer to go the route where we attempt to figure out the platform.

Thanks,
Rick

On Fri, Dec 12, 2014 at 1:56 PM, andrei ilitchev <andrei.ilitchev@xxxxxxxxxx> wrote:
Hi Rick,

I just realized there is a simpler solution - specify target server platform as a system property when starting the app. server.

Thanks,
Andrei


On 12/12/2014 1:45 PM, Rick Curtis wrote:
One more thing, thoughts on logging an INFO message in the event that we detected a target server and it is being used?

On Fri, Dec 12, 2014 at 12:41 PM, Rick Curtis <curtisr7@xxxxxxxxx> wrote:
Andrei -

Thanks for the pointers! I understand trying to avoid polluting core classes with externals. That was the largest concern with the patch I posted. 

I don't know why I didn't look into changing the JNDIConnector in the ServerPlatform. I will update the WebSpherePlatform constructor to change that value. Simple fix.

Attached below you'll find a patch where I add support for detecting the server platform if the target-server property hasn't been specified by a user. You'll notice that this detection only works for WebSphere_7 and WebSphere_liberty as those were the platforms I've tested. Should I blindly add in some of the other app servers, or wait to do that till after someone else confirms this approach works for the other servers?

While this solution isn't the most performant, but I don't know of a better route. That being said, I could cache the value returned from ServerPlatformDetector as that will not change from one invocation to the next.

Let me know what you think. 

Thanks,
Rick



On Fri, Dec 12, 2014 at 8:51 AM, andrei ilitchev <andrei.ilitchev@xxxxxxxxxx> wrote:
I would not alter the original Eclipselink approach (core classes like JNDIConnector have no knowledge of the outside world).
Not that this approach is bad (it is not), but the original approach is not going away - so the fear is confusion arising from mixture of two opposite approaches.

It would be easy to achieve the same with the existing approach.
Currently ServerPlatform defines initializeExternalTransactionController method, which is called before connecting the session (in DatabaseSessionImpl.preConnectdatasource).
It would be easy to define a new method on ServerPlatform (say, ServerPlatform.initialize), which would be called instead and which would do all necessary server-platform specific initialization of the session:
void initialize() {
  initializeExternalTransactionController();
  ...
}

I think that requirement for the users to specify server platform as a pu property could be removed, too:
Eclipselink used to require database platform to be specified, but now allows for db platform auto detection (see DatabaseSessionImpl.loginAndDetectDatasource).
Even without any Eclipselink changes, in case of container managed pu the correct server platform is easy for container (app. server) to set.

Thanks,
Andrei

On 12/11/2014 3:48 PM, Rick Curtis wrote:
All -

Currently I'm working on two problems when running in WebSphere that I need to come up with a solution for. 

1 - When an application uses javax.persistence.Persistence.createEntityManagerFactory(...), they need to specify a WebSphere target server to get transactions (among other things) to work. If they don't specify a target server, the EclipseLink runtime defaults to using the None target server and the app won't interact with our transaction manager. Yes I could require applications to configure eclipselink.target-server, but I would like to remove that requirement.

2 - Again when using javax.persistence.Persistence.createEntityManagerFactory(...) and direct JNDI names, WebSphere users will encounter bug 260383. Numerous places it is suggested to create a SessionCustomizer and then change the JNDIConnector lookup type. While that works, I would also like to remove that requirement. 

Since the changes that I'm looking to make are specific to a single application server, I'd like to add an extension point to EclipseLink so I don't need to pollute the codebase with lots of ibm specific code.

I'd like like to solve this problem by adding something to EclipseLink that would use the service loader mechanism to load a service implementation that would be able to change some of the defaults of various EclipseLink internals. At this point this only changes the values of target-server and the JNDIConnector, but I could see it be useful in other areas. Attached below is a patch of some rough prototyping that I did a few days back. 

Please take a quick browse through it to see if it seems like a reasonable approach. 

Thanks,
Rick

--
Rick Curtis


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev



--
Rick Curtis



--
Rick Curtis


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev



--
Rick Curtis


--
Rick Curtis


--
Rick Curtis

Attachment: platform.detector.v2.patch
Description: Binary data

Back to the top