Re: Security module layout
Hi George if you restructured the stuff on your computer, could you submit a patch? Thanks, Mikhail 2006/2/27, Mikhail Loenko <[EMAIL PROTECTED]>: > 2006/2/27, George Harley <[EMAIL PROTECTED]>: > > Mikhail Loenko wrote: > > > Hi George > > > > > > actually the native code we have in security should work on both > > > IA32 and IPF > > > > > > So, it seems that with your suggestion we will have to have > > > two copies of that code. Please correct me if I'm wrong > > > > > > What is about the following str: > > > > > > +-win/ > > > | | > > > | +--IA32/ > > > | | > > > | +--IPF/ > > > | | > > > | +-- common1.cpp > > > | | > > > | +-- common2.cpp > > > | | > > > ... > > > > > > Thanks, > > > Mikhail > > > > > > > Looks good to me. And it's the same story under the "linux" folder ? > > Exactly. > > Thanks, > Mikhail > > > > > > Best regards, > > George > > IBM UK > > > > > 2006/2/27, George Harley <[EMAIL PROTECTED]>: > > > > > >> Jean-frederic Clere wrote: > > >> > > >>> Mikhail Loenko wrote: > > >>> > > >>> > > Hi George, > > > > why e.g. 'win.IA32' not just 'win'? > > > > > > > > >>> Because there will be a posix.apr that will do the portable part ;-) > > >>> Correct me if I am wrong. > > >>> > > >> ...er...well, I'm not sure that it was foremost in my thoughts when I > > >> was working through the layout changes :-) > > >> > > >> I simply wanted to have a way of differentiating between code written > > >> for 32-bit and 64-bit Windows on Intel architecture. I am assuming that > > >> the Windows code there today is for 32 bit. I did wonder about splitting > > >> those directory names up so that instead of a folder called "win.IA32" > > >> we had a "win" folder with a "IA32" sub-folder (and likewise for Linux). > > >> i.e. > > >> > > >> java > > >> | > > >> +-common > > >> | > > >> +-win > > >> | | > > >> | \---IA32 > > >> | > > >> +-linux > > >> | | > > >> | \---IA32 > > >> | > > >> ... > > >> > > >> > > >> The above approach leaves the way open for other variants (e.g. 64-bit > > >> code) to be added in new sub-folders beneath "win" and "linux". In the > > >> end I opted for consistency with the "win.IA32" and "linux.IA32" names > > >> that are currently being used under the trunk/native-src folder in SVN. > > >> > > >> Best regards, > > >> George > > >> IBM UK > > >> > > >> > > >>> Cheers > > >>> > > >>> Jean-Frederic > > >>> > > >>> > > Thanks, > > Mikhail > > > > 2006/2/24, George Harley <[EMAIL PROTECTED]>: > > > > > > > > > Hi, > > > > > > Redrawing the proposed layout as it didn't render quite correctly > > > for me > > > when I read over the sent note (sigh). > > > > > > > > > > > >| > > >| > > >+---src > > >| | > > >| +---main > > >| | | > > >| | +---java > > >| | | | > > >| | | +---common > > >| | | | > > >| | | +---linux.IA32 > > >| | | | > > >| | | \---win.IA32 > > >| | | > > >| | +---native > > >| | | | > > >| | | +---linux.IA32 > > >| | | | > > >| | | \---win.IA32 > > >| | | > > >| | \---resources > > >| | | > > >| | \---common > > >| | > > >| +---test > > >| | > > >| +---java > > >| | > > >| +---common > > >| | > > >| +---linux.IA32 > > >| | > > >| \---win.IA32 > > >| > > >+---doc > > >| | > > >| \---images > > >| > > >+---make > > >| | > > >| \---native > > >| | > > >| +---linux > > >| | > > >| \---windows > > >| > > >+---META-INF > > > > > > > > > > > > Best regards, > > > George > > > IBM UK > > > > > > > > > > > > George Harley wrote: > > > > > > > > >> Hi, > > >> > > >> Earlier on today I spent some time following the instructions for > > >> developing Harmony Java code inside Eclipse [1]. After experimenting > > >> with archive, luni and nio I decided to check out modules/security > > >> and > > >> found that, in its current form, it can't be brought into an Eclipse > > >> workspace and used like the other modules. One obvious difference is > > >> that it doesn't have any Eclipse project metadata in there (e.g. > > >> .project and .classpath files). After adding these in (in my private > > >> workspace), I beg
[jira] Updated: (HARMONY-145) windows natives should use the shared files created by HARMONY-132
[ http://issues.apache.org/jira/browse/HARMONY-145?page=all ] Mark Hindess updated HARMONY-145: - Attachment: win.move.to.shared This patch removes ~90 files from the windows build that are "idential" to files moved out of the linux tree by patch HARMONY-132. This patch uses the files created by the HARMONY-132 patch so obviously it depends on that patch. (md5sum=7a63975afc6ab4c7f865e2d48e8f6021) > windows natives should use the shared files created by HARMONY-132 > -- > > Key: HARMONY-145 > URL: http://issues.apache.org/jira/browse/HARMONY-145 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Mark Hindess > Priority: Trivial > Attachments: win.move.to.shared > > The windows native build should be changed to share the common files created > by HARMONY-132. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-145) windows natives should use the shared files created by HARMONY-132
windows natives should use the shared files created by HARMONY-132 -- Key: HARMONY-145 URL: http://issues.apache.org/jira/browse/HARMONY-145 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Priority: Trivial The windows native build should be changed to share the common files created by HARMONY-132. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-144) Refactoring of windows makefiles.
[ http://issues.apache.org/jira/browse/HARMONY-144?page=all ] Mark Hindess updated HARMONY-144: - Attachment: win.makefile.refactoring Refactoring to make it easier to make the shared code changes. (md5sum=374799bd5d3569cdf8777fb856361f5d) > Refactoring of windows makefiles. > - > > Key: HARMONY-144 > URL: http://issues.apache.org/jira/browse/HARMONY-144 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Mark Hindess > Priority: Trivial > Attachments: win.makefile.refactoring > > There's still a lot of duplication in the linux makefiles. I've attempted to > remove as much as possible. I'l attach a patch shortly. This is the windows > equivalent of HARMONY-131. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-144) Refactoring of windows makefiles.
Refactoring of windows makefiles. - Key: HARMONY-144 URL: http://issues.apache.org/jira/browse/HARMONY-144 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Priority: Trivial There's still a lot of duplication in the linux makefiles. I've attempted to remove as much as possible. I'l attach a patch shortly. This is the windows equivalent of HARMONY-131. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: assigned modules
Hello Nathan, Welcome :-) However, as you may know, it may be difficult to implement annotation and instrument as we have no Java 5.0 compatible VM which can be used by Harmony. Also, there are prefs implementation in Harmony-88. :-) Richard Liang China Software Development Lab, IBM Nathan Beyer wrote: Along these lines, according to the "componentization" page [1] on the Wiki, there are a number of missing projects from the classlib. Would it be of value to at least stub out some of these major components? Perhaps things like Annotation, Instrument, Lang-Management, RMI, Concurrent, Prefs? It's not glamorous work, but I'd be willing to do some of it. I didn't know if there were any possible donations on the horizon that we might be waiting for. [1] http://wiki.apache.org/harmony/componentization -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 28, 2006 12:07 PM To: harmony-dev@incubator.apache.org Subject: Re: assigned modules We actually don't assign things because we don't want to create feelings of territory. That said, if someone is working in an area, it's courteous to show some deference in order to avoid commit clashes :) However, I think your question is different - we don't have a full classlibrary map, and that would be nice. There is some info on the wiki already. Are you interested in producing one suitable for the website? geir karan malhi wrote: How would I know what modules/classes are being worked upon already. I know JIRA is one place to look into, but it may not show a complete picture until an issue is created for a module. Is there a list i.e. spreadsheet or a wiki page where we have list of modules and volunteers working on that?
Contributions in process
I noticed that there are a few major contributions that are marked "In Process" [1][2]. Is there anything I, or others, can do to assist getting these contributions over the hill and into the repository and builds. -Nathan [1] http://issues.apache.org/jira/browse/HARMONY-39 [2] http://issues.apache.org/jira/browse/HARMONY-88
RE: assigned modules
Along these lines, according to the "componentization" page [1] on the Wiki, there are a number of missing projects from the classlib. Would it be of value to at least stub out some of these major components? Perhaps things like Annotation, Instrument, Lang-Management, RMI, Concurrent, Prefs? It's not glamorous work, but I'd be willing to do some of it. I didn't know if there were any possible donations on the horizon that we might be waiting for. [1] http://wiki.apache.org/harmony/componentization -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 28, 2006 12:07 PM To: harmony-dev@incubator.apache.org Subject: Re: assigned modules We actually don't assign things because we don't want to create feelings of territory. That said, if someone is working in an area, it's courteous to show some deference in order to avoid commit clashes :) However, I think your question is different - we don't have a full classlibrary map, and that would be nice. There is some info on the wiki already. Are you interested in producing one suitable for the website? geir karan malhi wrote: > How would I know what modules/classes are being worked upon already. I > know JIRA is one place to look into, but it may not show a complete > picture until an issue is created for a module. Is there a list i.e. > spreadsheet or a wiki page where we have list of modules and volunteers > working on that? >
[jira] Updated: (HARMONY-143) [classlib][luni]
[ http://issues.apache.org/jira/browse/HARMONY-143?page=all ] Nathan Beyer updated HARMONY-143: - Attachment: Flushable.java Iterable.java > [classlib][luni] > > > Key: HARMONY-143 > URL: http://issues.apache.org/jira/browse/HARMONY-143 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Nathan Beyer > Priority: Minor > Attachments: Flushable.java, Iterable.java > > Additional Java 5 interfaces for LUNI: Iterable and Flushable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-143) [classlib][luni]
[classlib][luni] Key: HARMONY-143 URL: http://issues.apache.org/jira/browse/HARMONY-143 Project: Harmony Type: Improvement Components: Classlib Reporter: Nathan Beyer Priority: Minor Additional Java 5 interfaces for LUNI: Iterable and Flushable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-142) java.nio.charset.CharsetDecoder constructor doesn't throw IllegalArgumentException when averageCharsPerByte is greater than maxCharsPerByte.
[
http://issues.apache.org/jira/browse/HARMONY-142?page=comments#action_12368204
]
Richard Liang commented on HARMONY-142:
---
Here is the testcases which pass on RI 5.0 and fail on both Haromny and RI 1.4.2
Thanks a lot.
/*
* test constructor: averBytesPerChar > maxBytesPerChar
*/
public void testConstructorIlegalAverageBytesPerChar() {
try {
Charset cs = Charset.forName("UTF-8"); //$NON-NLS-1$
CharsetDecoder decoder = new MockCharsetDecoderForHarmony142(cs,
1.1f, 1);
fail("Should throw IllegalArgumentException."); //$NON-NLS-1$
} catch (IllegalArgumentException e) {
// expected
}
}
/*
* MockCharsetDecoderForHarmony142: for constructor test
*/
static class MockCharsetDecoderForHarmony142 extends CharsetDecoder {
protected MockCharsetDecoderForHarmony142(Charset cs,
float averageBytesPerChar, float maxBytesPerChar) {
super(cs, averageBytesPerChar, maxBytesPerChar);
}
protected CoderResult decodeLoop(ByteBuffer in, CharBuffer out) {
return null;
}
}
> java.nio.charset.CharsetDecoder constructor doesn't throw
> IllegalArgumentException when averageCharsPerByte is greater than
> maxCharsPerByte.
>
>
> Key: HARMONY-142
> URL: http://issues.apache.org/jira/browse/HARMONY-142
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
>
> As spec says, constructor throws IllegalArgumentException when parameters are
> illegal. It should be considered as illegal parameters when
> averageCharsPerByte is greater than maxCharsPerByte.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-142) java.nio.charset.CharsetDecoder constructor doesn't throw IllegalArgumentException when averageCharsPerByte is greater than maxCharsPerByte.
java.nio.charset.CharsetDecoder constructor doesn't throw IllegalArgumentException when averageCharsPerByte is greater than maxCharsPerByte. Key: HARMONY-142 URL: http://issues.apache.org/jira/browse/HARMONY-142 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang As spec says, constructor throws IllegalArgumentException when parameters are illegal. It should be considered as illegal parameters when averageCharsPerByte is greater than maxCharsPerByte. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments
[ http://issues.apache.org/jira/browse/HARMONY-141?page=comments#action_12368197 ] Richard Liang commented on HARMONY-141: --- Again I forget something: The test cases pass on RI 5.0 and fail on Harmony and RI 1.4.2. This may be an improvement of RI 5.0 :-) > Constructors of java.nio.charset.CharsetEncoder do not validate arguments > - > > Key: HARMONY-141 > URL: http://issues.apache.org/jira/browse/HARMONY-141 > Project: Harmony > Type: Bug > Reporter: Richard Liang > Attachments: CharsetEncoder_patch.txt > > Constructors of java.nio.charset.CharsetEncoder should throw > IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-124) java.nio.charset.CharsetDecoder doesn't throw CoderMalfunctionError exception when decodeLoop threw unexpected exception.
[
http://issues.apache.org/jira/browse/HARMONY-124?page=comments#action_12368195
]
Richard Liang commented on HARMONY-124:
---
Yes, Tim. The fix looks good. Please close this issue.
Thanks a lot.
> java.nio.charset.CharsetDecoder doesn't throw CoderMalfunctionError exception
> when decodeLoop threw unexpected exception.
> -
>
> Key: HARMONY-124
> URL: http://issues.apache.org/jira/browse/HARMONY-124
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Attachments: CharsetDecoder_patch.txt, Charset_patch.txt
>
> public final CoderResult decode(ByteBuffer in, CharBuffer out, boolean
> endOfInput)
> As spec says, the method throws CoderMalfunctionError if an invocation of the
> decodeLoop method threw an unexpected exception.
> However, Harmony doesn't throws CoderMalfunctionError when decodeLoop method
> threw an unexpected exception.
> The following test cases pass on RI , but fail on Harmony.
> /*
>* Test malfunction decode(ByteBuffer)
>*/
> public void testDecode_CoderMalfunctionError() throws Exception {
> MockMalfunctionCharset cs = new MockMalfunctionCharset("mock",
> null);
> try{
>
> cs.newDecoder().onMalformedInput(CodingErrorAction.REPLACE)
>
> .onUnmappableCharacter(CodingErrorAction.REPLACE).decode(ByteBuffer.wrap(new
> byte[]{0x00,0x11}));
> fail("should throw CoderMalfunctionError");//NON-NLS-1$
> }catch(CoderMalfunctionError e){
> //expected
> }
> }
> /*
>* Test malfunction decode(ByteBuffer)
>*/
> public void testDecode_NoCoderMalfunctionError() throws Exception {
> MockMalfunctionCharset cs = new MockMalfunctionCharset("mock",
> null);
> try{
> cs.decode(ByteBuffer.wrap(new byte[]{0x00,0x11}));
> }catch(CoderMalfunctionError e){
> fail("Charset.decode should return
> silently");//NON-NLS-1
> }
> }
> /*
>* Mock charset class with malfunction decode & encode.
>*/
> static final class MockMalfunctionCharset extends Charset {
> public MockMalfunctionCharset(String canonicalName, String[]
> aliases) {
> super(canonicalName, aliases);
> }
> public boolean contains(Charset cs) {
> return false;
> }
> public CharsetDecoder newDecoder() {
> return new MockMalfunctionDecoder(this);
> }
> public CharsetEncoder newEncoder() {
> return new MockMalfunctionEncoder(this);
> }
> }
> /*
>* Mock decoder. decodeLoop always throws unexpected exception.
>*/
> static class MockMalfunctionDecoder extends
> java.nio.charset.CharsetDecoder {
> public MockMalfunctionDecoder(Charset cs) {
> super(cs, 1, 10);
> }
> protected CoderResult decodeLoop(ByteBuffer in, CharBuffer out)
> {
> throw new BufferOverflowException();
> }
> }
> /*
>* Mock encoder. encodeLoop always throws unexpected exception.
>*/
> static class MockMalfunctionEncoder extends
> java.nio.charset.CharsetEncoder {
> public MockMalfunctionEncoder(Charset cs) {
> super(cs, 1, 3, new byte[] { (byte) '?' });
> }
> protected CoderResult encodeLoop(CharBuffer in, ByteBuffer out)
> {
> throw new BufferOverflowException();
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jchevm] questions about libjc/zip.c
All,
Sorry for the duplicate email. I did not get the subject line correct
the first time
Archie,
I tried the "pread()" patch but I still get:
Making all in native
make[2]: Entering directory `/cygdrive/c/Documents and Settings/weldon/My Docume
nts/important/SSG_DRL/jchevm/jchevm/libjc/native'
../../tools/jcjavah/jcjavah -classpath ../../java/jc.zip:/usr/local/classpath/sh
are/classpath/glibj.zip `echo gnu_classpath_VMStackWalker.h | sed -e 's/\.h$//g'
-e 's/_/./g'`
jcjavah: can't load class `gnu/classpath/VMStackWalker': java/lang/NoClassDefFou
ndError: gnu.classpath.VMStackWalker
make[2]: *** [gnu_classpath_VMStackWalker.h] Error 1
Below is a diff of zip.c. I simply guessed what the arguments to
lseek() and read() should be. It would be great if someone would
reply with a diff of what this file should look like.
Thanks
Weldon
$ svn diff zip.c
Index: zip.c
===
--- zip.c (revision 381714)
+++ zip.c (working copy)
@@ -307,9 +307,12 @@
}
/* Read data */
+lseek(zip->fd, zent->offset, SEEK_SET); // wjw
for (i = 0; i < zent->comp_len; i += r) {
- if ((r = pread(zip->fd, (char *)data + i,
- zent->comp_len - i, zent->offset + i)) == -1) {
+ //wjw if ((r = pread(zip->fd, (char *)data + i,
+ //wjwzent->comp_len - i, zent->offset + i)) == -1) {
+if ((r = read(zip->fd, (char *)data + i, zent->offset + i)) == -1) { //
wjw
+
_JC_EX_STORE(env, IOException, "can't read entry `%s'"
" in ZIP file `%s': %s", zent->name, zip->path,
strerror(errno));
@@ -361,6 +364,7 @@
}
/* Read and inflate data */
+lseek(zip->fd, zent->offset, SEEK_SET); // wjw
for (i = 0; i < zent->comp_len; i += r) {
char buf[512];
int to_read;
@@ -370,8 +374,10 @@
to_read = zent->comp_len - i;
if (to_read > sizeof(buf))
to_read = sizeof(buf);
- if ((r = pread(zip->fd, buf,
- to_read, zent->offset + i)) == -1) {
+ //wjw if ((r = pread(zip->fd, buf,
+ //wjw to_read, zent->offset + i)) == -1) {
+ if ((r = read(zip->fd, buf, zent->offset + i)) == -1) { //wjw
+
_JC_EX_STORE(env, IOException, "error reading entry"
" `%s' in ZIP file `%s': %s", zent->name,
zip->path, strerror(errno));
--
Weldon Washburn
Intel Middleware Products Division
questions about the patches for libjc/zip.c
Archie,
I tried the "pread()" patch but I still get:
Making all in native
make[2]: Entering directory `/cygdrive/c/Documents and Settings/weldon/My Docume
nts/important/SSG_DRL/jchevm/jchevm/libjc/native'
../../tools/jcjavah/jcjavah -classpath ../../java/jc.zip:/usr/local/classpath/sh
are/classpath/glibj.zip `echo gnu_classpath_VMStackWalker.h | sed -e 's/\.h$//g'
-e 's/_/./g'`
jcjavah: can't load class `gnu/classpath/VMStackWalker': java/lang/NoClassDefFou
ndError: gnu.classpath.VMStackWalker
make[2]: *** [gnu_classpath_VMStackWalker.h] Error 1
Below is a diff of zip.c. I simply guessed what the arguments to
lseek() and read() should be. It would be great if someone would
reply with a diff of what this file should look like.
Thanks
Weldon
$ svn diff zip.c
Index: zip.c
===
--- zip.c (revision 381714)
+++ zip.c (working copy)
@@ -307,9 +307,12 @@
}
/* Read data */
+lseek(zip->fd, zent->offset, SEEK_SET); // wjw
for (i = 0; i < zent->comp_len; i += r) {
- if ((r = pread(zip->fd, (char *)data + i,
- zent->comp_len - i, zent->offset + i)) == -1) {
+ //wjw if ((r = pread(zip->fd, (char *)data + i,
+ //wjwzent->comp_len - i, zent->offset + i)) == -1) {
+if ((r = read(zip->fd, (char *)data + i, zent->offset + i)) == -1) { //
wjw
+
_JC_EX_STORE(env, IOException, "can't read entry `%s'"
" in ZIP file `%s': %s", zent->name, zip->path,
strerror(errno));
@@ -361,6 +364,7 @@
}
/* Read and inflate data */
+lseek(zip->fd, zent->offset, SEEK_SET); // wjw
for (i = 0; i < zent->comp_len; i += r) {
char buf[512];
int to_read;
@@ -370,8 +374,10 @@
to_read = zent->comp_len - i;
if (to_read > sizeof(buf))
to_read = sizeof(buf);
- if ((r = pread(zip->fd, buf,
- to_read, zent->offset + i)) == -1) {
+ //wjw if ((r = pread(zip->fd, buf,
+ //wjw to_read, zent->offset + i)) == -1) {
+ if ((r = read(zip->fd, buf, zent->offset + i)) == -1) { //wjw
+
_JC_EX_STORE(env, IOException, "error reading entry"
" `%s' in ZIP file `%s': %s", zent->name,
zip->path, strerror(errno));
--
Weldon Washburn
Intel Middleware Products Division
Re: Strange thing with jchevm/classpath
Archie Cobbs wrote:
Jean-frederic Clere wrote:
So either something weird is happening (always possible), or you
have some
other incompatible version of log4j on your classpath, or something
in your classpath was compiled against another version of log4j, etc.
My test is using:
Class.forName("org.apache.commons.logging.impl.Log4JLogger");
I have rebuild commons-logging using the log4j I am using in the test
and the test is working now.
But I still don't understand why it was working with the Sun JVM
before!!!
Probably due to classpath differences. E.g. do you have a CLASSPATH
environment variable set? Sun pays attention to it, jchevm does not.
That seems not to be a CLASSPATH problem, with the Sun JVM the used jar
files are:
+++
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/rt.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/sunrsasign.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/jsse.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/jce.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/charsets.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/ext/localedata.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/TOMCAT/apache-tomcat-5.5.15/common/lib/commons-logging.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/TOMCAT/apache-tomcat-5.5.15/common/lib/log4j-1.2.13.jar",
O_RDONLY|O_LARGEFILE) = 3
+++
jc uses the same common-logging and log4j jar files...
Geir idea is also a good hint:
The lastest commons-logging is from 15-Jun-2004, it was not compiled
with log4j-1.2.13 but with something else.
I have tried this commons-logging with logging-log4j-1.3alpha-8 and jc
works ok.
I think I will ask commons-dev@jakarta.apache.org about it ;-)
Cheers
Jean-Frederic
-Archie
__
Archie Cobbs *CTO, Awarix*
http://www.awarix.com
Re: assigned modules
Hi I have been thinking about this for a while. The reason is that I would like to contribute but as others have noted before, it's a little difficult to see where to start.The work of Stuart Ballard [1] made this a little bit easer. The problem that remains is that sometimes there is a big work being done within a company (IBM/Intel) which is invisible to the world and "suddenly" gets contributed. Another possibility is that a big contribution is up for voting. (There is one due now right?) For us mere mortals (not full-time employed on the Harmony project) both these cases are a problem since it's sometimes difficult to follow the list. (Or am I only speaking for myself?) Anyway, I propose that we make a page (I can do it or help doing it) where this information should be posted. It should contain: 1) A breakdown of the classlib (exactly like [1] IMHO) and possibly the VM's into 'bullets' 2) For each of these bullets a status: - "Done" We think it is done - "Under development", somebody is looking into it. This doesn't mean that person/group "owns" the module, but it's who to ask if you want to contribute - "Being voted on" On it's way - "Available" (Much more inviting for others than "not done" :) 3) Other info perhaps? Or maybe nice colouring or whatever This information will probably be most useful to people that would like to contribute a small part to the project (like me). But I think that there are more out there eager to help than the few that have raised their voices on this list. What do people think? Regards, Erik Axel Nielsen VU - Amsterdam [1] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-harmony Quoting karan malhi <[EMAIL PROTECTED]>: > Yes I am interested in documenting this thing. I dont know the best > way > to do it, but I was thinking if everybody could send in the following > information: > 1. Name > 2. Module and classes working on > Then I can create a simple wiki page with the above information. > However, it would be very difficult for me to keep the page updated, > so > I guess, it would be the responsibility of each contributor to update > that wiki page if he/she starts/stops working on a new module/class. > > Here is an example of what I am talking of. We could do something > similar, though not exactly the same format. > > http://wiki.apache.org/jdo/AllTheOtherTests > > Geir Magnusson Jr wrote: > > > We actually don't assign things because we don't want to create > > feelings of territory. > > > > That said, if someone is working in an area, it's courteous to show > > some deference in order to avoid commit clashes :) > > > > However, I think your question is different - we don't have a full > > classlibrary map, and that would be nice. > > > > There is some info on the wiki already. Are you interested in > > producing one suitable for the website? > > > > geir > > > > karan malhi wrote: > > > >> How would I know what modules/classes are being worked upon > already. > >> I know JIRA is one place to look into, but it may not show a > complete > >> picture until an issue is created for a module. Is there a list > i.e. > >> spreadsheet or a wiki page where we have list of modules and > >> volunteers working on that? > >> > > > > -- > Karan Singh >
Re: Harmony and the future of Java
Damian Hamill herculeez.com> writes: > Can we have a distribution of Harmony that complies with Java > certification and add whatever is required to build an on-demand version > so as a developer/distributor I can choose what technologies I adopt for > the distribution and execution of my Applets ? No. It needs to quack, walk and swim like Java in all configurations to be certified. Sun would sue Apache to hell and back if we did that, and as a negative bonus, we wouldn't get certified. Subsetting is prohibited for licensees, so Apache can not ship a subset. But the code being free software, you, personally, can ship a subset of Apache Harmony code, unless you've got a contract with Sun that prevents you from doing that. BCL, JRL, SCSL, or whatever else they have to prevent you from shipping subsets. If in doubt, ask your lawyer. cheers, dalibor topic
Re: shared code requirements
Mikhail Loenko gmail.com> writes: > > The reason I'm asking is that there is a chance that we do not have to > implement some parts. For example, Jason Hunter mentioned [1] that > swing goes as > a shared code. > > So probably we do not have to implement swing and maybe something else. > > Does anybody know what is the exact list of things which we will have to > take from Sun to be Java[tm]? Back in the old days, Sun and the JCP used to force you to include some proprietary code in a Java implementation. That's why no open source and certified implementations were possible up to last year. That's no longer the case, and no code is forcibly bundled any more. The code that was forcibly bundled was not open source, and therefore unaccaptable for Harmony anyway. In other words, we'll have to implement everything. cheers, dalibor topic
Re: FYI: Dalibor on Harmony
Geir Magnusson Jr pobox.com> writes: > > I can say this as I am a victim of the same thing... > My apologies, all the naming mistakes are mine. :( cheers, dalibor topic
Re: Platform dependent code placement (was: Re: repo layout again)
"Mark Hindess" <[EMAIL PROTECTED]> wrote on 02/23/2006 04:06:16 AM: > > I'd suggest that file is considered platform dependent if it contains > > any of "magic" platform keywords (like ia32, linux, e.t.c.) in it's > > full name. Directory name may or may not contain a "leading name". For > > example, file */linux/*.c should be considered as linux specific as > > well. Another example, file */*_linux_solaris_*/*.c is considered as > > shared between linux and solaris, but not applicable for win, e.t.c. > > I have a few concerns about this plan. > > First, that we'll end up renaming relatively simple file names like > foo_linux_solaris.c to unmanageable things like > foo_linux_solaris_aix_plan9_freebsd_osx_openbsd_ecos.c. Andrey's earlier statement about allowing the component to choose the names for specializations sounds exactly right. If you're developing the JIT you would want to split along processor lines (e.g. /ia32 /ppc) whereas the file-system interface will likely follow operating-system lines (e.g. /win32, /linux, /posix). I'm not convinced about embedding the axis of specialization (OS/ARCH) in filenames. It seems like a every new component that comes along could demand a token in the filename. Based on our experience with J9 we've also seen real value in keeping file names consistent (e.g function foo() lives in file bar.c). This helps developers form a mental map of where a given piece of functionality resides, and ultimately makes navigating a large codebase easier. For example, if a function hyfile_open() is always defined in the hyfile.c then your task is simply navigating to the correct version of hyfile.c in the directory tree. If you play tricks with the filename by appending suffixes, you become more dependent on external tools like grep or ctags to locate the right file. My vote is for consistent file names, in directories whose names are selected by the component owner. A list of 'blessed' OS and ARCH values would go a long way to helping component owners select the right directory name. > Second, if we define everything in terms of high level concepts, such > as os and arch, then we will be losing the important information about > the real distinction. This would make it harder for new developers to > understand the choices and reasoning embodied in the code. To avoid > this, we should really be defining (and using) the actual concept that > is important in making the distinction about which code to pick up. Regardless of where you start defining configuration flags (OS and ARCH seem like a good start to me) a few simple techniques can make your life easier: i) Choose names that are unlikely to conflict with system headers by adopting a suitable prefix. For example if you like: HY_ARCH or HY_OS, your code would read like: #define HY_ARCH_IA32 1 #define HY_OS_LINUX1/* this flag is turned on */ #define HY_OS_WIN320/* this flag is turned off */ ii) Produce a list of the blessed names, and the pattern for declaring new ones. This helps anyone new to the project understand what exists already. iIi) Consider using #define with values (either one or zero) so that you can use #if tests in the code. We've found this is slightly cleaner than the #ifdef(FLAGX) or defined(FLAGX) flavours. For example: #if HY_ARCH_IA32 && HY_OS_LINUX /* do something */ #else /* do something else */ #endif my $0.02 Graeme Johnson J9 VM Team, IBM Canada.
Re: FYI: Dalibor on Harmony
Geir Magnusson Jr wrote: I can say this as I am a victim of the same thing... Have you ever thought about just changing your name? :) Neva! Stefano Mazzocchi wrote: Stefano Mazzocchi wrote: Tim Ellison wrote: Since I know Dalibor will be too modest to point to it... http://www.linuxplanet.com/linuxplanet/interviews/6185/1/ Nice! Great article! of course, it would be even greater if they didn't mispell my last name, but, then again, who doesn't :-/ -- Stefano.
Re: assigned modules
Yes I am interested in documenting this thing. I dont know the best way to do it, but I was thinking if everybody could send in the following information: 1. Name 2. Module and classes working on Then I can create a simple wiki page with the above information. However, it would be very difficult for me to keep the page updated, so I guess, it would be the responsibility of each contributor to update that wiki page if he/she starts/stops working on a new module/class. Here is an example of what I am talking of. We could do something similar, though not exactly the same format. http://wiki.apache.org/jdo/AllTheOtherTests Geir Magnusson Jr wrote: We actually don't assign things because we don't want to create feelings of territory. That said, if someone is working in an area, it's courteous to show some deference in order to avoid commit clashes :) However, I think your question is different - we don't have a full classlibrary map, and that would be nice. There is some info on the wiki already. Are you interested in producing one suitable for the website? geir karan malhi wrote: How would I know what modules/classes are being worked upon already. I know JIRA is one place to look into, but it may not show a complete picture until an issue is created for a module. Is there a list i.e. spreadsheet or a wiki page where we have list of modules and volunteers working on that? -- Karan Singh
Re: [jchevm] runtime performance
Enrico Migliore wrote: I read an article that said that the performance of the SableVM, in terms of speed, was quite impressive. What's the difference between JCHEVM and the SableVM? JCHEVM should be roughly the same speed as SableVM's "direct intepreter" mode.. SableVM's "threaded interpreter" mode will be somewhat faster, as it eliminates some of the "goto" overhead assocated with each instruction. All of the above is theoretical, the best answer of course is to do some real benchmarking tests. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
[jchevm] runtime performance
Hi Ivan and Archie, > After applying your fix it no more crashes. > Just tested this with QuickSort algorithm. It's running OK. (but a bit slow under cygwin in comparison to SUN's JVM under Win) Great job! >> JCHEVM will definitely be slower right now because there's no JIT yet, i.e., it always operates in interpreter mode. It would be interestesting to run the same test on Sun's JVM, configured not to use the JIT (interpeted mode) Archie: I read an article that said that the performance of the SableVM, in terms of speed, was quite impressive. What's the difference between JCHEVM and the SableVM? Enrico
Re: assigned modules
We actually don't assign things because we don't want to create feelings of territory. That said, if someone is working in an area, it's courteous to show some deference in order to avoid commit clashes :) However, I think your question is different - we don't have a full classlibrary map, and that would be nice. There is some info on the wiki already. Are you interested in producing one suitable for the website? geir karan malhi wrote: How would I know what modules/classes are being worked upon already. I know JIRA is one place to look into, but it may not show a complete picture until an issue is created for a module. Is there a list i.e. spreadsheet or a wiki page where we have list of modules and volunteers working on that?
assigned modules
How would I know what modules/classes are being worked upon already. I know JIRA is one place to look into, but it may not show a complete picture until an issue is created for a module. Is there a list i.e. spreadsheet or a wiki page where we have list of modules and volunteers working on that? -- Karan Singh
Re: Classpath on Cygwin: failed to open native library error
snowdosker wrote: After applaing your fix it no more crashes. Cool. Just tested this with QuickSort algorithm. It's running OK. (but a bit slow under cygwin in comparison to SUN's JVM under Win) JCHEVM will definitely be slower right now because there's no JIT yet, i.e., it always operates in interpreter mode. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
Thanks, Archie. After applaing your fix it no more crashes. Just tested this with QuickSort algorithm. It's running OK. (but a bit slow under cygwin in comparison to SUN's JVM under Win) I will try some more sophisticated tests later. Thanks again, Ivan
Re: FYI: Dalibor on Harmony
I can say this as I am a victim of the same thing... Have you ever thought about just changing your name? :) Stefano Mazzocchi wrote: Stefano Mazzocchi wrote: Tim Ellison wrote: Since I know Dalibor will be too modest to point to it... http://www.linuxplanet.com/linuxplanet/interviews/6185/1/ Nice! Great article! of course, it would be even greater if they didn't mispell my last name, but, then again, who doesn't :-/
Re: FYI: Dalibor on Harmony
Stefano Mazzocchi wrote: Tim Ellison wrote: Since I know Dalibor will be too modest to point to it... http://www.linuxplanet.com/linuxplanet/interviews/6185/1/ Nice! Great article! of course, it would be even greater if they didn't mispell my last name, but, then again, who doesn't :-/ -- Stefano.
Re: Strange thing with jchevm/classpath
Jean-frederic Clere wrote:
So either something weird is happening (always possible), or you have
some
other incompatible version of log4j on your classpath, or something
in your classpath was compiled against another version of log4j, etc.
My test is using:
Class.forName("org.apache.commons.logging.impl.Log4JLogger");
I have rebuild commons-logging using the log4j I am using in the test
and the test is working now.
But I still don't understand why it was working with the Sun JVM before!!!
Probably due to classpath differences. E.g. do you have a CLASSPATH
environment variable set? Sun pays attention to it, jchevm does not.
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
[jira] Resolved: (HARMONY-124) java.nio.charset.CharsetDecoder doesn't throw CoderMalfunctionError exception when decodeLoop threw unexpected exception.
[ http://issues.apache.org/jira/browse/HARMONY-124?page=all ]
Tim Ellison resolved HARMONY-124:
-
Resolution: Fixed
Richard,
The code has been fixed in NIO_CHAR java.nio.CharsetDecoder at repo revision
381665.
Please check that the fix fully resolves your problem.
> java.nio.charset.CharsetDecoder doesn't throw CoderMalfunctionError exception
> when decodeLoop threw unexpected exception.
> -
>
> Key: HARMONY-124
> URL: http://issues.apache.org/jira/browse/HARMONY-124
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Attachments: CharsetDecoder_patch.txt, Charset_patch.txt
>
> public final CoderResult decode(ByteBuffer in, CharBuffer out, boolean
> endOfInput)
> As spec says, the method throws CoderMalfunctionError if an invocation of the
> decodeLoop method threw an unexpected exception.
> However, Harmony doesn't throws CoderMalfunctionError when decodeLoop method
> threw an unexpected exception.
> The following test cases pass on RI , but fail on Harmony.
> /*
>* Test malfunction decode(ByteBuffer)
>*/
> public void testDecode_CoderMalfunctionError() throws Exception {
> MockMalfunctionCharset cs = new MockMalfunctionCharset("mock",
> null);
> try{
>
> cs.newDecoder().onMalformedInput(CodingErrorAction.REPLACE)
>
> .onUnmappableCharacter(CodingErrorAction.REPLACE).decode(ByteBuffer.wrap(new
> byte[]{0x00,0x11}));
> fail("should throw CoderMalfunctionError");//NON-NLS-1$
> }catch(CoderMalfunctionError e){
> //expected
> }
> }
> /*
>* Test malfunction decode(ByteBuffer)
>*/
> public void testDecode_NoCoderMalfunctionError() throws Exception {
> MockMalfunctionCharset cs = new MockMalfunctionCharset("mock",
> null);
> try{
> cs.decode(ByteBuffer.wrap(new byte[]{0x00,0x11}));
> }catch(CoderMalfunctionError e){
> fail("Charset.decode should return
> silently");//NON-NLS-1
> }
> }
> /*
>* Mock charset class with malfunction decode & encode.
>*/
> static final class MockMalfunctionCharset extends Charset {
> public MockMalfunctionCharset(String canonicalName, String[]
> aliases) {
> super(canonicalName, aliases);
> }
> public boolean contains(Charset cs) {
> return false;
> }
> public CharsetDecoder newDecoder() {
> return new MockMalfunctionDecoder(this);
> }
> public CharsetEncoder newEncoder() {
> return new MockMalfunctionEncoder(this);
> }
> }
> /*
>* Mock decoder. decodeLoop always throws unexpected exception.
>*/
> static class MockMalfunctionDecoder extends
> java.nio.charset.CharsetDecoder {
> public MockMalfunctionDecoder(Charset cs) {
> super(cs, 1, 10);
> }
> protected CoderResult decodeLoop(ByteBuffer in, CharBuffer out)
> {
> throw new BufferOverflowException();
> }
> }
> /*
>* Mock encoder. encodeLoop always throws unexpected exception.
>*/
> static class MockMalfunctionEncoder extends
> java.nio.charset.CharsetEncoder {
> public MockMalfunctionEncoder(Charset cs) {
> super(cs, 1, 3, new byte[] { (byte) '?' });
> }
> protected CoderResult encodeLoop(CharBuffer in, ByteBuffer out)
> {
> throw new BufferOverflowException();
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (HARMONY-136) Cannot make libvmi.so and libhytext.so on linux
[ http://issues.apache.org/jira/browse/HARMONY-136?page=all ] Tim Ellison closed HARMONY-136: --- Verified by Richard. > Cannot make libvmi.so and libhytext.so on linux > --- > > Key: HARMONY-136 > URL: http://issues.apache.org/jira/browse/HARMONY-136 > Project: Harmony > Type: Bug > Components: Classlib > Reporter: Richard Liang > Attachments: readme_patch.txt > > Hello, > When trying to build Harmony native code on my redhat linux (RHEL 3), I fail > to make the libvmi.so. But after I convert the "makefile"(revision=379478) to > unix format using dos2unix, the "make" is successful. The same problem occurs > in module text. > in /native-src/linux.IA32/vmi/ > issue command: make > output: > cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT > -DHYX86 -I../include-c -o vmi_copyright.o vmi_copyright.c > cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT > -DHYX86 -I../include-c -o vmi.o vmi.c > cc -shared -Wl,-Map=vmi.map \ > -Wl,--version-script,vmi.exp -Wl,-soname=libvmi.so \ > -L. -L../lib -L.. -o ../libvmi.so \ > vmi_copyright.o vmi.o -Xlinker --start-group \ > : No such file or directory > make: *** [../libvmi.so] Error 1 > issue command: dos2unix makefile > issue command: make > output: > cc -shared -Wl,-Map=vmi.map \ > -Wl,--version-script,vmi.exp -Wl,-soname=libvmi.so \ > -L. -L../lib -L.. -o ../libvmi.so \ > vmi_copyright.o vmi.o -Xlinker --start-group \ > -lhyzip \ > -lhypool -Xlinker --end-group -lc -lm -ldl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: auth natives
sure thanks Stepan -- was the small fix just the loadLibrary call, or more? Talk to you tomorrow, Tim Stepan Mishura wrote: > Hi Tim, > > I reviewed source files: they look OK for me. Also I successfully (after > small fix in java code:-)) run the test for login module on Windows with > 'hyauth' library. Currently I'm trying to build Harmony and run the similar > test on Linux. Hope to finish it tomorrow. Does it works for you? > > Thanks, > Stepan. > > > On 2/28/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> Stepan, >> >> Have you completed your review? If things look ok I'll change the >> loadlibray calls to use 'hyauth'. >> >> (As I mentioned before, this is simply to bring the code in line with >> the other natives as a stepping-stone to the final native code layout >> within each module.) >> >> Thanks >> Tim >> >> Stepan Mishura wrote: >>> I've just checked out your update (have problems with network) and going >> to >>> review it. I'll let you know if I have questions or comments to your >> update. >>> BTW, we developed small tests for login modules that use these libraries >>> see: >>> 1) >>> >> modules\security\test\windows\unit\org\apache\harmony\security\x\security\auth\module\NTLoginModuleTest.java >>> 2) >>> >> modules\security\test\linux\unit\org\apache\harmony\security\x\security\auth\module\UnixLoginModuleTest.java >>> Thanks, >>> Stepan Mishura >>> Intel Middleware Products Division >>> >>> >>> >>> On 2/22/06, Tim Ellison <[EMAIL PROTECTED]> wrote: FYI: I have added the C versions of the auth natives into the build. They are building as hyayth.dll | libhyauth.so into jre/bin. However, I *haven't* removed the jaaswin.dll | libjaasnix.so code (and these are still being loaded by NTSystem.java | UnixSystem.java) until I've tested the new libraries. Regards, Tim Tim Ellison wrote: > sure -- this is the C version of the jaaswin code (including some Hy > portlib-ification), with building code in the makefile format that the > other natives use. The Linux version still needs doing, so I wanted >> to > stash it in SVN for discussion with Mikhail et al before linking it >> into > the actual build. > > Thanks > Tim > > Leo Simons wrote: >> On Thu, Feb 16, 2006 at 11:00:26PM -, [EMAIL PROTECTED] wrote: >>> Author: tellison >>> Date: Thu Feb 16 15:00:22 2006 >>> New Revision: 378390 >>> >>> URL: http://svn.apache.org/viewcvs?rev=378390&view=rev >>> Log: >>> Just stashing this code in svn, >>> not included in the build. >> When you put new things in SVN, please either make sure to have some notes next >> to them describing what it is for / what it does / what you will use >> it for or, >> failing that, write a meaningful commit message that has this info. >> >> The subversion project has a great HACKING.html that describes the >> how and the why >> and the like for this kind of thing. >> >> Thanks! >> >> Leo >> -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. >> -- >> >> Tim Ellison ([EMAIL PROTECTED]) >> IBM Java technology centre, UK. >> > > > > -- > Thanks, > Stepan Mishura > Intel Middleware Products Division > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[jira] Commented: (HARMONY-136) Cannot make libvmi.so and libhytext.so on linux
[ http://issues.apache.org/jira/browse/HARMONY-136?page=comments#action_12368099 ] Richard Liang commented on HARMONY-136: --- Thanks Tim. The fix looks good. Please close this issue. > Cannot make libvmi.so and libhytext.so on linux > --- > > Key: HARMONY-136 > URL: http://issues.apache.org/jira/browse/HARMONY-136 > Project: Harmony > Type: Bug > Components: Classlib > Reporter: Richard Liang > Attachments: readme_patch.txt > > Hello, > When trying to build Harmony native code on my redhat linux (RHEL 3), I fail > to make the libvmi.so. But after I convert the "makefile"(revision=379478) to > unix format using dos2unix, the "make" is successful. The same problem occurs > in module text. > in /native-src/linux.IA32/vmi/ > issue command: make > output: > cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT > -DHYX86 -I../include-c -o vmi_copyright.o vmi_copyright.c > cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT > -DHYX86 -I../include-c -o vmi.o vmi.c > cc -shared -Wl,-Map=vmi.map \ > -Wl,--version-script,vmi.exp -Wl,-soname=libvmi.so \ > -L. -L../lib -L.. -o ../libvmi.so \ > vmi_copyright.o vmi.o -Xlinker --start-group \ > : No such file or directory > make: *** [../libvmi.so] Error 1 > issue command: dos2unix makefile > issue command: make > output: > cc -shared -Wl,-Map=vmi.map \ > -Wl,--version-script,vmi.exp -Wl,-soname=libvmi.so \ > -L. -L../lib -L.. -o ../libvmi.so \ > vmi_copyright.o vmi.o -Xlinker --start-group \ > -lhyzip \ > -lhypool -Xlinker --end-group -lc -lm -ldl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: FYI: Dalibor on Harmony
Tim Ellison wrote: Since I know Dalibor will be too modest to point to it... http://www.linuxplanet.com/linuxplanet/interviews/6185/1/ Nice! Great article! Now let's show Dalibor that given the apache license, we can do what Classpath did in 10 years in 2 ;-) and without even writing a single line of code ;-) -- Stefano.
[jira] Updated: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments
[ http://issues.apache.org/jira/browse/HARMONY-141?page=all ] Richard Liang updated HARMONY-141: -- Attachment: CharsetEncoder_patch.txt Please try my patch. Thanks a lot. :-) > Constructors of java.nio.charset.CharsetEncoder do not validate arguments > - > > Key: HARMONY-141 > URL: http://issues.apache.org/jira/browse/HARMONY-141 > Project: Harmony > Type: Bug > Reporter: Richard Liang > Attachments: CharsetEncoder_patch.txt > > Constructors of java.nio.charset.CharsetEncoder should throw > IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments
[
http://issues.apache.org/jira/browse/HARMONY-141?page=comments#action_12368097
]
Richard Liang commented on HARMONY-141:
---
Here are the test cases which will pass on RI but fail on Harmony.
public void testConstructorIlegalAverageBytesPerChar() {
try {
Charset cs = Charset.forName("UTF-8"); //$NON-NLS-1$
CharsetEncoder encoder = new MockCharsetEncoderForHarmony141(cs,
1.1f, 1);
fail("Should throw IllegalArgumentException."); //$NON-NLS-1$
} catch (IllegalArgumentException e) {
// expected
}
}
public void testConstructorIlegalAverageBytesPerChar2() {
try {
Charset cs = Charset.forName("ISO8859-1"); //$NON-NLS-1$
CharsetEncoder encoder = new MockCharsetEncoderForHarmony141(cs,
1.1f, 1,
new byte[] { 0x1a});
fail("Should throw IllegalArgumentException."); //$NON-NLS-1$
} catch (IllegalArgumentException e) {
// expected
}
}
public static class MockCharsetEncoderForHarmony141 extends CharsetEncoder {
protected MockCharsetEncoderForHarmony141(Charset cs, float
averageBytesPerChar,
float maxBytesPerChar) {
super(cs, averageBytesPerChar, maxBytesPerChar);
}
public MockCharsetEncoderForHarmony141(Charset cs, float
averageBytesPerChar,
float maxBytesPerChar, byte[] replacement) {
super(cs, averageBytesPerChar, maxBytesPerChar, replacement);
}
protected CoderResult encodeLoop(CharBuffer in, ByteBuffer out) {
return null;
}
}
> Constructors of java.nio.charset.CharsetEncoder do not validate arguments
> -
>
> Key: HARMONY-141
> URL: http://issues.apache.org/jira/browse/HARMONY-141
> Project: Harmony
> Type: Bug
> Reporter: Richard Liang
>
> Constructors of java.nio.charset.CharsetEncoder should throw
> IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments
Constructors of java.nio.charset.CharsetEncoder do not validate arguments - Key: HARMONY-141 URL: http://issues.apache.org/jira/browse/HARMONY-141 Project: Harmony Type: Bug Reporter: Richard Liang Constructors of java.nio.charset.CharsetEncoder should throw IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: shared code requirements
The reason I'm asking is that there is a chance that we do not have to implement some parts. For example, Jason Hunter mentioned [1] that swing goes as a shared code. So probably we do not have to implement swing and maybe something else. Does anybody know what is the exact list of things which we will have to take from Sun to be Java[tm]? Thanks, Mikhail [1] http://www-128.ibm.com/developerworks/library/j-hunter/ 2006/2/27, Mikhail Loenko <[EMAIL PROTECTED]>: > Hello > > There is a number of places in the web where people are talking about > those requirements. Example: > > http://jakarta.apache.org/site/jspa-position.html > > Does anybody know whether those requirements are still valid and what exactly > code we will have to take from Sun if any? > > Thanks, > Mikhail Loenko > Intel Middleware Products Division >
Re: Strange thing with jchevm/classpath
Archie Cobbs wrote: Jean-frederic Clere wrote: I am using logging-log4j-1.2.13 and I have downloaded it. There is no such method: org/apache/log4j/Category.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljava/lang/Object;Ljava/lang/Throwable;)V in the JAR file that comes with that version of log4j. So either something weird is happening (always possible), or you have some other incompatible version of log4j on your classpath, or something in your classpath was compiled against another version of log4j, etc. That could be. I think that there was a major incompatible change made to log4j between 1.2 and 1.3 geir -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: auth natives
Hi Tim, I reviewed source files: they look OK for me. Also I successfully (after small fix in java code:-)) run the test for login module on Windows with 'hyauth' library. Currently I'm trying to build Harmony and run the similar test on Linux. Hope to finish it tomorrow. Does it works for you? Thanks, Stepan. On 2/28/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > Stepan, > > Have you completed your review? If things look ok I'll change the > loadlibray calls to use 'hyauth'. > > (As I mentioned before, this is simply to bring the code in line with > the other natives as a stepping-stone to the final native code layout > within each module.) > > Thanks > Tim > > Stepan Mishura wrote: > > I've just checked out your update (have problems with network) and going > to > > review it. I'll let you know if I have questions or comments to your > update. > > > > BTW, we developed small tests for login modules that use these libraries > > see: > > 1) > > > modules\security\test\windows\unit\org\apache\harmony\security\x\security\auth\module\NTLoginModuleTest.java > > 2) > > > modules\security\test\linux\unit\org\apache\harmony\security\x\security\auth\module\UnixLoginModuleTest.java > > > > Thanks, > > Stepan Mishura > > Intel Middleware Products Division > > > > > > > > On 2/22/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > >> FYI: I have added the C versions of the auth natives into the build. > >> They are building as hyayth.dll | libhyauth.so into jre/bin. > >> > >> However, I *haven't* removed the jaaswin.dll | libjaasnix.so code (and > >> these are still being loaded by NTSystem.java | UnixSystem.java) until > >> I've tested the new libraries. > >> > >> Regards, > >> Tim > >> > >> Tim Ellison wrote: > >>> sure -- this is the C version of the jaaswin code (including some Hy > >>> portlib-ification), with building code in the makefile format that the > >>> other natives use. The Linux version still needs doing, so I wanted > to > >>> stash it in SVN for discussion with Mikhail et al before linking it > into > >>> the actual build. > >>> > >>> Thanks > >>> Tim > >>> > >>> Leo Simons wrote: > On Thu, Feb 16, 2006 at 11:00:26PM -, [EMAIL PROTECTED] wrote: > > Author: tellison > > Date: Thu Feb 16 15:00:22 2006 > > New Revision: 378390 > > > > URL: http://svn.apache.org/viewcvs?rev=378390&view=rev > > Log: > > Just stashing this code in svn, > > not included in the build. > When you put new things in SVN, please either make sure to have some > >> notes next > to them describing what it is for / what it does / what you will use > it > >> for or, > failing that, write a meaningful commit message that has this info. > > The subversion project has a great HACKING.html that describes the > how > >> and the why > and the like for this kind of thing. > > Thanks! > > Leo > > >> -- > >> > >> Tim Ellison ([EMAIL PROTECTED]) > >> IBM Java technology centre, UK. > >> > > > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > -- Thanks, Stepan Mishura Intel Middleware Products Division
Re: auth natives
Stepan, Have you completed your review? If things look ok I'll change the loadlibray calls to use 'hyauth'. (As I mentioned before, this is simply to bring the code in line with the other natives as a stepping-stone to the final native code layout within each module.) Thanks Tim Stepan Mishura wrote: > I've just checked out your update (have problems with network) and going to > review it. I'll let you know if I have questions or comments to your update. > > BTW, we developed small tests for login modules that use these libraries > see: > 1) > modules\security\test\windows\unit\org\apache\harmony\security\x\security\auth\module\NTLoginModuleTest.java > 2) > modules\security\test\linux\unit\org\apache\harmony\security\x\security\auth\module\UnixLoginModuleTest.java > > Thanks, > Stepan Mishura > Intel Middleware Products Division > > > > On 2/22/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> FYI: I have added the C versions of the auth natives into the build. >> They are building as hyayth.dll | libhyauth.so into jre/bin. >> >> However, I *haven't* removed the jaaswin.dll | libjaasnix.so code (and >> these are still being loaded by NTSystem.java | UnixSystem.java) until >> I've tested the new libraries. >> >> Regards, >> Tim >> >> Tim Ellison wrote: >>> sure -- this is the C version of the jaaswin code (including some Hy >>> portlib-ification), with building code in the makefile format that the >>> other natives use. The Linux version still needs doing, so I wanted to >>> stash it in SVN for discussion with Mikhail et al before linking it into >>> the actual build. >>> >>> Thanks >>> Tim >>> >>> Leo Simons wrote: On Thu, Feb 16, 2006 at 11:00:26PM -, [EMAIL PROTECTED] wrote: > Author: tellison > Date: Thu Feb 16 15:00:22 2006 > New Revision: 378390 > > URL: http://svn.apache.org/viewcvs?rev=378390&view=rev > Log: > Just stashing this code in svn, > not included in the build. When you put new things in SVN, please either make sure to have some >> notes next to them describing what it is for / what it does / what you will use it >> for or, failing that, write a meaningful commit message that has this info. The subversion project has a great HACKING.html that describes the how >> and the why and the like for this kind of thing. Thanks! Leo >> -- >> >> Tim Ellison ([EMAIL PROTECTED]) >> IBM Java technology centre, UK. >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[jira] Commented: (HARMONY-136) Cannot make libvmi.so and libhytext.so on linux
[ http://issues.apache.org/jira/browse/HARMONY-136?page=comments#action_12368093 ] Tim Ellison commented on HARMONY-136: - Thanks Richard, patched the README.txt at repo revision 381630. > Cannot make libvmi.so and libhytext.so on linux > --- > > Key: HARMONY-136 > URL: http://issues.apache.org/jira/browse/HARMONY-136 > Project: Harmony > Type: Bug > Components: Classlib > Reporter: Richard Liang > Attachments: readme_patch.txt > > Hello, > When trying to build Harmony native code on my redhat linux (RHEL 3), I fail > to make the libvmi.so. But after I convert the "makefile"(revision=379478) to > unix format using dos2unix, the "make" is successful. The same problem occurs > in module text. > in /native-src/linux.IA32/vmi/ > issue command: make > output: > cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT > -DHYX86 -I../include-c -o vmi_copyright.o vmi_copyright.c > cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT > -DHYX86 -I../include-c -o vmi.o vmi.c > cc -shared -Wl,-Map=vmi.map \ > -Wl,--version-script,vmi.exp -Wl,-soname=libvmi.so \ > -L. -L../lib -L.. -o ../libvmi.so \ > vmi_copyright.o vmi.o -Xlinker --start-group \ > : No such file or directory > make: *** [../libvmi.so] Error 1 > issue command: dos2unix makefile > issue command: make > output: > cc -shared -Wl,-Map=vmi.map \ > -Wl,--version-script,vmi.exp -Wl,-soname=libvmi.so \ > -L. -L../lib -L.. -o ../libvmi.so \ > vmi_copyright.o vmi.o -Xlinker --start-group \ > -lhyzip \ > -lhypool -Xlinker --end-group -lc -lm -ldl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: procedure after checkout
Hi Karan, I neglected to mention in my previous response that if you think you could get involved with "component-ising" (or otherwise enhancing) the Ant build scripts then that would be a real help to everyone. Best regards, George IBM UK karan malhi wrote: Hi, Need help with the procedure to follow after checkout. Do we need to re-run ant using make/build.xml after every checkout ? Is there any plan to use maven?
[jira] Resolved: (HARMONY-137) CharsetDecoder should replace undefined bytes with replacement string
[ http://issues.apache.org/jira/browse/HARMONY-137?page=all ]
Tim Ellison resolved HARMONY-137:
-
Resolution: Won't Fix
For the reasons Richard and the ICU team give, this is being marked as won't
fix.
> CharsetDecoder should replace undefined bytes with replacement string
> -
>
> Key: HARMONY-137
> URL: http://issues.apache.org/jira/browse/HARMONY-137
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Vladimir Strigun
> Priority: Minor
>
> Corresponding to cp1250 mapping table, 0x81 byte is undefined. See
> http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1250.TXT
> So, charset decoder should replace undefined bytes with default replacement,
> i.e. 0xFFFD.
> Testcase for reproducing this issue:
> import java.nio.charset.*;
> import java.nio.*;
> public class Harmony137 {
> public static void main(String[] args) throws Exception {
> ByteBuffer bb = ByteBuffer.allocate(5);
> bb.put((byte)0x81); bb.flip();
> Charset cp1250 = Charset.forName("cp1250");
> CharBuffer cb =
> cp1250.newDecoder().onMalformedInput(CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE).decode(bb);
> if(cb.get(0)!=65533) {
> System.out.println("FAIL: expected 0xFFFD but result is:
> 0x"+Integer.toHexString(cb.get(0)).toUpperCase());
> }
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
Geir Magnusson Jr wrote: Anton Avtamonov wrote: On 2/27/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: As I understood people in this and similar threads tend to be compatible with the Spec rather then with RI (unless we prove that being incompatible with RI breaks some existing implementation) I'm trying to oppose that, I'd to be compatible with RI when in doubt. Well, actually you are right. I disagree just to simply copy all the existing bugs... And as I rememeber I'm not along :-). The main idea is to follow the guidelines Paulex proposed, i.e. to be reasonable. Lemme remember Paulex's rules: 1. we should comply with spec 2. if RI is contradict with spec, and RI is not logical(sometimes it is very obvious, you know what I mean), we comply with RI; else, we discuss it case by case. 3. if spec is not so clear, we should comply with RI 4. if some application failing on that different behavior, we discuss it case by case 5. Log every difference from either the spec or the RI in JIRA. +1 from me. I believe this approach will give better results: keepping us compatible with the existing applications and provide more consistent implementation where possible. Note that according to the rules above we are not mandatory follow to the spec. Btw, releasing new JDK SUN updates some existing methods, sometimes changing not only internal implementation, but even some behavior. I suppose they don't run all existing applications to make sure nothing is broken :-). I don't know how this process is organized, however I would expect some kind of CCB (Change Control Board) which decide if it's safe change or not. I suppose our mailing list can act in a very similar manner. Actually, I think that Sun does have an internal group which does exactly that. I've heard some great stories about the raging fights that have erupted internally due to this process... We'll get to have our great fights here :) That's the way to harmony ;-) geir -- Anton Avtamonov, Intel Middleware Products Division -- Paulex Yang China Software Development Lab IBM
Re: procedure after checkout
Hi Karan, Yes, at the moment, running the top level make/build.xml script is required after every checkout. The outlook is for the Ant building logic to eventually get devolved down to separate Ant scripts in each individual module so they will be capable of building just themselves. This componentised building should save the overhead of a "full build" when files in just one module have been changed. A full build will involve the top level Ant scripts calling down into each module's Ant script in turn. If you are working in just one module (e.g. luni or nio etc) and you are an Eclipse user then Tim's instructions on working inside the Eclipse workspace will be of interest to you [1] ; particularly as it does not require carrying out full builds. Best regards, George IBM UK [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/dev_eclipse.html karan malhi wrote: Hi, Need help with the procedure to follow after checkout. Do we need to re-run ant using make/build.xml after every checkout ? Is there any plan to use maven?
[jira] Commented: (HARMONY-137) CharsetDecoder should replace undefined bytes with replacement string
[
http://issues.apache.org/jira/browse/HARMONY-137?page=comments#action_12368087
]
Richard Liang commented on HARMONY-137:
---
Please see the bug info in ICU bug system:
http://bugs.icu-project.org/cgi-bin/icu-bugs?findid=5085&go=Go
And attached here is ICU team's response to this bug:
You are expecting incorrect behavior from cp1250. Both Microsoft's conversion
APIs and IBM mapping tables convert byte 81 to Unicode character 0081. This
conversion behavior will not change. The tables on unicode.org may tell you
about the official mappings, but there are other mappings that are commonly
expected.
More details about ICU charset conversion can be found on this page:
http://icu.sourceforge.net/charts/charset/
This charset conversion works as expected.
> CharsetDecoder should replace undefined bytes with replacement string
> -
>
> Key: HARMONY-137
> URL: http://issues.apache.org/jira/browse/HARMONY-137
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Vladimir Strigun
> Priority: Minor
>
> Corresponding to cp1250 mapping table, 0x81 byte is undefined. See
> http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1250.TXT
> So, charset decoder should replace undefined bytes with default replacement,
> i.e. 0xFFFD.
> Testcase for reproducing this issue:
> import java.nio.charset.*;
> import java.nio.*;
> public class Harmony137 {
> public static void main(String[] args) throws Exception {
> ByteBuffer bb = ByteBuffer.allocate(5);
> bb.put((byte)0x81); bb.flip();
> Charset cp1250 = Charset.forName("cp1250");
> CharBuffer cb =
> cp1250.newDecoder().onMalformedInput(CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE).decode(bb);
> if(cb.get(0)!=65533) {
> System.out.println("FAIL: expected 0xFFFD but result is:
> 0x"+Integer.toHexString(cb.get(0)).toUpperCase());
> }
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (HARMONY-125) Removed duplicate header files.
[ http://issues.apache.org/jira/browse/HARMONY-125?page=all ] Tim Ellison closed HARMONY-125: --- Verified by Mark. > Removed duplicate header files. > --- > > Key: HARMONY-125 > URL: http://issues.apache.org/jira/browse/HARMONY-125 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Mark Hindess > Assignee: Tim Ellison > Priority: Trivial > > The header files: > win.IA32/archive/jcl.h > win.IA32/math/jcl.h > linux.IA32/nio/jcl.h > are duplicates of the *.IA32/common/jcl.h header files and can be removed > without affecting the resulting code. > I wont attach a patch since it's too trivial. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Strange thing with jchevm/classpath
Archie Cobbs wrote:
Jean-frederic Clere wrote:
I am using logging-log4j-1.2.13 and I have downloaded it.
There is no such method:
org/apache/log4j/Category.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljava/lang/Object;Ljava/lang/Throwable;)V
in the JAR file that comes with that version of log4j.
So either something weird is happening (always possible), or you have
some
other incompatible version of log4j on your classpath, or something
in your classpath was compiled against another version of log4j, etc.
My test is using:
Class.forName("org.apache.commons.logging.impl.Log4JLogger");
I have rebuild commons-logging using the log4j I am using in the test
and the test is working now.
But I still don't understand why it was working with the Sun JVM before!!!
Cheers
Jean-Frederic
-Archie
__
Archie Cobbs *CTO, Awarix*
http://www.awarix.com
