Re: [INTRODUCE] apr-java
At 12:03 PM 1/11/2005, Mladen Turk wrote: William A. Rowe, Jr. wrote: Silly Question - doesn't this proposal fit better in the commons project than Tomcat? Perhaps, but the guys that are interested in both c and Java live inside J-T-C :). Actually, the converse is true - tomcat-dev is modestly high traffic high number of subscribers. The interest in this nitch is probably much lower across tomcat-dev subscribers (the ones who want to be here, not the ones who manage to subscribe post let me out 3 days later :-) And since it will be buildable independent of any connector code, it could be moved to commons or even apr. ??? If you don't have apr - it seems a little problematic to build an apr-jni interface. The reason I suggest this is that we have .pkg and .rpm folks supporting standardized apr 0.9 / 1.x installs. Well that's OK, but the apr-java consists of two parts: native library and .jar file, requires Java SDK installed, etc. Of course. There is glue on both sides. To build an apr xs thunk, one needs perl, to build an apr c++ wrapper, one needs c++ (which apr doesn't require.) Same if there was an apr .NET wrapper. I'm thinking in terms of optional components buildable under the apr tree, when the appropriate choices are made. The point I was making is that it would be a shame to reinvent the object model of APR for several different languages. Any robust APR-wrapper object model should prove exceedingly consistent (to the developer/user) between langauges, although the glue varies wildly. This has all already been accomplished by our devoted modperl developers. Why not fold all such special interests? If this is of little interest to [EMAIL PROTECTED] in general, we can always spin of [EMAIL PROTECTED] for object and glue discussions. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [INTRODUCE] apr-java
Silly Question - doesn't this proposal fit better in the commons project than Tomcat? For that matter, I'm rolling the dice that the apr project itself would entertain the possibilities of supporting jni / xs / c++ wrappers. The reason I suggest this is that we have .pkg and .rpm folks supporting standardized apr 0.9 / 1.x installs. To keep these in sync would ultimately become quite important. The second reason is that we should truly adopt consistent OO conventions for all of these varied extension schemas. Bill At 08:25 AM 1/7/2005, Mladen Turk wrote: Hi, Here is the work in progress for a new project I named apr-java. It offers a 'thin' layer using JNI over APR library. The initial code that I wrote over a year now had two way api, but I've decided to leave only Java-APR. I also have a working set of configure and make files for unixes, but since this is an overview of the technology, it's only a small subset of entire project, but you can get the picture :) . It will support around 90% of APR API (without things like strings, etc. that are well done inside java itself). The API itself on the Java side is done as close to the APR function call (apr_file_write - File.write) with almost the same function parameters as well. You can see that the wrapping code is very thin in most cases with only a couple of lines for each function, mostly caused by pointer issues. I'm sending the gz file (tried zip but failed) so you can see what the general idea is. Of course the library can be extended with functions that APR doesn't offer (for now or never will). One of the things would be setting user and group for a process, sending data from parent to child process, etc. The question is: Is it acceptable (think that previous discussions say it is) Where to put that in the cvs. Comments? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [INTRODUCE] apr-java
William A. Rowe, Jr. wrote: Silly Question - doesn't this proposal fit better in the commons project than Tomcat? Perhaps, but the guys that are interested in both c and Java live inside J-T-C :). And since it will be buildable independent of any connector code, it could be moved to commons or even apr. The reason I suggest this is that we have .pkg and .rpm folks supporting standardized apr 0.9 / 1.x installs. Well that's OK, but the apr-java consists of two parts: native library and .jar file, requires Java SDK installed, etc. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[INTRODUCE] apr-java
Hi, Here is the work in progress for a new project I named apr-java. It offers a 'thin' layer using JNI over APR library. The initial code that I wrote over a year now had two way api, but I've decided to leave only Java-APR. I also have a working set of configure and make files for unixes, but since this is an overview of the technology, it's only a small subset of entire project, but you can get the picture :) . It will support around 90% of APR API (without things like strings, etc. that are well done inside java itself). The API itself on the Java side is done as close to the APR function call (apr_file_write - File.write) with almost the same function parameters as well. You can see that the wrapping code is very thin in most cases with only a couple of lines for each function, mostly caused by pointer issues. I'm sending the gz file (tried zip but failed) so you can see what the general idea is. Of course the library can be extended with functions that APR doesn't offer (for now or never will). One of the things would be setting user and group for a process, sending data from parent to child process, etc. The question is: Is it acceptable (think that previous discussions say it is) Where to put that in the cvs. Comments? Regards, Mladen. apr-java.tar.gz Description: application/gunzip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [INTRODUCE] apr-java
awesome, i'll check it out tonight. You rock mladen! peter On Fri, 07 Jan 2005 15:25:07 +0100, Mladen Turk [EMAIL PROTECTED] wrote: Hi, Here is the work in progress for a new project I named apr-java. It offers a 'thin' layer using JNI over APR library. The initial code that I wrote over a year now had two way api, but I've decided to leave only Java-APR. I also have a working set of configure and make files for unixes, but since this is an overview of the technology, it's only a small subset of entire project, but you can get the picture :) . It will support around 90% of APR API (without things like strings, etc. that are well done inside java itself). The API itself on the Java side is done as close to the APR function call (apr_file_write - File.write) with almost the same function parameters as well. You can see that the wrapping code is very thin in most cases with only a couple of lines for each function, mostly caused by pointer issues. I'm sending the gz file (tried zip but failed) so you can see what the general idea is. Of course the library can be extended with functions that APR doesn't offer (for now or never will). One of the things would be setting user and group for a process, sending data from parent to child process, etc. The question is: Is it acceptable (think that previous discussions say it is) Where to put that in the cvs. Comments? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [INTRODUCE] apr-java
Mladen Turk wrote: Hi, Here is the work in progress for a new project I named apr-java. It offers a 'thin' layer using JNI over APR library. The initial code that I wrote over a year now had two way api, but I've decided to leave only Java-APR. I also have a working set of configure and make files for unixes, but since this is an overview of the technology, it's only a small subset of entire project, but you can get the picture :) . It will support around 90% of APR API (without things like strings, etc. that are well done inside java itself). The API itself on the Java side is done as close to the APR function call (apr_file_write - File.write) with almost the same function parameters as well. You can see that the wrapping code is very thin in most cases with only a couple of lines for each function, mostly caused by pointer issues. I'm sending the gz file (tried zip but failed) so you can see what the general idea is. Of course the library can be extended with functions that APR doesn't offer (for now or never will). One of the things would be setting user and group for a process, sending data from parent to child process, etc. The question is: Is it acceptable (think that previous discussions say it is) Where to put that in the cvs. Comments? Looks good. It seems it still does a lot of String operations in native - unlike SWT for example, where it's almost always byte[]. Also the typical memcpy, etc should be included somewhere to allow data to move from/to the pool and java heap. Why not checking it in j-t-c ? Just to make sure - you expect it to also have non-apr native methods ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [INTRODUCE] apr-java
Costin Manolache wrote: Comments? Looks good. It seems it still does a lot of String operations in native - unlike SWT for example, where it's almost always byte[]. Well the strings are used for non-frequent operations like file opening etc, for which you'll probably use String.getBytes() anyhow. The apr has a nice feature that its file operation supports UTF, so the cost is minimal thought. Perhaps only puts and similar operations should be changed to byte. Everything else is byte[]. Also the typical memcpy, etc should be included somewhere to allow data to move from/to the pool and java heap. Well, apr pools should be used only for allocating apr object not memory itself. Why not checking it in j-t-c ? Just to make sure - you expect it to also have non-apr native methods ? Yes. Inside file win32,netware,unix. For start it will be mostly the code already written for either used by Apache2 like setgrp, setuid when launching child process. That code should really be minimal and agreed in front. I don't wish that this ends like a messy repository for lots of junk code. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
