You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Michael Watzek <mw...@spree.de> on 2005/05/02 16:31:51 UTC
Re: Dependencies between ri11 runtime and r11 query
Hi Craig,
please find my comments inline:
> Hi Michael,
>
> Thanks for this analysis.
>
> On Apr 28, 2005, at 11:16 AM, Michael Watzek wrote:
>
>> Hi,
>>
>> Micheal Bouschen raised the issue to get rid of the compile time
>> dependencies between ri11 runtime and ri11 query. The benefit would be:
>>
>> 1) Runtime and query could be separated into 2 different projects.
>> 2) ri11 runtime could be executed with another query implementation.
>> 3) ri11 query could be executed with another runtime implementation.
>>
>> Below, I summerize what code changes have to be done to achieve issue 2).
>>
>> There are only 2 dependencies from runtime implementation to query
>> implementation:
>>
>> - PersistenceManagerFactoryImpl calls Tree constructor
>> - PersistenceManagerImpl calls QueryImpl constructors
>
>
> What if we move the method newQueryTree from PMFImpl to the FOStorePMF
> class?
>
> Similarly, we can move the nine newQueryXXX methods from PMImpl to
> FOStorePM.
The ri11 implementation does not declare a FOStore specific PM
implementation. Following up your proposal, we would add a new class
FOStorePM extending PMImpl. We would move all newQueryXXX methods to
that class and make PMImpl abstract (removing all all newQueryXXX methods).
We could still keep the QueryFactory approach and move the interface
from Runtime to Query. As an advantage, FOStore would not call
constructors of the query implementation. Instead, it would create a
query factory (using "Class.newInstance") and call the newQueryXXX
methods. Thus, FOStore would not have compile time dependencies to the
query implementation but only to the factory interface. Does this make
sense?
>
> If we break this dependency, we could keep the dependency from Query to
> Runtime. And not implement part 3 as outlined below. I think part 3 is a
> lot of work and still doesn't remove the dependencies.
>
> (The proposal below still requires the Query to know about
> StateManagerInternal, FieldManager, and StoreManager which I guess are
> still defined in Runtime.)
Actually, it is not so much work. I already know all locations in the
query implementation which have to be changed. The change is mostly to
replace the PM instance by a RuntimeContext instance.
However, we'd still have dependencies to FieldManager and StoreManager.
We would not have dependencies to StateManager. The query implementation
needs a StateManager instance to invoke "provideField". The two calls
"PM.findStateManager" and "SM.provideField" can both be implemented in
"RuntimeContext.provideField". For this reason, RuntimeContext would not
declare method "findStateManager" (in contrast to my original proposal)
and thus, would not depend on StateManager.
Changes 2) and 3) will aproximately take a day. Please let me know which
direction to go.
> So the new proposal is to break out ri11 into
>
> core20 (model plus utility): no dependencies
Ok.
> enhancer20: depends on core
Ok.
> runtime20: depends on core
Ok.
> query20: depends on runtime and core
Ok.
> fostore20: depends on core, runtime, and query
Ok.
Thanks,
Michael
>
> Craig
>
>>
>> The proposal is to introduce a new runtime interface QueryFactory
>> which defines methods creating QueryTree instances and Query
>> instances, e.g.
>>
>> public interface QueryFactory
>> {
>> QueryTree createTree();
>> Query createQuery(...);
>> }
>>
>> This interface is implemented by query implementations. The ri11 query
>> implementation calls the Tree and QueryImpl constructors.
>>
>> Additionally, ri11 runtime defines a new PMFInternal property
>> containing the class name of the QueryFactory implementation. The
>> property may be specified by a Properties instance which is passed to
>> JDOHelper.getPersistenceManagerFactory, or it may be set calling a
>> setter on the PMFInternal instance. The PMFInternal instance looks up
>> the implementation class and calls newInstance() in order to create a
>> QueryFactory instance. The class object is kept in an instance
>> variable. The Tree and QueryImpl constructor calls in
>> PersistenceManagerFactoryImpl and PersistenceManagerImpl are replaced
>> by corresponding calls on the QueryFactory instance.
>>
>> Constraints on the QueryFactory implementation class: It must
>> implement a public no argument constructor.
>>
>>
>> Below, I summerize what code changes have to be done to achieve issue 3).
>>
>> The ri11 query implementation does not have references into runtime
>> implementation packages, such as "org.apache.jdo.impl.pm" or
>> "org.apache.jdo.impl.state". However, it has some references into
>> runtime specific interfaces like PersistenceManagerInternal (PMI) and
>> StateManagerInternal (SMI):
>>
>> - PMI.findStateManager(...)
>> - PMI.loadClass(...)
>> - PMI.assertIsOpen()
>> - PMI.getStoreManager()
>> - PMI.getCurrentWrapper()
>> - SMI.provideField(...)
>>
>> Additionally, there is a dependency to the FieldManager interface: As
>> query implementation calls method SMI.provideField(...) having a field
>> manager parameter, it provides an implementation for that interface
>> and passes an instance of that implementation.
>>
>> The proposal is to define a new query interface RuntimeContext
>> defining all of the methods above, e.g.
>>
>> interface RuntimeContext
>> {
>> StateManager findStateManager(PersistenceCapable pc);
>> Class loadClass(String name, ClassLoader given) throws
>> ClassNotFoundException;
>> void assertIsOpen();
>> StoreManager getStoreManager();
>> PersistenceManager getCurrentWrapper();
>> void provideField(int fieldNumber, FieldManager fieldManager,
>> boolean identifying);
>> }
>>
>> This interface is implemented by runtime implementations. A query
>> instance has an instance of this interface which it gets through a
>> parameter of query factory method "createQuery", e.g.
>>
>> QueryFactory.createQuery(..., RuntimeContext context);
>>
>> All calls of the methods above are replaced by corresponding method
>> calls on RuntimeContext instance.
>>
>> Drawbacks of this proposal: It does not eliminate the dependency to
>> the FieldManager interface.
>>
>> Advantages of this proposal: It gathers all runtime calls in an single
>> instance implementing a small API, rather than having calls on 2
>> different instances each of which implements a big API (PMI defines 23
>> methods, SMI defines 33 meethods).
>>
>> Regards,
>> Michael
>> --
>> -------------------------------------------------------------------
>> Michael Watzek Tech@Spree Engineering GmbH
>> mailto:mwa.tech@spree.de Buelowstr. 66
>> Tel.: ++49/30/235 520 36 10783 Berlin - Germany
>> Fax.: ++49/30/217 520 12 http://www.spree.de/
>> -------------------------------------------------------------------
>>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
Re: Dependencies between ri11 runtime and r11 query
Posted by Michael Bouschen <mb...@spree.de>.
Hi Michael,
thanks a lot for the changes! I checked them in and set the issue JDO-36
to fixed.
BTW, I think if you do a 'svn add' on the new files they get included in
the 'svn diff' output.
Regards Michael
> Hi Craig,
>
> I filed a JIRA issue (http://issues.apache.org/jira/browse/JDO-36) on
> the query factory prososal below. That proposal solves issue 2) below.
>
> Attached you find an implementation for that issue which passes the
> ri11 testsuite. I attached four files containing the implementation:
>
> - rio.patch: This file contains the output of "svn diff" executed in
> directory "trunk/ri11". You can apply the patch using "patch -i
> rio.patch -p 0" in the same directory.
>
> - 3 .java files: These files declare new classes
> org.apache.jdo.jdoql.JDOQLQueryFactory,
> org.apache.jdo.impl.jdoql.JDOQLQueryFactoryImpl, and
> org.apache.jdo.impl.fostore.FOStorePM. You *must* copy these into your
> ri11 workspace. Otherwise, the project won't compile!
>
> The reason for the 3 .java files: I'm not familiar with "svn diff" and
> was not able to figure out how I can include new files into the patch.
> If anybody has a solution for this, please let me know.
>
> Regards,
> Michael
>
[...]
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Dependencies between ri11 runtime and r11 query
Posted by Craig Russell <Cr...@Sun.COM>.
Hi Michael,
Nice work!
There are no major issues that I see with the patch. Can you please
make sure that the internal tests as well as the tck tests run with and
without security? And see if Michael can check in the code for you. If
not, let me know and I'll do it.
In PersistenceManagerImpl can you remove the DEBUG flag?
I looked at the rest of the code and it looks good.
Craig
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Dependencies between ri11 runtime and r11 query
Posted by Michael Watzek <mw...@spree.de>.
Hi Craig,
I filed a JIRA issue (http://issues.apache.org/jira/browse/JDO-36) on
the query factory prososal below. That proposal solves issue 2) below.
Attached you find an implementation for that issue which passes the ri11
testsuite. I attached four files containing the implementation:
- rio.patch: This file contains the output of "svn diff" executed in
directory "trunk/ri11". You can apply the patch using "patch -i
rio.patch -p 0" in the same directory.
- 3 .java files: These files declare new classes
org.apache.jdo.jdoql.JDOQLQueryFactory,
org.apache.jdo.impl.jdoql.JDOQLQueryFactoryImpl, and
org.apache.jdo.impl.fostore.FOStorePM. You *must* copy these into your
ri11 workspace. Otherwise, the project won't compile!
The reason for the 3 .java files: I'm not familiar with "svn diff" and
was not able to figure out how I can include new files into the patch.
If anybody has a solution for this, please let me know.
Regards,
Michael
> Hi Michael,
>
> On May 2, 2005, at 7:31 AM, Michael Watzek wrote:
>
>> Hi Craig,
>>
>> please find my comments inline:
>>
>>> Hi Michael,
>>> Thanks for this analysis.
>>> On Apr 28, 2005, at 11:16 AM, Michael Watzek wrote:
>>>
>>>> Hi,
>>>>
>>>> Micheal Bouschen raised the issue to get rid of the compile time
>>>> dependencies between ri11 runtime and ri11 query. The benefit would be:
>>>>
>>>> 1) Runtime and query could be separated into 2 different projects.
>>>> 2) ri11 runtime could be executed with another query implementation.
>>>> 3) ri11 query could be executed with another runtime implementation.
>>>>
>>>> Below, I summerize what code changes have to be done to achieve
>>>> issue 2).
>>>>
>>>> There are only 2 dependencies from runtime implementation to query
>>>> implementation:
>>>>
>>>> - PersistenceManagerFactoryImpl calls Tree constructor
>>>> - PersistenceManagerImpl calls QueryImpl constructors
>>>
>>> What if we move the method newQueryTree from PMFImpl to the
>>> FOStorePMF class?
>>> Similarly, we can move the nine newQueryXXX methods from PMImpl to
>>> FOStorePM.
>>
>> The ri11 implementation does not declare a FOStore specific PM
>> implementation. Following up your proposal, we would add a new class
>> FOStorePM extending PMImpl. We would move all newQueryXXX methods to
>> that class and make PMImpl abstract (removing all all newQueryXXX
>> methods).
>
>
> Right. When I wrote this, I had forgotten that there was no FOStorePM!
> But you have accurately reflected the idea.
>
>>
>> We could still keep the QueryFactory approach and move the interface
>> from Runtime to Query. As an advantage, FOStore would not call
>> constructors of the query implementation. Instead, it would create a
>> query factory (using "Class.newInstance") and call the newQueryXXX
>> methods. Thus, FOStore would not have compile time dependencies to the
>> query implementation but only to the factory interface. Does this make
>> sense?
>
>
> Yes. Go for it.
>
>>
>>> If we break this dependency, we could keep the dependency from Query
>>> to Runtime. And not implement part 3 as outlined below. I think part
>>> 3 is a lot of work and still doesn't remove the dependencies.
>>> (The proposal below still requires the Query to know about
>>> StateManagerInternal, FieldManager, and StoreManager which I guess
>>> are still defined in Runtime.)
>>
>> Actually, it is not so much work. I already know all locations in the
>> query implementation which have to be changed. The change is mostly to
>> replace the PM instance by a RuntimeContext instance.
>>
>> However, we'd still have dependencies to FieldManager and
>> StoreManager. We would not have dependencies to StateManager. The
>> query implementation needs a StateManager instance to invoke
>> "provideField". The two calls "PM.findStateManager" and
>> "SM.provideField" can both be implemented in
>> "RuntimeContext.provideField". For this reason, RuntimeContext would
>> not declare method "findStateManager" (in contrast to my original
>> proposal) and thus, would not depend on StateManager.
>>
>> Changes 2) and 3) will aproximately take a day. Please let me know
>> which direction to go.
>
>
> I expect the changes for 3) will be more difficult and take more time
> for review to make sure we get it right. So I'd like to defer this
> exercise for now.
>
>>> So the new proposal is to break out ri11 into
>>> core20 (model plus utility): no dependencies
>>
>> Ok.
>>
>>> enhancer20: depends on core
>>
>> Ok.
>>
>>> runtime20: depends on core
>>
>> Ok.
>>
>>> query20: depends on runtime and core
>>
>> Ok.
>>
>>> fostore20: depends on core, runtime, and query
>>
>> Ok.
>
>
> So the end result will be the five projects buildable and testable
> against the api11 project library. We will then have a task to migrate
> these projects to depend on api20 instead.
>
> Thanks,
>
> Craig
>
>>
>> Thanks,
>> Michael
>>
>>> Craig
>>>
>>>>
>>>> The proposal is to introduce a new runtime interface QueryFactory
>>>> which defines methods creating QueryTree instances and Query
>>>> instances, e.g.
>>>>
>>>> public interface QueryFactory
>>>> {
>>>> QueryTree createTree();
>>>> Query createQuery(...);
>>>> }
>>>>
>>>> This interface is implemented by query implementations. The ri11
>>>> query implementation calls the Tree and QueryImpl constructors.
>>>>
>>>> Additionally, ri11 runtime defines a new PMFInternal property
>>>> containing the class name of the QueryFactory implementation. The
>>>> property may be specified by a Properties instance which is passed
>>>> to JDOHelper.getPersistenceManagerFactory, or it may be set calling
>>>> a setter on the PMFInternal instance. The PMFInternal instance looks
>>>> up the implementation class and calls newInstance() in order to
>>>> create a QueryFactory instance. The class object is kept in an
>>>> instance variable. The Tree and QueryImpl constructor calls in
>>>> PersistenceManagerFactoryImpl and PersistenceManagerImpl are
>>>> replaced by corresponding calls on the QueryFactory instance.
>>>>
>>>> Constraints on the QueryFactory implementation class: It must
>>>> implement a public no argument constructor.
>>>>
>>>>
>>>> Below, I summerize what code changes have to be done to achieve
>>>> issue 3).
>>>>
>>>> The ri11 query implementation does not have references into runtime
>>>> implementation packages, such as "org.apache.jdo.impl.pm" or
>>>> "org.apache.jdo.impl.state". However, it has some references into
>>>> runtime specific interfaces like PersistenceManagerInternal (PMI)
>>>> and StateManagerInternal (SMI):
>>>>
>>>> - PMI.findStateManager(...)
>>>> - PMI.loadClass(...)
>>>> - PMI.assertIsOpen()
>>>> - PMI.getStoreManager()
>>>> - PMI.getCurrentWrapper()
>>>> - SMI.provideField(...)
>>>>
>>>> Additionally, there is a dependency to the FieldManager interface:
>>>> As query implementation calls method SMI.provideField(...) having a
>>>> field manager parameter, it provides an implementation for that
>>>> interface and passes an instance of that implementation.
>>>>
>>>> The proposal is to define a new query interface RuntimeContext
>>>> defining all of the methods above, e.g.
>>>>
>>>> interface RuntimeContext
>>>> {
>>>> StateManager findStateManager(PersistenceCapable pc);
>>>> Class loadClass(String name, ClassLoader given) throws
>>>> ClassNotFoundException;
>>>> void assertIsOpen();
>>>> StoreManager getStoreManager();
>>>> PersistenceManager getCurrentWrapper();
>>>> void provideField(int fieldNumber, FieldManager fieldManager,
>>>> boolean identifying);
>>>> }
>>>>
>>>> This interface is implemented by runtime implementations. A query
>>>> instance has an instance of this interface which it gets through a
>>>> parameter of query factory method "createQuery", e.g.
>>>>
>>>> QueryFactory.createQuery(..., RuntimeContext context);
>>>>
>>>> All calls of the methods above are replaced by corresponding method
>>>> calls on RuntimeContext instance.
>>>>
>>>> Drawbacks of this proposal: It does not eliminate the dependency to
>>>> the FieldManager interface.
>>>>
>>>> Advantages of this proposal: It gathers all runtime calls in an
>>>> single instance implementing a small API, rather than having calls
>>>> on 2 different instances each of which implements a big API (PMI
>>>> defines 23 methods, SMI defines 33 meethods).
>>>>
>>>> Regards,
>>>> Michael
>>>> --
>>>> -------------------------------------------------------------------
>>>> Michael Watzek Tech@Spree Engineering GmbH
>>>> mailto:mwa.tech@spree.de Buelowstr. 66
>>>> Tel.: ++49/30/235 520 36 10783 Berlin - Germany
>>>> Fax.: ++49/30/217 520 12 http://www.spree.de/
>>>> -------------------------------------------------------------------
>>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>> --
>> -------------------------------------------------------------------
>> Michael Watzek Tech@Spree Engineering GmbH
>> mailto:mwa.tech@spree.de Buelowstr. 66
>> Tel.: ++49/30/235 520 36 10783 Berlin - Germany
>> Fax.: ++49/30/217 520 12 http://www.spree.de/
>> -------------------------------------------------------------------
>>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
Re: Dependencies between ri11 runtime and r11 query
Posted by Craig Russell <Cr...@Sun.COM>.
Hi Michael,
On May 2, 2005, at 7:31 AM, Michael Watzek wrote:
> Hi Craig,
>
> please find my comments inline:
>
>> Hi Michael,
>> Thanks for this analysis.
>> On Apr 28, 2005, at 11:16 AM, Michael Watzek wrote:
>>> Hi,
>>>
>>> Micheal Bouschen raised the issue to get rid of the compile time
>>> dependencies between ri11 runtime and ri11 query. The benefit would
>>> be:
>>>
>>> 1) Runtime and query could be separated into 2 different projects.
>>> 2) ri11 runtime could be executed with another query implementation.
>>> 3) ri11 query could be executed with another runtime implementation.
>>>
>>> Below, I summerize what code changes have to be done to achieve
>>> issue 2).
>>>
>>> There are only 2 dependencies from runtime implementation to query
>>> implementation:
>>>
>>> - PersistenceManagerFactoryImpl calls Tree constructor
>>> - PersistenceManagerImpl calls QueryImpl constructors
>> What if we move the method newQueryTree from PMFImpl to the
>> FOStorePMF class?
>> Similarly, we can move the nine newQueryXXX methods from PMImpl to
>> FOStorePM.
> The ri11 implementation does not declare a FOStore specific PM
> implementation. Following up your proposal, we would add a new class
> FOStorePM extending PMImpl. We would move all newQueryXXX methods to
> that class and make PMImpl abstract (removing all all newQueryXXX
> methods).
Right. When I wrote this, I had forgotten that there was no FOStorePM!
But you have accurately reflected the idea.
>
> We could still keep the QueryFactory approach and move the interface
> from Runtime to Query. As an advantage, FOStore would not call
> constructors of the query implementation. Instead, it would create a
> query factory (using "Class.newInstance") and call the newQueryXXX
> methods. Thus, FOStore would not have compile time dependencies to the
> query implementation but only to the factory interface. Does this make
> sense?
Yes. Go for it.
>
>> If we break this dependency, we could keep the dependency from Query
>> to Runtime. And not implement part 3 as outlined below. I think part
>> 3 is a lot of work and still doesn't remove the dependencies.
>> (The proposal below still requires the Query to know about
>> StateManagerInternal, FieldManager, and StoreManager which I guess
>> are still defined in Runtime.)
> Actually, it is not so much work. I already know all locations in the
> query implementation which have to be changed. The change is mostly to
> replace the PM instance by a RuntimeContext instance.
>
> However, we'd still have dependencies to FieldManager and
> StoreManager. We would not have dependencies to StateManager. The
> query implementation needs a StateManager instance to invoke
> "provideField". The two calls "PM.findStateManager" and
> "SM.provideField" can both be implemented in
> "RuntimeContext.provideField". For this reason, RuntimeContext would
> not declare method "findStateManager" (in contrast to my original
> proposal) and thus, would not depend on StateManager.
>
> Changes 2) and 3) will aproximately take a day. Please let me know
> which direction to go.
I expect the changes for 3) will be more difficult and take more time
for review to make sure we get it right. So I'd like to defer this
exercise for now.
>> So the new proposal is to break out ri11 into
>> core20 (model plus utility): no dependencies
> Ok.
>
>> enhancer20: depends on core
> Ok.
>
>> runtime20: depends on core
> Ok.
>
>> query20: depends on runtime and core
> Ok.
>
>> fostore20: depends on core, runtime, and query
> Ok.
So the end result will be the five projects buildable and testable
against the api11 project library. We will then have a task to migrate
these projects to depend on api20 instead.
Thanks,
Craig
>
> Thanks,
> Michael
>> Craig
>>>
>>> The proposal is to introduce a new runtime interface QueryFactory
>>> which defines methods creating QueryTree instances and Query
>>> instances, e.g.
>>>
>>> public interface QueryFactory
>>> {
>>> QueryTree createTree();
>>> Query createQuery(...);
>>> }
>>>
>>> This interface is implemented by query implementations. The ri11
>>> query implementation calls the Tree and QueryImpl constructors.
>>>
>>> Additionally, ri11 runtime defines a new PMFInternal property
>>> containing the class name of the QueryFactory implementation. The
>>> property may be specified by a Properties instance which is passed
>>> to JDOHelper.getPersistenceManagerFactory, or it may be set calling
>>> a setter on the PMFInternal instance. The PMFInternal instance looks
>>> up the implementation class and calls newInstance() in order to
>>> create a QueryFactory instance. The class object is kept in an
>>> instance variable. The Tree and QueryImpl constructor calls in
>>> PersistenceManagerFactoryImpl and PersistenceManagerImpl are
>>> replaced by corresponding calls on the QueryFactory instance.
>>>
>>> Constraints on the QueryFactory implementation class: It must
>>> implement a public no argument constructor.
>>>
>>>
>>> Below, I summerize what code changes have to be done to achieve
>>> issue 3).
>>>
>>> The ri11 query implementation does not have references into runtime
>>> implementation packages, such as "org.apache.jdo.impl.pm" or
>>> "org.apache.jdo.impl.state". However, it has some references into
>>> runtime specific interfaces like PersistenceManagerInternal (PMI)
>>> and StateManagerInternal (SMI):
>>>
>>> - PMI.findStateManager(...)
>>> - PMI.loadClass(...)
>>> - PMI.assertIsOpen()
>>> - PMI.getStoreManager()
>>> - PMI.getCurrentWrapper()
>>> - SMI.provideField(...)
>>>
>>> Additionally, there is a dependency to the FieldManager interface:
>>> As query implementation calls method SMI.provideField(...) having a
>>> field manager parameter, it provides an implementation for that
>>> interface and passes an instance of that implementation.
>>>
>>> The proposal is to define a new query interface RuntimeContext
>>> defining all of the methods above, e.g.
>>>
>>> interface RuntimeContext
>>> {
>>> StateManager findStateManager(PersistenceCapable pc);
>>> Class loadClass(String name, ClassLoader given) throws
>>> ClassNotFoundException;
>>> void assertIsOpen();
>>> StoreManager getStoreManager();
>>> PersistenceManager getCurrentWrapper();
>>> void provideField(int fieldNumber, FieldManager fieldManager,
>>> boolean identifying);
>>> }
>>>
>>> This interface is implemented by runtime implementations. A query
>>> instance has an instance of this interface which it gets through a
>>> parameter of query factory method "createQuery", e.g.
>>>
>>> QueryFactory.createQuery(..., RuntimeContext context);
>>>
>>> All calls of the methods above are replaced by corresponding method
>>> calls on RuntimeContext instance.
>>>
>>> Drawbacks of this proposal: It does not eliminate the dependency to
>>> the FieldManager interface.
>>>
>>> Advantages of this proposal: It gathers all runtime calls in an
>>> single instance implementing a small API, rather than having calls
>>> on 2 different instances each of which implements a big API (PMI
>>> defines 23 methods, SMI defines 33 meethods).
>>>
>>> Regards,
>>> Michael
>>> --
>>> -------------------------------------------------------------------
>>> Michael Watzek Tech@Spree Engineering GmbH
>>> mailto:mwa.tech@spree.de Buelowstr. 66
>>> Tel.: ++49/30/235 520 36 10783 Berlin - Germany
>>> Fax.: ++49/30/217 520 12 http://www.spree.de/
>>> -------------------------------------------------------------------
>>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>
>
> --
> -------------------------------------------------------------------
> Michael Watzek Tech@Spree Engineering GmbH
> mailto:mwa.tech@spree.de Buelowstr. 66
> Tel.: ++49/30/235 520 36 10783 Berlin - Germany
> Fax.: ++49/30/217 520 12 http://www.spree.de/
> -------------------------------------------------------------------
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!