Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Fwd: [Bug 455690] Add support to allow ServerPlatforms to do additional initialization
Andrei -

> I would remove any remnants of lookup_type from JNDIConnector - but we have to be backward compatible).
I considered the approach of removing the jndi lookup type from the JNDIConnector class all together but the compatibly concerns are what scared me away from that approach. The bit that made me change my mind is that JNDIConnector.lookupType is protected there is a slim chance that an extender(of JNDIConnector.. is that really possible?) actually used this field and it isn't be safe to remove. Tell me I'm being overly paranoid and I'll move all of the lookupType stuff into the ServerPlatform... I just don't have enough experience to make the call.

Thanks,
Rick

On Fri, Dec 19, 2014 at 4:10 PM, Andrei Ilitchev <andrei.ilitchev@xxxxxxxxxx> wrote:

Hi Rick,

 

It's hard to imagine JNDIConnector being used by two different ServerPlatforms or SelverPlatform changing - so I don't think there is a real difference.

However logically the whole jndi lookup procedure seem to belong to ServerPlatform (and I would remove any remnants of lookup_type from JNDIConnector - but we have to be backward compatible).

From this perspective I would probably not cache jndi lookup type that comes from ServerPlatform, and also I would not introduce  DEFAULT_LOOKUP_TYPE,

instead base ServerPlatform class would return the default type COMPOSITE_NAME_LOOKUP

 
Thanks,

Andrei

----- Original Message -----
From: curtisr7@xxxxxxxxx
To: eclipselink-dev@xxxxxxxxxxx
Sent: Friday, December 19, 2014 11:48:26 AM GMT -05:00 US/Canada Eastern
Subject: Re: [eclipselink-dev] Fwd: [Bug 455690] Add support to allow ServerPlatforms to do additional initialization

Andrei -

Thanks for the suggestion. I like that approach, but I have one implementation question. When JNDIConnector.connect is called and the lookupType is uninitialized (-1), should I cache the value returned from the ServerPlatform? I'm wondering if there is a scenario where a ServerPlatform instance could change but the JNDIConnector instance doesn't. Perhaps this isn't a valid scenario, but I don't have a deep enough understanding of the runtime to know. See the attached patch for details.

Thanks,
Rick

On Thu, Dec 18, 2014 at 10:36 PM, andrei ilitchev <andrei.ilitchev@xxxxxxxxxx> wrote:
Setting jndi look up type in ServerPlatform constructor is bad because:
- what if we set server platform before connector (which is normally the case - see EntityManagerSetupImpl);
- what if we switch from one server platform to another (say, websphere specified in persistence.xml, but weblogic in puProperties passed to createEMFactory);

Setting lookup type right before session connects would resolve those problems, but we would need to loop through all the connectors (write, read, sequence, possibly custom connection pools).
Still not covered the case of creating custom connector after server session has been created (through entity manager property for an individual entity manager).

My suggestion is to add getJndiLookupType method to ServerPlatform (returning STRING_LOOKUP in ServerPlatformBase).
In JNDIConnector constructor initialize lookupType with UNDEFINED value and in connect method - in case the type is still UNDEFINED - copy lookupType from session.getServerPlatform.getJndiLookupType.

Thanks,
Andrei

On 12/18/2014 5:31 PM, Rick Curtis wrote:
Can I get someone to take a look at my proposed change?

Thanks,
Rick

---------- Forwarded message ----------
From: <bugzilla-daemon@xxxxxxxxxxx>
Date: Thu, Dec 18, 2014 at 4:30 PM
Subject: [Bug 455690] Add support to allow ServerPlatforms to do additional initialization
To: curtisr7@xxxxxxxxx

https://bugs.eclipse.org/bugs/show_bug.cgi?id=455690
Product/Component: EclipseLink / JPA

Rick Curtis <curtisr7@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|eclipselink.orm-inbox@eclip |curtisr7@xxxxxxxxx
                   |se.org                      |

--- Comment #1 from Rick Curtis <curtisr7@xxxxxxxxx> ---
Created attachment 249540
  --> https://bugs.eclipse.org/bugs/attachment.cgi?id=249540&action="">
Attaching proposed change.

--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You reported the bug.
You are watching the assignee of the bug.


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

_______________________________________________
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

Back to the top