One of my POJO class is implementing an interface which extends Serializable
My doubt is, As we cant include serialVersionUID in interface class can it result in Cannot Marshal EJB parameters Exception?
You can not pass ,,an interface" as parameter of java method. You can only pass an instance of some class, that implements such interface. That class will be marked as Serializable due to abstraction hierarchy. The Serializable interface is a marker interface, and your implementation class will be serializable even if it does not declare the serialVersionUid attribute(However, it is strongly recommended that you do declare the serialVersionUID).
So to answer your question: as long as the particular instance you pass to your EJB method is marked as serializable it will be fine.
Related
I've read what the annotation says but I'm kinda dumb, so couldn't understand propertly
Identifies injectable constructors, methods, and fields. May apply to static as well as instance members. An injectable member may have any access modifier (private, package-private, protected, public). Constructors are injected first, followed by fields, and then methods. Fields and methods in superclasses are injected before those in subclasses. Ordering of injection among fields and among methods in the same class is not specified.
Can you explain me what is #Inject for? If it is possible with a real life analogy with something less abstract
#Inject is a Java annotation for describing the dependencies of a class that is part of Java EE (now called Jakarta EE). It is part of CDI (Contexts and Dependency Injection) which is a standard dependency injection framework included in Java EE 6 and higher.
The most notorious feature of CDI is that it allows you to inject dependencies in client classes. What do I mean by dependencies? It is basically what your class needs to do whatever it needs to do.
Let me give you an example so that it is easier to understand. Imagine that you have a class NotificationService that is supposed to send notifications to people in different formats (in this case, email and sms). For this, you would most probably like to delegate the actual act of sending the notifications to specialized classes capable of handling each format (let's assume EmailSender and SmsSender). What #Inject allows you to do is to define injection points in the NotificationService class. In the example below, #Inject instructs CDI to inject an EmailSender and SmsSender implementation objects via the constructor.
public class NotificationService {
private EmailSender emailSender;
private SmsSender smsSender;
#Inject
public NotificationService(EmailSender emailSender, SmsSender smsSender) {
this.emailSender = emailSender;
this.smsSender = smsSender;
}
}
It is also possible to inject an instance of a class in fields (field injection) and setters (setter injection), not only as depicted above in constructors.
One of the most famous JVM frameworks taking advantage of this dependency injection concept is Spring.
I was reading about private constructor and found a few points that I couldn't understand. It said, if you declare a constructor as private:
That class cannot be explicitly instantiated from another class
That class cannot be inherited
Should be used in classes containing only static utility methods
My first question: Point 2 says the class cannot be inherited. Well, if you declare a class private then it would still satisfy this property. Is it because, if a class is private, it can still be explicitly instantiated from outside by another class?
My second question: I don't understand point 3. If I have a helper class which is full of static methods, I would never have to instantiate that class to use the methods. So, what is the purpose of a constructor in that class which you are never going to instantiate?
Answer for Java
Question 1 You're confusing a private class, with a class that has a private constructor. Private constructors are used mainly for static classes that are not meant to be instatiated (i.e. they just have a bunch of static methods on them).
Question 2 Exactly there is no need for a constructor so you have to explicitly create a private constructor so that it does not get a default constructer that the JVM will provide if none is defined
An empty class with no methods defined will always be given a no argument constructor by the JVM by default
I take java and c++ as an examples (not the best OO languages known, but very popular) - since you are not defining which languge do you mean.
Ad.2. In these languages you must either call superclass constructor explicitly or it is implicitly called for you. From a subclass you cannot call private methods (only public and protected) - this rule applies to constructors as well. This means if the class has only private constructors, there is no way to call one in subclass constructor. So you cannot subclass such class.
Ad. 3. It is just to avoid confusion - since this class is only a container for utility methods, there is no point in instantiating it. This way you can enforce this rule at compile time.
We are implementing IoC/DI in our application using NInject framework. We are having internal classes having internal methods. To implement IoC/DI, we have to extract interfaces. But if we are having only internal methods in an internal class, we can't extract interface for that class.
So is there a way to implement IoC/DI in such cases (internal class having only internal methods) or should we change our internal methods to public methods. Kindly suggest. Thanks
If your class is already internal then there is absolutely not difference between internal and public methods. public methods of internal classes are only internally visible.
If you stay with injecting concrete classes though you loose all the advantages of DI. So yes you should extract (internal) interfaces and inject the interfaces. This requires that the configuration code has access to the classes by either beeing in the same assembly of the assembly must be declased as friend assembly. Futhermore, you have to configure Ninject to allow none public classes. See NinjectSettings.
The only thing that you really need to make public is the interface (not the concrete implementation).
You can use an abstract factory or (easier) Ninject to map the public interface to the internal concrete; thus your client code just has to request an instance of "a thing" that implements the interface and your factory / container will return the implementation.
You should read up on Dependency Inversion Principle as well as it goes hand-in-hand with this.
You could use InternalsVisibleTo attribute in AssemblyInfo.cs file like this
[assembly: InternalsVisibleTo("Assembly_That_Should_Access_The_Internal_Class")]
I am playing with this example http://scala.sygneca.com/code/remoteactors to learn how remote actors work in Scala (2.8.0). In particular I slightly modified how the messages send by the actors are defined as it follows:
sealed trait Event extends Serializable
case object Ping extends Event
case object Pong extends Event
case object Quit extends Event
and everything works as expected. Unfortunately if I define the events as case classes instead of case objects as in:
sealed trait Event extends Serializable
case class Ping extends Event
case class Pong extends Event
case class Quit extends Event
my example stop working. In more detail it seems that while case objects are serializable, case classes aren't. Indeed when I try to run my example with this last modification I get the following exception:
scala.actors.remote.DelegateActor#148cc8c: caught java.io.NotSerializableException: scalachat.remote.Ping$
java.io.NotSerializableException: scalachat.remote.Ping$
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at scala.actors.remote.JavaSerializer.serialize(JavaSerializer.scala:46)
at scala.actors.remote.NetKernel.namedSend(NetKernel.scala:38)
at scala.actors.remote.NetKernel.forward(NetKernel.scala:71)
at scala.actors.remote.DelegateActor$$anonfun$act$1$$anonfun$apply$1.apply(Proxy.scala:182)
at scala.actors.remote.DelegateActor$$anonfun$act$1$$anonfun$apply$1.apply(Proxy.scala:123)
at scala.actors.ReactorTask.run(ReactorTask.scala:34)
at scala.actors.ReactorTask.compute(ReactorTask.scala:66)
at scala.concurrent.forkjoin.RecursiveAction.exec(RecursiveAction.java:147)
at scala.concurrent.forkjoin.ForkJoinTask.quietlyExec(ForkJoinTask.java:422)
at scala.concurrent.forkjoin.ForkJoinWorkerThread.mainLoop(ForkJoinWorkerThread.java:340)
at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:325)
Is there a reason why case objects can be made serializable and case classes can't? Is there a way to make my example working with case classes either?
Edit: as suggested by Victor and confirmed by Aaron I am sending the companion object as message instead of the class. Moreover inspecting the compiled code with javap it appears evident that while the class is serializable:
public class scalachat.remote.Ping extends java.lang.Object implements scalachat.remote.Event,java.io.Serializable,scala.ScalaObject,scala.Product
the companion object is not:
public final class scalachat.remote.Ping$ extends scala.runtime.AbstractFunction0 implements scala.ScalaObject
Now the question is: how can I specify that I want to use the class instead of the companion object? I also added an empty couple of parenthesis when I send the message as suggested by Aaron like in:
pong ! Ping()
but nothing is changed. In the end I also added a fake parameter to the case class
case class Ping(i: Int) extends Event
sending the message as:
pong ! Ping(0)
but without experiencing any difference still. Any suggestion?
#serializable case class Foo
I was also surprised that case objects were serializable per default.
Edit: After reading the exception properly I suspect that:
You're trying to send the generated companion object of the case class over the wire, instead of an instance of the case class.
Case classes without parameters are meaningless and deprecated. And I see no Serializable in Scala, just serializable. Does it work if you fix these things?
I have an interface that describes an specialized list in my application...
Public Interface IAlphabeticListItem
Property StartingLetter() As String
Property DetailsList() As Generic.List(Of DetailsData)
End Interface
Multiple objects implement this interface, but I want to return them in a webservice not as the underlying object, but as the interface.
<WebMethod()> _
Public Function GetCategoryList(...) As Generic.List(Of IAlphabeticListItem)
...
End Function
Sadly, this causes an exception
Cannot serialize interface IAlphabeticListItem.
Exception Details: System.NotSupportedException: Cannot serialize interface IAlphabeticListItem.
Is there a way to make an interface serializable, or am I going to have to convert each of my objects into a concrete class implementing the interface, and then return that class?
Yes and no. You cannot directly expose the generic class for XML serialization because it's not supported. You can however expose a non-generic interface on the same collection and serialize that. This blog goes into great detail on how to make this work
http://srtsolutions.com/blogs/billwagner/archive/2006/11/20/xml-serialization-and-generic-interfaces.aspx
I don't have time to test it right now, but in C# you can extend interfaces, so I suppose you can do that in VB.NET.
Just make IAlphabeticListItem extend ISerializable