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
