Re: [dev] Lifetime of Java objects representing UNO_ENUM values ?
On 07/16/10 15:16, rony wrote: On 16.07.2010 14:51, Stephan Bergmann wrote: Can you present the exact failing code here? What type is the variable named right, and how exactly does the (reflective, IIUC) call to setPropertyValue look like? Yes, but you need to fasten your seat-belt! ;-) Sorry, even with your in-depth explanation, I remain clueless of what causes your problem. As you say you have a workaround, maybe we should leave this mystery unfathomed... -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Lifetime of Java objects representing UNO_ENUM values ?
On 07/15/10 22:10, Rony G. Flatscher wrote: today I stumbled over the following interesting (read: time-consuming) problem: while caching Java objects representing individual UNO_ENUM values, all of a sudden om.sun.star.lang.DisposedException started to be thrown. Here is one such received exception message: ... getCause(): [com.sun.star.lang.DisposedException: java_remote_bridge com.sun.star.lib.uno.bridges.java_remote.java_remote_bri...@105b99f is disposed] That DisposedException had more than likely a different reason. Java objects representing UNO enumeration type values are completely local -- none of their methods initiate any URP communication. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Lifetime of Java objects representing UNO_ENUM values ?
Hi Stephan, On 16.07.2010 08:48, Stephan Bergmann wrote: On 07/15/10 22:10, Rony G. Flatscher wrote: today I stumbled over the following interesting (read: time-consuming) problem: while caching Java objects representing individual UNO_ENUM values, all of a sudden om.sun.star.lang.DisposedException started to be thrown. Here is one such received exception message: ... getCause(): [com.sun.star.lang.DisposedException: java_remote_bridge com.sun.star.lib.uno.bridges.java_remote.java_remote_bri...@105b99f is disposed] That DisposedException had more than likely a different reason. Java objects representing UNO enumeration type values are completely local -- none of their methods initiate any URP communication. This is the use case using the Java bridge, where invocations of UNO APIs via Java are carried out using Java reflection (this allows me to basically address UNO typelessly from the perspective of Rexx users): * get all the enum values of com.sun.star.style.ParagraphAdjust and cache them for later use, e.g. the value for RIGHT is assigned to a local variable named right, * then, later, an XParagraphCursor is queried for its XPropertySet and then this is used to setPropertyValue(ParaAdjust, right). It is in this invocation where unexpectedly the above exception is thrown. Now, querying for the enum value RIGHT before using it in the setPropertyValue() works reliably. As I found a stable solution, this is more a report than a request for help, yet, it would be interesting to learn where and under what conditions such an exeption would be throwable. ---rony
Re: [dev] Lifetime of Java objects representing UNO_ENUM values ?
On 07/16/10 13:48, rony wrote: On 16.07.2010 08:48, Stephan Bergmann wrote: On 07/15/10 22:10, Rony G. Flatscher wrote: today I stumbled over the following interesting (read: time-consuming) problem: while caching Java objects representing individual UNO_ENUM values, all of a sudden om.sun.star.lang.DisposedException started to be thrown. Here is one such received exception message: ... getCause(): [com.sun.star.lang.DisposedException: java_remote_bridge com.sun.star.lib.uno.bridges.java_remote.java_remote_bri...@105b99f is disposed] That DisposedException had more than likely a different reason. Java objects representing UNO enumeration type values are completely local -- none of their methods initiate any URP communication. This is the use case using the Java bridge, where invocations of UNO APIs via Java are carried out using Java reflection (this allows me to basically address UNO typelessly from the perspective of Rexx users): * get all the enum values of com.sun.star.style.ParagraphAdjust and cache them for later use, e.g. the value for RIGHT is assigned to a local variable named right, * then, later, an XParagraphCursor is queried for its XPropertySet and then this is used to setPropertyValue(ParaAdjust, right). It is in this invocation where unexpectedly the above exception is thrown. Now, querying for the enum value RIGHT before using it in the setPropertyValue() works reliably. Can you present the exact failing code here? What type is the variable named right, and how exactly does the (reflective, IIUC) call to setPropertyValue look like? The DisposedException indicates either a problem in the bridge (say, it is asked to marshal an object of unexpected type, and thus shuts down) or in the remote soffice.bin process (it likely crashed). -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Lifetime of Java objects representing UNO_ENUM values ?
Hi Stephan, On 16.07.2010 14:51, Stephan Bergmann wrote: On 07/16/10 13:48, rony wrote: On 16.07.2010 08:48, Stephan Bergmann wrote: On 07/15/10 22:10, Rony G. Flatscher wrote: today I stumbled over the following interesting (read: time-consuming) problem: while caching Java objects representing individual UNO_ENUM values, all of a sudden om.sun.star.lang.DisposedException started to be thrown. Here is one such received exception message: ... getCause(): [com.sun.star.lang.DisposedException: java_remote_bridge com.sun.star.lib.uno.bridges.java_remote.java_remote_bri...@105b99f is disposed] That DisposedException had more than likely a different reason. Java objects representing UNO enumeration type values are completely local -- none of their methods initiate any URP communication. This is the use case using the Java bridge, where invocations of UNO APIs via Java are carried out using Java reflection (this allows me to basically address UNO typelessly from the perspective of Rexx users): * get all the enum values of com.sun.star.style.ParagraphAdjust and cache them for later use, e.g. the value for RIGHT is assigned to a local variable named right, * then, later, an XParagraphCursor is queried for its XPropertySet and then this is used to setPropertyValue(ParaAdjust, right). It is in this invocation where unexpectedly the above exception is thrown. Now, querying for the enum value RIGHT before using it in the setPropertyValue() works reliably. Can you present the exact failing code here? What type is the variable named right, and how exactly does the (reflective, IIUC) call to setPropertyValue look like? Yes, but you need to fasten your seat-belt! ;-) Reason being the following architecture: * ooRexx (C++) interacting with Java via an external function call package for ooRexx (C++) that communicates with Java via JNI (C++), * Java support classes which partly use the Apache Software Foundation's Bean Script Framework 2.x, * an ooRexx package named UNO.CLS that is tailored to ease interaction with UNO, taking advantage of ooRexx mechanisms (e.g. instead of the programmer issuing explicitly a Runtime.queryInterface(...) this is done in UNO.CLS, if the programmer merely sent the name of an interface as a message to the UNO Rexx object, etc.). Realizing the complexity of the architecture (which has evolved for the past four years with the specific OOo/UNO support package) I am always wary, when analyzing or reporting errors. In the concrete case the following code snippet had failed: ... cut ... /* make all of the UNO_ENUM values easily available to Rexx: */ paraEnum=.uno_enum~new(com.sun.star.style.ParagraphAdjust) /* for debugging: show all values */ say UNO_ENUM 'ParagraphAdjust': pp(paraEnum~makeString) /* get properties of XParagraphCursor */ xParagraphCursorProps=xTextCursor~XParagraphCursor~XPropertySet /* for debugging: show the definition, including all available properties */ say 'xParagraphCursorProps': ppd(xParagraphCursorProps~uno.getDefinition) /* right adjust paragraph */ xTextCursor~gotoEnd(.false) xText~insertControlCharacter(xTextCursor, ctlConstants~paragraph_Break, .false) xText~insertString(xTextCursor, This paragraph will be right-adjusted. ~copies(6), .true) *xParagraphCursorProps~setPropertyValue(ParaAdjust, paraEnum~right)* ^^^ failure with the reported exception ^^^ In the typeless (actually late binding) ooRexx (http://www.ooRexx.org) there is an explicit message operator (the tilde, ~) which means that the object left of the tilde will get the message sent to, that is given right of the tilde. If a message carries arguments, then these arguments can be enclosed in round parentheses. The statement paraEnum=.uno_enum~new(...) uses the ooRexx class UNO_ENUM defined in UNO.CLS to wrap an UNO_ENUM. The result is that one then merely needs to send the enum value's name as a message and will get the enum (Java) object returned. This is done in the last statement above, setting the ParaAdjust property. The ooRexx class UNO_ENUM would cache all enum (Java object) values and return them. In the process of analyzing the problem I also explicitly queried the enum (Java object) value right before the last statement above and it returned the same Java object, that has been cached. Except, in the latter case the exception was not thrown and the code worked. As a result I changed the implementation of the UNO_ENUM ooRexx class to not return a cached enum (Java object) value, but query that value at that point in time and return it. And the problem went away ... [I know, you might be inclined to think that the caching in UNO_ENUM does not work, but I can assure you that I double-checked on that. In a nutshell: as
[dev] Lifetime of Java objects representing UNO_ENUM values ?
Hi there, today I stumbled over the following interesting (read: time-consuming) problem: while caching Java objects representing individual UNO_ENUM values, all of a sudden om.sun.star.lang.DisposedException started to be thrown. Here is one such received exception message: ... getCause(): [com.sun.star.lang.DisposedException: java_remote_bridge com.sun.star.lib.uno.bridges.java_remote.java_remote_bri...@105b99f is disposed] Caching the Java class object and querying it for the field values in the same use-case (and timing) conditions worked. Question: is caching of Java objects representing individual UNO_ENUM values really unsafe, i.e. the UNO side may garbage collect them? (This seems to happen even if the Java class object representing the UNO_ENUM gets cached!) ---rony
