[jboss-user] [JNDI and Naming] - Service Override in JNDI
Thomas Goettlich [http://community.jboss.org/people/ThomasGo] created the
discussion
"Service Override in JNDI"
To view the discussion, visit: http://community.jboss.org/message/572722#572722
--
Hi,
before I ask my question, here's a short description of what we try to do:
We are building a platform for our projects that consists of multiple
components.
Each component contains entities, data access objects and business services.
If we use those components in a project and need to extend the entities, we
inherit from the base entity and the dao but not from the service.
The daos are abstract generic services, i.e. they provide generic
implementations but are not annotated with @Stateless.
The services are neither generic nor abstract and thus might be extended but
the logic must not be overridden.
A short example to illustrate my description:
The user component contains the following classes:
@Entity
UserEntity{ /*code here*/ }
abstract class UserDAOBean
{
doCrudStuff(Entity user) { ... }
}
@Stateless
@Local (IUserService.class)
class UserServiceBean
{
doBusinessLogic(UserEntity user) { ... }
}
The project needs to extend UserEntity and thus we have the following:
@Entity
ProjectUserEntity extends UserEntity { /*additional attributes*/ }
@Stateless
ProjectUserDAOBean extends UserDAOBean
{
@Override
doCrudStuff(ProjectUserEntity user) { /*some extended or changed code here */ }
}
This works so far.
The problem are the business services.
When I want to extend UserServiceBean, that's no problem. I then just add a
ProjectUserServiceBean and call that where needed.
However, when I need to override a method - e.g. doBusinessLogic - I need other
services to use the overriding service instead of the base one.
I can't change the calling services and thus have to rely on JNDI to return the
correct service.
The problem is, that the JBoss 4.2.3 implemantion (that's what we're using)
returns any service that implements the IUserService interface (and declares it
as its local interface).
So I need UserServiceBean not to be returned by JNDI or not be registered in
JNDI at all.
Finally the question: Is that possible? If so, how?
Thanks in advance.
Thomas
--
Reply to this message by going to Community
[http://community.jboss.org/message/572722#572722]
Start a new discussion in JNDI and Naming at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2083]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] New message: "Define injected persistence unit outside the ejb.jar"
User development, A new message was posted in the thread "Define injected persistence unit outside the ejb.jar": http://community.jboss.org/message/531349#531349 Author : Thomas Goettlich Profile : http://community.jboss.org/people/ThomasGo Message: -- Hi, I have a question regarding the injection of persistence units/entity managers: Consider the following setup: ear +- ejb_a.jar | +- DAO_A | +- Entity_A +- ejb_b.jar | +- DAO_B | +- Entity_B +- ejb_c.jar | +- DAO_C | +- Entity_C +- persistence.jar +- persistence.xml +- orm.xml ejb_a.jar and ejb_b.jar are components that are independent of the application. However, since the application might require some specific setup, the components only define some default settings via annotations, e.g. @Table(...) etc. The project-specific persistence.jar contains a persistence.xml that references the orm.xml which in turn defines application specific overrides. This works so far. The problem I'm facing now is the following: Each of the DAOs currently references a persistence unit by name (@PersistenceContext(unitName = "XXX")), which is defined in the persistence.xml. If DAO_B needs to load instances of Entity_A it should use the same persistence unit. However, if Entity_A and Entity_B are independent and sometimes need to be stored in different databases, I need to specify different persistence units. If I now have a case where Entity_C and DAO_C need access to both Entity_A and Entity_B (in which case they can't be in different databases) I'd need to create another persistence unit which references all 3 entities (resp. all 3 jars via the tag). Since the jar's generally are independent components, changing the unitName in the source isn't an option. This now would lead to 3 persistence units being defined, PU_A, PU_B and PU_C. Each of those reference one or more jars with PU_C referencing all 3 whereas PU_A and PU_B just reference ejb_a.jar/ejb_b.jar. If you extend that example you can see that there would be an explosion of persistence units that are required. So finally, here's the actual question: I'd like to inject the persistence unit into the DAOs via a deployment descriptor external to the ejb.jar. AFAIK ejb-jar.xml isn't an option, since it needs to be included in the jar file, doesn't it? The next thing I found was which seemed like a viable option: define a persistence context with a given name for the DAO and map that context to a persistence unit externally. The mapping needs to be put in a deployment descriptor, so application.xml seems to be fine. However, this didn't work, with JBoss 4.2.3.GA complaining about no default persistence unit being found (which indicates the mapping is either ignored or wrong). Another thing I found is that most sites on the net give examples for putting that mapping inside the servlet definition in web.xml, so it might only work for non-ejb classes. Is that true? Thanks for reading my quite lengthy post and even more thanks for your answers. Regards, Thomas -- To reply to this message visit the message page: http://community.jboss.org/message/531349#531349 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] New message: "Re: Application/EAR level interceptors"
User development, A new message was posted in the thread "Application/EAR level interceptors": http://community.jboss.org/message/526872#526872 Author : Thomas Goettlich Profile : http://community.jboss.org/people/ThomasGo Message: -- Thanks for the hint, I'll try that after my vacation. And yes, I knew this topic would also touch JBoss AOP, but since interceptors are part of EJB I thought the topic should go here. -- To reply to this message visit the message page: http://community.jboss.org/message/526872#526872 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] New message: "Re: Application/EAR level interceptors"
User development, A new message was posted in the thread "Application/EAR level interceptors": http://community.jboss.org/message/526475#526475 Author : Thomas Goettlich Profile : http://community.jboss.org/people/ThomasGo Message: -- Well, I've faced Ththat problem multiple times so far, but wasn't able to find a way around this yet. In the current case the primary objective is to provide more logging information: Since we have multiple applications that might be more or less identical (i.e. different builds for different customers) running on the same server, we want to provide information about the application that generated a log message (e.g. "[SomeClass (App: SomeApp)] message", with SomeApp being an application supplied string ). Using log4j, I figured out that the best way to do this would be to inject the information into the MDC which can be read by PatternLayout. Our application is mostly web-based and thus the first step was to add a servlet filter which sets the information at the beginning of each request and clears it afterwards. However, we also have processed that aren't initated via http requests, e.g. scheduler jobs or process started via the JMX console. We'd also like to add the extra information in those cases, without explicitly putting it into the MDC in each method that can start a process (i.e. MBean methods, job methods etc.). This approach would be tedious and error prone, so we decided an interceptor would be the best way, since each and every call to a service would be intercepted. Thus nobody could bypass/forget that step and we'd have to write our code only once. There are also a bunch of other applications that might end up running on the same server and those would not be able to provide the information required by a global interceptor. Conceptually, an application-wide interceptor could be used for other tasks that apply to all services of only one application. IMHO, the server should not know about any specifics of the application and putting a global interceptor into the server's lib directory for just one application would contradict this. Thanks for your help in that matter. -- To reply to this message visit the message page: http://community.jboss.org/message/526475#526475 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] New message: "Application/EAR level interceptors"
User development, A new message was posted in the thread "Application/EAR level interceptors": http://community.jboss.org/message/526079#526079 Author : Thomas Goettlich Profile : http://community.jboss.org/people/ThomasGo Message: -- Hi, I want to intercept every session bean invocations in my application but I could not yet figure out how to declare EAR level interceptors. I already tried JAR level interceptors, i.e. putting an ejb-jar.xml in my ejb jars and declaring the interceptor for all session beans in that jar. My applications contains multiple ejb jars and some of them are beyond my control, i.e. I can't add or change an ejb-jar.xml there. However, I still need to intercept their calls. Another thing I tried was server level interceptors, i.e. the interceptors were placed inside a jar in the server's lib directory and registered using a xxx-aop.xml file in the server's deploy directory. However, this also isn't an option, since there are other applications that will be deployed on the same machine and the interceptor should not be visible to them (and no calls should be intercepted). A third alternative would be load-time weaving, but that's an option that is not preferred by our server administrators, since it would enable load-time weaving for all deployed applications and would also require to patch our JBoss server (which is version 4.2.3.GA, btw). So the question remains: +Is it possible to declare EAR level interceptors? And if so, how would I do that?+ Any help would ver highly appreciated. Thanks in advance. Regards, Thomas -- To reply to this message visit the message page: http://community.jboss.org/message/526079#526079 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
