Dear BEA,

I've flirted with BEA and WLS since the 5.0 days. Just wanted to give
you some feedback on WLS 10 and my experiences with getting my
applications compatible with it. I gotta tell you, I LOVED WLS 6.1
and have had run-ins since then with 7 and 8 and portal. I wanted to
share some feedback on 10 and my EJB development needs.

I'm developing two Enterprise Applications. The first application has
a WAR and an EJB Jar in it. The WAR runs within a security realm and
gives our users a little administrative desktop for our backend
application. The EJB Jar contains one EJB that has only a Local
interface on it (because we require pass-by-reference and no speed
penalties of RMI).

The second Enterprise Application is a test application containing a
WAR. It's meant to emulate what our customers will do - which is to
deploy adjacent to the other EAR and access resources in that EAR by
way of the Local EJB. The Local EJB provides us with a local JVM in-
memory cache that our user's applications can share and draw resources
from. And before you pounce on us over our design, know that some of
the resources we share across Enterprise Application boundaries are
Java pojo Class objects that we load dynamically and cache centrally
in the Local EJB. We want a generic J2EE mechanism to do this sharing
with a minimum of vendor specifics - the Local EJB is the way we

I've discovered through my research that the J2EE spec is silent as to
whether vendors should allow local EJB's to be referenced externally
by other Enterprise Apps or not. Vendors such as BEA have interpreted
what to do here. Other vendors (open source and not) have explicit
vendor deployment descriptor tags to support sharing local EJB's with
external enterprise apps. Their decision creates support issues that
they must weather such as the EJB Client classes that the caller holds
for the EJBLocalObject are typically not compatible with the same
classes classloaded by the EJB's enterprise application - this leads
to confusing ClassNotFoundExceptions and customer dissatisfaction. We
understood all of these issues and use reflection to interact with the
local EJB object rather than trying to cast to the EJB Client classes.

I think I see all the issues and all sides of this issue. So, I don't
know if I can necessarily fault BEA for engineering WebLogic without
support for Local EJB external referencing. Customer satisfaction is
very important. I just wanted to communicate with you the raw fact
that your app server is not as functional as the competition (when in
our capable hands) and cannot benefit from our in-memory shared cache
scheme. Please consider adding support for Local EJB external
referencing in future versions of WebLogic so that we can lend our
users running under your app server the same resource sharing.

My other feedback for you is, as a newbie to the server, I found
WebLogic 10 very difficult to deploy our applications. The domain-to-
server-to-realm-to-application relationships were and are very foggy
to me. It was extremely challenging for me to create a viable realm,
and it was confusing to me that I needed to set it to be recognized as
the "active" realm in order for it to take effect in my application.
Shouldn't my application just reference the realm by name just like
all the other vendor products do, what is this "active" business?
Finally, there were far too many options with respect to how my web
application's roles would be copied into the server such that I could
do my role mapping to my user groups. I'm not even sure WHY I was
copying roles to the server, aren't my roles an application/realm

I guess my initial expectation was that the admin console would be
easy to navigate and I could figure out how to deploy the app based on
my knowledge of J2EE and deployment. This was too optimistic on my
part and upon pouring over the documentation, I did get the app
deployed successfully. I have to communicate that there were many
times that I got the feeling there were "black magic" steps that I
cannot explain to others if I needed to. I fear BEA has integrated
far too many customer feature requests and now the server is a little
too option heavy.

All of this would have been bearable, and I could have worked my way
through the screens had the admin console not CONSTANTLY asked me to
bounce the server to accept my settings changes. I may have been
asked to bounce my servers 15-20 times in the process of figuring out
the realms and server settings. These are slow bounces! And the
screen transitions in the console were sometimes extremely slow!
Expanding the deployments took 30+ seconds on my development laptop??
Other vendors' app servers do not have this magnitude of performance
problems on their admin consoles.

I did not use the WebLogic Express server to do my development, I
figured I should use the production servers for my compatibility
testing. In the future, I will look at Express to see if it is

I feel I must complain to you here because the poor performance of the
admin console made the experience of working with your server an
aggravating process. I hope you will perhaps consider moving to a
leaner web framework in future versions of the server. I always
recall WLS 6.1 as being slick and fast, and I have ALWAYS been very
impressed with BEA's engineering and understanding of the enterprise
application development space.