> IMHO, forcing web apps with an "open" user group to be non-portable would be
> a big blow for J2EE's usefulness. I'm hoping that Sun will "fix" this
> problem in future J2EE releases...
Yes,
<vendor>
We, as other j2ee suppliers, provide our own interface for user management
(http://www.orionserver.com/docs/api/com/evermind/util/UserManager.html to be precise).
We do feel as you do that there should definitely be a common interface for this stuff
though.
"It'd limit the functionality of the interface" shouldnt be a viable arg against it -
use the same
strategy as with JNDI: The provider follows the basic interface spec setup but can
also be
casted to a more specific interface with additional functionallity. There should be no
problem
for each vendor making an interface for this - it by no means has to be their "main"
interface
if they dont want it to, it can just serve as an adapter.
User management is the biggest thing thing that I've seen people do "over and over"
again,
duplicating the containers work. It's sad to see ~30% of a projects code going into
reinventing
the wheel.
The APM demo ("Duke's pet store") does a rather poor job of abstracting the
container-specific
code as is though, which we sadly found out when attempting to port it to Orion. The
container-specific
code should be as abstracted as possible, prefferably even loaded as a dynamic class
implementation
of an interface settable as a env-var.
Orion lets the user "plug in anything" via the UserManager interface, we mainly
recommend the
EJBUserManager implementation which pulls the users from EJBs (other examples are
DataSourcerUserManager, LDAPUserManager, XMLUserManager etc) making it highly
customizable since adding user
"attributes" is simply adding/subclassing EJB fields.
We encourage Sun to create a standard API for this as soon as possible, it is (as
noted) the one big
missing piece in J2EE as is. For those of you not on the EJB or J2EE interest lists it
can be noted that
this very topic has been a great source for discussion on those respective lists too.
As a worst case scenario
make the API optional - it would still go a long way if compared to one API per server
vendor/platform.
That said, we still recommend the small portion of "bad",container specific code in
contrast to reinventing
the wheel for every app. Just make sure to keep the container-specific interaction
abstracted so it's pluggable.
</vendor>
Pardon the ranting, have a nice day! :)
/Magnus Stenman, the Orion team
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
