[Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?
Locked
[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?
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 |
Re: [Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?
|
|
From: "Mariano Martinez Peck" <[hidden email]>Yes 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 ... I've got to eat lunch, so I'll save my reply for after lunch:)
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?
|
|
In reply to this post by Mariano Martinez Peck
From: "Mariano Martinez Peck" <[hidden email]>..... 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 |
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:
Yes, I was thinking about that too.
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!
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?
|
|
From: "Mariano Martinez Peck" <[hidden email]>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 |
Re: [Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?
|
|
On Wed, Dec 18, 2013 at 12:07 PM, Dale K. Henrichs <[hidden email]> wrote:
We are in sync then :) Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?
|
|
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:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |