[Tcl Java] java::bind questions
I am trying to get java::bind to work in the following situation:
* I am developing services for my application as represented by Java interfaces
* The interface has addlistener and removelistener method signatures.
* Access to the service is managed through TclCmd classes (so the Tcl
script is *not* referencing objects)
* The Service has a method getObject which returns a ReflectObject wrapping
the interface's implementation.
* set l [Login getObject] works, I get a ref that supports things like $l show
* when I execute java::bind $l processLogin login I get a
java.lang.NullPointerException
where:
proc login {} {
do stuff
}
I am going to work my way through this, but if anyone has any helpful
pointers I would appreciate hearing from you.
Thanks -- Randy Kahle
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] java::bind questions
Mo,
The problem was mine. The collection object that held listeners was null
(never initialized). That was the null pointer problem.
java::bind seems fine. I'm using it to do queries, etc. and it seems
reasonable. I will be working over Jacl in the next couple of days as our
team completes a prototype of a client-side architecture for building a new
generation of applications. Jacl is really helping us pull this together.
I am running into another block... Now that I can do this --
java::bind $l processLogin login
where
proc login {} {
...
}
When the event is fired from Java, it never returns from the method call on
processLogin on the listener (the link to the tcl script).
Any suggestions on how I can trace down where my thread went? Can any
thread fire the event into Tcl? (I remember reading through the source code
and seeing something about the event system keeps track of the
interpreter's primary thread...)
(Do I need to have a thread spinning on the interpreter?)
Randy
Was it a bug in the tcljava code or your code? Could the java::bind
command be improved in some way to avoid this type of problem in
the future?
Mo Dejong
Cygnus Solutions
On Thu, 9 Dec 1999, Randolph S. Kahle wrote:
Mo,
Problem solved in very short order because of your help.
Thank you *very* much for the prompt reply to my email.
Regards,
Randy Kahle
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] JavaBean event is locking on evt.sync()
Mo, I did as you suggested (this is the first time I've run jdb, so I hope I am using it to best advantage). I have 7 Threads: Thread-1 (running) AWT-EventQueue-0 (cond. wait) PostEventQueue-0 (cond. wait) AWT-Windows (running) IFC (cond. wait) (Yes, I am using IFC!) TimerQueue(cond. wait) interpreterworker (cond. wait) Screen Updater(cond. wait) Login eventing(cond. wait) The thread that is blocked on the evt.sync() method is the Login eventing thread. From my reading of the Jacl source code, there is a test to see if this thread (the "Login eventing" thread) is the primary thread for this interpreter's notifier. Since it is not (it was created late in the game), then - as I understand it - some other thread is supposed to be on the other side of the event queue pulling off events. Where is this thread? I guess that is where I am really confused. My architecture is using a single interpreter and we send commands from a GUI console-type source as well as hitting the interpreter from threads that are "helper threads" for the IFC. That is -- The IFC thread responds to the button press and create the "login event", it hands this off (via proper synchronization) to the "Login eventing" threads, which then "fires" the event into the Tcl system. It is this "Login eventing" thread that is getting blocked. Does this information help? Or should I do more research? Thanks -- Randy I can see the thread blocked on the evt.sync() call (outlined below) At 02:48 PM 12/9/99 , Mo DeJong wrote: Run this same code in Jacl under jdb. When it locks up, interupt the code and see which threads are locked. You should then be able to get a backtrace for each of the threads to find out where the deadlock is. I think this bug in in the notifier somewhere, so it should deadlock both Jacl and Tcl Blend. Mo Dejong Cygnus Solutions On Thu, 9 Dec 1999, Randolph S. Kahle wrote: I am making a lot of progress today understanding the JavaBean event processing. But I am now stuck again. In the class EventAdaptor.java the method _processEvent(...) has the following code: BeanEvent evt = new BeanEvent( interp, paramTypes, params, cmd ); interp.getNotifier().queueEvent( evt, TCL.QUEUE_TAIL); evt.sync(); When my JavaBean fires an event into the Adapter class created by Tcl (upon registration using the java::bind command ), it locks up on the call to: evt.sync(); (I put in trace print out). and never returns. What occurs to me is that there must be a Thread running on interp somewhere that fetches these events and processes them internally. I do not have any such threads running. Can someone point me to the point where I must be "spinning" a thread on the other side of this event queue? I guess I'm missing a fundamental step here... Thanks! Randy Kahle The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Keeping multiple interpreters in sync
I am building a system in Java with Jacl and I believe I need to use multiple interpreters (we are in the prototype stage and we are not yet ready to make this design decision). One interpreter will be used for a "command window" for users to interact with the system and the others would be either in a "resource pool" or specifically assigned to parts of the system. I would like to keep these interpreters "in sync" as far as available commands and other state (variables, etc.) Is there an easy "back-door" way to keep multiple interpreters synchronized? Randy The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Plans for Jacl 1.3?
Moses, What are the plans for Jacl 1.3? I am in the process of integrating Jacl into an application framework and I want to know what you think the possible feature additions release dates are for 1.3 so I can plan accordingly. Regards, Randy Kahle The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Plans for Jacl 1.3?
Moses, Thanks for the reply. I am intrigued by one new feature you mention: Work on ability to load Tclblend from inside Java (TclBlend) One reason I am using Jacl and not even looking at (the supported!) TclBlend is that Jacl is pure Java. If this feature is added to TclBlend will that change how one can via TclBlend? Regards, Randy The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Ignore last error report
I apologize for sending out that last set of errors for the JDK 1.1.8 build. Most of them were due to some changes I was working on in the TclIndex.java file. I am new to this code base and I'm trying to get up to speed! Embarrassed :-( -- Randy Kahle The TclJava mailing list is sponsored by WebNet Technologies. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. A list archive is at: http://www.findmail.com/listsaver/tcldallas/
