Hi,
I share many of the same concerns regarding the Spec and process. It seems to
me that I could have little effect on the output. I have tried a number of
strategies to do this. First it was contructive criticism, then it was plain
pointing out of faults and finally I developed an alternate proposal. Each of
these times my opinions were largely dismissed. The reason given was because
it was not "we" decided or that we were running out of time or ... etc.
It is true that some of my concerns were addressed later but I had no ability
to participate in the process. It was always Thomas who decided what to do
and how it was done. He then informed the group of the changes.
Even though I would like a more open process I don't see this as the major
issue here. (Sidenote: A recent rant I made about JCP on general@jakarta list
was probably induced at least partially by this JSR). The main issue I see
here has to do with technical choices made.
Before I discuss this I guess we need to identify the potential uses of API.
The three identified in order of complexity are
1. Alternate Invocation API
2. Daemon Management System (like unix based daemontools from DJ Bernstein).
This is essentially (1) with added requirement of a deployment format (ie
archive + manifest entries or descriptor).
3. Generic hosted Applications (ie applications hosted in database or other
App Servers to do auxilliary work)
I don't think (3) should be included. It was not defined in initial JSR
proposal and there is existing JSRs which deal with this layer. The two
existing JSRs of most relevence include the Isolate API and the Services API.
The Services API hopes to standardize the interface that used to host
applications (ie kernel contains application whichs is assembled from
services). It intends to cover a broader range of use cases than this current
JSR does and will likely become dominant when/if gets fully developed.
The Isolate API is being put together by some very very smart people and can
be likened to fork() for java. This way you will be able to Isolate
computation (ie fork()) and manage these Isolates via Events (aka signals).
While I can't say much more about it - let me just say that it is a very
interesting API and AppServer vendors will most likely use this API when push
comes to shove. It will be a jdk1.5+ only thing however.
Given these JSRs I can not really see any use in maintaining (3) as a viable
use case.
My personal reason for the joining the group is similar to Pier except
instead of option (1) I would like option (2) ;). As it has evolved I can't
see myself or anyone who writes servers finding a use for the API. The
facilities it provides are not worth the added complexity and some of the
facilities encourage poor design practices.
This brings me to my major concern. I don't think the technical design is
adequete. The design violates some well established idioms of the java
platform. Many of these idioms are based on widely accepted design patterns.
Yet there is no explanation why this has been done. Some sample violations
follow
* breaks naming patterns (ie we use the postfix Info to indicate dynamic
instance data rather than static type data).
* we require that daemon writers do their own security checks while other
component based solutions relegate security to the container (and do it
declaritivly). Where procedural security is required these APIs offer hooks
for the component to call back into the container.
* we require that daemon writers check state transitions. Other APIs require
that the container call transitions in correct order. For instance if a
servlet container was to call destroy() before it called init() then it would
be a bug in container. Yet the daemon API requires daemon to check that state
transition order is correct and if not throw a suitable exception.
* The daemon API uses ints to represent actions when there is no performance
reason to do so. There is several good reasons to use Strings for these data
items.
* The daemon API defines the container, daemon API and client management
of daemons. This would be like defining the servlet API as a particular
servlet container. What other APIs do is specify the Container->Component
contract. What we try to do is specify the Container->Component contract, the
Container and the Client->Container contract. I think it is not in our
interest to try to attempt such an endeavor.
Besides overlapping use cases, the Daemon API also overlaps other non-related
specs. It defines its own management (ie DaemonController) and monitoring (ie
DaemonInfo, DaemonListener) APIs when we already have existing and IMHO
superior management APIs such as JMX.
Anyways these have been my main concerns for a while. Many more minor issues
and expansions can be seen in my previous emails ;)
On Fri, 29 Jun 2001 02:20, Pier P. Fumagalli wrote:
> 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)
--
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
