My sense on this is that adding another EJB layer is overkill for what I am
trying to achieve. So is having to package and deploy another module/bundle
into the server. Perhaps some more details of a specific example of what this
library jar does will provide more context:
I have an existing EJB layer backing JAX-WS web services and it is all
working perfectly. If the EJB gets an exception at run time, the method
merely passes the exception to an exception manegement framework we have
written, which in turn deals with the exception and returns an exception of
the type requested by the method backing the JAX-WS operation. That method
then throws the expection. E.g.
<code>
// EJB Method backing a JAX-WS
public AuthenticationResult authenticate(AuthenticationQuery
authenticationQuery) throws IMError {
AuthenticationResult result = new AuthenticationResult();
try {
// do all our stuff, some of which may thrown an error - e.g. user not found
} catch (Exception e) {
throw processError(IMError.class, e);
}
return result;
}
</code>
The implementation of processError() sits in some classes that use a PU and
Entity classes with JPA to access a error configuration table. ProcessError
deduces the class name that threw the error, error type, error message etc
and then looks up the appropriate error config in the configuration table. It
looks up and uses the severity, transaction handling (e.g. whether to set
rollbackonly) methodology, whether to send an alert to our ops platform, and
internationalised simple descriptions of the error that ops guys can
understand. The error framework classes are packaged up into a jar like
errorframework.jar and can be used by each EJB module we write.
The EJB module that uses errorframework.jar may not even use JPA and may not
have any PU's of its own, or may well use JPA, but connect to a different
database to that which holds the error configuration table. The PU in
errorframework.jar uses RESOURCE_LOCAL transaction management and a container
managed datasource jdbc/OperationsDB for example. Ideally, errorframework.jar
can be used in any module in Glassfish, with the only constraint that the
container must have a jdbc/OperationsDB datasource targeted (which we already
do). Thats neat, has few dependencies and just works. It also allows for the
error management framework to be transactionally isolated from the caller as
we may well want to do DB work in the error handler framework itself (e.g.
log an error in a table). All would be great... but with the shared PU's, the
class casting issues arrise for the entity classes. I have worked around this
by doing all DB workin in errorframework.jar with plain old sql and
em.unwrap(Connection.class).... but I feel its a hack thats only needed due
to a packaging issue I cant get around. My "ultimate" solution would be a
change in the EE6 spec to either:
a) mandate that a named persistence unit and associated EMF acquired from the
JPA framework should be isolated to the classloader of the deployed EAR (yea
I know... big impact on layer 2 caching...).
b) ensure that any operations on an EM/EMF always use entity classes that
available to the classloader that asked for the EMF
My understanding is that thats the intent of java EE - to be able to
deploy/undeploy an EAR without concern for what other EARS are already
deployed in the container (classloader independence). As things stand, the
first EAR could call Persistence.createEntityManagerFactory("MyPU") and
happily use the EMF/EM. Then another EAR could be deployed that also uses
Persistence.createEntityManagerFactory("MyPU") and get an EMF. But when
trying to use a resulting EM, classcast runtime errors would be thrown. Also,
if the original ear calls EMF.close, who knows what would happen to other
EARS as they aren't isolated.
.... just me 2c
--
[Message sent by forum member 'paulcb']
View Post: http://forums.java.net/node/788153