We Keep Coding

Questions about Spring DM,OSGi and web application

I've started looking at osgi with the main purpose to achieve the task ahead of me. Basically i would be able to distribute an web based application and build specific features of the whole web app separately in such a way that i can deploy at A my web app with features a,b,c and deploy at B with features a,c,d.
A little like how one can install plugin in joomla. So for example when i want to add a different aspect of the web application, i would build a small war with all the html and its admin section and have this feature admin section available in the main admin panel.
Second question is about Spring DM. most likely i will be using Spring and it seem logical i see what Spring DM has to offer.After downloading Spring DM .1.2.1 i found out that its lib folder contains spring jars for version 2.5.6.SEC01 but i planned on using 3.1.2 so am a little confuse as how everything will play nice together.
Thanks for reading

I've just been doing such an exercise so I can shed some light how you do it without the overhead of Spring. I've made a clear division: all application code is in the browser, all data handling is in the server. With HTML5 the browser has grown up to an impressive, portable, and powerful application environment. One has multiprocessing, messaging, modularity, and amazing visuals. I am using angularjs as the framework in the browser.
Angular works with a central routing table mapping the hash part of the page url to "modules" in Javascript. This makes it very easy to define what modules are part of the application. The server can easily control this part.
On the server side I have bundles that carry the Javascript code, the html fragments and the data handling. I based this on the OSGi Http Server model since it is more flexible. However, I added proper support for static resources in bundles: caching, streaming, ranges, etc.
In the server I used DS and bndtools to develop the bundles. This is an impressive development experience since it works like Smalltalk. You change and it is immediately reflected in the server. Adding bundles, removing bundles, the server keeps on running. Server restarts are rare during development.
The disadvantage is that there are unfortunately very few components that leverage OSGi. Most components, with Spring being the archetypical example, rely heavily on class loading hacks to wire applications from a central point. This is fundamentally not modular. For this reason I had to develop many highly cohesive and uncoupled components that leverage the OSGi service model. Once I get time I will donate them to an open source project.

I'm not sure you need to be considering OSGi, at least not directly, to achieve your state requirements. You said:
Basically i would be able to distribute an web based application and
build specific features of the whole web app separately in such a way
that i can deploy at A my web app with features a,b,c and deploy at B
with features a,c,d.
If these are youre requirements, then you don't actually need to concern yourself with OSGi directly, but rather find a web app framework that supports modular extensions. Which most likely means that the framework itself uses OSGi. I'm not familiar with Spring, but I do know that Struts 2 ( a comparable web app framework ) has an OSGi based plugin meant to achieve your use case.
On the other hand, if your idea is to play with OSGi, then I suggest you pick a lower level task, such as writing a web application framework, rather than a web app itself.

GWT and Spring integration

I'm currently working on a specification for a web application which consist of a administration interface, and a set of web-services which will be consumed by parter websites.
I been playing around with GWT and it seems like an amazing fit for the administration interface, but at the same time, I would love to use the Spring framework to produce the REST based web-service API exposed by the application.
My plan is to create two separate web applications, one for the admin and one for the web-services. One set up for spring and the other with the GWT app. Obviously, I wish to share the domain model between the two applications, I'm guessing this should be fairly trivial to accomplish? I'm thinking just to keep it simple, implement the full domain model in the GWT client project, and simply setting the sourcepath of the web-service to include the domain model from the relevant folders in the GWT project.
Now, to my question. I'm sure somebody out there have done something similar to this, are there any potential pitfalls I should be aware of before starting out?
I got a fair amount of time set aside for this project, but I never actually used GWT before for anything "serious" I just played around with it out of personal interest and I'm fairly experienced in both Swing and Android UI development, so I'm confident I can mange to use it for the (very simple) UI. The "unknown" in this equation is sharing of a domain model. I cant imagine this being a problem, since the domain model will be just POJO's (using JDBC, but again, I cant really imagine this being a problem).
Also, are there better ways of integrating GWT and Spring than simply doing to separate web applications and sharing their domain model?

Why do you want to create two separate applications?
Create one, with a clearly separated application services tier. Expose this services via standard Spring annotations as webservices, and also expose access to this services via GWT requestfactory (unfortunately, as far as I know, currently requestfactory does not play nice with REST requests, mainly because their way of serialization). This approach results in only one entrance (facade) to your application and allows to use this facade in two different ways.
I've worked on several GWT+Spring projects - for standard cases development goes very fast, frameworks integrates very well. However, if you want to do some customization, e.g. introduce security based on spring security - you will need to do some hacks, such as overriding transport classes. Of course it takes some time, but results are very nice.
I would definitely recommend to take a look at Spring ROO sample applications (as far as I know, roo is partially developed by google guys).

Java web application in a Servlet container vs. standalone

What are the advantages of building a small Java web app to run in a Servlet container (like Tomcat) vs. building a standalone Java app with a built-in web server and running it behind a reverse proxy?
I've been playing with Java for about a year. I've noticed that to launch Tomcat takes time, and it's not always possible to do a hot-redeploy due to class loader issues. The Servlet API seems somewhat convoluted to me, especially from the perspective of configuration and of RESTful design (which it doesn't really fully support).
On the other hand, I've noticed that my IDE can compile and run a standalone app at lightning speed. Configuring Apache for reverse-proxying is a piece of cake, and embedded Jetty seems to handle whatever I can throw at it. I don't need Servlets when I can use Restlet, Wicket, etc. Being able to know better how my app works (because it's not integrated with a huge app server) feels empowering. The stack traces are shorter. Download size is smaller. End-user configuration is easier. I'm guessing performance is likely to be better because there are fewer software layers involved.
However, I am reminded of the saying that what sounds too good to be true usually is. So my question is, why would I not want to make my web apps standalone? What does a Servlet container give me and/or my end users that we really need but don't know about?

There are 2 separate questions in here:
Should I be using an embedded
server, or deploy into a container?
I don't think you should be seeing a
big difference one way or the other.
There's slightly more code to
startup a Jetty server
programmatically, and configuration
is easier to do programmatically.
Even though IDE support for web app
configuration and deployment is
getting better, it's still worse
than for standalone applications
(this is kinda by definitions, since
there's a superset of things to
support).
On the other hand, app servers give
you some nice benefits like built-in
management, built-in ability to run
as a service, etc.
You could even use a hybrid
approach: use an embedded server to
develop locally, then deploy into a
container in production. But that's
a bit weird: if you go through the
trouble of making a proper WAR file,
IDEs should really be able to handle
deployment into a container
adequately.
BTW, it's weird that you have issues
with hot-redeploy; Tomcat shouldn't
be having issues with it unless
you're running into some strange
corner case...
Should I be using Servlet API?
This is orthogonal from #1. You
could very well embed Jetty and
implement Servlets. You could also
use Restlet API inside Tomcat
through a ServerServlet
http://www.restlet.org/documentation/1.0/faq#02.
I personally find the Servlet API to
be pretty straight-forward.You get
nice things like concurrency and
state management. I don't quite know
what that means that RESTful design
is not supported, but if Restlets
address your requirements better,
then use that...

Embedded Jetty can be a good choice if you don't need the full Servlet stack. Unlike Tomcat, Jetty makes it easy to get rid of the parts you're not using (JSP, JNDI, whatever).
Writing your own HTTP server, on the other hand, is a terrible idea. Sure, it's easy to write something that handles basic requests. But soon you'll find that some clients are having trouble with it because it doesn't support the full protocol specs; or that it crashes when there's more than a few hundred users; or that there's a vulnerability that allows some kid in Malaysia to blow up your printer. So don't re-invent the wheel.
As for your complaint that the Servlet API doesn't support RESTful design - you're missing the point, it was never intended to do that. But there are plenty of REST libraries that run on top of the Servlet API.

An embedded Jetty is also a servlet container. I assume your application includes a web.xml where you define a wicket filter / servlet, the RESTlet servlet and their mappings (at least). So you cannot get rid of the Servlet API (or of a servlet container, even if you embed it), but you can hide it as well as possible underneath your frameworks and into some main() method of your own. RESTlet (or Jersey or any JAX-RS implementation) as well as Spring MVC are all based on servlets, so the Servlet API does support REST pretty well, i'd say.
P.S.
The two approaches do not exclude each other. You can very well work with Jetty during development and then deploy your war into some (non-embeded) container for QA / production. Or... stick with Jetty for production, if that really suits your needs.

Servlet containers often provide a bunch of useful stuff like automatic session management, hot-deploying, frameworks for failover and clustering and so on. It depends on the container, of course, but sometimes these are very useful tools. Sometimes they are not.
EDIT: Just noticed your comment about hot-redeploy. Yes, sometimes the containers are buggy and a pain to work with, and they all tend to have their own quirks. Nevertheless, sometimes they do provide some really good stuff.

The in-process Servlet containers are the containers which work inside the JVM of Web server, these provides good performance but poor in scalibility.
The out-of-process containers are the containers which work in the JVM outside the web server. poor in performance but better in scalibility
In the case of out-of-process containers, web server and container talks with each other by using the some standard mechanism like IPC.
In addition to these types of containers, there is 3rd type which is stand-alone servlet containers. These are an integral part of the web server.

if you are having issues with your hot deploy, most likely you aren't cleaning up your external connections or other resources. To handle this, usually you want to implement a listener that will let you know when something is started or stopped.
you should probably in your wars implement something like this (tomcat 6):
public class MyTomcatInitCleanupListener implements ServletContextListener
{
#Override
public void contextInitialized(ServletContextEvent arg0)
{
super.contextInitialized(arg0);
}
#Override
public void contextDestroyed(ServletContextEvent arg0)
{
super.contextDestroyed(arg0);
}
}
for tomcat 7+, you can google "tomcat lifecycle listener"

How to develop a modular enterprise application using just GWT

Hi
I want to design and develop a big enterprise application using just
GWT in client side.
I want to break this enterprise application into parts and I call each
of them a module (or bundle or portlet or whatever!).
These modules might have relation with each other and might call some services that
exists in other modules (in both client and server side).
The problem is, These modules must be Designed , Developed, Compiled
and Deployed Independently and Dynamically and they will be placed and
shown together in one context on the client and the dependencies
between modules should be manageable (in both client and server side).
What can I do? What kind of technologies I can use to build an enterprise application like this?
When you develop an application that is not divided into parts (In the way that i mentioned) you can easily deploy your application after building your project, but when you change just one form in your application you have to build the entire application again, and deploy the entire application.
In this application I cannot stop the server to deploy the application again, I want to change and deploy that part of application that is needed to be changed not the entire application!!!
Of course I have searched about the way that I can solve my problem!!!
I have found that I can use OSGI on server side because it provides modularity at software construction level and helps me to manage life cycle of modules and many other benefits that you know!
And I have found that I can use Gadgets on client side.
What do you think? Are they good choices?
If they are good choices, how can I start? I know that we have different kinds of implementations of OSGi, like Apache Felix, Eclipse Equinox and Knopflerfish. Which one is good for this choice?
How GWT and OSGi can be integrated? How can they interact with each other?

Unfortunately what you want to do is not fully possible with GWT.
OSGi is a modularity solution for Java, or more accurately the JVM. A GWT client application does not run on the JVM, it runs on the browser in a JavaScript environment. Therefore OSGi cannot be used to create runtime-assembled modular GWT applications.
A GWT application can be modular at the source level, but the modules must be assembled into an application at build time. The resulting runtime is monolithic.
However, it's perfectly possible to use OSGi to host the GWT servlets, and you can use the full power of OSGi runtime modularity on the server side.
As an alternative you may want to look at Vaadin. This is a web framework that uses GWT to provide widgets, but the logic of the application runs on the server. As a result, it does support full runtime modularity through OSGi bundles. There is a cost with this approach though: your web application is quite chatty, with lots more communication going between the browser and the server than in GWT or in a traditional web application. It's possible that this approach will not scale to very large numbers of users.
As for whether to use Equinox, Felix or Knopflerfish... it really doesn't matter. Stick to the specification, and you can easily switch between implementations.

I did just this two years ago: OSGi and GWT for no downtime deployments of project modules.
Verdict: Don't do it unless you really must.
In short, OSGi is a beast and retrofitting an existing application for it is far from trivial. You're no longer making .war files (.ear now) and can't use the standard jars and Maven repositories you used before. Now everything needs to be a bundle. Trouble is, a lot of stuff (GWT, Spring, tons of libs) are not bundles! And you'll need to find them in an enterprise bundle repository or, even more fun, start rebundling 3rd party sources them yourself. Better yet, telling the other devs to rewrite everything that uses their favorite lib because bundling it would be too complex.
The GWT part didn't take that much work. The way contexts for modules were handled in gwt-servlet had to be modified so each module could find it's context on the server. We also had to make a way for most of the GWT services to register/unregister on load and a discovery service so they could know who else was out there.
Now the other pain: project explosion.
Let's say you had 20 modules you wanted to deploy independently. Well, to start with they're probably more coupled than you'd like, so better spent a few weeks breaking them into independent Maven projects and pushing common parts to a lib project. But now, you've got tons of dependencies to keep track of. When someone tweaks your lib project, do you need up upgrade every project or just 7 of them? In the classic stop the world deployment, you only had one version of all your code. Now, you need to decide if that forgot password form being upgrades will require you to also upgrade your index page module. You'll have a ton of version numbers to make up and keep track of. In our case, we quickly had 55 Maven projects building all the time in our CI server. This meant some checkins could trigger 55 builds. Eek.
Finally, JSON interfaces.
We used GWT RPC. It's magical. Write an interface and everything just works. It's also serialized and gzipped over the wire too. Awesome. But, the serialization policies depend on object and string lookup tables that are built at compile time per module. So, project A cannot RPC to project B. Boo. We chose to use JSON due to the graceful degradation, that is not failing when new unrecognized properties were present on objects. This means you'll again need a way to keep all the backend service calls coherent in the versions of the JSON they are expecting and can handle. Better simulate that live upgrade beforehand too.
So, final word: possible, but why? Do you really need OSGi to hot deploy modules because you're running a 1000% uptime business critical application? Or does your boss/architect just refuse to accept that 99.999% is good enough? You probably don't need that uptime and can achieve nearly 100% uptime with a good proxy to let you take instances in/out of the balancer pool. Also, don't forget that even if you can upgrade your projects live on the fly, I hope you've got a way to upgrade your database on the fly without dropping a single transaction.

I think you are setting yourself for more headaches than it is worth.
I would go with deploying the whole thing at a pop. If not you will end up with mismatched pieces of the application that are out of sync with each other. GWT has both Client and Server components and they need to be deployed together. If you have a zero downtime policy then you probably have load balancing in place.
I would use the load balancing software to deploy the new version of the app. Turn off one side (by diverting all traffic to the other side) deploy to it, do a quick smoke test, switch all traffic to the new side and repeat with the old side.

How to make my Java Swing application a Client-Server application?

I have made a Java Swing application. Now I would like to make it a Client-Server application. All clients should be notified when data on the server is changed, so I'm not looking for a Web Service. The Client-Server application will be run on a single LAN, it's a business application. The Server will contain a database, JavaDB.
What technology and library is easiest to start with? Should I implement it from scratch using Sockets, or should I use Java RMI, or maybe JMS? Or are there other alternatives that are easier to start with?
And is there any server library that I should use? Is Jetty an alternative?

Given that you have the application already, perhaps the simplest thing to do is to identify the interface that you require between the client and server, and first of all to refactor your application to use that interface to talk between the back-end/front-end within the same process.
Then you can start to split this apart. A simple solution would be to split this apart using RMI (since you're talking Java objects and have Java method calls). Spring contains useful tools to simplify/automate the RMI exposure of interfaces.
For the notification requirement, a simple UDP multicast (or broadcast) would suffice.
Note that as soon as you split your application up, you have issues re. maintaining consistent views of data, managing timely updates, handling cases when the server is down, possible loading issues when you get lots of clients etc. In a sense, splitting the application up into a client and server is just the start of a new architecture process.

Mina is a good choice as a network application framework for building a simple server for this purpose - it's a much better option than using raw sockets.
http://mina.apache.org/
If you really need an application server then you could take look at JBoss. It also provides a remoting component (as an alternative to something like Mina):
http://www.jboss.org/jbossremoting
You probably won't have much need for Enterprise Java Beans though. In most cases a simple POJO based framework is more than sufficient - you could tie this altogether with a dependency injection framework such as Guice:
http://code.google.com/p/google-guice/
or Spring. Keep it simple, don't use a J2EE server unless you really need to. Hope that helps.

This is much of what J2EE does, but it's a whole new learning curve because they have pre-solved many of the problems you will run into and many you may not and therefore add on a lot of new technologies.
But at it's most basic, J2EE answers just that question.

I worked in a project like this. We implemented Client-Side Swing and Server side with J2EE. We used EJB,Stateless beans and Message Driven Beans.Also I have been in a device tracking, management project. Our clients were trucks+Swing users and We have used Servets+TCP/UDP,Apache Mina framework to handle and keep connections.

I have been working in Java Swing Client/Server applications for almost 3 years. I would suggest you to go for RMI/EJBs. The initial application that we developed was doing this using RMI/EJB for client-server communication with WebLogic being the server.
But we later found out that there are lot of "browser-like" features to be included to the application such as session-timeout etc., So, we used the BrightSide Framework which wraps the RMI calls through HTTP. One more enhancment we made is that we replaced Weblogic with the open source JBoss server.
The wrapping of calls with HTTP will become very handy and you can make your swing applications really rich. Later, when the situation demands for you to use a website strictly, you can deploy your swing using jnlp.
Hope this helped.