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.
