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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@framework.openoffice.org
For additional commands, e-mail: dev-h...@framework.openoffice.org
