Hi Mikhail,
Sorry, I have this question at the very beginning of debugging:
after I set a breakpoint in SfxDocTplService_Impl::addTemplate()
however each time I drag a template into "My Templates" folder,
the cursor is stuck in the "dragging" state thus both the
keyborad and mouse stop working until I restart the desktop
window. Is there any trick I can use to avoid this please?
Thanks and Best Regards,
Felix.
On Mon, Jun 15, 2009 at 1:59 PM, Mikhail Voytenko
<mikhail.voyte...@sun.com <mailto:mikhail.voyte...@sun.com>> wrote:
Hi Felix,
thank you for the info, and good luck. :)
The questions are as always welcome.
Best regards,
Mikhail.
On 06/15/09 06:21, Zhang Xiaofei wrote:
Hi Mikhail,
Sorry for the first abnormal test result from my bad
environment. The problem does exist in my new DEV300_m46
build. I guess it still needs to be investigated, and I
will write mails as soon as I get some information from
debugging.
Best Regards,
Felix.
Mikhail Voytenko
Hi Felix,
Never mind, my first description indeed was not
detailed enough, and the dmake syntax is quite
confusing as well.
I think the change you have done is the fix for the
issue. In case JavaLoader still has to be fixed, we
can open a new issue, I think.
Could you please attach the patch to the issue.
After that please take a look to the issue
http://qa.openoffice.org/issues/show_bug.cgi?id=71512
This is a Unix-only issue. The problem there is that
after a template is dragged and dropped to the user
templates, the access rights of the template file are
preserved, so the template can not be edited. The
rights actually should be adjusted every time a new
template is added to the user templates set.
The implementation can be found in
sfx2/source/doc/doctemplates.cxx in the method
"SfxDocTplService_Impl::addTemplate()". Please get
familiar with the code and prepare the environment to
reproduce and debug the problem. We can discuss the
details on the next IRC meeting.
Best regards,
Mikhail.
On 06/08/09 11:08, Zhang Xiaofei wrote:
Hi Mikhail,
Sorry that I totally misinterpreted your
suggestion previously. I removed the space before
the '>' mark and I can install the extension
afterwards.
And I was wrong about the PropertySet example
too, it looks adding any string, no matter how
long or if it contains space, would cause the
same error message. I'm awfully sorry about my
unsound assumptions. I find it really necessary
for me to start reading the manual of dmake.
I'm looking forward to hear the result of the
discussions between you and the developer of
JavaLoader, so that we can decide if patching the
makefile is enough for this issue.
Thank You and Best Regards,
Felix.
Mikhail Voytenko
Hi Felix,
As we have already discussed on the IRC
meeting the splitting of the line itself is
no problem, the splitting of the correct
class name works pretty well.
The problem is the space at the end of the
class name.
RegistrationClassName:
org.openoffice.examples.embedding.OwnEmbeddedOb
jectFactory
^ ^
The first space marked above is introduced by
splitting, it is no problem at all. The
second one, at the end of the class name is
introduced by the Makefile, it is the problem.
If you take a look to the Makefile in
\sdk\examples\java\PropertySet\, the
generation of the manifest file does not
introduces the space at the end of the class
name, this is why it works there.
By the way, how did you make the
RegistrationClassName longer in your
experiments? I suspect that you have added
spaces and this is why it did not work.
So it is actually a problem of the example
Makefile, the generation of the manifest uses
"echo" command, and this command prints
everything in manifest till the ">" sign
including the space, that is actually wrong.
Could you please try to remove the
unnecessary space in the Makefile and check
whether it helps.
We still should contact the responsible
developer to be sure that the current
behavior of the JavaLoader implementation is
the intended one. Unfortunately, I could not
reach him today.
Thanks and best regards,
Mikhail.
On 06/05/09 11:13, Zhang Xiaofei wrote:
Hi Mikhail,
Thank you for your reply, I agree with
your point, it seems according to my
investigation, a line is broken and
inserted the space when it exceeds 70
chars, and the OwnEmbeddedObject example
just happens to be the only one has a
RegistrationClassName line long enough to
cause the error. To confirm this I
changed RegistrationClassName
\sdk\examples\java\PropertySet\Makefile ,
which works fine before, to a string long
enough( in $(COMP_CLASS_OUT)/%.Manifest :
target) and got the same compiling error:
-------------------------------
make:
[D:/work/C/issues/i100835/WINexample.out/misc/PropTest\\java_PropTest_regi
ster_component.flag] Error 1 (ignored)
"D:\Software\ooo300m9\OpenOffice.org
3\program\\unopkg" add -f "D:\work\C\issues
\i100835\WINexample.out\bin\PropTest.oxt"
An error occurred while enabling:
PropTest.uno.jar
make: ***
[D:/work/C/issues/i100835/WINexample.out/misc/PropTest\\java_PropTest_
register_component.flag] Error 1
-------------------------------
and the same installing error, the
message box of which shows only the
RegistrationClassName.
So I guess the problem is not in the
example itself, and I agree maybe an
investigation should be made in
Javaloader implementation. Hope the
information above helps.
Thanks and Best Regards,
Felix.
Mikhail Voytenko
Hi Felix,
Sorry for the delay with the answer,
I had to switch to other tasks.
The problem is the space in the
MANIFEST.MF file in the
OwnEmbeddedObject.uno.jar. The space
is added just after
org.openoffice.examples.embedding.OwnEmbeddedObjectFactory,
if it is removed the extension can be
successfully installed.
I must confess, I do not understand
currently why did it work before,
probably something was changed in the
JavaLoader implementation so that now
the space is a problem.
Anyway, could you please try to
changed the Makefile, so that the
generation of the manifest does not
introduce the space at the end ( it
is in $(COMP_GEN_OUT)/%.Manifest:
target ) and check whether the
extension works on your side. I will
discuss the problem with the
developer responsible for the
JavaLoader implementation to see
whether the current office behavior
is correct.
Best regards,
Mikhail.
On 06/03/09 08:41, Zhang Xiaofei wrote:
Hi Mikhail,
Thank you, I have got the stack
ant it looks like this:
Thread: 216 :javaloader.cxx:
mapped javaloader - 0xd900a4
java.lang.ClassNotFoundException:
org.openoffice.examples.embedding.OwnEmbeddedO
bjectFactory
at
java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at
java.security.AccessController.doPrivileged(Native
Method)
at
java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at
java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at
java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:579)
at
java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
com.sun.star.comp.loader.RegistrationClassFinder.find(RegistrationCla
ssFinder.java:67)
at
com.sun.star.comp.loader.JavaLoader.writeRegistryInfo(JavaLoader.java
:437)
An error occurred while enabling:
OwnEmbeddedObject.uno.jar
By the way, sorry I forgot to
mention before, after I built
desktop/source/deployement/registry/component/dp_component.cxx
with debug information, I got
this assertion every first time
after startup the mouse hovers
over the DecoToolBox or the Tool
menu entry, I suspect there's a
possibility it be related to this
problem:
Error: File
g://DEV300_m37/desktop/source/deployment/registry/component/dp_component.cxx,
Line 660
:### invalid UNO_JAVA_CLASSPATH
entry!
(Yes=Abort / No=Ignore /
Cancel=Debugger )
Best Regards,
Felix.
Mikhail Voytenko
Hi Felix,
the stack should be printed
to the stderr, it might be
that it is redirected.
Please try to print to a file
using java.io.PrintStream and
e.printStackTrace( PrintStream ).
Additionally you could the
printing at the beginning of
the method and in the
constructor to be sure that
the printing works at all.
Best regards,
Mikhail.
On 06/02/09 11:22, Zhang
Xiaofei wrote:
Hi Mikhail,
Sorry, but after I
delivered the modified
jurt.jar to the
installation path, I
looked both from Visual
Studio output with OOo
being debugged, and from
running unopkg from
console, but neither
seems to be the right way
to see the call stack
printed. Could you please
give me a hint please?
Thanks and Best Regards,
Felix.
Mikhail Voytenko
Hi Felix,
The problem with
debugging of the
registration process
was indeed the java
implementation of the
JavaLoader. For the
further investigation
please introduce the
change in the
JavaLoader implementation
jurt/com/sun/star/comp/loader/JavaLoader.java
in method
public boolean
writeRegistryInfo()
The caught in the
method exception
should be used to
print the call stack.
You could use
"e.printStackTrace()"
call to get the stack
to the exception. By
the way, please change
"catch ( Exception e
)" to "catch(
Throwable )" to catch
all the exceptions.
Best regards,
Mikhail.
