Related
i have a use case where i would like to offer a simple API to extend the functionality of my scala application.
i've spent the last couple of days trying to find a java/scala DI framework or library that does the following for me:
identifies implementations of an interface/trait on the classpath
instantiates and injects said implementations ( important feature: all of them ) at a site marked, preferably with an annotation
the above can't happen in the compiler because i need a plugin architecture where the plugins are not introduced until the JVM starts
therefore above can happen at JVM start (no hot-swap necessary)
i'm gravitating more and more towards OSGi DS, which i'm a big fan of, except i see it as an overkill due to #4.
i looked at guice, weld, scaladi and macwire, and could not immediately see a simple way to do this. My objective is for the "plugin" authors to not have to be aware of my injection/IoC solution in any way, except for the occasional Annotation ( preferably JSR330 ) At the injection site i am willing to deal with uglier things. :-)
Will i have to roll my own solution here, go with OSGi, or am i missing something trivial in the above mentioned libraries?
ps: i'm trying to steer clear of OSGi mainly because of it's interaction with the application framework i'm using (akka - not sure the bundle/DS lifecycle mixes well with a single actor system)
If you can afford it, it's probably best (not only for you, but for the entire ecosystem) to go with Peter's suggestion.
Pragmatically speaking though, Java has SPI which comes OOTB and may be the simplest way to go in your particular case.
I have a look at what functionality is provided by Scaldi at the moment. I've found it is mature enough. So nothing hard to use this DI library to achieve your goals. For example you can only implement code for searching specifically annotated/specified in some configuration file or anything else.
If you like DS (and it seems eminently suitable for your problem) then why not solve any problems with Akka? I am pretty sure others will be willing to help out since it looks like an interesting combination.
I followed the path of Java EE for quite a while now, used JBoss Seam and followed its standardization within CDI.
Now after trying to solve the first steps on the hard path from Seam 2 to 3 migration, I learned that all was moved to Apache Deltaspike.
But while Seam was decently documented and equipped with examples, Deltaspike is not. There are menu items leading to "Documentation", which is very poor, littered with TODOs and without any visible structure and to "Examples", which is more or less a joke.
Ever since I tried to step up to Java EE 6, I feel a bit like standing in the rain - even though it's great, that many concepts of Seam 2 went into the standard, I miss many things I had before - and exactly those things should be covered by CDI extensions. Here again, it's great that there is a common effort to channel those extensions in a project like Apache Deltaspike - but at the moment there is a very high hurdle to get benefits from it, even if you're not a beginner in the technology.
So - can anyone lead me to decent resources, documentation and examples how to use and understand the CDI extensions?
As noted in other responses, the DeltaSpike documentation is a little lacking. You could always take a look at the tests and javadoc. For examples, I think you'll find JBoss jdf quickstarts to be the best location for examples currently. Do a search on the right for DeltaSpike and you should see around seven examples.
DeltaSpike is still early in its development. It is only at version 0.3; it might be quite some time before it's production-ready. Until then, you might take a look at MyFaces CODI or Seam, two projects whose development has halted as they are presently being merged into DeltaSpike.
The documentation at the DeltaSpike web site, I agree, is quite insufficient for users; I bet it's just for people that want to test it out or develop for it.
Here's a concrete example. I am a reasonably experienced software person. I would like to use DeltaSpike BeanProvider.getContextReference to inject an EJB into some code that is not itself an EJB. I included the requisite Maven dependencies and added the BeanProvider.getContextReference code to one of my classes. I'm getting error messages that tell me that DeltaSpike is not configured. Two hours with the documentation did not get me any closer to understanding what I need to do simply to turn it on. What seems to be missing is a "How to configure DeltaSpike core." page.
I read Bill Burkes book "Restful Java with JAX-RS" (2009) and when he wrote about frameworks (RESTEasy, Apache CXF, Jersey), specially about frameworks which support the client side implementation, he said:
There is a lot
of interest from the JAX-RS specification lead and expert group members to get a
standardized client framework baked into JAX-RS 2.0.
Am I right when I say, there isnt a standardized client framework yet? Will there ever be one?
I thought about writing a 60 pages long work about the different frameworks with regard to client side implementation. At the end maybe a prototype of an own implementation, with some good ideas. Do you think it's a good issue to discuss about? Do you have ideas what else I could consider in this discussion?
I think, you need to be very clear on what the objective of such a paper would be. Ie. what the interesting application of your findings would be.
Do you e.g. intend to submit it as input to the JAX-RS specification board, or publish it as a white-paper for solution architects or even as a scientific paper? If not, then I agree with Donal Fellows on that 60 pages is way too much, and that you otherwise probably will need more than that to establish your methodology, describe the experiments including how they relate to the objective, analyse your findings, and so on. And if you also want to try your own hand in creating a client framework, then you will quickly come close to the extend of a postgraduate thesis...
On the other hand, am I certain, that we are many practitioners, who are reluctant to embrace JAX-RS as long, as there are no mature ways of consuming the services it enable us to produce. It should however be possible evaluate the different options in a more accessible form than a 60-page report.
If you decide to go ahead with making some sort of paper about this, I (too?) will be interested in seeing the result.
Also, I am curious of, whether any of the JAX-RS frameworks supports "dynamic" clients based on runtime binding of URI templates delivered from the server.
A repeating theme in my development work has been the use of or creation of an in-house plug-in architecture. I've seen it approached many ways - configuration files (XML, .conf, and so on), inheritance frameworks, database information, libraries, and others. In my experience:
A database isn't a great place to store your configuration information, especially co-mingled with data
Attempting this with an inheritance hierarchy requires knowledge about the plug-ins to be coded in, meaning the plug-in architecture isn't all that dynamic
Configuration files work well for providing simple information, but can't handle more complex behaviors
Libraries seem to work well, but the one-way dependencies have to be carefully created.
As I seek to learn from the various architectures I've worked with, I'm also looking to the community for suggestions. How have you implemented a SOLID plug-in architecture? What was your worst failure (or the worst failure you've seen)? What would you do if you were going to implement a new plug-in architecture? What SDK or open source project that you've worked with has the best example of a good architecture?
A few examples I've been finding on my own:
Perl's Module::Plugable and IOC for dependency injection in Perl
The various Spring frameworks (Java, .NET, Python) for dependency injection.
An SO question with a list for Java (including Service Provider Interfaces)
An SO question for C++ pointing to a Dr. Dobbs article
An SO question regarding a specific plugin idea for ASP.NET MVC
These examples seem to play to various language strengths. Is a good plugin architecture necessarily tied to the language? Is it best to use tools to create a plugin architecture, or to do it on one's own following models?
This is not an answer as much as a bunch of potentially useful remarks/examples.
One effective way to make your application extensible is to expose its internals as a scripting language and write all the top level stuff in that language. This makes it quite modifiable and practically future proof (if your primitives are well chosen and implemented). A success story of this kind of thing is Emacs. I prefer this to the eclipse style plugin system because if I want to extend functionality, I don't have to learn the API and write/compile a separate plugin. I can write a 3 line snippet in the current buffer itself, evaluate it and use it. Very smooth learning curve and very pleasing results.
One application which I've extended a little is Trac. It has a component architecture which in this situation means that tasks are delegated to modules that advertise extension points. You can then implement other components which would fit into these points and change the flow. It's a little like Kalkie's suggestion above.
Another one that's good is py.test. It follows the "best API is no API" philosophy and relies purely on hooks being called at every level. You can override these hooks in files/functions named according to a convention and alter the behaviour. You can see the list of plugins on the site to see how quickly/easily they can be implemented.
A few general points.
Try to keep your non-extensible/non-user-modifiable core as small as possible. Delegate everything you can to a higher layer so that the extensibility increases. Less stuff to correct in the core then in case of bad choices.
Related to the above point is that you shouldn't make too many decisions about the direction of your project at the outset. Implement the smallest needed subset and then start writing plugins.
If you are embedding a scripting language, make sure it's a full one in which you can write general programs and not a toy language just for your application.
Reduce boilerplate as much as you can. Don't bother with subclassing, complex APIs, plugin registration and stuff like that. Try to keep it simple so that it's easy and not just possible to extend. This will let your plugin API be used more and will encourage end users to write plugins. Not just plugin developers. py.test does this well. Eclipse as far as I know, does not.
In my experience I've found there are really two types of plug-in Architectures.
One follows the Eclipse model which is meant to allow for freedom and is open-ended.
The other usually requires plugins to follow a narrow API because the plugin will fill a specific function.
To state this in a different way, one allows plugins to access your application while the other allows your application to access plugins.
The distinction is subtle, and sometimes there is no distiction... you want both for your application.
I do not have a ton of experience with Eclipse/Opening up your App to plugins model (the article in Kalkie's post is great). I've read a bit on the way eclipse does things, but nothing more than that.
Yegge's properties blog talks a bit about how the use of the properties pattern allows for plugins and extensibility.
Most of the work I've done has used a plugin architecture to allow my app to access plugins, things like time/display/map data, etc.
Years ago I would create factories, plugin managers and config files to manage all of it and let me determine which plugin to use at runtime.
Now I usually just have a DI framework do most of that work.
I still have to write adapters to use third party libraries, but they usually aren't that bad.
One of the best plug-in architectures that I have seen is implemented in Eclipse. Instead of having an application with a plug-in model, everything is a plug-in. The base application itself is the plug-in framework.
http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html
I'll describe a fairly simple technique that I have use in the past. This approach uses C# reflection to help in the plugin loading process. This technique can be modified so it is applicable to C++ but you lose the convenience of being able to use reflection.
An IPlugin interface is used to identify classes that implement plugins. Methods are added to the interface to allow the application to communicate with the plugin. For example the Init method that the application will use to instruct the plugin to initialize.
To find plugins the application scans a plugin folder for .Net assemblies. Each assembly is loaded. Reflection is used to scan for classes that implement IPlugin. An instance of each plugin class is created.
(Alternatively, an Xml file might list the assemblies and classes to load. This might help performance but I never found an issue with performance).
The Init method is called for each plugin object. It is passed a reference to an object that implements the application interface: IApplication (or something else named specific to your app, eg ITextEditorApplication).
IApplication contains methods that allows the plugin to communicate with the application. For instance if you are writing a text editor this interface would have an OpenDocuments property that allows plugins to enumerate the collection of currently open documents.
This plugin system can be extended to scripting languages, eg Lua, by creating a derived plugin class, eg LuaPlugin that forwards IPlugin functions and the application interface to a Lua script.
This technique allows you to iteratively implement your IPlugin, IApplication and other application-specific interfaces during development. When the application is complete and nicely refactored you can document your exposed interfaces and you should have a nice system for which users can write their own plugins.
I once worked on a project that had to be so flexible in the way each customer could setup the system, which the only good design we found was to ship the customer a C# compiler!
If the spec is filled with words like:
Flexible
Plug-In
Customisable
Ask lots of questions about how you will support the system (and how support will be charged for, as each customer will think their case is the normal case and should not need any plug-ins.), as in my experience
The support of customers (or
fount-line support people) writing
Plug-Ins is a lot harder than the
Architecture
Usualy I use MEF. The Managed Extensibility Framework (or MEF for short) simplifies the creation of extensible applications. MEF offers discovery and composition capabilities that you can leverage to load application extensions.
If you are interested read more...
In my experience, the two best ways to create a flexible plugin architecture are scripting languages and libraries. These two concepts are in my mind orthogonal; the two can be mixed in any proportion, rather like functional and object-oriented programming, but find their greatest strengths when balanced. A library is typically responsible for fulfilling a specific interface with dynamic functionality, whereas scripts tend to emphasise functionality with a dynamic interface.
I have found that an architecture based on scripts managing libraries seems to work the best. The scripting language allows high-level manipulation of lower-level libraries, and the libraries are thus freed from any specific interface, leaving all of the application-level interaction in the more flexible hands of the scripting system.
For this to work, the scripting system must have a fairly robust API, with hooks to the application data, logic, and GUI, as well as the base functionality of importing and executing code from libraries. Further, scripts are usually required to be safe in the sense that the application can gracefully recover from a poorly-written script. Using a scripting system as a layer of indirection means that the application can more easily detach itself in case of Something Bad™.
The means of packaging plugins depends largely on personal preference, but you can never go wrong with a compressed archive with a simple interface, say PluginName.ext in the root directory.
I think you need to first answer the question: "What components are expected to be plugins?"
You want to keep this number to an absolute minimum or the number of combinations which you must test explodes. Try to separate your core product (which should not have too much flexibility) from plugin functionality.
I've found that the IOC (Inversion of Control) principal (read springframework) works well for providing a flexible base, which you can add specialization to to make plugin development simpler.
You can scan the container for the "interface as a plugin type advertisement" mechanism.
You can use the container to inject common dependencies which plugins may require (i.e. ResourceLoaderAware or MessageSourceAware).
The Plug-in Pattern is a software pattern for extending the behaviour of a class with a clean interface. Often behaviour of classes is extended by class inheritance, where the derived class overwrites some of the virtual methods of the class. A problem with this solution is that it conflicts with implementation hiding. It also leads to situations where derived class become a gathering places of unrelated behaviour extensions. Also, scripting is used to implement this pattern as mentioned above "Make internals as a scripting language and write all the top level stuff in that language. This makes it quite modifiable and practically future proof". Libraries use script managing libraries. The scripting language allows high-level manipulation of lower level libraries. (Also as mentioned above)
I am about to start on a college project (a web application) and I have never used a full-fledged IDE such as Eclipse.
Turbo C/C++, Visual Basic 6,Java Basic, a bit of SQL, ASP, etc is the sort of exposure I have.
What things should I keep in mind before starting my project using Eclipse? Are the tools mentioned appropriate for the project?(If not please give a detailed answer)
Designing - UML (Rational Rose)
Language - Google Web Toolkit
Server - Google App Engine
IDE - Eclipse
Version Control - Subversion or Mercurial?
I would definitely recommend Googling first. There are a number of tutorials regarding Eclipse as it is a very popular IDE. A quick Google search of my own brought up all these results: developing web applications in eclipse
As for other things to consider, if you are developing a web application, you'll need:
web server (Tomcat is a popular one)
possibly a database (MySQL is an open source, easy to use DB)
language (I'm assuming you're going with Java since you are using Eclipse)
Of course, you'll also need to consider how you hook everything together and what technologies you want to use to do that. (Hibernate, Spring, etc) Eclipse itself has a ton of plugins to help bring together all these various aspects.
That list from Wikipedia is a good and comprehensive list, but if you are learning or developing on your own machine, you may not necessarily need all of that.
Hope that helps.
Since it is a web application, then start with the looks of it.
First, layout a template of how your pages should look, that is what users see. If it does not look good, the users will think the application (in its entirety) is also not good (it does not matter if the code behind the view is perfect; it will just make a first bad impression).
Start with that and be consistent with the design in all your pages. SiteMesh is a nice tool to dissociate the looks of the page from the functionality you put in it.
Then think what the application will do and what it will use:
you have a database? (use something like MySQL). With what are you going to access it? (IBatis is nice; Hibernate I think is a bit heavy weight for a first project)
you need a server: Tomcat is easy to use;
are you going for a simple Servlet/JSP approach or you want to use a framework (look at Spring or Struts);
try to find the good ways of writing the application, look at service layers, DAO pattern, DTO, MVC. Also, you must understand how HTTP works.
A lot more could be said.
Ah.. and also use a source repository. It’s a must (even if you work alone on this project).
Eclipse can handle all of these tools, but then so can Netbeans.
For your first project with GWT you should read through this tutorial:
http://code.google.com/webtoolkit/tutorials/1.6/gettingstarted.html
If you don't know Java then you will have some learning to do, and unlike Visual Studio your UI won't be just drag and drop, so it will be a bit harder than you are used to.
Subversion is fine, it is a nice source control, and any IDE will work with it.
Depending on your project would determine if GWT is the best choice though.
I expect UML may be overkill, and if you were following an agile methodology you wouldn't use it.
Your best bet is to get the UI done first, just have it appear as you want, and have some fake results, until you are happy with the look and feel.
Then, start to do the wiring to whatever you need on the backend.
Don't mean to be harping on you, but is Eclipse a must? For myself, in the beginning NetBeans turned out to be a really painless introduction to getting a web project up a running fast. I believe in the beginning one will spend a lot less time fighting the IDE with NetBeans.
A lot of the items from your bullet list NB makes super easy to ramp up as well. Just my $0.2