Chuck,
> On 22 Aug 2018, at 5:03 AM, Chuck Hill <ch...@gevityinc.com> wrote:
> Assuming that we are looking at the same version of ERXGenericRecord
Probably we are: I have downloaded Wonder-Applications.tar.gz just yesterday,
to replace v6 which I have been using before. The ERExtension framework's
Info.plist says “7.1-SNAPSHOT”. Is there a build # or a build time somewhere in
the frameworks to check?
The main problem was that yesternight, I have been a bit at the sleepy side,
and I have pursued a wrong exception (caused, it seems, by a bug in my catch
block); terribly sorry I have bothered you with that, too :/
What really happens there is that faultWithPrimaryKeyValue — the first time it
is called, which also is the first time the DB is accessed at all — causes the
SEC to initialise, load the shared objects... and then throws
java.lang.IllegalArgumentException: The shared context recently initialized the
object <DBDFList@6418e39e PK:110 Title:'Subsets definition for users'
Id:'SUBSET_DBUser' /EC:30f74e79> which is already registered in this context.
Objects must be unique in both contexts.
(full trace for reference below, caused directly by WO code, alas, so we can't
check the source).
Far as I understand this, I sort of suspect with faultWithPrimaryKeyValue the
following might be what happens:
(i) ERXEC.faultWithPrimaryKeyValue somehow starts with creating a globalID for
entity/PK and registering it itself (even though the ERXEC has a SEC)
(ii) further processing on-demand creates the DB stack, which creates the SEC
yadda yadda...
(iii) ... and SEC dutifully loads the shared objects
(iv) and, the inconsistence betw. a shared object just loaded into SEC and the
registered gid of (i) is found and throws.
To make sure it is not caused by the fact that at the moment of the first
faultWithPrimaryKeyValue the ERXEC has not a SEC yet (for no DB operation has
been performed yet and thus
EODefaultSharedEditingContextWasInitializedNotification did not come yet), I
tried to add
===
if (!ec.sharedEditingContext)
ec.sharedEditingContext=EOSharedEditingContext.defaultSharedEditingContext()
object=EOUtilities.faultWithPrimaryKeyValue(ec,ename,pk)
===
but that did not help. Then, recalling with objectWithPrimaryKeyValue it did
work (but for the superfluous fetch), I have tried
===
if (!ec.sharedEditingContext)
object=EOUtilities.objectWithPrimaryKeyValue(ec,ename,pk)
else
object=EOUtilities.faultWithPrimaryKeyValue(ec,ename,pk)
===
and this did help: the first time, objectWithPrimaryKeyValue is called, causes
the SEC to initialise and load shared EOs without any problem (but for, of
course, the superfluous harmless SELECT being sent to DB). From the time on,
faultWithPrimaryKeyValue is being used, and it works as expected — no fetch,
shared EOs returned directly.
Well work it does, but isn't that a super-ugly contraption? :(
Incidentally, since yesternight I have added awakeFromInsertion logging, I have
found another suspicious thing: for the shared EOs (loaded as a side-effect of
the first objectWithPrimaryKeyValue call) I do not get awakeFromInsertion at
all! (Before I haven't noticed, for I did not log it.) The sharedEC loads all
the shared objects all right, but never awakeFromInsertion comes. Is this the
intended behaviour?
Aside of that, quite unimportant followup:
> the NPE is from here:
>
> EOGlobalID gid =
> editingContext.globalIDForObject(this);
> if (gid.isTemporary()) {
>
> That suggests that editingContext != this.editingContext()
Just before super.awakeFromInsertion, this.EC has been null; that caused the
problem.
> In other words, that the object is registered in an editing context that is
> different from the parameter to the awakeFromInsertion method. Can you check
> what ECs those are? I am not sure how you would get them to be different…
The mess has been caused by a bug in my exception handler, which I have alas
overlooked — before trying faultWithPrimaryKeyValue the handler has never been
used :)
> Also, I see two awakeFromInsertion methods in your code:
> at
> cz.ocs.model.OCSEnterpriseObject.super$4$awakeFromInsertion(OCSEnterpriseObject.groovy)
> and
> at
> cz.ocs.model.OCSEnterpriseObject.awakeFromInsertion(OCSEnterpriseObject.groovy:265)
> // [*]
>
> Or that just an artifact from using Groovy?
Yup, for some reason, the thing inserts its own stub for each supercall.
Thanks and all the best,
OC
Here's the full trace of the real exception:
===
java.lang.IllegalArgumentException: The shared context recently initialized the
object <DBDFList@6418e39e PK:110 Title:'Subsets definition for users'
Id:'SUBSET_DBUser' /EC:30f74e79> which is already registered in this context.
Objects must be unique in both contexts.
at
com.webobjects.eocontrol.EOEditingContext._processInitializedObjectsInSharedContext(EOEditingContext.java:2602)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at com.webobjects.foundation.NSSelector.invoke(NSSelector.java:358)
at
com.webobjects.foundation.NSSelector._safeInvokeSelector(NSSelector.java:110)
at
com.webobjects.eocontrol.EOEditingContext._sendOrEnqueueNotification(EOEditingContext.java:4715)
at
com.webobjects.eocontrol.EOEditingContext._objectsInitializedInSharedContext(EOEditingContext.java:2589)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
com.webobjects.foundation.NSSelector._safeInvokeMethod(NSSelector.java:122)
at
com.webobjects.foundation.NSNotificationCenter$_Entry.invokeMethod(NSNotificationCenter.java:588)
at
com.webobjects.foundation.NSNotificationCenter.postNotification(NSNotificationCenter.java:532)
at
com.webobjects.foundation.NSNotificationCenter.postNotification(NSNotificationCenter.java:562)
at
com.webobjects.eocontrol.EOSharedEditingContext._processRecentChanges(EOSharedEditingContext.java:569)
at
com.webobjects.eocontrol.EOEditingContext.processRecentChanges(EOEditingContext.java:1969)
at
com.webobjects.eocontrol.EOSharedEditingContext.unlock(EOSharedEditingContext.java:781)
at
com.webobjects.eocontrol.EOEditingContext.unlockObjectStore(EOEditingContext.java:4686)
at er.extensions.eof.ERXEC.unlockObjectStore(ERXEC.java:805)
at
com.webobjects.eocontrol.EOEditingContext.faultForGlobalID(EOEditingContext.java:3626)
at er.extensions.eof.ERXEC.faultForGlobalID(ERXEC.java:1210)
at
com.webobjects.eoaccess.EOUtilities.faultWithPrimaryKey(EOUtilities.java:407)
at
com.webobjects.eoaccess.EOUtilities.faultWithPrimaryKeyValue(EOUtilities.java:388)
at
com.webobjects.eoaccess.EOUtilities$faultWithPrimaryKeyValue.call(Unknown
Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:144)
at
cz.ocs.model.OCSEnterpriseObject.staticEOSVM(OCSEnterpriseObject.groovy:154) //
faultWithPrimaryKeyValue called
===
>
> From: "ocs@ocs" <o...@ocs.cz <mailto:o...@ocs.cz>>
> Date: Tuesday, August 21, 2018 at 7:05 PM
> To: Chuck Hill <ch...@gevityinc.com <mailto:ch...@gevityinc.com>>
> Cc: "webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>"
> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>>
> Subject: Re: Should loading a shared object try to fetch? (was: Should ERXEC
> get sharedEC automagically?)
>
> Chuck,
>
> thanks again! I did not know that (well one could write a much bigger book
> than you did with just those things I do not know...)
>
> Nevertheless, there still must be some ugly fault of mine. When using
> objectWithPrimaryKeyValue, there's the superfluous fetch, but it works.
>
> When replaced by faultWithPrimaryKeyValue, I keep getting NPEs somewhere
> inside of awakeFromInsertion — at the moment, I can't really make sense of it
> :( It looks like this:
>
> ===
> == about to load 110 from 348ad293 (SEC ) // first time, there's yet no SEC...
> 4105 [main] DEBUG NSLog - Using JDBCPlugIn
> 'com.webobjects.jdbcadaptor.FrontbasePlugIn' for JDBCAdaptor@2076611420
> ... and it is being initialised here; it fetches properly all the shared EOs
> ...
> 4110 [main] DEBUG NSLog - connecting with dictionary: {username = "";
> password = "<password deleted for log>"; URL =
> "jdbc:FrontBase://localhost/SBERDAT3/user=FINServis/isolation=read_committed/locking=optimistic
>
> <frontbase://localhost/SBERDAT3/user=FINServis/isolation=read_committed/locking=optimistic>";
> }
> ... ... ... the proper SQL to load all the shared objects here ... ... ...
> 4235 [main] DEBUG NSLog - === Commit Internal Transaction
> ... and here's a problem; my overridden awakeFromInsertion logs this just
> before a super.awakeFromInsertion:
> awakeFromInsertion: <DBDFList@709f0202 PK: N NULL-EC> in
> er.extensions.eof.ERXEC@348ad293
> ... and a log _after_ super does not happen; instead, I get this:
> java.lang.Exception:
> ... ... ...
> Caused by: java.lang.NullPointerException
> at
> er.extensions.eof.ERXGenericRecord.awakeFromInsertion(ERXGenericRecord.java:512)
> at
> cz.ocs.model.OCSEnterpriseObject.super$4$awakeFromInsertion(OCSEnterpriseObject.groovy)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
> ... groovy stuff here ...
> at
> cz.ocs.model.OCSEnterpriseObject.awakeFromInsertion(OCSEnterpriseObject.groovy:265)
> // [*]
> at
> com.webobjects.eocontrol.EOEditingContext.insertObjectWithGlobalID(EOEditingContext.java:2871)
> at er.extensions.eof.ERXEC.insertObjectWithGlobalID(ERXEC.java:975)
> at er.extensions.eof.ERXEC$insertObjectWithGlobalID$0.call(Unknown Source)
> ... groovy stuff here ...
> at
> cz.ocs.model.OCSEnterpriseObject.staticEOSVM(OCSEnterpriseObject.groovy:164)
> // the faultWith... here
> ===
>
> The awake code looks simply like this:
>
> ===
> void awakeFromInsertion(EOEditingContext ec) {
> println "awakeFromInsertion: ${this} in ${ec}" // this one happens before the
> NPE
> super.awakeFromInsertion(ec) // [*]
> println "supered awakeFromInsertion: ${this} in ${ec}" // we do not get this
> far
> ... ... ...
> ===
>
> Alas, at the moment I have no idea at all what in my code might be the
> culprit :(
>
> Thanks and all the best,
> OC
>
>
> On 22 Aug 2018, at 3:14 AM, Chuck Hill <ch...@gevityinc.com
> <mailto:ch...@gevityinc.com>> wrote:
>
> Yes, that makes complete sense. EOUtilities.objectWithPrimaryKeyValue is
> documented to “Fetches the Enterprise Object identified by the specified
> primary key value”. It will fetch. Always. It might not use the fetched
> result, but you asked it to fetch so it will. The method you want is
> faultWithPrimaryKeyValue. That will either resolve the object reference from
> an EO already in the EC, in the shared EC, or in the snapshot cache. If all
> of those fail, only then will it fetch.
>
> And yes, the JavaDocs for faultWithPrimaryKeyValue are wrong (copied from
> objectWithPrimaryKeyValue).
>
>
> Chuck
>
>
> From: "ocs@ocs" <o...@ocs.cz <mailto:o...@ocs.cz>>
> Date: Tuesday, August 21, 2018 at 5:15 PM
> To: Chuck Hill <ch...@gevityinc.com <mailto:ch...@gevityinc.com>>
> Cc: "webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>"
> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>>
> Subject: Should loading a shared object try to fetch? (was: Should ERXEC get
> sharedEC automagically?)
>
> Even without ERXObjectStoreCoordinatorPool, there's another strange
> behaviour. I happen to be loading my objects (many of which happen to be in
> the SEC) using “EOUtilities.objectWithPrimaryKeyValue”.
>
> If the object happens to be in the SEC, I get it all right, but when I switch
> on SQL log, it looks like it is fetched anyway?!? I.e., something like this:
>
> ===
> println "== about to load $pk from $ec.identityHashString (SEC
> $ec.sharedEditingContext.identityHashString)"
> def foo=ec.sharedEditingContext.objectsByEntityName[ename].find {
> it.rawPrimaryKey==pk }
> if (foo!=nil) println " it IS pre-loaded in SEC: $foo"
> //object=EOUtilities.objectWithPrimaryKeyValue(ec,ename,pk)
>
> object=ERXEOControlUtilities.objectWithPrimaryKeyValue(ec,ename,pk,NSArray.EmptyArray,NO,NO)
> println " got $object"
> ===
>
> logs out something like
>
> ===
> == about to load 101 from 25673087 (SEC a7cf42f)
> it IS pre-loaded in SEC: <DBDFList@3a4aadf8 PK:101 SEC:a7cf42f>
> 4663 [main] DEBUG NSLog - === Begin Internal Transaction
> 4663 [main] DEBUG NSLog - evaluateExpression:
> <com.webobjects.jdbcadaptor.FrontbasePlugIn$FrontbaseExpression: "SELECT
> t0."C_DESCRIPTION", t0."C_CREATION_DATE", t0."C_CREATOR_ID",
> t0."C_IDENTIFIER", t0."C_CONTENT_DATA", t0."C_MODIFICATION_DATE",
> t0."C_TITLE", t0."C_UID" FROM "T_DF_LIST" t0 WHERE t0."C_UID" = 101"
> withBindings: >
> 4664 [main] DEBUG NSLog - 1 row(s) processed
> 4665 [main] DEBUG NSLog - === Commit Internal Transaction
> got <DBDFList@3a4aadf8 PK:101 SEC:a7cf42f>
> ===
>
> Happens even with a
> “ERXEOControlUtilities.objectWithPrimaryKeyValue(...,NSArray.EmptyArray,false,false)”
> instead.
>
> Does it make any sense? I would presume that with the desired object in the
> SEC, no database roundtrip should be needed (and done) at all?
>
> Thanks and all the best,
> OC
>
>
>
> On 21 Aug 2018, at 10:02 PM, ocs@ocs <o...@ocs.cz <mailto:o...@ocs.cz>> wrote:
>
> Indeed! If I switch off the OSCPool, it starts to work properly.
>
> Thanks just again!
>
> Nevertheless, I still must be missing something of grave importance, for with
> OCSPool (I use ), I would presume the SEC for the pool being currently used
> by the ERXEC would load the shared objects?
>
> It does not: the global one does automatically load the shared objects, but
> the SEC-based one of ERXEC remains empty.
>
> Note: the code in question does not run in a session context; it is performed
> at launch, before the first session is created. Might that be important
> perhaps?
>
> All the best,
> OC
>
>
>
>
> On 21 Aug 2018, at 9:42 PM, Chuck Hill <ch...@gevityinc.com
> <mailto:ch...@gevityinc.com>> wrote:
>
> Are you using the ERXObjectStoreCoordinatorPool? It keeps one SEC per pool,
> not one shared globally.
> EOSharedEditingContext.defaultSharedEditingContext() is the global one.
>
> Chuck
>
> From: "ocs@ocs" <o...@ocs.cz <mailto:o...@ocs.cz>>
> Date: Tuesday, August 21, 2018 at 12:23 PM
> To: Chuck Hill <ch...@gevityinc.com <mailto:ch...@gevityinc.com>>
> Cc: "webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>"
> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>>
> Subject: Re: Should ERXEC get sharedEC automagically?
>
> P.S. It seems ERX completely ignores the default shared EC, using its own
> one. If I try e.g., this:
>
> ===
> println "The default sharedEC is
> ${EOSharedEditingContext.defaultSharedEditingContext()}"
> 6.times {
> def e=ERXEC.newEditingContext()
> println "EC $e gets sec $e.sharedEditingContext"
> }
> println "The default sharedEC still is
> ${EOSharedEditingContext.defaultSharedEditingContext()}"
> ===
>
> it looks like this:
>
> ===
> The default sharedEC is
> com.webobjects.eocontrol.EOSharedEditingContext@26bbe604
> 2005 [main] INFO er.extensions.eof.ERXObjectStoreCoordinatorPool -
> initializing Pool...
> 2008 [main] INFO er.extensions.eof.ERXObjectStoreCoordinatorPool -
> initializing Pool finished
> EC er.extensions.eof.ERXEC@40e32762 gets sec
> com.webobjects.eocontrol.EOSharedEditingContext@5875de6a
> EC er.extensions.eof.ERXEC@7d78f3d5 gets sec
> com.webobjects.eocontrol.EOSharedEditingContext@5875de6a
> EC er.extensions.eof.ERXEC@f5b6e78 gets sec
> com.webobjects.eocontrol.EOSharedEditingContext@5875de6a
> EC er.extensions.eof.ERXEC@71926a36 gets sec
> com.webobjects.eocontrol.EOSharedEditingContext@5875de6a
> EC er.extensions.eof.ERXEC@48976e6d gets sec
> com.webobjects.eocontrol.EOSharedEditingContext@5875de6a
> EC er.extensions.eof.ERXEC@7f6874f2 gets sec
> com.webobjects.eocontrol.EOSharedEditingContext@5875de6a
> The default sharedEC still is
> com.webobjects.eocontrol.EOSharedEditingContext@26bbe604
> ===
>
> Thanks and all the best,
> OC
>
>
>
>
> On 21 Aug 2018, at 9:07 PM, ocs@ocs <o...@ocs.cz <mailto:o...@ocs.cz>> wrote:
>
> Chuck,
>
> sorry, I did not describe the problem clearly enough...
>
>
>
>
> On 21 Aug 2018, at 8:39 PM, Chuck Hill <ch...@gevityinc.com
> <mailto:ch...@gevityinc.com>> wrote:
> Once an EC has objects in it, its shared EC won’t get changed if a new
> default is set. The notification is ignored.
>
> Quite, but that's not the problem.
>
> With EOEditingContext, it works like this:
>
> (i) ec created, has no sharedEC (ec.sharedEditingContext==null)
> (ii) (due to something which creates a DBContext, I believe) the default
> sharedEC is initialized; it loads the shared objects, and sends the
> notification
> (iii) ec observes the notification, and sets the default sharedEC as its own
> sharedEC (for it is still empty)
> (iv) now, ec fetches the objects — automatically giving shared ones from its
> sharedEC, which does contain them
>
> With ERXEC (and ERXEC.useSharedEditingContext=true), there's an important
> difference:
>
> (i) erxec created, immediately gets a sharedEC
> (ec.sharedEditingContext!=null). This sharedEC differs from the default
> shared EC
> (ii) (due to something which creates a DBContext, I believe) the default
> sharedEC is initialized; it loads the shared objects, and sends the
> notification
> (iii) erxec (although still empty) does nothing, it already has a sharedEC,
> different from the default one
> (iv) now, erxec fetches the objects — would automatically give shared ones
> from its sharedEC, which, alas, contains nothing (the default one does).
>
> Thanks and all the best,
> OC
>
>
>
>
>
>
> From: "ocs@ocs" <o...@ocs.cz <mailto:o...@ocs.cz>>
> Date: Tuesday, August 21, 2018 at 11:21 AM
> To: Chuck Hill <ch...@gevityinc.com <mailto:ch...@gevityinc.com>>
> Cc: "webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>"
> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>>
> Subject: Re: Should ERXEC get sharedEC automagically?
>
> Chuck,
>
>
>
>
>
> On 21 Aug 2018, at 7:50 PM, Chuck Hill <ch...@gevityinc.com
> <mailto:ch...@gevityinc.com>> wrote:
>
> See er.extensions.ERXEC.useSharedEditingContext at
> https://wiki.wocommunity.org/display/documentation/Explanation+of+the+default+properties+in+a+Wonder+project
>
> <https://wiki.wocommunity.org/display/documentation/Explanation+of+the+default+properties+in+a+Wonder+project>
>
> Thanks a lot!
>
> (Why on earth don't they mention this on the ERXEC documentation page? Oh,
> never mind.)
>
>
>
>
>
> Did that fix it?
>
> Well, sort of.
>
> It gets curiouser and curiouser — in other words, I must be doing something
> far wrong.
>
> When I set the “ERXEC.useSharedEditingContext” property to true, then
>
> - the newly created ERXEC gets a shared editing context immediately upon
> creation, not later upon receiving
> DefaultSharedEditingContextWasInitializedNotification;
> - and it is a different shared EC instance, not
> EOSharedEditingContext.defaultSharedEditingContext()
> - but it is EOSharedEditingContext.defaultSharedEditingContext() who reads in
> automatically all the shared EOs
> - and therefore, when fetching EOs through the ERXEC, I am still getting
> non-shared ones in the ERXEC (for its own sharedEC is empty, and thus
> EOSharedEditingContext.defaultSharedEditingContext is ignored).
>
> Can you make any sense of that?
>
> Thanks again a very big lot,
> OC
>
>
>
>
>
>
>
> On 2018-08-21, 9:43 AM, "Webobjects-dev on behalf of ocs@ocs"
> <webobjects-dev-bounces+chill=gevityinc....@lists.apple.com
> <mailto:webobjects-dev-bounces+chill=gevityinc....@lists.apple.com> on behalf
> of o...@ocs.cz <mailto:o...@ocs.cz>> wrote:
>
> Hi there,
>
> the EOEditing context doc pretty unequivocally says
>
> ===
> By default, an editing context that has no shared editing context listens
> for DefaultSharedEditingContextWasInitializedNotifications. If a notification
> is posted while the context has no registered objects, the editing context
> sets its shared editing context to the newly initialized default shared
> editing context.
> ===
>
> Should it apply for an ERXEC, too? I sort of inferred it would, but by my
> testing, it does not seem so: an ERXEC I make (through
> ERXEC.newEditingContext()) seems to adamantly stay without
> sharedEditingContext, although the notification is posted all right (I have
> observed it myself to be sure), and if there's a good ole EOEditingContext,
> it indeed duly sets its sharedEC at the time.
>
> Have I missed something of importance somewhere? The ERXEC documentation
> does not say essentially anything of the sharedEC, far as I can say:
>
> http://wonder.sourceforge.net/javadoc/er/extensions/ERXEC.html
> <http://wonder.sourceforge.net/javadoc/er/extensions/ERXEC.html>
>
> In principle, I could work around the problem by setting the sharedEC to
> all my ERXECs programmatically -- that works all right --, but it would be a
> lot of work, with a danger I overlook something somewhere and got bit in the
> tender parts by that...
>
> Thanks,
> OC
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com
> <mailto:Webobjects-dev@lists.apple.com>)
> Help/Unsubscribe/Update your Subscription:
>
> https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com
> <https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com>
>
> This email sent to ch...@gevityinc.com <mailto:ch...@gevityinc.com>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com
> <mailto:Webobjects-dev@lists.apple.com>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz
> <https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz>
>
> This email sent to o...@ocs.cz <mailto:o...@ocs.cz>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com
> <mailto:Webobjects-dev@lists.apple.com>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz
> <https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz>
>
> This email sent to o...@ocs.cz <mailto:o...@ocs.cz>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
