[Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?

Mariano Martinez Peck
Hi guys,

If I understand correctly, I can, for example, print to transcript from a seaside callback. If I have a GemTools connected, then I am supposed to see the string in the transcript, right? 
First..can I confirm that this only work if the both seaside and gemtools are running with the same gem?   If not...how does the GemTool gets notified?  I know you use exception mechanism for this so maybe it is related. 

Finally, and this is my real question...I have gems running seaside in which I have some buttons to ease development. These buttons send #inspect or #explore to some objects in seaside callbacks. When I do that (having a GemTools connected to the same GemStone), I get this error:

-----------

Internal Server Error:

a TransactionError occurred (error 2407), The object aSessionTemps( #'GsHostRandomFile'->aGsFile, #'GRGemStoneRandomProvider_MUTEX'->aTransientMutex, #'SystemChangeNotifier_UniqueInstance'->aSystemChangeNotifier, #'GsPackage_TransactionBoundary_Dict'->aSessionTemps( #'SessionMethodChange'->1614, #'ClassChange'->6791), #'Cached_Class_Organizer'->aCachingClassOrganizer, #'GRGemStoneRandomProvider_GENERATOR'->aHostRandom, #'GemToGemStaticException'->aGsExceptionHandler, #'GsPackagePolicy_SessionMethodDictionary'->anIdentitySet( Array, Association, Behavior, Boolean, Character, Class, Collection, Integer, Magnitude, ObsoleteMetaclass, Number, Object, PositionableStream, ReadStream, SequenceableCollection, SmallInteger, Stream, String, UndefinedObject, ...), ...) may not be committed, 'instances of its class are non-persistent'

You should contact the system administrator

-------------


So I guess this is expected right? there is no workaround? 



--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?

Dale Henrichs-3



From: "Mariano Martinez Peck" <[hidden email]>
To: [hidden email]
Sent: Tuesday, December 17, 2013 11:59:09 AM
Subject: [Glass] Is it possible to explore/inspect objects from seaside        callbacks in GemTools?

Hi guys,

If I understand correctly, I can, for example, print to transcript from a seaside callback. If I have a GemTools connected, then I am supposed to see the string in the transcript, right?
Yes
 
First..can I confirm that this only work if the both seaside and gemtools are running with the same gem?
If you are running Seaside from the gemtools gem, then the transcript output goes to the client gem's Transcript window ... the window should be open before you log into GemTools.

If you are running Seaside in a topaz process not connected to GemTools then the Transcript output is routed to the gem log ...

In both cases the Transcript output is put into the ObjectLog ... you can view the Object Log from a web browser by registering the object log application:

 WAAdmin
    register: WAObjectLog
    asApplicationAt: WAObjectLog entryPointName
    user: ''admin'' password: ''tool''.

or inspect it the object log ...


  If not...how does the GemTool gets notified?  I know you use exception mechanism for this so maybe it is related. 

Finally, and this is my real question...I have gems running seaside in which I have some buttons to ease development. These buttons send #inspect or #explore to some objects in seaside callbacks. When I do that (having a GemTools connected to the same GemStone), I get this error:
I've got to eat lunch, so I'll save my reply for after lunch:)

-----------

Internal Server Error:

a TransactionError occurred (error 2407), The object aSessionTemps( #'GsHostRandomFile'->aGsFile, #'GRGemStoneRandomProvider_MUTEX'->aTransientMutex, #'SystemChangeNotifier_UniqueInstance'->aSystemChangeNotifier, #'GsPackage_TransactionBoundary_Dict'->aSessionTemps( #'SessionMethodChange'->1614, #'ClassChange'->6791), #'Cached_Class_Organizer'->aCachingClassOrganizer, #'GRGemStoneRandomProvider_GENERATOR'->aHostRandom, #'GemToGemStaticException'->aGsExceptionHandler, #'GsPackagePolicy_SessionMethodDictionary'->anIdentitySet( Array, Association, Behavior, Boolean, Character, Class, Collection, Integer, Magnitude, ObsoleteMetaclass, Number, Object, PositionableStream, ReadStream, SequenceableCollection, SmallInteger, Stream, String, UndefinedObject, ...), ...) may not be committed, 'instances of its class are non-persistent'

You should contact the system administrator

-------------


So I guess this is expected right? there is no workaround? 



--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?

Dale Henrichs-3
In reply to this post by Mariano Martinez Peck



From: "Mariano Martinez Peck" <[hidden email]>
To: [hidden email]
Sent: Tuesday, December 17, 2013 11:59:09 AM
Subject: [Glass] Is it possible to explore/inspect objects from seaside        callbacks in GemTools?

.....
Finally, and this is my real question...I have gems running seaside in which I have some buttons to ease development. These buttons send #inspect or #explore to some objects in seaside callbacks. When I do that (having a GemTools connected to the same GemStone), I get this error:

-----------

Internal Server Error:

a TransactionError occurred (error 2407), The object aSessionTemps( #'GsHostRandomFile'->aGsFile, #'GRGemStoneRandomProvider_MUTEX'->aTransientMutex, #'SystemChangeNotifier_UniqueInstance'->aSystemChangeNotifier, #'GsPackage_TransactionBoundary_Dict'->aSessionTemps( #'SessionMethodChange'->1614, #'ClassChange'->6791), #'Cached_Class_Organizer'->aCachingClassOrganizer, #'GRGemStoneRandomProvider_GENERATOR'->aHostRandom, #'GemToGemStaticException'->aGsExceptionHandler, #'GsPackagePolicy_SessionMethodDictionary'->anIdentitySet( Array, Association, Behavior, Boolean, Character, Class, Collection, Integer, Magnitude, ObsoleteMetaclass, Number, Object, PositionableStream, ReadStream, SequenceableCollection, SmallInteger, Stream, String, UndefinedObject, ...), ...) may not be committed, 'instances of its class are non-persistent'

You should contact the system administrator

-------------


So I guess this is expected right? there is no workaround? 

I'm not surprised that you are getting an error ... presumably we're trying to dump the stack into the object log and it has some references to the SessionTemps ... since there is no head inspect/explore aren't going to bring up an inspector, however, it wouldn't be a bad idea to go ahead and change inspect/explore to drop off the object into the ObjectLog ... it is possible to tell if GemTools is connected, if `OBGemStonePlatform canInform` answers true GemTools is running ...

Dale



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?

Mariano Martinez Peck



On Tue, Dec 17, 2013 at 7:22 PM, Dale K. Henrichs <[hidden email]> wrote:



From: "Mariano Martinez Peck" <[hidden email]>
To: [hidden email]
Sent: Tuesday, December 17, 2013 11:59:09 AM
Subject: [Glass] Is it possible to explore/inspect objects from seaside        callbacks in GemTools?

.....

Finally, and this is my real question...I have gems running seaside in which I have some buttons to ease development. These buttons send #inspect or #explore to some objects in seaside callbacks. When I do that (having a GemTools connected to the same GemStone), I get this error:

-----------

Internal Server Error:

a TransactionError occurred (error 2407), The object aSessionTemps( #'GsHostRandomFile'->aGsFile, #'GRGemStoneRandomProvider_MUTEX'->aTransientMutex, #'SystemChangeNotifier_UniqueInstance'->aSystemChangeNotifier, #'GsPackage_TransactionBoundary_Dict'->aSessionTemps( #'SessionMethodChange'->1614, #'ClassChange'->6791), #'Cached_Class_Organizer'->aCachingClassOrganizer, #'GRGemStoneRandomProvider_GENERATOR'->aHostRandom, #'GemToGemStaticException'->aGsExceptionHandler, #'GsPackagePolicy_SessionMethodDictionary'->anIdentitySet( Array, Association, Behavior, Boolean, Character, Class, Collection, Integer, Magnitude, ObsoleteMetaclass, Number, Object, PositionableStream, ReadStream, SequenceableCollection, SmallInteger, Stream, String, UndefinedObject, ...), ...) may not be committed, 'instances of its class are non-persistent'

You should contact the system administrator

-------------


So I guess this is expected right? there is no workaround? 

I'm not surprised that you are getting an error ... presumably we're trying to dump the stack into the object log and it has some references to the SessionTemps ... since there is no head inspect/explore aren't going to bring up an inspector, however, it wouldn't be a bad idea to go ahead and change inspect/explore to drop off the object into the ObjectLog ...

Yes, I was thinking about that too. 
 
it is possible to tell if GemTools is connected, if `OBGemStonePlatform canInform` answers true GemTools is running ...


And do you think it is possible to avoid dumping the stack in the object log for the case of inspect/explore? because if true, we can check if GemTools is running, if true, we might be able to open a real inspector/explorer in GemTools and otherwise (or in addition) write the object to the object log? 

Thanks!

 
Dale





--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?

Dale Henrichs-3



From: "Mariano Martinez Peck" <[hidden email]>
To: "Dale K. Henrichs" <[hidden email]>
Cc: [hidden email]
Sent: Wednesday, December 18, 2013 6:20:50 AM
Subject: Re: [Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?




On Tue, Dec 17, 2013 at 7:22 PM, Dale K. Henrichs <[hidden email]> wrote:



From: "Mariano Martinez Peck" <[hidden email]>
To: [hidden email]
Sent: Tuesday, December 17, 2013 11:59:09 AM
Subject: [Glass] Is it possible to explore/inspect objects from seaside        callbacks in GemTools?

.....

Finally, and this is my real question...I have gems running seaside in which I have some buttons to ease development. These buttons send #inspect or #explore to some objects in seaside callbacks. When I do that (having a GemTools connected to the same GemStone), I get this error:

-----------

Internal Server Error:

a TransactionError occurred (error 2407), The object aSessionTemps( #'GsHostRandomFile'->aGsFile, #'GRGemStoneRandomProvider_MUTEX'->aTransientMutex, #'SystemChangeNotifier_UniqueInstance'->aSystemChangeNotifier, #'GsPackage_TransactionBoundary_Dict'->aSessionTemps( #'SessionMethodChange'->1614, #'ClassChange'->6791), #'Cached_Class_Organizer'->aCachingClassOrganizer, #'GRGemStoneRandomProvider_GENERATOR'->aHostRandom, #'GemToGemStaticException'->aGsExceptionHandler, #'GsPackagePolicy_SessionMethodDictionary'->anIdentitySet( Array, Association, Behavior, Boolean, Character, Class, Collection, Integer, Magnitude, ObsoleteMetaclass, Number, Object, PositionableStream, ReadStream, SequenceableCollection, SmallInteger, Stream, String, UndefinedObject, ...), ...) may not be committed, 'instances of its class are non-persistent'

You should contact the system administrator

-------------


So I guess this is expected right? there is no workaround? 

I'm not surprised that you are getting an error ... presumably we're trying to dump the stack into the object log and it has some references to the SessionTemps ... since there is no head inspect/explore aren't going to bring up an inspector, however, it wouldn't be a bad idea to go ahead and change inspect/explore to drop off the object into the ObjectLog ...

Yes, I was thinking about that too. 
 
it is possible to tell if GemTools is connected, if `OBGemStonePlatform canInform` answers true GemTools is running ...


And do you think it is possible to avoid dumping the stack in the object log for the case of inspect/explore? because if true, we can check if GemTools is running, if true, we might be able to open a real inspector/explorer in GemTools and otherwise (or in addition) write the object to the object log?

Exactly what I was thinking ... if GemTools (or Tode) is not present, drop the object into the object log for later ...

Dale

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?

Mariano Martinez Peck



On Wed, Dec 18, 2013 at 12:07 PM, Dale K. Henrichs <[hidden email]> wrote:



From: "Mariano Martinez Peck" <[hidden email]>
To: "Dale K. Henrichs" <[hidden email]>
Cc: [hidden email]
Sent: Wednesday, December 18, 2013 6:20:50 AM
Subject: Re: [Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?





On Tue, Dec 17, 2013 at 7:22 PM, Dale K. Henrichs <[hidden email]> wrote:



From: "Mariano Martinez Peck" <[hidden email]>
To: [hidden email]
Sent: Tuesday, December 17, 2013 11:59:09 AM
Subject: [Glass] Is it possible to explore/inspect objects from seaside        callbacks in GemTools?

.....

Finally, and this is my real question...I have gems running seaside in which I have some buttons to ease development. These buttons send #inspect or #explore to some objects in seaside callbacks. When I do that (having a GemTools connected to the same GemStone), I get this error:

-----------

Internal Server Error:

a TransactionError occurred (error 2407), The object aSessionTemps( #'GsHostRandomFile'->aGsFile, #'GRGemStoneRandomProvider_MUTEX'->aTransientMutex, #'SystemChangeNotifier_UniqueInstance'->aSystemChangeNotifier, #'GsPackage_TransactionBoundary_Dict'->aSessionTemps( #'SessionMethodChange'->1614, #'ClassChange'->6791), #'Cached_Class_Organizer'->aCachingClassOrganizer, #'GRGemStoneRandomProvider_GENERATOR'->aHostRandom, #'GemToGemStaticException'->aGsExceptionHandler, #'GsPackagePolicy_SessionMethodDictionary'->anIdentitySet( Array, Association, Behavior, Boolean, Character, Class, Collection, Integer, Magnitude, ObsoleteMetaclass, Number, Object, PositionableStream, ReadStream, SequenceableCollection, SmallInteger, Stream, String, UndefinedObject, ...), ...) may not be committed, 'instances of its class are non-persistent'

You should contact the system administrator

-------------


So I guess this is expected right? there is no workaround? 

I'm not surprised that you are getting an error ... presumably we're trying to dump the stack into the object log and it has some references to the SessionTemps ... since there is no head inspect/explore aren't going to bring up an inspector, however, it wouldn't be a bad idea to go ahead and change inspect/explore to drop off the object into the ObjectLog ...

Yes, I was thinking about that too. 
 
it is possible to tell if GemTools is connected, if `OBGemStonePlatform canInform` answers true GemTools is running ...


And do you think it is possible to avoid dumping the stack in the object log for the case of inspect/explore? because if true, we can check if GemTools is running, if true, we might be able to open a real inspector/explorer in GemTools and otherwise (or in addition) write the object to the object log?

Exactly what I was thinking ... if GemTools (or Tode) is not present, drop the object into the object log for later ...


We are in sync then :)


--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?

Dale Henrichs-3
In reply to this post by Mariano Martinez Peck
Mariano,  et. al.,

I've just fixed this bug[1] in the glassdbglass repository[4] and I thought it was worth talking a bit about how I see the GLASS repo being used moving forward.

I intend to continuously release bugfixes into the glass repository. I do development on the dev branch until the tests are green[2] (note that the tests cover 4 different versions of GemStone: 2.4.5.2, 3.0.1, 3.1.0.6 and 3.2) and then I do a merge onto the master branch.

The best way for you to use the glass repo is to first fork[3] the repository to your github user account and make a local clone of the repository. When you are at a good point to pick up the latest glass code, you will merge the master branch on glassdb into a branch in your local repository and verify that your application works with the new version of glass. If it does, you can then follow your procedures for releasing the glass code into production ... You can also make bugfixes in your local repository and issue pull requests to the glassdb repository with those bugfixes ... if you choose.

I know that becoming comfortable with git isn't necessarily easy, but the "soon to be released tODE[9]" (I'm down to only 7 "must have" issues on tode[5] and when that total reaches zero I will announce a public alpha) has some fairly high level support for the basic git operations and I will be added menu items/commands that should pretty much automate the process of merging in changes from glassdb/glass to your local repository. If there are conflicts the tODE merge tool will be opened and you will be able to resolve the merges or abort the operation all together. 

I'm about a week or so away from the public alpha (barring anymore high priority interrupts), but I expect the early alpha users to be comfortable with git as I won't have all of the steps automated by then...I intend to add git-related documentation to the webEditionHome site[8] with more detail about using git and tODE together so that folks with less experience with git can get a hopefully gentle introduction:)

You can track tODE progress here[6] or here[7].

Dale



On Wed, Dec 18, 2013 at 6:20 AM, Mariano Martinez Peck <[hidden email]> wrote:



On Tue, Dec 17, 2013 at 7:22 PM, Dale K. Henrichs <[hidden email]> wrote:



From: "Mariano Martinez Peck" <[hidden email]>
To: [hidden email]
Sent: Tuesday, December 17, 2013 11:59:09 AM
Subject: [Glass] Is it possible to explore/inspect objects from seaside        callbacks in GemTools?

.....

Finally, and this is my real question...I have gems running seaside in which I have some buttons to ease development. These buttons send #inspect or #explore to some objects in seaside callbacks. When I do that (having a GemTools connected to the same GemStone), I get this error:

-----------

Internal Server Error:

a TransactionError occurred (error 2407), The object aSessionTemps( #'GsHostRandomFile'->aGsFile, #'GRGemStoneRandomProvider_MUTEX'->aTransientMutex, #'SystemChangeNotifier_UniqueInstance'->aSystemChangeNotifier, #'GsPackage_TransactionBoundary_Dict'->aSessionTemps( #'SessionMethodChange'->1614, #'ClassChange'->6791), #'Cached_Class_Organizer'->aCachingClassOrganizer, #'GRGemStoneRandomProvider_GENERATOR'->aHostRandom, #'GemToGemStaticException'->aGsExceptionHandler, #'GsPackagePolicy_SessionMethodDictionary'->anIdentitySet( Array, Association, Behavior, Boolean, Character, Class, Collection, Integer, Magnitude, ObsoleteMetaclass, Number, Object, PositionableStream, ReadStream, SequenceableCollection, SmallInteger, Stream, String, UndefinedObject, ...), ...) may not be committed, 'instances of its class are non-persistent'

You should contact the system administrator

-------------


So I guess this is expected right? there is no workaround? 

I'm not surprised that you are getting an error ... presumably we're trying to dump the stack into the object log and it has some references to the SessionTemps ... since there is no head inspect/explore aren't going to bring up an inspector, however, it wouldn't be a bad idea to go ahead and change inspect/explore to drop off the object into the ObjectLog ...

Yes, I was thinking about that too. 
 
it is possible to tell if GemTools is connected, if `OBGemStonePlatform canInform` answers true GemTools is running ...


And do you think it is possible to avoid dumping the stack in the object log for the case of inspect/explore? because if true, we can check if GemTools is running, if true, we might be able to open a real inspector/explorer in GemTools and otherwise (or in addition) write the object to the object log? 

Thanks!

 
Dale





--
Mariano
http://marianopeck.wordpress.com


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass