We have a rich web application based in Java & Spring framework which have many functionalities and classes. recently something sparked in my mind that why not we provide modularity to make it even better.
what I mean by modularity is to provide a section inside the web application that the authenticated user can contribute with us using plugins or extensions. exactly like joomla, wordpress and the other cms's around.
I want to separate each part one to another and while a user upload a plugin, that does not break down the entire system and core. also I want to provide the plugin/extension tester in the backend that the system won't accept malicious plugins.
The system should be able to uninstall each plugins and extensions without harming the core as well
How do I make this functionalities, and from where we have to start?
I'd say this depends on a couple things.
One way of achieving this could be having a Modular Framework like either Wicket or Vaadin, use those with OSGi mechanisms like Services provided through blueprint or DS and you should be able to have a fine modular web-application. For example take a look at the Pax-Wicket project it does have a sample application that does exactly this.
Related
Just a general question on any techniques used to seperate your web application for customer specific requirements. At the moment I have one web application but I need to add new functionality for one customer thats not needed by another. I know spring 3 comes with new support for profiles but I'm just curious if anyone has had a similar problem and how they went about solving it particularly using spring mvc and maven as a build management tool
The proper way to do this would be as follows:
Have a web assembly module. This module will build a war file containing the proper features extracted into separate modules simply defined as dependencies. My advice is to have a separate web assembly project per client. This way you will keep things neat for yourself, avoid mix-ups (such as releasing features to clients who haven't paid for them) and have an overall easier maintenance.
Furthermore decide whether to do your version separation at the level of the version tag or classifier:
The version tag you can use in order to separate things in branches.
The classifier tag you can also use to separate configurations specific to your clients.
I'm coming to SpringMVC from the world of PHP, precisely I was working with Symfony for several years.
For your information, in Symfony, there are plugins and bundles that are created by other developers so that you could use them in your project. When I come to Spring, I don't find these notions or may be I've missed something !?.
For example, I'm looking for a component that does the registration and login form, which I think that must be done many times already, and I don't want to reinvent the wheels certainly.
So, my question is, I wonder if in Spring, are there possibilities to have and how to use reusable components?
Authentication is directly supported by the Java EE spec. You don't even need any particular framework for that. Every web container supports it out of the box. If you want some additional functionalities (like remember-me, etc.), loot at spring-security.
I know the title may seem like apples & oranges, but hear me out... :)
I'm building the architecture of an MVC app and considering what to use for the core of the controller / services. This stack will also serve as a RESTful API which will be equally as important as the UI.
I'm narrowing down my stack to be built with either Grails or JAX-RS (at this point I've ruled out other options and am not super interested in expanding this list). Either way I'll be using Groovy, and my model and views will be virtually unaffected by this choice, so that further levels some of the differences between the two. Here are the pros/cons that I've been pondering and was wondering if anyone had any other inputs or caveat experiences.
Grails
I am not going to use a ton of the built-in Grails features (GSP/SiteMesh, Hibernate, nearly all plugins), so I'm concerned that Grails might be a bit heavy for my purposes
I'm concerned that I won't have enough control over my ability to handle the REST API since it is very view-centric
I've seen inconsistencies in the quality of plugins to the point where I'm not sure I consider them much of a 'pro'
I love the convention-over-configuration & edit-and-refresh, to the point where I'd probably want to wire up something similar if I go with JAX-RS
I like the grails command line for everything it streamlines, but I'm concerned that it might get in my way since I'm not using as much of the stack
I like the scaffolding but since I'm not using Hibernate or GSP/SiteMesh it might not mesh well
JAX-RS
JAX-RS is made for REST. This will make my RESTful API really a snap to implement as I have complete control
Groovy is an important part of what makes Grails shine, so I'll benefit from that even in JAX-RS
I love how JAX-RS doesn't automatically pull in a bunch of other things so I can have more control of what components are in/out
unfortunately since it doesn't pull in everything else anything that I end up needing will require more work, whereas Grails might have a plugin
the grails command line and scaffolding will be missed; perhaps Maven can fill some gaps
It seems like the capabilities of each for creating actions and routing are pretty similar (although the implementation styles are different). In fact there are other SO questions wish touch upon this so I'm not too concerned.
I wrote a small REST service prototype in several frameworks last year (namely Grails, Play!, Spring MVC, Jersey, Restlet). My feeling about Grails in this concern was that although Grails supports REST style architecture, it isn't really made for it. I don't want to get religious here, so if you only want to map resources to URLs and HTTP verbs your fine, but if you want to dig deeper into REST with tight control over return codes, location headers, etc. you might still be able to do it with Grails, but it is probably better supported in a pure REST framework.
Grails also comes with a lot of dependencies, which might not be a problem if you're starting on a green field, but can cause problems when you have to integrate it with existing legacy components or frameworks.
From the two used REST frameworks, I liked Jersey more, as it just worked in my case and the documentation was good (although a bit focused on Maven and Netbeans).
Yeah, it does seem heavy to build on a MVC framework when you're not going to use the model or the view. While the autowiring and simplified configuration is super nice, Grails would still be providing a lot of extra stuff that you don't need.
I'd personally take the lighter approach and leave Grails out, using any standalone libraries or writing custom code which provide the features that you do want. There's a number of container projects listed on the Groovy site, perhaps Spring or one of the alternatives would add some value to your architecture.
I'm looking to make a website that will probably get some heavy, repetitive traffic. Is grails up to the task?
I agree with lael, also because it's built on java technologies there are a lot of proven clustering and 'enterprisey' tools available which allow you to easily scale across multiple application services.
The cloud tools around Grails are also becoming very good and make deploying to a cloud like EC2 very easy. I've recently been using Cloud Foundry and found it very good.
As the first poster points out however, you can write a badly performing application in any framework/language. One thing I'd recommend is getting a good understanding of Hibernate which is the underlying persistence library. If you understand how that works, it should help you avoid making any silly mistakes at the DB level. On this side of things, a tool like p6spy is great for checking what the database is up to during normal use. It should help you spot any repetitive queries.
The scalability of your web application won't really depend on what language/framework you choose to use, but rather how your application is built. You can build a scalable web application in Grails, just as you can build an incredibly slow application in C++. If Grails is the framework you would like to use, then use it; you can always rewrite the slow parts in Java or another fast language, if need be. (After all, that's what Twitter did with Scala.)
Disclaimer: I've never actually used Grails.
Grails is essentially a thin layer on top of the Spring Framework, which many consider to be a very scalable framework in the enterprise world. Spring + Hibernate has become a standard in many Java shops around the globe.
If you run into performance bottlenecks in Groovy, you can always rewrite those parts in Java.
Take a look at the Success Stories for examples of sites that were written in Grails. The Testamonials are also a good place to look for examples. You will use a little more memory(heap and permgen) than a vanilla Java app, but you can tune it just like you would any other Java application.
On the low end you aren't going to find $3/month Hosting options that you could with PHP stack (for example). That said, there are some good caching solutions for Grails apps EhCache, MemCache, etc. Beyond that you can also setup an Apache layer to caches static resources or whatever you need.
Don't mean to pile on here. You've already got some great answers but I just want to add on thing that I was reminded of recently. Scalability depends not only on the software you write (regardless of language/framework) but also on the deployment environment. A very well written application deployed on an undersized or poorly configured server will not scale at all. If you do use Grails or any other Java based framework, the default settings on your container (Tomcat, JBoss, etc.) will probably not be what you need.
Just something to keep in mind,
Dave
Grails run on the JVM. Simply put, you will not find a more scalable, solid and robust runtime platform than the JVM, anywhere. That's Grails's big advantage over, say, PHP or RoR.
I've got a Spring MVC application and I've decided that I'd like to try using GWT for the front end. I'd like to continue using MVC as I'll also be using Spring Security and some other springy stuff.
I'm aware of the GWT-SL project, and I guess I'll use it. The documentation is light on examples unfortunately.
What I'm wondering now is.... how do I reconfigure my project so that I can use GWT? I'm assuming that I'll lose the ability to run in hosted mode, and I suppose that's ok. Do I just add the GWT and GWT-SL jars, reconfigure my web.xml, and add a package to my project for the GWT code?
I'm using Eclipse 3.4. My existing project is standard web project.
With the new version of the GWT plugin, you'd have all the benefits of the hosted mode browser without having to modify any options. The GWTHandler from the GWT-SL will take care of your rpc call mapping. However, you will have a problem with your existing domain objects structure. You will either have to put them in GWT's 'client' package, or mirror your existing domain objects to enable them to be compiled to javascript. I have been looking for a stable non-invasive framework for doing this, but have yet to find one. Gilead looks promising, but you will have to extend its classes on your domain.
I have posted a view month ago my simple project (3 classes) how to integrate GWT with existing Spring MVC application. Simple sample also provided.
Try it, it is clear and simple: http://code.google.com/p/gspring.
You won't lose hosted mode. I don't know if you're using the internal server for that - I use -noserver so I can't help you there.
Other than that, I guess the documentation is quite clear. Have you hit any specific problems?