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.
--
Sun Microsystems GmbH Mikhail Voytenko
Nagelsweg 55 Software Engineer
20097 Hamburg Phone: (+49 40)23646 500
Germany Fax: (+49 40)23646 550
http://www.sun.de mailto:mikhail.voyte...@sun.com
Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@framework.openoffice.org
For additional commands, e-mail: dev-h...@framework.openoffice.org
