what would be a recommended way to work with Spring application context within Eclipse RCP project.
I have a Swing based application that is wired together by Spring and its configurations. What would be the best strategy for these two, without too many conflicts between them (I'm just beginning with Eclipse RCP, and I am mostly worried about how similarly eclipse plugin.xml looks in comparison with xxx-context.xml.
Thank you for help.
I think the best way to use Spring in Eclipse RCP project is to use it with Spring Dynamic Modules. I define beans in diffrent contexts over the plugins and export some of them as osgi services to allow beans from other plugins use them in dependency injection. Also I implemented some kind of ServiceAccessor (singleton wrapper over osgi service accessor) that displays "waiting services to be registered" dialog to user until all necessary services will be registered.
Related
I am currently building a library or API which will be used by another Spring REST application, below are the advantages I thought of using Spring.
Spring flow(Context initialization->Post construct)
Easy way of reading properties file
Autowiring and bean management
Rapid development
Below are the disadvantage
Tightly coupled, the main application which is going to use the library/API has to import or refer the configuration class of library in order to initialize context
Main application has to use Spring(considering use in other projects)
Is there anything I am missing, can Spring framework be used to develop API or library?
Note: The number of library to build is 3-5 and will grow in future.
The only reason to use spring you are giving, is to benefit from the building of the application runtime.
I do not see it as a great advantage from spring for a library : it is only replacing a few new and set statements, that could be easily explained in a doc, with even some sample bean declaration for the users of your api, if he wishes to init your lib in a spring context.
One of the drawback you are not giving is the support of multiple versions of spring by your library :
what will happen in one / two years, when an old application developped using your library will need small enhancements, but still be on spring v4, but new application will import spring v6 (with no resource to migrate old app on spring v4 to latest version) ?
So i would use spring in a library only if you need to participate in database transaction of the main application (and other tasks like this where it is really convenient to use spring), but otherwise try to depend as little as possible on spring.
EDIT:
Even when minimising the use of spring in the runtime of your library, you can use it extensively to test your library.
The spring context instead of being included in the resource of your lib is only a test resource, which you can use to bootstrap spring-test, for example.
What is the simplest way to have some sort of DI in RCP application?
I need to register dependencies and use them in different parts of application: wizards, dialogs, properties pages, etc.
What I have: a product with bunch of plugins.
What I need: at start of Eclipse RCP product I need to read some files, keep this data in memory and make it accesible to different UI elements(among different plugins) without using of singletons.
I cant pass this data in constructors when creating consumers, because consumers are UI elements which often created by RCP platform and I dont have direct access for their creation.
Eclipse 4.3 supports DI. This works best for a RCP created as a pure Eclipse 4 application which does not use Eclipse 3 compatibility code ('e4' mode). Objects which are defined in the new application model are created using DI, but it is also possible to create other objects (dialogs for example) using injection.
For an introduction to Eclipse 4 RCP see http://www.vogella.com/articles/EclipseRCP/article.html
For an Eclipse 3 application a part can get the Eclipse Context needed for injection using
IWorkbenchPartSite site = part.getSite();
IEclipseContext parentContext = (IEclipseContext) site.getService(IEclipseContext.class);
Use org.eclipse.e4.core.contexts.ContextInjectionFactory for injection.
Or, if you are still using an Eclipse 3 application, you can use the Eclipse Plugin Registry to define extension points and extensions. This also amounts to Dependency Injection, without the injection :-)
I'm starting to develop a new web app application with Vaadin and Spring, but I can't find an maven archetype for this.
Can you give me some assistance?
There is no such archetype. In fact, just to get those two frameworks working together at all, you're either going to need to go all wild-west and do it yourself (what I did) or use a plugin to get it working.
Here's the SpringVaadinIntegration plugin.. It takes an interesting approach to integrating Spring scopes with Vaadin sessions. The sample project for that plugin will be especially helpful for you to look at.
If you want to do it the do-it-yourself way, I can tell you that I divorced my vaadin from my spring as much as possible. Essentially I created some classes with static references to my spring singleton-scoped beans, and used those static methods for accessing my spring beans from Vaadin.
We are using a opensource grails project, we want to integrate it with our systems using message queues.
We can add our code for the message queues to the grails project. But what we would prefer to do is get the grails project to build a stand-alone jar file that we can then use from our project.
In our application we would want to initiate the hibernate/GORM layer of the opensource grails project, we don't need to the web layers as we are using messaging.
Ideally we would like our project to be a Spring/Java, however if this not practical then we would use a grails project.
Is any of this possible, or are they better ways to extend an existing grails project?
There is no out-of-the-box way of reusing a Grails application in a Spring/Java application, although there are ways to use GORM standalone in a Spring application (as discussed here)
My advice would be to extend the Grails application. If Groovy or certain Grails features are not desirable, you can still work with the project as if it was a plain Java-based Spring project by adding Java sources to src/java, using a separate beans.xml Spring bean configuration file and other "fallbacks".
I would like to develop a web application in Java/Spring/Hibernate serving as a business platform that I could connect plugins to (i.e. CRM plugin, ware plugin, sales plugin). Those plugins could be dependent on other plugins in a tree manner. The parent project would be packaged as war having all the basic configuration and looks (Spring configs, CSS, scripts), ready-to-go user and group management, security settings, etc.
Altogether, I would like it to behave and look a bit like Joomla, but be built using different tools for different purposes. And I have a few questions concerning that project:
Do you know of any open source projects offering such a platform ready to go?
If not, is Maven applicable for managing those plugins?
What is the best way to package and deploy those plugins?
And last but not least, is this the right way to go, or is it a dead end? Would it be better to create a separate web app for those business needs?
There are lots of ways to build plugin modules.
Some Ideas:
You could package every plugin module as a jar and in the classpath root of this jar, put a spring config file with the beans configuration, so if when you are using a specific plugin. You can "turn on" the beans of this package on a web application by simply adding this file to the contextConfigLocation parameter in your web.xml:
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:module1.xml
classpath:module2.xml
classpath:module3.xml
classpath:module4.xml
</param-value>
</context-param>
So you are able to use those beans in your web application. Another way of doing this, would be to use a more annotations driven approach. Or you can mix the methods.
Some time ago, I structured a way to automatically hot-detect (in execution time, without having to restart the application) plugins in a desktop application by detecting all implementations of a specific abstract class (a contract) in the classpath. So, all that I had to do to build a new plugin, was to implement this "contract". I've used some "classloader" goodies to do this.
When talking about "modules" maybe you would like to see something about OSGi
Well... those are some ideas. I hope it helps in any way. ;-)
I think this is a fine way to design a web application, depending on the requirements. I use plugins because I had several clients using the same codebase with different requirements. If you are developing for one installation, I would say don't waste your time.
Now for the how-to. "Plugins" are a very vague concept. I've used plugins
to intercept method calls
to run background processes
to add additional views in my web application
The question is now, how does this work. The method interceptor works using a org.aopalliance.intercept.MethodInterceptor. The background processors use a TimerTask. The additional views in the web application use Spring MVC routing.
My plugins are packaged as JARs and discovered at application startup time as Spring application contexts.
This is all very general, but might give you some ideas to go off of.
Do you know of any open source
projects offering such a platform
ready to go?
Have a look at Spring Roo
If not is maven applicable for
managing those plugins?
Yes, it is. Check out how AppFuse uses it.
What is the best way to package and
deploy those plugins?
Again, check how Spring ROO or AppFuse does it.
Hope that helps.
*
And last but not least, is this the right way to go, or is it a dead
end? Would it be better to create a separate web app for those
business needs?
*
I have negative experiences in area modularisation with JPA. For example #Entity Customer is included in CRM module, but is intensively used from other. First natural idea one module = own persistence unit is very hard to realise, JPA should be across modules, and modularisation idea is gone to dead end, modules are not separated.
I use kind of modularisation "in process & in JAR", kind of structures is build, some menus / entities etc belong to "modules" in lighter sense