Using javax.management.* api in Hibernate - java

Just curious,What is the use of below imports in java.I'm wrongly imported while doing hibernate stuff and those are not compatible with hibernate.
import javax.management.Query;
import javax.management.QueryExp;
I gone through the api and found in that they can fire queries on the beans.
Can i use them on my hibernate pojo(to avoid some memory eat up)??or I understood in a wrong way ??
Any idea about them??

I gone through the api and found in that they can fire queries on the beans.
Not exactly. API Page states:
The MBean Server can be queried for MBeans that meet a particular condition, using its queryNames or queryMBeans method
So, it's not exactly about regular pojos. MBean or managed bean is one of the concepts introduced by Java Management Extensions (JMX) technology. As JMX Technology Overview states:
The Java objects that implement resources and their instrumentation are called managed beans, or MBeans. MBeans must follow the design patterns and interfaces defined in the JMX specification (JSR 3). This ensures that all MBeans provide the instrumentation of managed resources in a standardized way.
Basically MBeans are used to extend standard JVM management functionality. So, developers can integrate application-specific options to standard monitoring tools (jconsole) and, thus, simplify and standardize resource administration.
Query is just a utility class that introduce several methods used to build QueryExps. QueryExp objects are used to query MBeansServer.
Can i use them on my hibernate pojo(to avoid some memory eat up)?
Well, they aren't meant to be used that way. So, using them for such a purposes will just introduce confusion.
If you are looking for a way to query your pojos (I don't understand how does it help with memory eat up, though), check out these questions:
How do you query object collections in Java (Criteria/SQL-like)?
What is the Java equivalent for LINQ?

They are part of the JMX Framework. I don't think using them without the framework would make sense.

Related

How does jconsole get all the information he needs?

I want to make a system to gather some data of the JVM and notify me at certain levels, jconsole have this data, but I have no idea how it collects such data.
Does someone know a way to gather this data programatically with java?
As described in the docs for JConsole, it "is a monitoring tool that complies to the Java Management Extensions (JMX) specification" and "uses the extensive instrumentation of the Java Virtual Machine" to gather datta.
In other words, it uses the Java Management Extensions (JMX).
JMX provides a ton of data from various sources within the JVM, and new data sources can be defined by libraries. These are advertised using managed beans (JMX MBeans), which use a particular set of defs or annotations to indicate that they provide data or operations, what, and how.
with the JMX 2.0 spec, you can use a set of annotations to mark your beans, making it fairly easy to provide data. Depending on your container, adding new beans may be trivial. JMX can act as both a data source and allow methods to be called from the console or other client, actually allowing you to perform (supported) operations on the VM being watched.
Various containers (such as Tomcat) and libraries (such as C3P0) provide additional metrics, in addition to the slew of beans the JVM provides. These expose such things as memory usage (one of the more popular).
These beans are exposed by the JVM over a pair of ports using a domain: key-property-list naming convention. Each bean and property exposes some relevant information, which clients like JConsole can use to build the tree of available beans and each screen with counters and buttons.

Framework like ATG Dynamo Application Framework

I am a ATG developer, I am developing an application for my own venture, I know ATG is pretty expensive. So I want to know if there is any java framework like ATG. Of if any way to use ATG DAF free of cost or with min. expense. I just want to use the basic of DAF, Nucleus(component model), Repository and dsp taglibs.
I don't work for Oracle so I can't comment on the commercial aspects of your question. That said, the components you are referring to are available in some shape or form in other JAVA based technologies which, with your knowledge of ATG you should be able to pick up quite quickly.
For example the Nucleus provides you IOC in a similar way that Spring does. The repository layer is a precursor to Hibernate while most of the DSP tags (useful ones at least) is mimicked by JSTL.
You could also refer to this discussion elsewhere on Stackoverflow where opensource alternatives to ATG is being discussed.
You can go for Spring. Spring also provide much thing which help you to developing these your own venture. You can also use Hibernate as per repository layer.
Though there are no exact framework like ATG dynamo, but I have found combination of Strips Framework (https://stripesframework.atlassian.net/wiki/display/STRIPES/Home) and Ebean as ORM (http://ebean-orm.github.io/) to be closed in offering to ATG.
Most of the things behave in the same manner as ATG. Below are few examples
In ATG you refer to components by path like /com/path/MyComp in stripes you refer to ActionBeans using package like com.path.MyComp and you can access all the properties using ${actionbean.myProperty} as you do in ATG
is equivalent to droplets, only better, instead of always calling service method(which forces you to write all the code in service method) you can invoke any method you want by passing name of the method in event variable
For pipeline they have Interceptors
Also have a pretty awesome validation framework
Like ATG Stripes is also very customizable
Ebean
Ebean is also very much simple to use, it used JPA mappings

Dependency Injection in OSGI environments

First some background:
I'm working on some webapp prototype code based on Apache Sling which is OSGI based and runs on Apache Felix. I'm still relatively new to OSGI even though I think I've grasped most concepts by now. However, what puzzles me is that I haven't been able to find a "full" dependency injection (DI) framework. I've successfully employed rudimentary DI using Declarative Services (DS). But my understanding is that DS are used to reference -- how do I put this? -- OSGI registered services and components together. And for that it works fine, but I personally use DI frameworks like Guice to wire entire object graphs together and put objects on the correct scopes (think #RequestScoped or #SessionScoped for example). However, none of the OSGI specific frameworks I've looked at, seem to support this concept.
I've started reading about OSGI blueprints and iPOJO but these frameworks seem to be more concerned with wiring OSGI services together than with providing a full DI solution. I have to admit that I haven't done any samples yet, so my impression could be incorrect.
Being an extension to Guice, I've experimented with Peaberry, however I found documentation very hard to find, and while I got basic DI working, a lot of guice-servlet's advanced functionality (automatic injection into filters, servlets, etc) didn't work at all.
So, my questions are the following:
How do declarative services compare to "traditional" DI like Guice or Spring? Do they solve the same problem or are they geared towards different problems?
All OSGI specific solutions I've seen so far lack the concept of scopes for DI. For example, Guice + guice-servlet has request scoped dependencies which makes writing web applications really clean and easy. Did I just miss that in the docs or are these concerns not covered by any of these frameworks?
Are JSR 330 and OSGI based DI two different worlds? iPOJO for example brings its own annotations and Felix SCR Annotations seem to be an entirely different world.
Does anybody have experience with building OSGI based systems and DI? Maybe even some sample code on github?
Does anybody use different technologies like Guice and iPOJO together or is that just a crazy idea?
Sorry for the rather long question.
Any feedback is greatly appreciated.
Updates
Scoped injection: scoped injection is a useful mechanism to have objects from a specific lifecycle automatically injected. Think for example, some of your code relies on a Hibernate session object that is created as part of a servlet filter. By marking a dependency the container will automatically rebuild the object graph. Maybe there's just different approaches to that?
JSR 330 vs DS: from all your excellent answers I see that these are a two different things. That poses the question, how to deal with third party libraries and frameworks that use JSR 330 annotations when used in an OSGI context? What's a good approach? Running a JSR 330 container within the Bundle?
I appreciate all your answers, you've been very helpful!
Overall approach
The simplest way to have dependency injection with Apache Sling, and the one used throughout the codebase, is to use the maven-scr-plugin .
You can annotate your java classes and then at build time invoke the SCR plugin, either as a Maven plugin, or as an Ant task.
For instance, to register a servlet you could do the following:
#Component // signal that it's OSGI-managed
#Service(Servlet.class) // register as a Servlet service
public class SampleServlet implements Servlet {
#Reference SlingRepository repository; // get a reference to the repository
}
Specific answers
How do declarative services compare to "traditional" DI like Guice or Spring? Do they solve the same problem or are they geared towards different problems?
They solve the same problem - dependency injection. However (see below) they are also built to take into account dynamic systems where services can appear or disappear at any time.
All OSGI specific solutions I've seen so far lack the concept of scopes for DI. For example, Guice + guice-servlet has request scoped dependencies which makes writing web applications really clean and easy. Did I just miss that in the docs or are these concerns not covered by any of these frameworks?
I haven't seen any approach in the SCR world to add session-scoped or request-scoped services. However, SCR is a generic approach, and scoping can be handled at a more specific layer.
Since you're using Sling I think that there will be little need for session-scoped or request-scoped bindings since Sling has builtin objects for each request which are appropriately created for the current user.
One good example is the JCR session. It is automatically constructed with correct privileges and it is in practice a request-scoped DAO. The same goes for the Sling resourceResolver.
If you find yourself needing per-user work the simplest approach is to have services which receive a JCR Session or a Sling ResourceResolver and use those to perform the work you need. The results will be automatically adjusted for the privileges of the current user without any extra effort.
Are JSR 330 and OSGI based DI two different worlds? iPOJO for example brings its own annotations and Felix SCR Annotations seem to be an entirely different world.
Yes, they're different. You should keep in mind that although Spring and Guice are more mainstream, OSGi services are more complex and support more use cases. In OSGi bundles ( and implicitly services ) are free come and go at any time.
This means that when you have a component which depends on a service which just became unavailable your component is deactivated. Or when you receive a list of components ( for instance, Servlet implementations ) and one of them is deactivated, you are notified by that. To my knowledge, neither Spring nor Guice support this as their wirings are static.
That's a great deal of flexibility which OSGi gives you.
Does anybody have experience with building OSGI based systems and DI? Maybe even some sample code on github?
There's a large number of samples in the Sling Samples SVN repository . You should find most of what you need there.
Does anybody use different technologies like Guice and iPOJO together or is that just a crazy idea?
If you have frameworks which are configured with JSR 330 annotations it does make sense to configure them at runtime using Guice or Spring or whatever works for you. However, as Neil Bartlett has pointed out, this will not work cross-bundles.
I'd just like to add a little more information to Robert's excellent answer, particularly with regard to JSR330 and DS.
Declarative Services, Blueprint, iPOJO and the other OSGi "component models" are primarily intended for injecting OSGi services. These are slightly harder to handle than regular dependencies because they can come and go at any time, including in response to external events (e.g. network disconnected) or user actions (e.g. bundle removed). Therefore all these component models provide an additional lifecycle layer over pure dependency injection frameworks.
This is the main reason why the DS annotations are different from the JSR330 ones... the JSR330 ones don't provide enough semantics to deal with lifecycle. For example they say nothing about:
When should the dependency be injected?
What should we do when the dependency is not currently available (i.e., is it optional or mandatory)?
What should we do when a service we are using goes away?
Can we dynamically switch from one instance of a service to another?
etc...
Unfortunately because the component models are primarily focused on services -- that is, the linkages between bundles -- they are comparatively spartan with regard to wiring up dependencies inside the bundle (although Blueprint does offer some support for this).
There should be no problem using an existing DI framework for wiring up dependencies inside the bundle. For example I had a customer that used Guice to wire up the internal pieces of some Declarative Services components. However I tend to question the value of doing this, because if you need DI inside your bundle it suggests that your bundle may be too big and incoherent.
Note that it is very important NOT to use a traditional DI framework to wire up components between bundles. If the DI framework needs to access a class from another bundle then that other bundle must expose its implementation details, which breaks the encapsulation that we seek in OSGi.
I have some experience in building applications using Aries Blueprint. It has some very nice features regarding OSGi services and config admin support.
If you search for some great examples have a look at the code of Apache Karaf which uses blueprint for all of its wiring.
See http://svn.apache.org/repos/asf/karaf/
I also have some tutortials for Blueprint and Apache Karaf on my website:
http://www.liquid-reality.de/display/liquid/Karaf+Tutorials
In your environment with the embedded felix it will be a bit different as you do not have the management features of Karaf but you simply need to install the same bundles and it should work nicely.
I can recommend Bnd and if you use Eclipse IDE sepcially Bndtools as well. With that you can avoid describing DS in XML and use annotations instead. There is a special Reference annotation for DI. This one has also a filter where you can reference only a special subset of services.
I am using osgi and DI for current my project, I've choosed gemini blueprint because it is second version of SPRING DYNAMIC MODULES, Based on this information I suggest you to read Spring Dynamic Modules in Action. This book will help you to understand some parts and points how to build architecture and why is it good :)
Running into a similar architecture problem here - as Robert mentioned above in his answer:
If you find yourself needing per-user work the simplest approach is to
have services which receive a JCR Session or a Sling ResourceResolver
and use those to perform the work you need. The results will be
automatically adjusted for the privileges of the current user without
any extra effort.
Extrapolating from this (and what I am currently coding), one approach would be to add #param resourceResolver to any #Service methods so that you can pass the appropriately request-scoped object to be used down the execution chain.
Specifically we've got a XXXXService / XXXXDao layer, called from XXXXServlet / XXXXViewHelper / JSP equivalents. So managing all of these components via the OSGI #Service annotations, we can easily wire up the entire stack.
The downside here is that you need to litter your interface design with ResourceResolver or Sessions params.
Originally we tried to inject ResourceResolverFactory into the DAO layer, so that we could easily access the session at will via the factory. However, we are interacting with the session at multiple points in the hierarchy, and multiple times per request. This resulted in session-closed exceptions.
Is there a way to get at that per-request ResourceResolver reliably without having to pass it into every service method?
With request-scoped injection on the Service layers, you could instead just pass the ResourceResolver as a constructor arg & use an instance variable instead. Of course the downside here is you'd have to think about request-scope vs. prototype-scope service code and separate out accordingly.
This seems like it would be a common problem where you want to separate out concerns into service/dao code, leaving the JCR interactions in the DAO, analogous to Hibernate how can you easily get at the per-request Session to perform repo operataions?

Why is the Spring framework called "non-intrusive"?

Spring framework is NON - INTRUSIVE.
Can you please elaborate this?
Thank You :)
Here, "non-intrusive" means that your application code doesn't need to depend on the Spring framework directly. Anything that can inject the appropriate dependencies will (theoretically) work just as well.
The main appeal of a nonintrusive framework is that it stays out of the way of your design and modelling activities. It stays completely out of the way until you need it.
It is perfectly possible to use Spring without any direct dependencies on the spring framework in your application code. That doesn't mean the code will continue to function without spring, since the functionality provided by spring will need to be replaced by another IoC container or code which directly instantiates all objects in a dependency chain, but it does mean that you can choose to wire things up with spring, or via some other mechanism.
However, to be really unintrusive with spring, you need to keep all of your configuration outside of your code, which means using XML for everything. This works beautifully in spring, but its a pain in the neck for developers and, since the advent of the widespread use of annotations in Java 5, isn't really the java way. So spring provides lots of annotations for wiring things together directly in your code. This can obviously create dependencies on Spring within the code, although all of the Spring tags are resolved at compile time, so you can still execute your classes outside of a spring context without any dependencies on spring jars and such. Also, wherever possible, custom spring annotations have been replaced with generic JEE annotations. With Spring 3, it is really pretty easy to use only JEE annotations plus a limited quantity of XML to initialize the application context.
The beauty of the spring way of doing things is that the underlying functionality which implements a feature can often be selected at runtime. If you are using an ORM system in a non-managed container for development, using a native session manager, you can easily switch to container managed sessions in production without changing any code whatsoever if you have configured the app to let spring handle transaction management. Methods that are marked as #Transactional will pick up a session and transaction automatically, regardless of the source, without any changes to the code. In fact, you can trivially switch to an entirely different ORM framework, if you are so inclined, though that's a pretty rare use case, in truth, so most applications will tend to have ORM framework specific code and/or queries in their data access code.
The difference between spring and an old-fashioned 'intrusive' framework is that intrusive frameworks often require you to implement particular interfaces or, even worse, force you to inherit from particular base classes, in order to access framework functionality. In the latter case, not only do you have a dependency on the framework you are using, but it severely limits your class hierarchy structure, too - in a language which only allows single inheritance. Recent versions of EJB learned from the elegance of Spring's (and others') less-intrusive model and EJB itself has since become much less intrusive (It's all about the POJOs).
I don't really see any support for irreputable's argument that spring is now a billion dollar beast that locks users in. Spring is, if anything, less intrusive than it has ever been while offering ever more functionality. It is certainly possible to lock yourself into spring, and a lot of devs are perfectly willing to do so precisely because the runtime overhead of using spring is so trivially small that most of us can't imagine a lot of scenarios in which we might remove spring from a project. If I want a fully managed JEE environment, I can configure for that (and run in the container of any available vendor). If I want to run in tomcat or jetty with 100% of configuration and runtime management coming from spring, I can do that, too. So I'm generally perfectly happy to use spring-specific functionality at the risk of lock-in unless the project requirements specifically forbid it. Spring adds very little overhead at runtime, so it is a low risk choice.
When push comes to shove, I find Spring to be far easier to learn than EJB. I can accomplish the same things with either methodology, but it is easier to bring in devs who are inexperienced if I'm using Spring compared to EJB, so hiring is easier, long term maintenance costs are lower, and release cycles are shorter.
No matter what the language direction, generally speaking, a framework is too intrusive, which is a voice of criticism, so I guess it is not because of this that non intrusiveness has become a "selling point" of publicity.
For example, spring and struts 2 use annotations, configuration files, conventions or reflection (other languages may be other ways) to achieve non-invasive, and the compilation and operation does not have formal dependence on the framework API.
But in essence, without this framework, our program simply cannot run correctly. These so-called annotations are customized. When and how they are processed are different. Think about the migration from gson to Jackson. The migration has costs and risks. Do you need users to write a new one?
In addition, how high is the probability of real migration? It feels very small.
years ago, there was this EJB beast, which was very "intrusive". Spring was touted to be a much simpler set of helper classes, and it was more like libraries than frameworks.
today, Spring becomes the new beast. As a billion dollar business, it is in their best interest to lock people in. Yeah, sure, you don't have a dependency problem, and you can quit Spring anytime.
With EJB, at least you have a few vendors to choose from.

How to implement Singleton-like EJB3.0 bean?

I need to implement a simple DAO bean, which also caches data read from the database. This DAO bean is used by stateless beans.
Because EJB3.0 doesn't support singleton beans, what would be the correct way to implement such a DAO bean? Is it ok to just use static variable to keep the cache?
We are using Oracle AS and not going to use clustering.
The "correct" way to do this in a somewhat cross-appserver way is to use a jmx mbean for the caching behavior. mbeans are singletons (per-app server) and can do things like threading and locking. depending on the appserver you use, of course, mbeans can be more or less difficult to work with in practice.
Most Application servers and JPA implementations offer some sort of built-in caching mechanism which is controllable by the user. It might be worthwhile investigating ways of accomplishing what you want without having to build a singleton.
One of the major issues with singletons and J2EE is that there is no easy way to handle them in a clustered environment.
That all said, I did find an article which makes some suggestions for possibly doing what you want under JBoss, and mentions a new #Singleton annotation for EJB3.1 so that may be a possibility. If that works for you, you should write up what you did as another answer to this question.
If you are running on Weblogic server, it is actually possible to implement a singleton bean that is also cluster-aware. I don't believe this feature exists on other application servers though.

Categories