Could anyone explain me how do the functions inside the HOME and REMOTE interfaces relate to the Bean object?
The interfaces are instanciated so that the functions are used. But the functions body rests only in the Bean object. What am I missing?
The actual EJB instances will typically be instances of java.lang.reflect.Proxy that delegate calls to the bean's implementation class after doing their transaction-, clustering- and security-stuff.
The Java EE container is dealing with those details for you. It knows to find the bean implementation when a call is made to that interface. It hides all the magic from you.
Related
I'm having a hard time understanding why javabeans are necessary and why they didn't just place the javabean features directly into the object class(root class) in java?
My understanding is you turn an object(instance) into a java bean and that way you get all the benefits like serializable and so on for all the objects in the bean. But if that is the case, why even have a separate bean class for this, why not just have built into the root object class?
Or am I not understand this?
You are not understanding it correctly.
There is no actual Java class or interface that is a bean. It is merely a pattern, a convention.
The bean convention is basically that a class will publicly expose some or all of its properties via public getXxx and setXxx methods, where XXX is the name of the property.
Beans generally should be serializable, but any class can be serializable, and does not need to follow the bean convention.
Besides that answer by Grey: even if there would be a Bean interface or method - not every fruit is an apple!
Meaning: there are zillions of classes that are just fine NOT being beans.
Beyond that: serialization as java does it was often found to be not that helpful. There are good reasons why we mostly serialize into JSON nowadays. In other words: we are pretty happy now that not all classes implement Serializeable by default; because Object being a Bean.
Just to talk about the no-argument constructor part of the bean pattern: A class does have a no argument constructor by default, but as soon as you create another constructor, that effectively removes it, as you probably know. But if you were forced to always have a no-argument constructor, this would be really annoying if you had a class which had a final field which is assigned by an argument in the constructor. You would then need to have some no argument constructor which either assigns everything to null, or throws an exception to tell other developers not to use the no argument so, which is just ugly.
I've just read the chapter about Constructor Bindings in Guice's User Guide but don't really understand when to use Constructor bindings.
As far as I understand, they provide the same functionality as #Provider methods, except instances created with Constructor Bindings participate in AOP. Is this correct? Can anyone give a better example than the one in the doc?
As far as I understand, they provide the same functionality as #Provider methods, except instances created with Constructor Bindings participate in AOP.
That's more or less correct, though there are some advantages that constructor binding has. Basically, it's a way of binding to a class as if it had an #Inject on a specific constructor even if it doesn't and you can't add the annotation yourself. Unlike #Provides methods, you could write utilities to allow you to do more interesting things. For instance, you could have a utilitiy method that returns the only constructor of a class, throwing an exception if there are more than one:
bind(Foo.class).toConstructor(getOnlyConstructor(FooImpl.class));
You could also use some other annotation (besides #Inject) if you wanted for some reason and have a utility method that gets the constructor that's annotated with that for binding.
For example I have proxy that is proxing interface CashManagment, toString of this proxy is somepackage.CashManagment:Stateless. I would like to know what real classes is being used by this proxy.
I think its EJB. CashManagment has more than one implementation.
As far as I know, java.lang.reflect.Proxy — I'm assuming that's what you're talking about — does not offer any way of discovering what the underlying proxied object is, or its class for that matter. It might be obtainable by using reflection, but that would be dependent on the runtime implementation and thus not a good idea.
If you're using Spring and its proxy mechanisms, then perhaps there is a way to obtain this.
You could introduce a function getType() in the interface, which returns the type of the implementation.
Sometimes, I find some class names including Aware such as ApplicationContextAware and MessageSourceAware (spring). Does this Aware have any special meanings or is it a famous rule?
Those are not classes, are interfaces. The name is just a convention on Spring meaning that some special framework object is going to be injected to that class if it is managed by the framework.
Directly from the docs of ApplicationContextAware:
Interface to be implemented by any object that wishes to be notified of the ApplicationContext that it runs in.
In this case, the bean that implements this interface will get a reference to the ApplicationContext managing the application.
Appending adjectives like "aware" to the end is a naming scheme often used for Java interfaces. This can then be implemented by classes, and the resulting is code which is more fluent to read for human beings, like
class Broker implements ApplicationContextAware { /* ... */ }
where it's quite easy to see that this class is a broker for something, and it knows how to deal with application contexts. Besides that, the "Aware" suffix has no special meaning from the Java (compiler) perspective.
The interfaces you cite seem to be a Spring-specific convention for allowing objects to interact with the dependency injection container that created them. By implementing the interface, a class signals that it wants certain information from the container and at the same time provides a method through which to pass that information.
I'd see it simply as an attempt to find a generic name for an interface that offers such functionality, not necessarily a strong convention with a specific technical meaning.
The concept of aware interfaces:
If I want the reference of objects of spring classes like XmlBeanFactory,ApplicationContext... In 2 or more classes, then there are 3 possible ways are there.
creating 2 BeanFactories in two classes.
creating at one class and sharing to all required classes .
In the 1st case ,we are unnecessarely creating 2 BeanFactories.
In the 2nd case, classes are tightly coupled with each other.
If our class implements BeanFactoryAware interface and overrides the contractual method called public BeanFactory setBeanFactory(BeanFactory factory) then IOC container see that special interface and calls setBeanFactory method by setting BeanFactory reference to that.
In 3. case above two problems are not there.
I have provider which should inject javax.mail.Session (provider looks it up in env. context of tomcat) as singleton. There is a problem when I use field injection somewhere in code:
java.lang.IllegalArgumentException: Cannot subclass final class class javax.mail.Session
Is there a way to go round this? Only clues that I've found point to Spring AOP/Proxies.
Thanks && regards
Look at this http://code.google.com/p/google-guice/wiki/AOP. It seems that there is some limitations:
Limitations
Behind the scenes, method interception is implemented by generating
bytecode at runtime. Guice dynamically creates a subclass that applies
interceptors by overriding methods. If you are on a platform that
doesn't support bytecode generation (such as Android), you should use
Guice without AOP support.
This approach imposes limits on what classes and methods can be
intercepted:
Classes must be public or package-private. Classes must be non-final
Methods must be public, package-private or protected Methods must be
non-final Instances must be created by Guice by an #Inject-annotated
or no-argument constructor