Modular/pluggable java web application?

Well, I've used OSGi for a large modular UI before. We used opensocial gadgets running inside of shindig. OSGi is nice because you can just drop additional gadgets into the framework as bundles and have a listener pick them up and add them to the user's gadget choices.

This model extends well to other things like themes. What issues are you having with OSGi and other dependencies?

It seems I'm doing a very similar thing. While in the end component frameworks such as OSGi and the NetBeans Platform (that can be uses also server-side) are a workable solution that I've used and I'm using for other projects, they pay their complexity when you use more features that they offer, beyond searching for registered components (e.g. Enforcing dependencies checks, version checks, module isolation, etc...). But for scanning bundled classes there's a simpler solution, based on annotation scanning.

In my project with Vaadin I'm creating a user interface referring to "abstract" component names, that have to be matched by actual Java classes that might be provided by a user. Java classes implementing a component are marked with a custom-made annotation: e.g. @ViewMetadata(typeUri="component/HtmlTextWithTitle", controlledBy=DefaultHtmlTextWithTitleViewController. Class) public class VaadinHtmlTextWithTitleView extends Label implements HtmlTextWithTitleView Then I search for annotated classes in the classpath with a ClassScanner: final ClassScanner classScanner = new ClassScanner(); classScanner.

AddIncludeFilter(new AnnotationTypeFilter(ViewMetadata. Class)); for (final Class viewClass : classScanner.findClasses()) { final ViewMetadata viewMetadata = viewClass. GetAnnotation(ViewMetadata.

Class); final String typeUri = viewMetadata.typeUri(); // etc... } This is my complete implementation for the ClassScanner, implemented on top of Spring: import javax.annotation. Nonnull; import java.util. ArrayList; import java.util.

Collection; import java.util. List; import org.springframework.beans.factory.config. BeanDefinition; import org.springframework.context.annotation.

ClassPathScanningCandidateComponentProvider; import org.springframework.core.type.filter. TypeFilter; import org.springframework.util. ClassUtils; public class ClassScanner { private final String basePackage = "it"; // FIXME private final ClassPathScanningCandidateComponentProvider scanner = new ClassPathScanningCandidateComponentProvider(false); @Nonnull public final Collection findClasses() { final List classes = new ArrayList(); for (final BeanDefinition candidate : scanner.

FindCandidateComponents(basePackage)) { classes. Add(ClassUtils. ResolveClassName(candidate.

GetBeanClassName(), ClassUtils. GetDefaultClassLoader())); } return classes; } public void addIncludeFilter (final @Nonnull TypeFilter filter) { scanner. AddIncludeFilter(filter); } } It's very simple, but effective.

Note that, because of how Java ClassLoaders work, you have to specify at least one package to search into.In my example I hardwired the top package "it" (my stuff is "it.tidalwave. *"), it's easy to put this information in a property that can be configured, eventually specifying more than one package. Another solution could be used by just using two libraries from the NetBeans Platform.

I stress the concept that this wouldn't import the whole platform into your project, including the classloader facilities etc. , but just using two jar files. Thus it's not invasive. The libraries are org-openide-util.

Jar and org-openide-util-lookup. Jar (I stress again, you can use the plain . Jar files instead of the .

Nbm files that are specific of the NetBeans Platform). Basically, you'd use the @ServiceProvider annotation.It gets triggered during compilation (with Java 6) and generates a META-INF/services/ description file that will be placed in the classpath. This file is a standard feature of Java (since 1.3, I believe) and can be queried with the standard class ServiceLoader.

In this case, you'd use the NetBeans Platform libraries only during compilation, because they are only used for generating META-INF/services. Eventually, the libraries could be used also for better ways to query the registered services, by means of the Lookup class. There's a design difference between the two solutions.

With my custom annotation, I'm discovering classes: then I use them with reflection to instantiate objects. With @ServiceProvider the system automatically instantiates a 'singleton' object from the class. Thus in the former case I register the classes for the objects I want to create, in the second cases I register a factory for creating them.

In this case, it seems that the former solution requires one less passage, and that's why I'm using it (normally, I use @ServiceProvider a lot). Summing up, three solutions have been enumerated: Use my provided ClassScanner with Spring. Requires Spring in the runtime.

Use @ServiceProvider in code and scan with ServiceLoader. Requires two NetBeans Platform libraries at compile-time, and just the Java Runtime at runtime. Use @ServiceProvider in code and scan with Lookup.

Requires two NetBeans Platform libraries at runtime. You might also look at answers to this question.

I tried several of those approaches actually and in my exact scenario they failed in one way or another. I was actually able to accomplish what I needed finally using OSGI. – broschb Aug 5 at 4:28.

I got this working the way I wanted using osgi and vaadin. I used this tutorial as a reference. That got me half way to what I needed.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.