RE: [JSR-96-Members] JSR-096 (Java Daemon API) critique...

["Kopp, Thomas (DIALOGIKA)" <Th...@dialogika.de>]

Pier,
you send a negative feedback on things you have agreed to when we met in
London.

Your critics contains an entire paper about daemons and services but you
only say that the current spec does not address VM issues.
I have the problem that I do not know, which technical aspect you refuse.
Please, tell me more detailed and technical arguments.
If you let me know these issues we might be able to discuss and solve the
problems on a technical level.

In London we agreed that the modules we ship consist of 
- a Java block, which is subject of the API spec and
- a platform-specific block, which can hardly be specified for each
individual platform.

Hence, we said that we try to put a maximum of functionality in the Java
building block, which can exactly be specified and tested.
In addition, we would give suggestions, how to use the control side of the
API without defining, how this should be done in detail.
In fact, we even cannot define it due to the broad variety of existing
platforms.

This partition of the original proposal in separate building blocks seemed
to be completely natural and there was no critics about this packaging
model. The outcome still fully addresses the issue of the initial JSR. It
now also addresses a lot more due to long-term reflections about an ideal
design of the API.

YOU said YES to this model and YOU proposed that Apache would supply the
native platform side for the major OS, i.e. Win32, Solaris, Linux. Nobody
asked you to do so. 


During the first phase of JSR96, there was a significant number of requests
concerning remote management support.
Since this issue is addressed by JMX for the Java platform, we further
agreed that we would also provide a JMX-enabled control side to satisfy
these requirements. The current packaging model provides a simple way to
address these issues.

Everything that has been initially proposed is still addressed except for a
lot more, which I didn't even think about in the beginning.
We did not leave the roots. In contrast, we are only able to do a lot more
with some more careful thinking about how we realize individual aspects
think we shouldn't be afraid of being more powerful than it was initially
planned. 

In addition, the Java community has many different interests. Since, we
supply infrastructure for the community and not only for one individual
aspect, we have a certain responsibility to take a careful choice.


Pier, YOU wanted to elaborate a security concept together with Damon.
Nothing happened for weeks. (We met at 21 April.) I do not criticize if
somebody has not the time to contribute. I know that everybody has a hard
job and I understand if there is no time left to contribute to a specific
JSR.

But, I think it can also be understood if I as the spec lead try to move the
project forward. So I proposed a security concept elaborated together with
the resources available, i.e. with my colleagues, which are also valid
expert group members like you or anybody else in this group. 

These were valid technical discussions, like you discuss things with your
colleagues in Apache group. Nothing is hidden. Every important result of any
person-to-person discussion automatically goes to the expert group via
mailing lists, phone calls or the spec. This is ordinary working style. We
cannot have meetings with the whole expert group for each detail. So do you
think that I shouldn't talk personally to individual expert group members
anymore?


In addition, versions of spec are out since one week after our London
meeting. There was nearly no feedback since that time.
So, I must assume that there is a kind of agreement if I don't get any
feedback at all.. Consequently, I have a problem to understand this sudden
360-degree-turn-around. What is the real problem?

Please, tell me what functionality you need, cannot be fulfilled by the
current spec in a suitable way?
Since the beginning of this JSR I was continuously thinking about a lot of
aspects and use cases. In addition, many issues of internet discussions,
expert group discussions and our meeting brought a lot of different aspects.
So I tried to recognize and combine all  aspects in the spec. An FAQ was
added to explain and justify why a certain requirement resulted in a certain
design.

This was a long-term growing process. Nothing fall out of the sky like a big
surprise. YOU contributed to this process. YOU noticed all individual steps.
So, please Pier, tell me what suddenly goes wrong?

Regards, Thomas.



> -----Original Message-----
> From:	Pier P. Fumagalli [SMTP:pier@betaversion.org]
> Sent:	Thursday, June 28, 2001 6:21 PM
> To:	jsr-96-members@dialogika.de; Thomas.Kopp@dialogika.de
> Cc:	tomcat-dev@jakarta.apache.org; jcp@apache.org; members@apache.org;
> jim.driscoll@sun.com
> Subject:	[JSR-96-Members] JSR-096 (Java Daemon API) critique...
> 
> What is a daemon? Historically, a daemon has been defined by the CTSS
> group
> in 1963 as a "Disk And Execution MONitor", and has been adopted into the
> Unix world as a program that is not invoked explicitly, but lies dormant
> waiting for some condition(s) to occur.
> 
> What are those conditions? Two classes, basically: an unspecified I/O
> condition that triggers a stage of the daemon execution process, and a
> service request; while we cannot schematize and abstract the first class
> of
> conditions, as these are dependant from daemon to daemon and determine
> what
> a daemon serves (the LPR daemon is different from the HTTP daemon),
> history
> already determined the second class of conditions as signals.
> 
> For instance, it is assumed (and specified), that in response to a TERM
> signal the daemon should terminate its operation and exit its process, in
> response to a HANGUP signal it should hangup a connection, or more
> recently
> reload its configurations and restart.
> 
> So, we can now abstract a more "generic" definition for daemon: a daemon
> is
> a dormant program (meaning detached from its parent process, and not
> interrupting its flow of execution), which serves I/O requests for its
> clients (from here the symmetry daemon=server) and interacts with the
> underlying operating system with a defined set of signals or events.
> 
> In the Win32 world, the term daemon is substituted with the term
> "service",
> and signals (which do not exist in that environment) have been changed
> with
> specific calls to certain declared functions, but on the overall the
> design
> remains the same.
> 
> In any modern multi-user operating system there is a concept of "deamon",
> "service", "server", and this concept has been associated with "a dormant
> program serving I/O requests for its clients and interacting with the
> underlying operating system with a defined set of signals or events"
> 
> So far, the Java Platform lacked of a way to build an operating system
> daemon using the Java language: Java applications are -all- interactive
> programs, as the current invocation mechanism lacks of a way to create a
> dormant program, and lacks of a way to interact with the underlying
> operating system. Notably, see JavaSoft's Bug # 4323062: the java.exe
> application invocator is used as a "deamon" and it fails. The current fix
> is
> a hack, and the platform still lacks of a way thru which an operating
> system
> daemon written in java can receive events triggered by the OS (we can
> easily
> launch "java myClass &" in Unix, but it dies inexorably when a TERM signal
> is delivered to its process).
> 
> Those are the problems I wanted to solve when I joined the JSR-096 expert
> group, those are the issues that in the proposal listed on the JCP site we
> are supposed to solve, and this is what the Java community expect us to
> deliver.
> 
> And today (incredible timing, I would say) I received the last copy of the
> specification. And I'm disappointed to see that even in this last copy
> there
> is no reference to the behavior of the JVM process related to its
> supporting
> operating system. This specification does not solve my problem, is not the
> reason why I joined this group.
> 
> I see this version of the specification as a description on how to build
> Java daemons for the Java Platform (one tier up), not a Java daemon for a
> generic underlying operating system. This idea is corroborated by the fact
> that its test Reference Implementation delivered with the specification is
> based on JMX, doesn't touch at all the problems that we need to face when
> integrating a generic Java daemon (from the definition above) within the
> scope the underlying operating system. In my opinion, this specification
> is
> redundant, JMX and JSR-111 are already a great way to address these
> problems
> (I believe this came out also from our meeting in London last month).
> 
> And that's why last week, on my own, silently, I came up with an
> implementation that addresses the problems I needed to solve, and were
> needed to be solved by my team (the Apache Tomcat team) to deal with how a
> daemon written in Java can deal with the operating system.
> <http://www.apache.org/websrc/viewcvs.cgi/jakarta-tomcat-4.0/service/>
> 
> Being responsible for solving these problems in the Tomcat world, his
> implementation is what I feel I can safely deliver to my team and to the
> community, while I don't feel that adding another layer of cumbersomeness
> to
> the current specifications will help in any possible way.
> 
> And this is why as an Apache member, and its current representative in
> this
> expert group, as a Sun Microsystems employee working on the Tomcat
> project,
> I will not support the current specification until the problems I face,
> the
> problems I endorsed when joining this effort, the problems we were
> supposed
> to solve will be addressed.
> 
> My implementation doesn't try to be a full 360 degrees solution to the
> problems of daemons, and does not try to be a fancy JCP specification, but
> it solves those problems that we, software developers, need to face
> everyday
> when developing daemons in the Java Language and with the help of the
> community, will be improved and enhanced.
> 
> I believe that this expert group went too far, forgetting its roots, and
> the
> real problems that we needed to solve.
> 
> Also, another problem I faced while working with this group was the way in
> which the discussion was held. Our mailing list rarely held technical
> discussions, if not triggered by one of us in the Apache Software
> Foundation
> (thanks especially to Peter Donald) or few others and the whole
> specification was developed internally at Dialogika. I've been thru
> several
> specifications in the Servlet/JSP and XML lands and being a member of the
> expert group usually ment to know _what_ was going on, not just listening
> to
> decisions taken inside a company by few and "blessing" them.
> 
> In your last email, Thomas, I quote "As a late reaction of Peter's critics
> I
> did some brainstorming and discussed the control code model once more with
> my colleagues". WE, Thomas, are your colleagues on this specification, not
> whoever works at Dialogika, my name is on that specification, and apart
> from
> the one in London I never had a brainstorming session with you.
> 
> I'm sorry I didn't come to JavaONE, but my current economic situation
> didn't
> allow me to get there, I would have told you this in person, but I feel
> left
> out, and right now I should have to bless a specification that I don't
> agree
> with and that doesn't include any of my thoughts on the matter.
> 
> Apart from this my vote on JSR-096 is a veto, a -1, for technical reasons,
> we don't solve those problems we were supposed to.
> 
> Sincerely,
> 
>     Pier Fumagalli
>     - Apache Software Foundation (member, JSR-096 representative)
> 
> (CCing to the Tomcat Developers mailing list, the Apache JCP mailing list,
> the Apache Members mailing list and my manager at Sun Microsystems)
> 
> 
> 
> 
> 
> 
> 
> 
> 
>