I don't see any downside in having to make POJOs implement Serializable. But just thinking that why somebody else has to force me to do something when it is not absolutely necessary?
If I am going to use hibernate in distributed environment I would make POJOs serializable anyway, hibernate shouldn't forcing me.
And If it ts that Secondary cache implementations needed, why only IDs need Serializable and not actual entities?
I see that hibernate's session.get() and load() methods is accepting only Serializable IDs as argument to get Entities.
As per my understanding of hibernate, it will generate an SQL statement and send it to DBMS when it needs to get a row from DB.
It will never need to send a java object over network.
In that case why hibernate is forcing serialization on us? It can easily use Class to accept IDs.
Even if Serialization has many benefits, I would like to take that decision of making ID objects Serializable on my own.
Is there any specific reason there which I am missing?
I have a non-public bean class in the package "demo.beans" with some setter methods.
I am setting these values in the Spring configuration file. But, setter injection should be failed since my bean class is in different package and BeanFactory (or XmlBeanFactory) is in different package.
Spring Client Application:
But, it is running normally. How BeanFactory was able to access my bean class ( with default access ), which is in the other package? How JVM allows this?
It is a rule in Java that you have to allow to send Array of String object to main, whether you will pass parameters at run time or not. Even you don't have any need to send parameters through command line you must write main method like
public static void main(String a)
you can use any identifier name in the place of a.
The above link says SessionFacade will reduce network calls made to the server. But how - putting a session bean between client and server - will reduce network calls? We have to still make all the calls to the SessionFacade which is other side on the network. Then how it will reduce network traffic?
DispatchAction and LookupDispatchAction both are used to combine related operations into a single class, so that they can share common resources like helper methods without exposing them to other classes.
DispatchAction selects the method to execute depending on the request parameter value which is configured in the xml file. This will be problematic for internationalized applications since the values will be different for different locales. So, LookupDispatchAction looks into the resource bundle file and find out the corresponding key name. We can map this key name to a method name by overriding the getKeyMethodMap() method.