We have a third party application deployed on JBoss and Weblogic. We need to log access to EJBs in this application for audit purposes. Is it possible to apply a transparent service that will log all calls to these EJBs to a file or database ?
The only option that I can think of is to use Spring as a business delegate and modify clients to use the Spring bean. Unfortunately, we do not have an option of modifying client code and this has to be done on the server in a way that our code gets executed before and after EJBs are invoked by clients.
I searched for a solution for this and have found nothing that could point me the right direction.
Thank you for the help.
Edit:
After further research, it appears that JBoss does support custom EJB interceptors. Configuration for this is possible using standardjboss.xml for EJB 2.x and ejb3-interceptors-aop.xml for EJB 3.x
As it turns out, there is not much available by way of samples on how to create such interceptors for use with EJB 2.x - which is what I need. It does not appear too difficult and I will try this to see if it works.
You should be able to just use straight forward EJB 3 interceptors. Look for DefaultInterceptor in http://docs.jboss.org/ejb3/docs/tutorial/1.0.7/html/EJB3_Interceptors.html to see how to apply an interceptor to all ejbs in your deployment. This is supported by the EJB 3 spec.
For EJB 2.x in JBoss, take a look at standard-jboss.xml. There you can either modify the full default containers for the different ejb types. You can also create a new container configuration in standard-jboss.xml and add your interceptors there and associate your EJBs with the new configuration by including a jboss.xml in your ejb.jar META-INF/ folder. Or, if I remember correctly, you can both define the new container configuration and the association in META-INF/jboss.xml. Some information here: http://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/EJBDeployer_MBean-Container_configuration_information.html
Related
I need to execute some code after the start of the application server (JBoss).
I googled the annotations #startup and #create that might prove useful, but in this situation seems impossibile to operate with EntityManager or Hibernate current session (if using Hibernate).
Is there any chance to perform Hibernate operation immediately after JBoss is started?
Are you using a framework? If not, you could use a startup servlet. In your web.xml, simply mark the servlet to have a <load-on-startup> value and it will run when the webapp is started. If you want it to load after other servlets, just set the load order.
If you are using a framework, it will have its own methodologies, such as Spring's InitializingBean interface.
You could deploy a custom JBoss service or just use plain old portable ServletListener in a war.
I'm currently developing a small EJB application running on IBM Websphere Application Server 7 (Java EE 5). The app mainly consists of one MDB listening for incoming MQ messages which are transformed and stored in a DB. Currently I'm using a lot of Singleton/Factories to share configurations, mappings, datasource lookups etc. But this actually leads to some very hard to test code. The solution might be using a (simple) DI framework like guice/spring to inject the different instances. The question is: Where to place the initialization/ setup code? Where is the main entry point of the application? How can I inject instances into the MDBs?
it might be worth looking at backing off from using Guice, and trying to work with the injection mechanisms already available with Java EE 5.
Regarding finding a suitable "startup point", unfortunately the EJB specification does not define a way where you can have a bean run at startup. However, the web profile of the EE spec does have one -- you can add a WAR to your application, and set a servlet listener component:
http://java.sun.com/javaee/5/docs/api/javax/servlet/ServletContextListener.html
You can set this to start whenever the application is loaded and started by the container (WebSphere). Watch out for classloader issues though.
Using Spring, you can do it via EJB3 interceptors, see http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/ejb.html#ejb-implementation-ejb3
Useful info on caveats are in the javadoc, make sure you read it: http://static.springsource.org/spring/docs/3.0.x/api/org/springframework/ejb/interceptor/SpringBeanAutowiringInterceptor.html
On the Tomcat FAQ it says: "Tomcat is not an EJB server. Tomcat is not a full J2EE server."
But if I:
use Spring to supply an application context
annotate my entities with JPA
annotations (and use Hibernate as a
JPA provider)
configure C3P0 as a connection pooling data
source
annotate my service methods
with #Transactional (and use Atomikos
as JTA provider)
Use JAXB for marshalling and unmarshalling
and possibly add my own JNDI capability
then don't I effectively have a Java EE application server? And then aren't my beans EJBs? Or is there some other defining characteristic?
What is it that a Java EE compliant app server gives you that you can't easily/readily get from Tomcat with some 3rd party subsystems?
EJBs are JavaEE components that conform to the javax.ejb API.
JavaEE is a collection of APIs, you don't need to use all of them.
Tomcat is a "partial" JavaEE server, in that it only implements some of the JavaEE APIs, such as Servlets and JNDI. It doesn't implement e.g. EJB and JMS, so it's not a full JavaEE implementation.
If you added some additional bits and pieces (e.g. OpenEJB, HornetQ), you'd add the missing parts, and you'd end up with a full JavaEE server. But out of the box, Tomcat isn't that, and doesn't try to be.
But if I add (...) then don't I effectively have a Java EE application server? And then aren't my beans EJBs? Or is there some other defining characteristic?
No, you don't have a Java EE application server, a full-fledged Java EE application server is more than Tomcat + Spring + a standalone Transaction Manager. And even if you add a JMS provider and an EJB container, you still won't have a Java EE server. The glue between all parts is IMO important and is part of the added value of a Java EE container.
Regarding EJBs, the EJB specification is much more than JPA and specifices also Session Beans and Message Driven Beans (actually, I don't really consider JPA Entities as EJBs even if JPA is part of the EJB 3.0 specification in Java EE 5 for historical reasons - which is not true anymore in Java EE 6, JPA 2.0 and EJB 3.1 are separate specifications).
I should also mention that a Spring bean annotated with #Transactional is not equivalent to a Session Bean. A Java EE container can do more things with Session Beans (see below). You may not need them though but still, they are not strictly equivalent.
Last thing, Java EE containers implement a standard, the Spring container does not, it is proprietary.
What is it that a Java EE compliant app server gives you that you can't easily/readily get from Tomcat with some 3rd party subsystems?
As I said, I think that the "glue" is a part of the added value and highly contributes to the robustness of the whole. Then, ewernli's answer underlined very well what is difficult to achieve. I'd just add:
Clustering and Fail-over (to achieve fault-tolerance)
Administration facilities
Yes, a good Java EE server will do pretty neat things to improve fault tolerance (clustering of connection pools, JNDI tree, JMS destinations, automatic retry with idempotent beans, smart EJB clients, transaction recovery, migration of services, etc). For "mission critical" applications - the vast majority are not - this is important. And in such cases, libraries on top of the Servlet API are IMO not a replacement.
1) You're confusing JPA entities with EJBs. While JPA belongs to the EJB3 specification, it was always meant to be a standalone technology.
2) EJBs are: stateless beans, stateful beans and message driven beans. While each of these functionalities can easily be achieved using spring, spring just does not use this terminology. In Spring, you don't have POJO + "magic" as in EJBs, in Spring it's POJO + your own configuration (which sometimes feels like magic, too). The main difference is that spring does more and the application server does less, which is why a spring app is happy with a tomcat while an ejb3 app needs a 'real' application server.
In my opinion, 90% of applications can be deployed using spring + tomcat, ejb3 is rarely needed.
Indeed, if you put enough effort you can almost turn Tomcat/Spring into a full-fledged heavyweight application server :) You could even embed a portable EJB3 container...
What is it that a Java EE compliant app
server gives you that you can't
easily/readily get from Tomcat with
some 3rd party subsystems?
There are still a few features that are hard to get with 3rd party modules:
stateful session beans (SFSB)
extended persistence context
application client container / java web start
clustering depending on the app. server
CORBA interoperability
JCA integration ~
remoting ~
container-managed transactions ~
decent management of distributed transactions (e.g. recover heuristic tx)
Entries with ~ are also supported by Spring, but not so trivially, at least to my best knowledge.
A few more details in this answer: EJB vs Spring
Outside of the strict definition of what is and isn't an EJB, you're adding a lot of stuff to Tomcat. Even if what you have is an EJB server, it's not really plain Tomcat anymore.
The FAQ is correct: Tomcat is not an EJB server. However, it can be that or many other things if you pile on enough extra libraries and code.
An EJB implementation would be a bean written and packaged to run on any compliant EJB server. If you do what you describe, it may work, but it won't be portable to another vendor's application server.
So EJB is a standard that adheres to a specific specification and is therefore portable.
In practice many EJB's are not fully compliant or application server neutral. However, in the main they are, so the small incompatibilities would be much easier to fix if you changed application server vendors than attempting to move the architecture you described to a GlassFish, JBoss or Weblogic server.
EDIT: In response to your comment you would not have an EJB appropriately annotated and/or configured via XML in such a way that code that accessed it in EJB compliant ways would be able to use it without changes.
There are two angles to your comment. One is what functionality would you lose deploying on a JBoss or any of the others instead of Tomcat? Likely nothing, if you brought along all of the frameworks you relied on. However, if you wanted to move your code to Weblogic, for example, to use some of its features, then your code would need some likely significant changes to keep up.
I am not saying that you cannot replicate all EJB functionality (certainly the subset you care about) via other means, just that it is not the spec, and therefore not implementation independent.
then don't I effectively have a Java EE
application server? And then aren't my
beans EJB's? Or is there some other
defining characteristic?
Quick answer EJBs actually have to follow a Java EE specification. Tomcat is a Java EE container not an app server.
What is it that a Java EE compliant app
server gives you that you can't
easily/readily get from Tomcat with
some 3rd party subsystems?
Quick answer to your second question. In your case most likely nothing.
EJBs tend to be really heavy objects and people ended up using them to solve problems when they were essentially overkill. Frameworks like Spring were created to solve those problems without using EJBs. I think the first book where Spring was introduced was even called "J2EE development without EJB."
I am using Spring to manage my DAO & Services. And JSF for UI. I want to use dependency injection in my JSF backing-bean. There is an article that explained how I can do that.
But I have two separate projects: one for Service and one for UI. The Spring configuration file is located in Service project.
How can I connect both project with Spring? I want to annotate my JSF pages for DI.
You can achieve this by using Spring Web Flow.
Spring have examples which show:
A JSF centric approach where your Spring and JSF beans are managed/configured the JSF way (faces-config) and a
Spring centric approach where your beans (including ManagedBeans) are managed in the Spring Context.
See Spring Flow Web Home
If you mean that you have one WAR with web services defined in it, and another separate WAR with the JSF stuff, I think it's really two separate projects each with their own Spring configuration.
The web service WAR will use either Spring web services or perhaps HTTP remoting to expose your service interfaces to clients via HTTP. This will have one set of application context configuration, either XML or annotations.
The JSF WAR will have the JSPs and controllers. The controllers will be injected with clients that will interact with the remote services to accomplish what you wish. That's all they need to know about the service WAR. There doesn't need to be any duplication of configuration at all.
It's actually a nice design, because it completely decouples the view from the rest of the problem.
Thank for everyone I did it. My mistake was with bean initialization. I tried to access my injected bean in constructor, but must must did in #PostConstruct method. And all that time i tried to find mistake in my config file. But it was in such simply place :)
I find some solution one:
Sample Application using JSF, Spring 2.5, and Java Persistence APIs with Glassfish v2
. But I have problem with it.
I can post this problem hear or must create new topic? Sorry for stupid question, i'm newbie her.
OSGi employs a service-oriented architecture: Bundles register service objects, that other bundles consume. Service publishing and binding is managed by the framework. This decouples service providers from service users completely (except for the need to agree on a service interface).
Is there a way to limit (by configuration) what services are visible to what bundles ?
For example, if I have an HttpService, all bundles that feel like doing so can install servlets into it. I would like to make the HttpService not visible to selective bundles.
For extra credits: In addition to just filtering service registrations, the ability to modify registration properties. So that even if a bundle registers a Servlet with alias=/admin, I can change that to alias=/somethingelse for consumption by Pax Web Extender Whiteboard.
Is there a way to limit (by configuration) what services are visible to what bundles?
As you are aware, it is possible to filter on service properties, though this probably doesn't give the sort of control you are asking for: the services are still visible to other bundles deployed in the framework.
In SpringSource's dm Server (an open-source, modular, OSGi-based Java application server) an application can be Scoped when it is deployed. This allows you to deploy multiple applications (in separate scopes) that might include inconsistent versions of dependent bundles, while still allowing common bundles to be shared (by deploying them outside of a scope—in the so-called global scope).
If a scoped application/bundle registers an OSGi service it is only available to the bundles in the same scope. (The services are 'scoped' as well.)
This is not magic: the server wraps the OSGi services interfaces and uses service properties 'under the covers' to perform the filtering required on-the-fly.
I think this would give you the sort of separation you are looking for.
For information about dm Server (not to be confused with Spring DM) go to the SpringSource.org dmServer page.
Steve Powell
SpringSource; dm Server Development
The upcoming R4.2 of the OSGi specification define a component called Find Hook that allows exactly to:
"inspect the returned set of service references and optionally shrink the set of returned services"
See
http://www.osgi.org/download/r4-v4.2-core-draft-20090310.pdf section 12.5
Please note that R4.2 is not final yet, still I believe the major OSGi implementations (Felix and Equinox) already have the code for this additional functionality in their trunk
Is there a way to limit (by configuration) what services are visible to what bundles ?
There is no way to do that using service properties. You could define your own service property that specifies which bundles should consume the service you are exporting, but there is no way to prevent other bundles from consuming it as well.
For extra credits: In addition to just filtering service registrations, the ability to >modify registration properties. So that even if a bundle registers a Servlet with >alias=/admin, I can change that to alias=/somethingelse for consumption by Pax Web >Extender Whiteboard.
Well... that's a tough one. You could define your own Servlet interface "MyServlet" and export your Servlets using that interface. Then, another bundle could consume those MyServlets and re-export them as Servlets with modified service properties.
Other than that ... no idea.
I haven't tried this, but seems like it may help you...
In the OSGi R4 Component Spec describes the "Configuration Admin Service" which, from a 5 minutes inspection, appears to be able to alter services dynamically.
Ultimately I think it will be up to you to control access to the services based on some agreed upon configuration values
For extra credits: In addition to just filtering service registrations, the ability to modify registration properties. So that even if a bundle registers a Servlet with alias=/admin, I can change that to alias=/somethingelse for consumption by Pax Web Extender Whiteboard.
using iPOJO you can change properties of the exposed services pretty simple. It has bunch of other features, which could be interessting to someone using OSGi a lot.
If you want to limit the visibility of services, your best bet is to enable OSGi security. It is designed to limit what services, packages and other things are visible to what bundles. You can for example only make a certain service available to a bundle that is signed by you (or use various other criteria).
The other option, already mentioned, it to use the 4.2 service hooks, which allow a sort of "do it yourself" security mechanism.
The second question, changing properties like the endpoint under which a service is registered, is something you can do via the ServiceRegistration that you get back when registering your service. Changes can be triggered by becoming a ManagedService and use ConfigurationAdmin to configure yourself.