Shai,
Thanks for writing to us. I have looked at your Java related blogs
<
http://jroller.com/page/vprise/Weblog?catname=%2FJava> and noticed your
blog about another application server. Please give GlassFish
<
https://glassfish.dev.java.net/> a try and let us know what you think
about our administration and management.
I have scheduled to talk about application loading in our user
experience meeting on March 07, 2006. I will discuss your suggestions
with the deployment module
<
https://glassfish.dev.java.net/javaee5/deployment/index.html> owner
(QingQing - cc..ed in this email). For incorporating this into the
specification, we need to go through JCP
<
http://www.jcp.org/en/home/index>. You may want to participate in JSR
88 <
http://www.jcp.org/en/jsr/detail?id=88>.next effort.
We are documenting GlassFish modules to make it easier to start such
discussions. Please see this page
<
https://glassfish.dev.java.net/public/ServerModules.html> and get involve.
Daily news of GlassFish is available in The Aquarium
<
http://blogs.sun.com/roller/page/theaquarium>. You may send your blog
links to theaquarium_at_sun.com <mailto:theaquarium_at_sun.com>
--
Nazrul Islam - (408) 276-6468 - Sun Microsystems, Inc.
Shai Almog wrote:
>Hi,
>a user called ai109478 sent a response for my blog post feedback here:
>http://weblogs.java.net/blog/kgh/archive/2006/02/raving_about_ja.html
>
>And asked me to send further details to this list, I assume the user
>name is a form of Sun ID (my company does quite a bit of contracting
>work for Sun and I am sa112012 or shai.almog_at_sun.com). So anyway
>hopefully this E-Mail is not being wasted.
>
>First, I blogged about this and about the problems I had with Spring
>quite a while back (I think I even sent feedback to the alias but I
>don't recall). You can see my old posts on my old blog here from May
>23rd 2005:
>http://jroller.com/comments/vprise?anchor=why_j2ee_5_is_still
>
>And this one from June 7th about Spring (which I eventually dumped):
>http://jroller.com/comments/vprise?anchor=eclipse_fud_about_the_apple
>
>I want to get one thing strait:
>I think the annotations work is great and its a huge step in the right
>direction!
>
>However, I don't think simplicity is greater with annotations it can be
>argued that just groking (visually as a programmer) the source code
>littered with annotations is harder than going over several "plain"
>source files and an XML file.
>
>There are two separate problems we can discuss that relate to making the
>Java EE experience simple:
>1. Perceived simplicity.
>2. Actual simplicity.
>
>The first is the approach taken by Spring and the Java EE 5, by using
>some buzzwords (IoC, AOP, Annotations etc...) as a sort of pixie dust
>coupled with the "POJO" lie we supposedly "simplified". We can even
>present a checklist to the customers where we outline the exact features
>that were added to produce simplicity i.e. "You just write a standard
>Java object add one annotation and voila"...
>
>Why is this a lie?
>
>Repeat after me: "There is no such a thing as a POJO within a container!"
>This is true for Hibernate (which is a great product on its own, but
>doesn't do any magic) and this is true for all other technologies
>supposedly based on POJO's. The closest thing we have for POJO's in Java
>is serialization and even that isn't fool proof. The problem is that a
>container has a contract with the component within it, there are rules
>and there is a sequence of initialization (of fields and dependency
>injection) so a POJO for container A (such as Spring) will not move to
>container B (such as JBoss with EJB 3 implementation) worse I'd even bet
>there are quite a few "cracks" where a POJO for one EJB container won't
>move easily to another EJB container!
>
>The problem is that every container MUST offer POJO's today otherwise
>customers will complain about the "Perceived simplicity" regardless of
>the fact that they will NEVER EVER move to a different application
>server, they would also be right since this is something that was
>offered by all other servers for quite some time.
>
>Whats the solution?
>
>Stop pretending! POJO's are fine but ignoring the fact that there is a
>contract and order related to POJO handling will just produce code that
>won't be portable. Define everything and force everyone to work in
>"portability mode" by default, define errors (and error messages) and
>define checks for every single API. There shouldn't be race conditions
>to dependency injected attributes there should be a well defined uniform
>sequence of field initialization.
>
>The validator that exists is worthless, it breaks on the simplest
>applications. A validator must force itself on the user (such as the XML
>validator or the strictness of Java itself) otherwise people will not
>follow its guidelines (how many C programmers ever run lint and its like).
>
>On a positive note I think many features in Java EE 5 can simplify
>things in the long term such as the ability to "detach" entities and
>serialize them, this will reduce real world redundancy in code. There
>are many such gems in the spec, but it seems like the spec focused on
>cramming many features asked by the users and sadly users just don't
>know whats good for them ;-)
>You need to push in the celery with the carrot (or carrot cake,
>analogies aren't my strong suite) give the users the features they are
>asking for while slipping in the features that they need such as strict
>validation and clearly defined limitations.
>
>So the steps I am proposing:
>1. Define deployment - for once and for all just say exactly what the
>hell happens there!
>So you will break an application server, who cares. The 90% portability
>that was "great" for the EJB 1.0 era is no longer acceptable today when
>people are moving to Spring.
>
>2. Define failure - The problem is that application servers choose to go
>on running even if you do some clearly incorrect operations. The thing
>is that they will fail later with a message that you just can't
>understand. Define within the spec the points of failure (by clearly
>defining developer interaction with the container) allow for developer
>move/runtime mode in case of a potential performance cost but make sure
>this is minimal (bugs that only happen in production are just the worst
>kind).
>
>3. Standardize the abstract - From class loading behavior, field
>initialization sequences, invoking API's when servers aren't fully
>loaded and connecting the various pieces that are Java EE. The Java EE
>spec is RIDICULOUSLY thin! Its as if the committee took a look at the
>other specs (EJB, Servlets etc...) and declared "they already did all
>the work". The problem is that those guys did NOTHING, they defined a
>small API and didn't define anything about integration.
>
>4. Have default implementations - Simple things such as preexisting
>login modules for JAAS that can be defined within the standard Java EE
>deployment descriptor go a long way.
>
>5. Build REAL applications as a part of the spec - not blueprints or
>other "theories". By having a set references application server vendors
>can tune their products, customers can "borrow" source code and you will
>see that there is no standard way to "logoff" users that I could find in
>Java EE. A TCK is usually too "low level" to truly define portability, a
>real set of applications that can run unmodified on all application
>servers and provide a decent starting point for your own application
>will simplify everyones lives (this is a part of the spec since the TCK
>is a part of the spec and the TCK isn't enough).
>
>
>I could go on further but I think thats enough for now ;)
>I'm not on the list so make sure to reply to this address.
>
>Thanks for reading so far.
>
>Shai Almog
>vPrise Consulting.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>