> I will make one minor point. The ultimate user-friendly deployment
> is that a bean developer can just plop his jar or ear into a directory
> and not worry about any JBoss-specific settings at all.
Dan, thanks for making this point. It is not a minor point at all.
Rickard has developed a sh*t load of functionality in jBoss2.0, way
beyond what we had for jBoss1.0. We have an agreement that "modular" is
good and that the benefits in terms of development, documentation,
ownership, configuration, adaptability, and what not, are real. Right
now we are paying a price and that is that the "newby" user comes here
and faces a daunting GUI task where he has to specify if he wants a
"statelessSingletonPool" or a "FIFOManagedStatelessPool" neither of
which he is aware of or really cares about. The result is that to
generate the various ejb-jar.xml, jboss.xml and jaws.xml the learning
curve is REALLY steep when the technology behind is still the same hot
deployment (It was already Rickard's design back in jBoss 1.0).
So I completely agree, 95% of our user will test the container with a
simple bean and will want to get going in no time. That means that even
a bare ejb-jar.xml like the one we use today in jBoss 1.0 (no addition
to it whatsoever) must still work. I am not sure I agree with Oleg when
he says "Don't mask away my errors, I want to know about it"... well
yes, *you* do, but you are the 5% power user that will take jBoss and
make it a custom container for your application to resell (if I am not
mistaken ;-) and so it is very important that you be able to tweak all
the configuration at a very deep granularity in jBoss.xml and jaws.xml
or castor.xml ;-).
I am aware of the fact that most of jBoss attraction is its famed ease
of use and the buzz around jBoss2.0 new design. Let's offer the power
of the new design even to our newby user by just "dropping" a bean with
only the "EJB1.1 spec" requirement (all the assumptions (what you call
heuristic container Dan) made in jBoss1.0).
The simple way is to provide default files jboss and jaws as well as
simple mapping rules (no JNDI name? use the mandatory ejb-name (or ref
or whatever it is in the <enterprise-beans> section) and so on and so
forth. It is an 'enhancement' to RIckard fundamental work that in no
way invalidates the "complex" design he has chosen to do to accomodate
even the requirements of an Oleg in a way that not even WebLogic is
remotely capable of doing (we will build a custom server for you?). It
is just a very necessary feature that will make sure and you me and all
the newbies on the list don't get turned off at the first run of jBoss.
marc
I don't mind
> making the developer who wants this feature use ejb-link, but we
> can add additional value for the case where the developer has
> followed a set of naming conventions during development (as some
> certainly will) but didn't use the optional ejb-link feature.
>
> This capability would not violate 14.3.3, even if ejb-link is not
> specified. If he or she enables this option in JBoss, this "naming
> convention match" IS the container-specific deployment tool. So
> the only unresolved EJB references of which we would need to
> inform him or her, would be the ones without an appropriate binding
> even after naming convention matches are applied.
>
> Would anyone want this?
>
> -Dan
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
--
----------------------------------------------------------------
Visit Telkel at JavaOne(SM), Sun's 2000 Worldwide Java Developer
Conference(SM)
June 5-9, 2000 - Moscone Center - San Francisco
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
