For reuse reasons I have wrapped my current serialization/deserialization services in an abstract generic class, which is compiled in a shared JAR across the project. I need to serialize objects to String
The class can be extended and a type can be specified for it in other JARs/WARs (yea, this is a web application).
When I made my first deserialization tests from within the same WAR it all worked fine, but now that I moved the abstract class into another JAR I get a ClassNotFoundError when deserializing.
The base class is structured as follows:
public abstract class ConverterBase<T extends Serializable> {
public final Object getAsObject(String str) {
//Use java.io serialization services from the base64 representation
try {
ByteArrayInputStream ba = new ByteArrayInputStream(decoder
.decodeBuffer(str));
try {
ObjectInputStream is = new ObjectInputStream(ba);
try {
Object ret = is.readObject();
return ret;
} finally {
is.close();
}
} finally {
ba.close();
}
} catch (Throwable ex) {
return null;
}
}
public final String getAsString(Object obj) {
//simply do the opposite
}
}
It is structured such a way in order to allow future changes impact all subclasses (ie. avoid base64, be more efficient...). For now, the java.io solution is a temporary implementation.
Then I have the following inside the same WAR:
public class MyPojo implements Serializable {
//Stuff
}
public final class MyPojoConverter extends ConverterBase<MyPojo> { }
The class that extends this one is in a different archive than the abstract class and is specialized on an type of that WAR.
What could I do to avoid that error?
Thank you
If you want to store the data as String, I would use XML or JSon to serialise your objects with a tool like XStream. These tools are not sensitive to change in packages, class names, parent classes, interfaces or method changes.
The ObjectInputStream must be able to access all the classes which are used in the serialized objects.
Normally it should be enough if the code creating the thread (e.g. its classloader) can load each class mentioned in the stream. Make sure this is the case. (I'm not really sure about your class loader structure in your application container. If you provide more information about this, maybe others can help.)
For more complicated cases, you can create a subclass and override resolveClass there.
This is probably a class loading issue (yeah, of course).
If I got you right, the problem occurs from within your WAR, i.e. a JSP or servlet.
Please provide your stack trace, I'm not sure, which class cannot be found.
Related
Can I do it with reflection or something like that?
I have been searching for a while and there seems to be different approaches, here is a summary:
reflections library is pretty popular if u don't mind adding the dependency. It would look like this:
Reflections reflections = new Reflections("firstdeveloper.examples.reflections");
Set<Class<? extends Pet>> classes = reflections.getSubTypesOf(Pet.class);
ServiceLoader (as per erickson answer) and it would look like this:
ServiceLoader<Pet> loader = ServiceLoader.load(Pet.class);
for (Pet implClass : loader) {
System.out.println(implClass.getClass().getSimpleName()); // prints Dog, Cat
}
Note that for this to work you need to define Petas a ServiceProviderInterface (SPI) and declare its implementations. you do that by creating a file in resources/META-INF/services with the name examples.reflections.Pet and declare all implementations of Pet in it
examples.reflections.Dog
examples.reflections.Cat
package-level annotation. here is an example:
Package[] packages = Package.getPackages();
for (Package p : packages) {
MyPackageAnnotation annotation = p.getAnnotation(MyPackageAnnotation.class);
if (annotation != null) {
Class<?>[] implementations = annotation.implementationsOfPet();
for (Class<?> impl : implementations) {
System.out.println(impl.getSimpleName());
}
}
}
and the annotation definition:
#Retention(RetentionPolicy.RUNTIME)
#Target(ElementType.PACKAGE)
public #interface MyPackageAnnotation {
Class<?>[] implementationsOfPet() default {};
}
and you must declare the package-level annotation in a file named package-info.java inside that package. here are sample contents:
#MyPackageAnnotation(implementationsOfPet = {Dog.class, Cat.class})
package examples.reflections;
Note that only packages that are known to the ClassLoader at that time will be loaded by a call to Package.getPackages().
In addition, there are other approaches based on URLClassLoader that will always be limited to classes that have been already loaded, Unless you do a directory-based search.
What erickson said, but if you still want to do it then take a look at Reflections. From their page:
Using Reflections you can query your metadata for:
get all subtypes of some type
get all types annotated with some annotation
get all types annotated with some annotation, including annotation parameters matching
get all methods annotated with some
In general, it's expensive to do this. To use reflection, the class has to be loaded. If you want to load every class available on the classpath, that will take time and memory, and isn't recommended.
If you want to avoid this, you'd need to implement your own class file parser that operated more efficiently, instead of reflection. A byte code engineering library may help with this approach.
The Service Provider mechanism is the conventional means to enumerate implementations of a pluggable service, and has become more established with the introduction of Project Jigsaw (modules) in Java 9. Use the ServiceLoader in Java 6, or implement your own in earlier versions. I provided an example in another answer.
Spring has a pretty simple way to acheive this:
public interface ITask {
void doStuff();
}
#Component
public class MyTask implements ITask {
public void doStuff(){}
}
Then you can autowire a list of type ITask and Spring will populate it with all implementations:
#Service
public class TaskService {
#Autowired
private List<ITask> tasks;
}
The most robust mechanism for listing all classes that implement a given interface is currently ClassGraph, because it handles the widest possible array of classpath specification mechanisms, including the new JPMS module system. (I am the author.)
try (ScanResult scanResult = new ClassGraph().whitelistPackages("x.y.z")
.enableClassInfo().scan()) {
for (ClassInfo ci : scanResult.getClassesImplementing("x.y.z.SomeInterface")) {
foundImplementingClass(ci); // Do something with the ClassInfo object
}
}
With ClassGraph it's pretty simple:
Groovy code to find implementations of my.package.MyInterface:
#Grab('io.github.classgraph:classgraph:4.6.18')
import io.github.classgraph.*
new ClassGraph().enableClassInfo().scan().withCloseable { scanResult ->
scanResult.getClassesImplementing('my.package.MyInterface').findAll{!it.abstract}*.name
}
What erikson said is best. Here's a related question and answer thread - http://www.velocityreviews.com/forums/t137693-find-all-implementing-classes-in-classpath.html
The Apache BCEL library allows you to read classes without loading them. I believe it will be faster because you should be able to skip the verification step. The other problem with loading all classes using the classloader is that you will suffer a huge memory impact as well as inadvertently run any static code blocks which you probably do not want to do.
The Apache BCEL library link - http://jakarta.apache.org/bcel/
Yes, the first step is to identify "all" the classes that you cared about. If you already have this information, you can enumerate through each of them and use instanceof to validate the relationship. A related article is here: https://web.archive.org/web/20100226233915/www.javaworld.com/javaworld/javatips/jw-javatip113.html
Also, if you are writing an IDE plugin (where what you are trying to do is relatively common), then the IDE typically offers you more efficient ways to access the class hierarchy of the current state of the user code.
I ran into the same issue. My solution was to use reflection to examine all of the methods in an ObjectFactory class, eliminating those that were not createXXX() methods returning an instance of one of my bound POJOs. Each class so discovered is added to a Class[] array, which was then passed to the JAXBContext instantiation call. This performs well, needing only to load the ObjectFactory class, which was about to be needed anyway. I only need to maintain the ObjectFactory class, a task either performed by hand (in my case, because I started with POJOs and used schemagen), or can be generated as needed by xjc. Either way, it is performant, simple, and effective.
A new version of #kaybee99's answer, but now returning what the user asks: the implementations...
Spring has a pretty simple way to acheive this:
public interface ITask {
void doStuff();
default ITask getImplementation() {
return this;
}
}
#Component
public class MyTask implements ITask {
public void doStuff(){}
}
Then you can autowire a list of type ITask and Spring will populate it with all implementations:
#Service
public class TaskService {
#Autowired(required = false)
private List<ITask> tasks;
if ( tasks != null)
for (ITask<?> taskImpl: tasks) {
taskImpl.doStuff();
}
}
I was wondering, if I can cheat serialization by wrapping them in local nested classes, something like this:
I have a service which I need to pass around, but it internally has some very complex data.
interface ComplexService {
IncredibleComplexObject getData();
}
So I thinking about wrapping it in another class that is serializeable via decorator pattern.
public final class Utils {
public static Serializable wrap(final ComplexService service) {
class WrapperService implements ComplexService, Serializeable {
#Override
public IncredibleComplexData getData() {
return service.getData();
}
};
return new WrapperService();
}
}
I actually don't believe that I can cheat serialization like that, because it would be a little bit too much magic if Java could actually recreate my class that is dependent on my final ComplexService-parameter. But I am wondering, why exactly this fails and what exception would be thrown, where and why.
(just for clarification why I would want to do this: I am on android and I need to pass this service to a Fragment, which naturally can only save serializeable objects).
Yes, you can wrap your non-serializable object in a serializable wrapper. No, it won't magically make the wrapped object serializable. You'll get a NotSerializableException if you attempt to serialize the wrapper class (without making that field transient).
I have a singleton object that implements some basic functionality in a common library. It's much more complicated than this, but for documenting the issue, below is the Singleton implementation, with all but one inner properties/objects removed:
package mystuff.lib.common
public class CommonSingleton {
public final static CommonSingleton INSTANCE = new CommonSingleton();
private Cache<String, Object> cache = null;
private CommonSingleton() {
// Exists only to defeat instantiation.
Initialize();
}
private void Initialize() {
cache = null;
}
public Cache<String, Object> getCache() {
if (cache == null) {
cache = new Cache<String, Object>();
}
return cache;
}
public void Reload() {
Initialize();
}
}
I have included that library in two SEPARATE projects. The library isn't installed on the machine where the code runs. The contents of the common library is included within each JAR when the artifacts are created in IntelliJ IDEA.
Both projects (JAR files) load and run (as plugins) inside a parent application, so they're both loaded inside the same JVM. I expected each JAR to have its own copy of this common singleton, since they are, after all, separate JAR files. It is only included in a common library because many of my projects require the same functionality and I would rather include the library in my project than have multiple copies of the code floating around.
Project/Module #1: TestPluginOne.JAR
package mystuff.plugins.TestPluginOne;
import mystuff.lib.common.CommonSingleton;
import mystuff.lib.common.Objects.Cache;
public class TestClassOne {
public TestClassOne() {
}
public Boolean SaveItemInCache(String key, String content) {
return CommonSingleton.INSTANCE.getCache().add(key, content, 30);
}
public void Reload() {
CommonSingleton.INSTANCE.Reload();
}
}
Project/Module #2: TestPluginTwo.JAR
package mystuff.plugins.TestPluginTwo;
import mystuff.lib.common.CommonSingleton;
import mystuff.lib.common.Objects.Cache;
public class TestClassTwo {
public TestClassTwo() {
}
public String GetItemFromCache(String key) {
return CommonSingleton.INSTANCE.getCache().get(key);
}
public void Reload() {
CommonSingleton.INSTANCE.Reload();
}
}
I am finding, however, that when I use this object in both of my modules (separate JAR files, mind you), that they are both accessing the same singleton. While this particular example with a Cache object, might not indicate any issue with this, there are many reasons why I need these treated as separate objects. There are many internal/private member variables that need to contain different values, depending on the project/module/plugin that is consuming this Singleton.
I'm confused. When I do this in .NET (for example) in separate DLLs, each DLL maintains it's own internal instance of that common object.
How can I have this common Singleton functionality included in separate projects, from a common library, without them sharing instances of the Singleton object?
Thanks!
/* What a nicely pure example of the evil of singletons. */
I'm afraid that as long as the same class is attempted to be loaded by the same class loader, the class will only be loaded once. No matter which jars are involved: a jar, unlike a DLL, is just a signed extension of a file system.
The simplest (regarding required code changes) I can imagine is to subclass your singleton in each plugin, so that a separate class is instantiated, with separate state.
Otherwise, you could either explicitly initialize instances or use dependency injection to provide you with instances.
I have an interface, Resource, which is supposed to wrap something and expose a few operations on the wrapped object.
My first approach was to write the following, with the Strategy pattern in mind.
interface Resource<T> {
ResourceState read();
void write(ResourceState);
}
abstract class AbstractResource<T> implements Resource<T> {
// This is where the Strategy comes in.
protected AbstractResource(ResourceStrategy<T> strat) {
// ...
}
// Both the read and write implementations delegate to the strategy.
}
class ExclusiveResource<T> extends AbstractResource<T> { ... }
class ShareableResource<T> extends AbstractResource<T> { ... }
The two implementations above differ in the locking scheme used (regular locks, or read-write locks).
There is also a ResourceManager, an entity responsible for managing these things.
My idea of usage by the client, would be:
ResourceManager rm = ...
MyCustomObject o = ...
MyCustomReadWriteStrategy strat = ...
rm.newResourceFor(o, "id", strat);
This way, the client would know about resources, but wouldn't have to deal directly with resources (hence the package-private classes). Also, I could make my own implementation of some common resources, like sockets, and the client would only ask for them (ie, I would have to write a SocketStrategy implements ResourceStrategy<Socket>).
ResourceManager rm = ...
rm.newSocketResource("id", host, port);
To access resources, he would request an handler from the manager. This is due to each thread having some specific access privileges, and so the manager would create an handler with the appropriate access privileges.
// This is in the ResourceManager class.
public ResourceHandler getHandlerFor(String id) {
if (!canThreadUseThisResource(id)) throw ...;
if (isThreadReaderOnly()) {
return new ResourceReadHandler( ... );
} else {
return new ResourceWriteHandler( ... );
}
}
This is where the problem kicks in.
This approach seems clean and clear to me, it also seems to be intuitive for the user.
But, as hinted, the manager keeps a mapping from identifiers to resources. How would this be declared, and how would the manager retrieve the resources from the map?
Map<String, Resource<?>> map;
// Can I go around without any specific cast? Not sure yet.
Resource<?> r = map.get(id);
// This could have an enum ResourceType, to check if thread has privileges
// for the specific type.
Is this design acceptable, and/or following good practices?
Alternatively, I could wipe out the generics, and have ExclusiveResource and ShareableResource be abstract and public.
These classes would then be extended, both by me and the client, for every type of resource needed (FileResource extends ExclusiveResource, SocketResource extends ExclusiveResource, ...).
This would probably eliminate the need for the strategy pattern, but would expose more of my package to the user.
Which of these alternatives is the most correct, or widely accepted as good practice?
Edit: After some thought, I think I could be able to remove the generic from the Resource interface, since that's the one causing trouble, and leave it on AbstractResource and its subclasses. The latter could still grant me compile-time verification of the strategies used.
public <T> void newExclusiveResourceFor(
T obj, String id, ResourceStrategy<T> strat) {
ExclusiveResource<T> r = new ExclusiveResource<>(obj, strat);
map.put(id, r);
}
However, following the inheritance way seems to be more correct.
As suggested by dkaustubh and Paul Bellora, as it stands, there is no plausible justification for the generic in the Resource interface. This had gone completely unnoticed by me, at first, since I wanted the implementations to be generic, so I assumed the interface should also be generic. That's not the case.
I still have two options here.
Using Generics
I should remove the generic in the interface. Then, I would end up with the following.
interface Resource {
ResourceState read();
void write(ResourceState);
void dispose();
}
abstract class AbstractResource<T> implements Resource {
/* This is where the Strategy comes in.
* The generic ensures compile-time verification of the
* strategy's type. */
protected AbstractResource(ResourceStrategy<T> strat) {
// ...
}
// Both the read and write implementations delegate to the strategy.
}
class ExclusiveResource<T> extends AbstractResource<T> { ... }
class ShareableResource<T> extends AbstractResource<T> { ... }
// This is the behaviour the client implements, for custom resources.
public abstract class ResourceStrategy<T> {
public abstract ResourceState read(T obj);
public abstract void write(ResourceState state);
public abstract void dispose(T obj);
}
Only ResourceHandler, ResourceManager, ResourceState and ResourceStrategy need to be public, to the client.
Using Inheritance
Using inheritance, I can achieve the same results, with some trade-offs.
public interface Resource {
ResourceState read();
void write(ResourceState);
void dispose();
}
/* These implement only the locking schemes. */
abstract class ExclusiveResource implements Resource { ... }
abstract class ShareableResource implements Resource { ... }
/* The user extends these for custom content and behaviour. */
public abstract class CustomExclusiveResource
extends ExclusiveResource { ... }
public abstract class CustomShareableResource
extends ShareableResource { ... }
Resources are now public to the client.
Conclusions
There are ways to misuse resources with both approaches, bypassing the expected contracts and thread permissions. Both approaches are equal here.
With generics, the inner representation of resources need not be known by the client, since the manager creates the resources in the background. With inheritance, resource creation takes place on the client side, so the manager's API would change to accept provided resources.
Even though Resources are not public, using generics, the client needs to know about the strategies. With inheritance, these are gone, and the public status is assigned to resources instead.
With strategies, the behaviour can be changed in runtime, or there could be different behaviours for the same kind of resource. Without them, the client needs to dispose of a resource, and them re-create it using another subclass that implements different behaviour.
E.g.: small files can be completely read to memory, while large files may require an appropriately sized buffer.
Unless something else is missing, it may just be a matter of choice, and thinking about the desired API and use cases.
I'm developing an app with Jersey where I have many resources. Although main functionality of these resources varies, they share lots of common methods (like list, read, update and etc). The app runs on Google App Engine and uses Guice for dependency injection.
My first approach was to have a generic AbstactResource which contains all common logic, and it's respectively extended by all other resources which add their required custom methods.
public class AbstractResource<T> {
#GET
public ListPage<T> list(#QueryParam("limit") Integer limit,
#QueryParam("start") Integer start) {
// ... implementation
}
#GET
#Path("/{id}")
public T get(#PathParam("id") Long id) {
// ... implementation
}
And sample resource looks like:
public class TenantResource extends AbstractResource<Tenant> {
// custom resource related methods here
}
Everything works fine in this case. The problems appear when I add one more level of abstraction. Let's say if I want to store history and changelogs only for some of my resources. I've created one more abstract class extending AbstractResource called AudiatableResource which adds the required functionality.
public abstract class AuditableResource<T extends AuditableModel>
extends AbstractResource {
// here I override update and create methods to save changelogs
}
As you see the type parameter in this case has changed (now it extends AuditableModel).
New concrete resources will look like:
public class PropertyResource extends AuditableResource<Tenant> {
// custom resource related methods here
}
In this case everything still works, but this time I'm getting lots of warning messages on start-up:
WARNING: Return type T of method public T com.pkg.AbstractResource.get(java.lang.Long) is not resolvable to a concrete type
WARNING: Return type T of method public T com.pkg.AbstractResource.getNew() is not resolvable to a concrete type
WARNING: Return type com.pkg.data.ListPage<T> of method public com.pkg.ListPage<T> com.pkg.AbstractResource.list(java.lang.Integer,java.lang.Integer) is not resolvable to a concrete type
I really wonder if this approach is correct using Jersey and if I can just ignore this messages. It would be interesting to know how resources are organized in cases when there are large number of them.
One way to go is to separate the definition of the resources from the implementation.
Have very simple resource classes, defining the different services you want to offer. This way, the API you expose through rest is easily located and audited. The different methods are probably delegates to an implementation class
Implement the business logic of your resources in the implementations, where you might want to use inheritance to factor common behavior.
The reason you get those messages at runtime is that jersey uses runtime information about types in the resource. Generic type information being erased at compile time, it cannot get the actual return type of the generic class methods. If you provide a REST "facade" to your implementation, you can make this explicit.
public class Facade {
private final PropertyResource propertyResource;
public Facade() {
propertyResource = new PropertyResource();
}
#GET
#Path("somepath")
public Tenant something() {
return propertyResource.something();
}
}