You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Mark R. Diggory" <md...@latte.harvard.edu> on 2003/03/10 02:01:25 UTC
Re: jakarta-commons-daemon could use that ?
(Please excuse the cross post, I wanted to get this out onto the the
Commons Development List and to JPackage as well. I think the Tomcat
Lists seem to get a little crowded)
Henri,
I emailed the developer of Easy Posix (Greg Guerin). Turns out that its
current implementation is dependent upon "Ten" , a Mac OS X package for
MacJVM, so it is not deployable in the standard Linux OS.
From my conversation with him, he spoke that he is planning to develop
a straight JNI implementation of the EasyPosix interfaces in the future,
but that if others went that route earlier he would have an interest.
As there has already been much work in the JNI area with daemon, this
would certainly seem an interesting co-evolution. Perhaps daemon could
grow into quite a powerful java based service environment with the
addition of a JNI Implementation of EasyPosix?!
Cygwin supports a wide array of posix functions, and making sure the
implementation of EasyPosix that worked on cygwin as well would provide
a port of these functions to Windows via Cygwin.
Perhaps, even a "standard" could evolve to support a specific subset of
posix-like Functions. Using something like EasyPosix as a guide, a java
program (daemon or not) that needed greater access to POSIX functions
could be ported to any system that EasyPosix was supported on,
completely independent of its implementation on that system. It would
possibly make "java services" quite cross-platform for at least in the
unix/linux/darwin/cygwin world.
Another point of interest: If JPackage produced a Tomcat RPM based on
the current implementation of daemon and another implementation of
daemon based on EasyPosix were developed. It would be easy to adapt to
such a change. In the end, this would possibly make EasyPosix the means
by which daemon could be ported to Darwin/Mac without the wieght of
compiling or porting a JNI implementation.
-Mark
Henri Gomez wrote:
> I didn't track jakarta-commons-daemon but I know many of you here
> which are subscribed to it.
>
> What do you think of easyposix ?
>
> http://www.amug.org/~glguerin/sw/easyposix/overview.html
>
> Couldn't it be a nice add-on for daemon ?
>
> It's still related to tomcat since I need a very complete
> java service launcher for tomcat, and this easyposix as
> very nice features.
>
> Comments welcomed
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Greg Guerin wrote:
> The supplied code only provides a Mac OS X implementation. That
> implementation uses JDirect-3, which is an Apple-specific means to call
> arbitrary native-code functions directly from Java, without an
intervening
> JNI layer.
>
> All other platforms will need a JNI implementation for that platform.
> Absent a JNI implementation, the "unimplemented" implementation is used,
> i.e. UnPosix. See the docs for UnPosix for more details.
>
> You could pattern a JNI imp off the Mac OS X imp. The mapping of the Mac
> OS X implementation to JNI functions, and the bodies of the JNI functions
> themselves, should be fairly straightforward. That's because all the
> 'native' methods in the Ten class are essentially the names of C
functions
> in the BSD/Posix library. Getting the callbacks right is a little
> trickier, but well within the skill-set of a capable JNI programmer.
>
> FYI, I have "write Easy Posix JNI imp" on my list of projects to do, but
> it's several items down in the queue right now, and at least a couple
> months or more away from getting to the head of the queue. The
source may
> not be instantly portable to Linux, but it shouldn't be so different that
> it would be useless as a starting point. Or, if you wrote a JNI imp for
> Linux before I get to the JNI imp for Mac OS X, I wouldn't mind the
> positions being reversed.
>
>
>
>
>>On another note, Apache has another package they've been working on that
>>is a java based "daemon" for running Java programs as daemons on both
>>Unix and Windows.
>>
>>http://jakarta.apache.org/commons/sandbox/daemon/
>>
>>Henri Gomez (of www.jpackage.org - the packagers of the tomcat and other
>>java based rpm's) and I reviewed your site and suggested to both Apache
>>and JPackage that they should seriously take a look at your package as
>>an additional tool for controlling Java based Daemons.
>>
>>While I am not actually an Apache developer, I have a great interest in
>>the organization, regularly use the tools they develop and often try to
>>make recommendations to improve the tools. I try to provide avenues for
>>improvement when I see external open source tools that are benificial. I
>>think the Apache Jakarta Commons project "Daemon" is a good start, and a
>>natural growth for a generic tool out of the Tomcat source-base, but its
>>obvious that your package captures alot more functionality above and
>>beyond that of "Daemon".
>
>
> That makes sense, since I was interested in the underlying POSIX
facilities
> themselves, not the nature of the program (deamon vs. non-daemon) that
> called the POSIX facilities. The daemonic nature is a different question
> altogether. Not unimportant, just different.
>
> -- GG
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jakarta-commons-daemon could use that ?
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Thats fine, however, if you do find an interest in any of our
discussion, we would love to hear from you again. "The ideas must flow!"
I'll leave you off any emails from this point on. Thank you for
answering my questions.
Cheers,
Mark
Greg Guerin wrote:
>Mark et al.
>
>Please leave me out of these discussions. I have no side to take, and no
>agenda to push.
>
>If you decide to use Easy Posix Toolkit, that's fine. If you decide not
>to, that's fine, too.
>
>If you write a JNI implementation for Linux, I'd like to hear about it. If
>you don't, then I guess I don't need to hear about it.
>
>Thanks for your consideration.
>
> -- GG
>
>
>
>
>
>
>
>
>>jean-frederic clere wrote:
>>
>>
>>>Mark R. Diggory wrote:
>>>
>>>
>>>>Cygwin supports a wide array of posix functions, and making sure the
>>>>implementation of EasyPosix that worked on cygwin as well would
>>>>provide a port of these functions to Windows via Cygwin.
>>>>
>>>>
>>>I am afraid that is not a very accepted solution. jakarta-commons-daemon
>>>(service) uses Cygwin and a lot of people were complaining about that.
>>>
>>>
>>>
>>I can see why Windows developers would complain; Cygwin isn't very
>>popular with them because itís so "divergent" from their "paradigm". I
>>wouldn't suggest it if it werenít that its almost the cases that if it
>>runs on Unix, it will run on Cygwin with just a little modification. I
>>never understood why someone would want to run Windows as a server, but
>>I'll avoid any Windows OS bashing as I'm typing this email on one at the
>>moment and that would seem hipocritical. ;-)
>>
>>
>>
>>>Apache has an already portable runtime: APR. It would be probably more
>>>efficient to bring an APR interface to JNI than to use a new runtime.
>>>And that is already some code in jakarta-connectors.
>>>
>>>
>>YES, Yet anothor reason to consider another "layer" similar to EasyPosix
>>for daemon and other services requiring the native OS access to run
>>upon. Then you can have one implementation of daemon/connectors that can
>>run on multiple implmentations of Easy-Posix. This is a case for mapping
>>a set of Easy-Posix commands/functions through the APR as well. Consider
>>that there may be a *Union* of shared functionality currently captured
>>through JNI --> APR, JNI --> Ten and JNI --> Posix.
>>
>>What I'm suggesting is not to "isolate" the daemon service to one
>>particular native solution. By adding a layer of "OS functionality"
>>between the OS and the daemon, the daemon can stay a conceptually simple
>>interface/implementation and the *functionality of the OS* can be
>>captured at the *level of its functionality*, making it possible to
>>"extend" that functionality across different systems without many
>>different versions of daemon (which is a tiny subset of that
>>functionality). In theory, what we are talking about is a means to
>>"extend" the JVM's capabilities at the level of *that native
>>functionality* making its capabilites available across all current or
>>new projects that may be depended on it, instead of at the level of each
>>project.
>>
>>I've considered this results in further "Balkinization" of the Commons
>>code base, But I've come to the conclusion that it is more a
>>"reorganization of functionality". Its recognizing that there is a set
>>of "native" functionality that is used across Jakarta and reorganizing
>>that use into a subproject that is "clearly focused" and with "strong
>>interface boundaries".
>>
>>What do you think of it ?
>>-Mark
>>
>>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Jpackage-discuss] Re: jakarta-commons-daemon could use that
?
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Drawing on the ideas presented so far (Greg, Jean, Henri etc) this is
how the idea maps out in my head.
Current arch:
------------------- --------------------------
------------------
| daemon | | jakarta-connectors |
| EasyPosix |
------------------- --------------------------
------------------
|Custom JNI Impl | | JNI Apache APR Impl | | OS X
JDirect |
------------------- --------------------------
------------------
| Cygwin/Unix | |Windows/Unix (OS X?) | | OS X
Darwin |
------------------- --------------------------
------------------
Currently only one solution for installation in each case.
Possible future arch:
----------------------------------------------------------------------------
| daemon | jakarta-connectors | other
packages |
----------------------------------------------------------------------------
| EasyPosix (or APR like)
Interface |
----------------------------------------------------------------------------
| APR Impl | Custom JNI Impl | OS X -
JDirect Impl |
----------------------------------------------------------------------------
| Win/Unix/OS X | Unix, Cygwin, OS X, etc | OS X
Darwin |
----------------------------------------------------------------------------
Notice how it gives a "wide array" of possibilites for usage at the OS
level. This means installers can have "choice" of implementations to
install daemon like jakarta packages ontop of. "Porting" is moved into
"one layer shared by all" instead of "separate custom implementations of
each".
Note: I don't neccessarily suggest that EasyPosix is the only means of
attaining this interoperability, if the developers of the
jakarta-connectors have established a layer of similar functionality, it
could easily be the case that this support maps into the same position
in the arch as where I've placed EasyPosix at the moment. I am using
EasyPosix as just an example of an interface that may be implemented by
various means on one particular operating system and I am not
restricting it to be an "only case", just an example of a clearly
defined interface.
-Mark
Mark R. Diggory wrote:
>
>
> jean-frederic clere wrote:
>
>> Mark R. Diggory wrote:
>>
>>>
>>> Cygwin supports a wide array of posix functions, and making sure the
>>> implementation of EasyPosix that worked on cygwin as well would
>>> provide a port of these functions to Windows via Cygwin.
>>
>>
>>
>> I am afraid that is not a very accepted solution.
>> jakarta-commons-daemon (service) uses Cygwin and a lot of people were
>> complaining about that.
>>
>
> I can see why Windows developers would complain; Cygwin isn't very
> popular with them because it’s so "divergent" from their "paradigm". I
> wouldn't suggest it if it weren’t that its almost the cases that if it
> runs on Unix, it will run on Cygwin with just a little modification. I
> never understood why someone would want to run Windows as a server,
> but I'll avoid any Windows OS bashing as I'm typing this email on one
> at the moment and that would seem hipocritical. ;-)
>
>> Apache has an already portable runtime: APR. It would be probably
>> more efficient to bring an APR interface to JNI than to use a new
>> runtime. And that is already some code in jakarta-connectors.
>
>
> YES, Yet anothor reason to consider another "layer" similar to
> EasyPosix for daemon and other services requiring the native OS access
> to run upon. Then you can have one implementation of daemon/connectors
> that can run on multiple implmentations of Easy-Posix. This is a case
> for mapping a set of Easy-Posix commands/functions through the APR as
> well. Consider that there may be a *Union* of shared functionality
> currently captured through JNI --> APR, JNI --> Ten and JNI --> Posix.
>
> What I'm suggesting is not to "isolate" the daemon service to one
> particular native solution. By adding a layer of "OS functionality"
> between the OS and the daemon, the daemon can stay a conceptually
> simple interface/implementation and the *functionality of the OS* can
> be captured at the *level of its functionality*, making it possible to
> "extend" that functionality across different systems without many
> different versions of daemon (which is a tiny subset of that
> functionality). In theory, what we are talking about is a means to
> "extend" the JVM's capabilities at the level of *that native
> functionality* making its capabilites available across all current or
> new projects that may be depended on it, instead of at the level of
> each project.
>
> I've considered this results in further "Balkinization" of the Commons
> code base, But I've come to the conclusion that it is more a
> "reorganization of functionality". Its recognizing that there is a set
> of "native" functionality that is used across Jakarta and reorganizing
> that use into a subproject that is "clearly focused" and with "strong
> interface boundaries".
>
> What do you think of it ?
> -Mark
>
> _______________________________________________
> Jpackage-discuss mailing list
> Jpackage-discuss@zarb.org
> http://lists.zarb.org/mailman/listinfo/jpackage-discuss
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jakarta-commons-daemon could use that ?
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
jean-frederic clere wrote:
> Mark R. Diggory wrote:
>>
>> Cygwin supports a wide array of posix functions, and making sure the
>> implementation of EasyPosix that worked on cygwin as well would
>> provide a port of these functions to Windows via Cygwin.
>
>
> I am afraid that is not a very accepted solution. jakarta-commons-daemon
> (service) uses Cygwin and a lot of people were complaining about that.
>
I can see why Windows developers would complain; Cygwin isn't very
popular with them because it’s so "divergent" from their "paradigm". I
wouldn't suggest it if it weren’t that its almost the cases that if it
runs on Unix, it will run on Cygwin with just a little modification. I
never understood why someone would want to run Windows as a server, but
I'll avoid any Windows OS bashing as I'm typing this email on one at the
moment and that would seem hipocritical. ;-)
> Apache has an already portable runtime: APR. It would be probably more
> efficient to bring an APR interface to JNI than to use a new runtime.
> And that is already some code in jakarta-connectors.
YES, Yet anothor reason to consider another "layer" similar to EasyPosix
for daemon and other services requiring the native OS access to run
upon. Then you can have one implementation of daemon/connectors that can
run on multiple implmentations of Easy-Posix. This is a case for mapping
a set of Easy-Posix commands/functions through the APR as well. Consider
that there may be a *Union* of shared functionality currently captured
through JNI --> APR, JNI --> Ten and JNI --> Posix.
What I'm suggesting is not to "isolate" the daemon service to one
particular native solution. By adding a layer of "OS functionality"
between the OS and the daemon, the daemon can stay a conceptually simple
interface/implementation and the *functionality of the OS* can be
captured at the *level of its functionality*, making it possible to
"extend" that functionality across different systems without many
different versions of daemon (which is a tiny subset of that
functionality). In theory, what we are talking about is a means to
"extend" the JVM's capabilities at the level of *that native
functionality* making its capabilites available across all current or
new projects that may be depended on it, instead of at the level of each
project.
I've considered this results in further "Balkinization" of the Commons
code base, But I've come to the conclusion that it is more a
"reorganization of functionality". Its recognizing that there is a set
of "native" functionality that is used across Jakarta and reorganizing
that use into a subproject that is "clearly focused" and with "strong
interface boundaries".
What do you think of it ?
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jakarta-commons-daemon could use that ?
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Mark R. Diggory wrote:
> (Please excuse the cross post, I wanted to get this out onto the the
> Commons Development List and to JPackage as well. I think the Tomcat
> Lists seem to get a little crowded)
>
> Henri,
>
> I emailed the developer of Easy Posix (Greg Guerin). Turns out that its
> current implementation is dependent upon "Ten" , a Mac OS X package for
> MacJVM, so it is not deployable in the standard Linux OS.
>
> From my conversation with him, he spoke that he is planning to develop
> a straight JNI implementation of the EasyPosix interfaces in the future,
> but that if others went that route earlier he would have an interest.
>
> As there has already been much work in the JNI area with daemon, this
> would certainly seem an interesting co-evolution. Perhaps daemon could
> grow into quite a powerful java based service environment with the
> addition of a JNI Implementation of EasyPosix?!
In jakarta-commons-daemon the JNI is limited to what was needed for the daemon.
>
> Cygwin supports a wide array of posix functions, and making sure the
> implementation of EasyPosix that worked on cygwin as well would provide
> a port of these functions to Windows via Cygwin.
I am afraid that is not a very accepted solution. jakarta-commons-daemon
(service) uses Cygwin and a lot of people were complaining about that.
Apache has an already portable runtime: APR. It would be probably more efficient
to bring an APR interface to JNI than to use a new runtime. And that is already
some code in jakarta-connectors.
>
> Perhaps, even a "standard" could evolve to support a specific subset of
> posix-like Functions. Using something like EasyPosix as a guide, a java
> program (daemon or not) that needed greater access to POSIX functions
> could be ported to any system that EasyPosix was supported on,
> completely independent of its implementation on that system. It would
> possibly make "java services" quite cross-platform for at least in the
> unix/linux/darwin/cygwin world.
>
> Another point of interest: If JPackage produced a Tomcat RPM based on
> the current implementation of daemon and another implementation of
> daemon based on EasyPosix were developed. It would be easy to adapt to
> such a change. In the end, this would possibly make EasyPosix the means
> by which daemon could be ported to Darwin/Mac without the wieght of
> compiling or porting a JNI implementation.
>
> -Mark
>
> Henri Gomez wrote:
>
>> I didn't track jakarta-commons-daemon but I know many of you here
>> which are subscribed to it.
>>
>> What do you think of easyposix ?
>>
>> http://www.amug.org/~glguerin/sw/easyposix/overview.html
>>
>> Couldn't it be a nice add-on for daemon ?
>>
>> It's still related to tomcat since I need a very complete
>> java service launcher for tomcat, and this easyposix as
>> very nice features.
>>
>> Comments welcomed
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>
>
>
> Greg Guerin wrote:
> > The supplied code only provides a Mac OS X implementation. That
> > implementation uses JDirect-3, which is an Apple-specific means to call
> > arbitrary native-code functions directly from Java, without an
> intervening
> > JNI layer.
> >
> > All other platforms will need a JNI implementation for that platform.
> > Absent a JNI implementation, the "unimplemented" implementation is used,
> > i.e. UnPosix. See the docs for UnPosix for more details.
> >
> > You could pattern a JNI imp off the Mac OS X imp. The mapping of the
> Mac
> > OS X implementation to JNI functions, and the bodies of the JNI
> functions
> > themselves, should be fairly straightforward. That's because all the
> > 'native' methods in the Ten class are essentially the names of C
> functions
> > in the BSD/Posix library. Getting the callbacks right is a little
> > trickier, but well within the skill-set of a capable JNI programmer.
> >
> > FYI, I have "write Easy Posix JNI imp" on my list of projects to do, but
> > it's several items down in the queue right now, and at least a couple
> > months or more away from getting to the head of the queue. The
> source may
> > not be instantly portable to Linux, but it shouldn't be so different
> that
> > it would be useless as a starting point. Or, if you wrote a JNI imp for
> > Linux before I get to the JNI imp for Mac OS X, I wouldn't mind the
> > positions being reversed.
> >
> >
> >
> >
> >>On another note, Apache has another package they've been working on that
> >>is a java based "daemon" for running Java programs as daemons on both
> >>Unix and Windows.
> >>
> >>http://jakarta.apache.org/commons/sandbox/daemon/
> >>
> >>Henri Gomez (of www.jpackage.org - the packagers of the tomcat and other
> >>java based rpm's) and I reviewed your site and suggested to both Apache
> >>and JPackage that they should seriously take a look at your package as
> >>an additional tool for controlling Java based Daemons.
> >>
> >>While I am not actually an Apache developer, I have a great interest in
> >>the organization, regularly use the tools they develop and often try to
> >>make recommendations to improve the tools. I try to provide avenues for
> >>improvement when I see external open source tools that are benificial. I
> >>think the Apache Jakarta Commons project "Daemon" is a good start, and a
> >>natural growth for a generic tool out of the Tomcat source-base, but its
> >>obvious that your package captures alot more functionality above and
> >>beyond that of "Daemon".
> >
> >
> > That makes sense, since I was interested in the underlying POSIX
> facilities
> > themselves, not the nature of the program (deamon vs. non-daemon) that
> > called the POSIX facilities. The daemonic nature is a different
> question
> > altogether. Not unimportant, just different.
> >
> > -- GG
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jakarta-commons-daemon could use that ?
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Mark R. Diggory wrote:
> (Please excuse the cross post, I wanted to get this out onto the the
> Commons Development List and to JPackage as well. I think the Tomcat
> Lists seem to get a little crowded)
>
> Henri,
>
> I emailed the developer of Easy Posix (Greg Guerin). Turns out that its
> current implementation is dependent upon "Ten" , a Mac OS X package for
> MacJVM, so it is not deployable in the standard Linux OS.
>
> From my conversation with him, he spoke that he is planning to develop
> a straight JNI implementation of the EasyPosix interfaces in the future,
> but that if others went that route earlier he would have an interest.
>
> As there has already been much work in the JNI area with daemon, this
> would certainly seem an interesting co-evolution. Perhaps daemon could
> grow into quite a powerful java based service environment with the
> addition of a JNI Implementation of EasyPosix?!
In jakarta-commons-daemon the JNI is limited to what was needed for the daemon.
>
> Cygwin supports a wide array of posix functions, and making sure the
> implementation of EasyPosix that worked on cygwin as well would provide
> a port of these functions to Windows via Cygwin.
I am afraid that is not a very accepted solution. jakarta-commons-daemon
(service) uses Cygwin and a lot of people were complaining about that.
Apache has an already portable runtime: APR. It would be probably more efficient
to bring an APR interface to JNI than to use a new runtime. And that is already
some code in jakarta-connectors.
>
> Perhaps, even a "standard" could evolve to support a specific subset of
> posix-like Functions. Using something like EasyPosix as a guide, a java
> program (daemon or not) that needed greater access to POSIX functions
> could be ported to any system that EasyPosix was supported on,
> completely independent of its implementation on that system. It would
> possibly make "java services" quite cross-platform for at least in the
> unix/linux/darwin/cygwin world.
>
> Another point of interest: If JPackage produced a Tomcat RPM based on
> the current implementation of daemon and another implementation of
> daemon based on EasyPosix were developed. It would be easy to adapt to
> such a change. In the end, this would possibly make EasyPosix the means
> by which daemon could be ported to Darwin/Mac without the wieght of
> compiling or porting a JNI implementation.
>
> -Mark
>
> Henri Gomez wrote:
>
>> I didn't track jakarta-commons-daemon but I know many of you here
>> which are subscribed to it.
>>
>> What do you think of easyposix ?
>>
>> http://www.amug.org/~glguerin/sw/easyposix/overview.html
>>
>> Couldn't it be a nice add-on for daemon ?
>>
>> It's still related to tomcat since I need a very complete
>> java service launcher for tomcat, and this easyposix as
>> very nice features.
>>
>> Comments welcomed
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>
>
>
> Greg Guerin wrote:
> > The supplied code only provides a Mac OS X implementation. That
> > implementation uses JDirect-3, which is an Apple-specific means to call
> > arbitrary native-code functions directly from Java, without an
> intervening
> > JNI layer.
> >
> > All other platforms will need a JNI implementation for that platform.
> > Absent a JNI implementation, the "unimplemented" implementation is used,
> > i.e. UnPosix. See the docs for UnPosix for more details.
> >
> > You could pattern a JNI imp off the Mac OS X imp. The mapping of the
> Mac
> > OS X implementation to JNI functions, and the bodies of the JNI
> functions
> > themselves, should be fairly straightforward. That's because all the
> > 'native' methods in the Ten class are essentially the names of C
> functions
> > in the BSD/Posix library. Getting the callbacks right is a little
> > trickier, but well within the skill-set of a capable JNI programmer.
> >
> > FYI, I have "write Easy Posix JNI imp" on my list of projects to do, but
> > it's several items down in the queue right now, and at least a couple
> > months or more away from getting to the head of the queue. The
> source may
> > not be instantly portable to Linux, but it shouldn't be so different
> that
> > it would be useless as a starting point. Or, if you wrote a JNI imp for
> > Linux before I get to the JNI imp for Mac OS X, I wouldn't mind the
> > positions being reversed.
> >
> >
> >
> >
> >>On another note, Apache has another package they've been working on that
> >>is a java based "daemon" for running Java programs as daemons on both
> >>Unix and Windows.
> >>
> >>http://jakarta.apache.org/commons/sandbox/daemon/
> >>
> >>Henri Gomez (of www.jpackage.org - the packagers of the tomcat and other
> >>java based rpm's) and I reviewed your site and suggested to both Apache
> >>and JPackage that they should seriously take a look at your package as
> >>an additional tool for controlling Java based Daemons.
> >>
> >>While I am not actually an Apache developer, I have a great interest in
> >>the organization, regularly use the tools they develop and often try to
> >>make recommendations to improve the tools. I try to provide avenues for
> >>improvement when I see external open source tools that are benificial. I
> >>think the Apache Jakarta Commons project "Daemon" is a good start, and a
> >>natural growth for a generic tool out of the Tomcat source-base, but its
> >>obvious that your package captures alot more functionality above and
> >>beyond that of "Daemon".
> >
> >
> > That makes sense, since I was interested in the underlying POSIX
> facilities
> > themselves, not the nature of the program (deamon vs. non-daemon) that
> > called the POSIX facilities. The daemonic nature is a different
> question
> > altogether. Not unimportant, just different.
> >
> > -- GG
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org