Re: [APR-JAVA] cvs upload
William A. Rowe, Jr. wrote: I agree with you. After all, the main focus is Tomcat support, as APR's main focus is Httpd support. Outch! Hope that isn't the worldwide impression; When it will have apr_free then it will be free of httpd spirit :). Clearly, your interface will be broader than apr. When you do encounter the need for abstracting apr specifically, I do hope you consider doing this in a concerted effort. A reply to my post on [EMAIL PROTECTED], that an oo-dev abstraction effort is worthwhile, wanted, or you want to participate in, would be most appreciated. I'm surely do. I've started the apr-java project as a two way interface, with apr being capable to use java and vice versa. This is far more complex then what we need for tomcat, but other projects like commons/daemon could benefit from it. For example we have there three separate codebases resolving the JVM loading, so portable solution would be welcome. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [APR-JAVA] cvs upload
At 01:25 AM 1/14/2005, Mladen Turk wrote: >Costin Manolache wrote: >>To be honest, I don't like where this is going. I think access to native >>functionality for tomcat is great - and starting with functionality provided >>by apr is ok. But there is a lot outside apr, and if this becomes 'apr - java >>interface', it won't be easy to add. > >I agree with you. After all, the main focus is Tomcat support, >as APR's main focus is Httpd support. Outch! Hope that isn't the worldwide impression; http://apr.apache.org/projects.html Other portability-related issues are also welcomed, discussed and oftentimes adopted! For example - multicast is fairly useless to http: scheme, but development of multicast is lively and progressing well, and is subject to tcp/ip implementation quirks and deviations. Yes it sprouted from httpd's portability needs, but work continues apace and it's been a -long- time since I heard the refrain "We don't need to do that, it's not required by httpd." That train of thought gets slapped down fast :) However, apr isn't a dumping ground. If the concern isn't really portability, but more akin to library wrappers and so on, those items end up in the apr-util (dumping ground) of nice-to-have sorts of features, or sometimes dismissed out of hand. >One of the goals is to add openssl support, as well as witting >Servlet API four using by legacy applications (like module interface >for httpd). >Perhaps my posts led to wrong presumption that this is only JNI >wrapper over APR library. Probably my confusion. >>So maybe it would be better to rename it to org.apache.tomcat.jni or >>something, keep the apr stuff as 'tomcat interface with apr' ( with a comment >>that when/if apr does have an official binding - we can switch), and keep it >>open for the other non-apr stuff that may be interesting. > >Sure, org.apache.tomcat.jni would be fine, and even better reflect the >purpose of the package. Clearly, your interface will be broader than apr. When you do encounter the need for abstracting apr specifically, I do hope you consider doing this in a concerted effort. A reply to my post on [EMAIL PROTECTED], that an oo-dev abstraction effort is worthwhile, wanted, or you want to participate in, would be most appreciated. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [APR-JAVA] cvs upload
Costin Manolache wrote: To be honest, I don't like where this is going. I think access to native functionality for tomcat is great - and starting with functionality provided by apr is ok. But there is a lot outside apr, and if this becomes 'apr - java interface', it won't be easy to add. I agree with you. After all, the main focus is Tomcat support, as APR's main focus is Httpd support. One of the goals is to add openssl support, as well as witting Servlet API four using by legacy applications (like module interface for httpd). Perhaps my posts led to wrong presumption that this is only JNI wrapper over APR library. So maybe it would be better to rename it to org.apache.tomcat.jni or something, keep the apr stuff as 'tomcat interface with apr' ( with a comment that when/if apr does have an official binding - we can switch), and keep it open for the other non-apr stuff that may be interesting. Sure, org.apache.tomcat.jni would be fine, and even better reflect the purpose of the package. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [APR-JAVA] cvs upload
To be honest, I don't like where this is going. I think access to native functionality for tomcat is great - and starting with functionality provided by apr is ok. But there is a lot outside apr, and if this becomes 'apr - java interface', it won't be easy to add. So maybe it would be better to rename it to org.apache.tomcat.jni or something, keep the apr stuff as 'tomcat interface with apr' ( with a comment that when/if apr does have an official binding - we can switch), and keep it open for the other non-apr stuff that may be interesting. Costin William A. Rowe, Jr. wrote: At 01:56 PM 1/13/2005, Mladen Turk wrote: William A. Rowe, Jr. wrote: org.apache.apr... ??? If this is private, and you've suggested it should be, don't you mean org.apache.jakarta.apr... ? He he :) I didn't said it should be private to J-T-C nor Jakarta. But the fact is that we don't have OO languages infrastructure for APR glue code. Seems to me that we'll need to go through incubation to create self standing apr-java project, or something like apr-oo/java. Self standing? If apr is borked (and the oo-dev'ers prove it) do you want another layer in the middle? This probably should be closely paired to apr to ensure communications and direction. Having them both under the same pmc ensures that the apr project doesn't go off on some weird tangent that interferes with oo implementations (not that I expect this would happen.) If you think we can make something like that in a reasonable amount of time, count me in. Happy to encourage it and I'll present it (with myself as a list moderator) to the apr project, and invite our modperl friends along with John Sterling and others who have created C++ wrappers. In other case I can rename the package to whatever name desired if it breaks some policy or something like. This sort of surprises me coming from an ASF java developer. I seriously doubt this team would find it amusing to discover org.apache.catalina namespaces populating an xml project's code. -1 on appropriating another ASF project's namespace (the same -1 I should have offered to forking proxy.) +/-0 if you want to build on org.apache.jk.apr namespace. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [APR-JAVA] cvs upload
At 01:56 PM 1/13/2005, Mladen Turk wrote: >William A. Rowe, Jr. wrote: >>org.apache.apr... ??? >>If this is private, and you've suggested it should be, don't you mean >>org.apache.jakarta.apr... ? > >He he :) > >I didn't said it should be private to J-T-C nor Jakarta. >But the fact is that we don't have OO languages infrastructure >for APR glue code. Seems to me that we'll need to go through >incubation to create self standing apr-java project, or >something like apr-oo/java. Self standing? If apr is borked (and the oo-dev'ers prove it) do you want another layer in the middle? This probably should be closely paired to apr to ensure communications and direction. Having them both under the same pmc ensures that the apr project doesn't go off on some weird tangent that interferes with oo implementations (not that I expect this would happen.) >If you think we can make something like that in a reasonable >amount of time, count me in. Happy to encourage it and I'll present it (with myself as a list moderator) to the apr project, and invite our modperl friends along with John Sterling and others who have created C++ wrappers. >In other case I can rename the package to whatever name desired >if it breaks some policy or something like. This sort of surprises me coming from an ASF java developer. I seriously doubt this team would find it amusing to discover org.apache.catalina namespaces populating an xml project's code. -1 on appropriating another ASF project's namespace (the same -1 I should have offered to forking proxy.) +/-0 if you want to build on org.apache.jk.apr namespace. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [APR-JAVA] cvs upload
William A. Rowe, Jr. wrote: org.apache.apr... ??? If this is private, and you've suggested it should be, don't you mean org.apache.jakarta.apr... ? He he :) I didn't said it should be private to J-T-C nor Jakarta. But the fact is that we don't have OO languages infrastructure for APR glue code. Seems to me that we'll need to go through incubation to create self standing apr-java project, or something like apr-oo/java. If you think we can make something like that in a reasonable amount of time, count me in. In other case I can rename the package to whatever name desired if it breaks some policy or something like. Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [APR-JAVA] cvs upload
org.apache.apr... ??? If this is private, and you've suggested it should be, don't you mean org.apache.jakarta.apr... ? Bill At 04:25 AM 1/13/2005, Mladen Turk wrote: >Hi all, > >You can find the sources at: >http://www.apache.org/~mturk/ >File is: >http://www.apache.org/~mturk/apr-java.tar.gz > >My intention is to put that inside: >jakarta-tomcat-connectors/apr-java > >Although OtherBill thinks this is not a proper >place to put that code, IMO until we have a >generic infrastructure inside APR for OO languages >glue code it can be placed here thought. > >How to build the library: >WIN32: >1. You will need system environment variable > JAVA_HOME that points to J2SDK installation path >2. Create directory of your choice and unpack > apr-1.0.1.tar.gz in directory apr. >3. Unpack apr-java.tar.gz > >It should look like: >\apr >\apr-java > >4. Build APR >5. Build APR-JAVA >6. cd java\org\apache\apr\jni >7. javac *.java >8. copy libapr-1.dll to java directory >9. copy libaprjava-1.dll to java directory >10. cd java >11. java org.apache.apr.jni.Test > >UNIX: >1. export JAVA_HOME=/path/to/the/java >2. mkdir work >3. cd work >4. tar zxf /path/to/apr-1.0.1.tar.gz >5. tar zxf /path/to/apr-java.tar.gz >Building APR >7. cd apr-1.0.1 >8. ./configure >9. make >10. make install >11. cd ../apr-java >12. ./buildconf --with-apr=../apr-1.0.1 >13. ./configure --with-apr=../apr-1.0.1 > or ./configure --with-apr=/usr/local/apr >14. make >15. make install >16. export LD_LIBRARY_PATH=/usr/local/apr/lib >17. cd java >18. $JAVA_HOME/bin/javac org/apache/apr/jni/*.java >19. $JAVA_HOME/bin/java org.apache.apr.jni.Test > > >That's it. > >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]
[APR-JAVA] cvs upload
Hi all, You can find the sources at: http://www.apache.org/~mturk/ File is: http://www.apache.org/~mturk/apr-java.tar.gz My intention is to put that inside: jakarta-tomcat-connectors/apr-java Although OtherBill thinks this is not a proper place to put that code, IMO until we have a generic infrastructure inside APR for OO languages glue code it can be placed here thought. How to build the library: WIN32: 1. You will need system environment variable JAVA_HOME that points to J2SDK installation path 2. Create directory of your choice and unpack apr-1.0.1.tar.gz in directory apr. 3. Unpack apr-java.tar.gz It should look like: \apr \apr-java 4. Build APR 5. Build APR-JAVA 6. cd java\org\apache\apr\jni 7. javac *.java 8. copy libapr-1.dll to java directory 9. copy libaprjava-1.dll to java directory 10. cd java 11. java org.apache.apr.jni.Test UNIX: 1. export JAVA_HOME=/path/to/the/java 2. mkdir work 3. cd work 4. tar zxf /path/to/apr-1.0.1.tar.gz 5. tar zxf /path/to/apr-java.tar.gz Building APR 7. cd apr-1.0.1 8. ./configure 9. make 10. make install 11. cd ../apr-java 12. ./buildconf --with-apr=../apr-1.0.1 13. ./configure --with-apr=../apr-1.0.1 or ./configure --with-apr=/usr/local/apr 14. make 15. make install 16. export LD_LIBRARY_PATH=/usr/local/apr/lib 17. cd java 18. $JAVA_HOME/bin/javac org/apache/apr/jni/*.java 19. $JAVA_HOME/bin/java org.apache.apr.jni.Test That's it. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
