Re: [equinox-dev] Equinox and UTF-8
Well you should not be getting bytes from a String. A String is a set of Characters. Some characters may fit into bytes, but some are wider. Also, remember that the length of a String is the number of characters not the number of bytes into which those characters may be encoded. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Holger Mense [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008/07/10 02:37 AM Subject: Re: [equinox-dev] Equinox and UTF-8 Hi, On Wed, 9 Jul 2008 15:45:03 -0400, Oleg Besedin [EMAIL PROTECTED] wrote: To get more consistent results, use String.getBytes(UTF8). The getBytes() method uses default encoding. using String.getBytes(UTF-8) does not change the behaviour. Running the code as a bundle inside Eclipse leads to === cut === § length() = 1 § cast to byte = -89 § getBytes() = -62 -89 === cut === while starting it as a bundle in a running Equinox framework outside Eclipse leads to === cut === +é-º length() = 2 +é-º cast to byte = -62 -89 +é-º getBytes() = -61 -126 -62 -89 === cut === I've read that Windows has different default encodings for GUI and console applications. If that is true, it might explain why you see different outputs. I don't think that this is the reason of the watched behaviour. Executing the same code without a running Equinox framework leads to the correct identical result in- and outside Eclipse. When running it in an Equinox instance, both results differ. So it looks for me like an Equinox issue. Currently I am migrating a bigger application on top of Equinox. The last days I was working to get it to start again outside my development environment. That was the time where a detected the watched behaviour. -- Holger Mense ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox and UTF-8
Hello, On Thu, 10 Jul 2008 03:01:40 -0400, BJ Hargrave [EMAIL PROTECTED] wrote: Well you should not be getting bytes from a String. A String is a set of Characters. Some characters may fit into bytes, but some are wider. that is correct. Also, remember that the length of a String is the number of characters not the number of bytes into which those characters may be encoded. I agree with you. The output === cut === § length() = 1 § cast to byte = -89 § getBytes() = -62 -89 === cut === is correct. But I am getting a wrong output when running the same code without Eclipse as Equinox standalone application. === cut === +é-º length() = 2 +é-º cast to byte = -62 -89 +é-º getBytes() = -61 -126 -62 -89 === cut === The result of length() is wrong. And also the result of getBytes(). I discovered the behaviour while encoding Strings as Base64. The Base64 class in Apache-Commons Codec uses byte[] as input. However the resulting Base64 String differs in both execution environments because of the different results of getBytes() in both cases. -- Holger Mense ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Re: Equinox and UTF-8
Hi Holger, Please have a look at the command line that Eclipse generates. I noticed that Eclipse automatically passes -Dfile.encoding parameter depending on the encoding set on the Java source file, project properties or system default. BTW, I also can't confirm your observations. There are no differences on my Windows system (Version 6.0.6001). Eclipse, Test.java, uses default encoding (Cp1252) D:\Java\jdk1.6.0_05\bin\javaw.exe -Dfile.encoding=Cp1252 -classpath T:\workspaces\encoding-test\test\bin Test § length() = 1 § cast to byte = -89 § getBytes() = -89 Eclipse, Test2.java, uses UTF-8 encoding D:\Java\jdk1.6.0_05\bin\javaw.exe -Dfile.encoding=UTF-8 -classpath T:\workspaces\encoding-test\test\bin Test2 § length() = 1 § cast to byte = -89 § getBytes() = -62 -89 Command Line, Test.java, uses default encoding (Cp1252) D:\D:\Java\jdk1.6.0_05\bin\java.exe -Dfile.encoding=Cp1252 -classpath T:\workspaces\encoding-test\test\bin Test º length() = 1 º cast to byte = -89 º getBytes() = -89 º getBytes(UTF-8) = -62 -89 Command Line, Test2.java, uses UTF-8 encoding D:\D:\Java\jdk1.6.0_05\bin\java.exe -Dfile.encoding=UTF-8 -classpath T:\workspaces\encoding-test\test\bin Test2 -º length() = 1 -º cast to byte = -89 -º getBytes() = -62 -89 -º getBytes(UTF-8) = -62 -89 -Gunnar -- Gunnar Wagenknecht [EMAIL PROTECTED] http://wagenknecht.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Re: httpContext extension point not working, but servlet extension point is?
Korotney, James schrieb: Hopefully this is the correct place for this post… I did not see an equivalent .usr mailing list for equinox. There is none. Please use the Equinox newsgroup. I'll post the anser there. The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Note, this footer is absurd on a public mailing list or newsgroup. -Gunnar -- Gunnar Wagenknecht [EMAIL PROTECTED] http://wagenknecht.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Re: Equinox and UTF-8
Hello Gunnar, On Thu, 10 Jul 2008 10:24:54 +0200, Gunnar Wagenknecht [EMAIL PROTECTED] wrote: Hi Holger, Please have a look at the command line that Eclipse generates. I noticed that Eclipse automatically passes -Dfile.encoding parameter depending on the encoding set on the Java source file, project properties or system default. I think I got it now. Thank you for putting me into the right direction. For testing on console I exported my bundle with the Eclipse Export... function. For testing it as standalone I first used Fat Jar. The Fat Jar jar was okay, the Export... jar failed. Now I exported the bundle with Fat Jar as OSGi bundle and used it inside Equinox - it worked correctly. I checked the class file in both jars. The one of the Export... jar is two bytes bigger than the other. Looking into it with a hex editor showed, that the String representation of the paragraph symbol was enhanced by two bytes in the Export... jar. That leds to the different results. My workspace and my project is configured to use UTF-8 as textfile encoding. For me it looks like that the Export... function is not working properly. Can someone confirm my observations? -- Holger Mense ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Re: Equinox and UTF-8
Hello, On Thu, 10 Jul 2008 12:22:59 +0200, Holger Mense [EMAIL PROTECTED] wrote: Hello Gunnar, On Thu, 10 Jul 2008 10:24:54 +0200, Gunnar Wagenknecht [EMAIL PROTECTED] wrote: Hi Holger, Please have a look at the command line that Eclipse generates. I noticed that Eclipse automatically passes -Dfile.encoding parameter depending on the encoding set on the Java source file, project properties or system default. I think I got it now. Thank you for putting me into the right direction. For testing on console I exported my bundle with the Eclipse Export... function. For testing it as standalone I first used Fat Jar. The Fat Jar jar was okay, the Export... jar failed. [...] My workspace and my project is configured to use UTF-8 as textfile encoding. For me it looks like that the Export... function is not working properly. Can someone confirm my observations? I did some investigations. Export... seems to use that encoding which is given with -Dfile.encoding at Eclipse start. Adding a line into eclipse.ini to use UTF-8 leds to Export... correctly exporting the class file. -- Holger Mense ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] resolving partially
Hi, I'm using the Equinox resolver in tooling (Maven) to build a classpath for the JDT compiler. This requires me to have all the transitive dependencies of the plugins I'm building, and I'd like to avoid this. Is it possible to mark certain bundles as resolved before resolving, even if their dependencies are not present ? Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] webstart problem on 1.6.0_07
I'm getting reports that Equinox is no longer running under webstart with 1.6.0_07, while earlier updates have no problem. This is on an older version of org.eclipse.equinox.launcher (from 3.3). Is this a known problem ? I didn't find anything in bugzilla. This is the exception we get in the logs: !SESSION Thu Jul 10 08:54:31 CEST 2008 - !ENTRY org.eclipse.equinox.launcher 4 0 2008-07-10 08:54:31.737 !MESSAGE Exception launching the Eclipse Platform: !STACK java.io.IOException: Unable to initialize osgi.frameworkClassPath at org.eclipse.equinox.launcher.Main.addBaseJars(Main.java:757) at org.eclipse.equinox.launcher.Main.getDevPath(Main.java:649) at org.eclipse.equinox.launcher.Main.getBootPath(Main.java:841) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:439) at org.eclipse.equinox.launcher.WebStartMain.basicRun(WebStartMain.java:70) at org.eclipse.equinox.launcher.Main.run(Main.java:1198) at org.eclipse.equinox.launcher.WebStartMain.main(WebStartMain.java:48) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.sun.javaws.Launcher.executeApplication(Unknown Source) at com.sun.javaws.Launcher.executeMainClass(Unknown Source) at com.sun.javaws.Launcher.doLaunchApp(Unknown Source) at com.sun.javaws.Launcher.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Re: Equinox and UTF-8
Holger Mense schrieb: I did some investigations. Export... seems to use that encoding which is given with -Dfile.encoding at Eclipse start. Adding a line into eclipse.ini to use UTF-8 leds to Export... correctly exporting the class file. That sound like a bug to me. Can you open one against JDT UI and report your findings and steps to reproduce? -Gunnar -- Gunnar Wagenknecht [EMAIL PROTECTED] http://wagenknecht.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] %featureName and other values not being resolved
I am making a P2 updater site for AJDT. but I am running into some issues. It seems that the feature.properties file is not being used in the content.jar. And therefore %featureName, %copyright. %description, etc, is being used instead of the proper values that are inside feature.properties. You can find the update site here: http://download.eclipse.org/tools/ajdt/34/dev/update The site works (i.e.- it is possible to download from it), but the strings are not showing properly. The relevant portion of the content.xml file is pasted below: ... unit id='org.eclipse.ajdt.source.feature.jar' version='1.6.0.200807041530' update id='org.eclipse.ajdt.source.feature.jar' range='[0.0.0,1.6.0.200807041530)' severity='0'/ properties size='8' property name='org.eclipse.equinox.p2.name' value='%featureName'/ property name='org.eclipse.equinox.p2.description' value='%description'/ property name='org.eclipse.equinox.p2.provider' value='%providerName'/ property name='df_LT.featureName' value='Eclipse AspectJ Development Tools Source Code'/ property name='df_LT.copyright' value='Copyright (c) 2000, 2006 IBM Corporation and others.#xA;All rights reserved. This program and the accompanying materials#xA;are made available under the terms of the Eclipse Public License v1.0#xA;which accompanies this distribution, and is available at#xA;http://www.eclipse.org/legal/epl-v10.html#xA;T'/ property name='df_LT.providerName' value='Eclipse.org'/ property name='df_LT.description' value='Eclipse AspectJ Development Tools (AJDT) including the AspectJ compiler.'/ ... As you can see, the variable org.eclipse.equinox.p2.name has a value of %featureName, whereas the variable df_LT.featureName has the right value. This implies to me that the feature.properties file is being found during metadata creation, but it is not being used everywhere. Does anyone have any idea what is going on? The version of org.eclipse.releng.basebuilder is from June 6. thanks, --a ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox p2 Webinar - Jul. 15
Eclipse is hosting a webinar on Equinox p2. Please register if you're interested in learning more about this provisioning system in the new Ganymede release. Introduction to Equinox p2 July 15, 2008 at 9:00 am PDT / 12:00 pm EDT / 4:00 pm GMT Presented by Pascal Rapicault To register email webinar-p2 at eclipse dot org For more information on this and other Eclipse webinars visit http://live.eclipse.org/. Special thanks to Adobe for contributing their Adobe Acrobat Connect product to host the webinar. Cheers, Lynn Gayowski Marketing Events Manager Eclipse Foundation, Inc. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
