IDE plugin's for developing multithreaded network applications - java

I am looking for a plugin that helps developers create multithreaded network applications that works with either Eclipse and/or Netbeans. Should allow for functionality such as:
Graphical modeling of callbacks
Configuring executors
Creating custom SSL factories
Wizards for creating various filter streams

How about a framework? JBoss Netty (http://www.jboss.org/netty/) and Apache MINA (http://mina.apache.org/) are very similar in function and will both facilitate the sorts of things you mention. As for an IDE plugin, I don't know of anything but doubt the value of such a tool.

Related

Is Citrus Framework suitable for standalone deployment

I'm a developer of a BPM application. Our team has a simple hand-written tool, that allows to mock external systems over JMS and SOAP, also this tool allows us to call our own integrations.
However, we want to use something more extensible and bulletproof for integration testing purposes and Citrus Framework seems like a good alternative, but it is designed primarily to be executed like JUnit/TestNG tests, which is not suitable for the case.
We need an application that runs as a standalone one and allows simple configuration without redeployment.
Is this possible with Citrus Framework?
If not, what approach would you recommend for the purpose?
Thank you!
There is a side project from Citrus called Citrus Simulator that is a standalone simulator for multiple message transports including JMS. The project is available on github: https://github.com/christophd/citrus-simulator
User manual (still under construction) can be found here: https://christophd.github.io/citrus-simulator/

Java Web application "plugin" architecture

Please give an advise on how to do "plugin" architecture for Java web application.
Currently we are using quite simple and standard Spring+Hibernate+Struts 2 in Tomcat servlet container. (Built with maven)
I need something like Redmine. Where any module can be enabled/disabled, updated
Please exclude heavy options like OSGi, Portlet.
OSGi is too heavy, there is no good adoption of the technology for web. I already looked at Eclipse Germini;
Portlet it just old, and never was popular.
I will try to provide several possible solution. I did spent some time preparing small PoCs for the project I'm working on, so let's hope the options below are relevant.
Important note: it is really easy to define some extension point, do resolve and find available implementations. There are a lot of solutions available, for example good and simple one -- JSPF
Resources are the main problem for WEB applications
OSGi
OSGi, is not that bad and can be useful. It seems to be heavy (and some implementations are heavy) but this is price of standardized platform. I would suggest to check Apache Felix. It can be used in a "lightweight" mode. By the way, it includes Web Console which is build as loosely coupled plugin-based application, could be helpful:
Some examples Extending the Apache Felix Web Console
The Web Console can be extended by registering an OSGi service for the
interface javax.servlet.Servlet with the service property
felix.webconsole.label set to the label (last segment in the URL) of
the page. The respective service is called a Web Console Plugin or a
plugin for short.
You can also check eie-manager which is clean and simple and uses OSGi to manage plugins. Could be a good example for you.
Custom plugin framework
I would suggest to review solution behind Jenkins/Hudson. I would say Jenkins plug-in system is quite mature and reliable. Can be used as a good example.
Please also check Hudson Plugin Architecture
Simple solution
For my project I've build plugin abstraction layer based on JSPF with custom dependency resolver.
PROS:
simple and small
clean concept
works good
CONS:
without proper plugin management can be slow (full classpath search)
provides very basic functionality
may require additional attention
I would suggest to use JSPF only if you really need some simplicity and want to control everything. JPF provides a lot of interesting features out of the box, for example:
Plug-ins can be "hot-registered" and even de-registered during
application execution. What's more, registered plug-ins can be
activated and deactivated "on the fly", minimizing runtime resource
usage.
The problem is JPF is dead.
Suggestion
Do spend some time with Apache Felix. It is mature enough, so your time investments may pay back a lot.
Check out the answers to this question: Best way to build a Plugin system with Java
If you don't trust the plugin code, you can implement sandboxing, as described here: Sandbox against malicious code in a Java application
The open-source Java Plug-in Framework project supports plugin deactivation, you can get inspired from it even if it is too heavy for your purposes.
Atlassian open sourced their plugin system here. I see it is being worked heavily by Atlassian team. Worth to explore its documentation

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.

Application framework for Java desktop applications?

I'm currently using a custom framework to build Java Swing applications which have event monitoring over a network. I'd like to replace our custom networking layer with something like JMS but our framework is tightly coupled to its current implementation.
This lead me to search for existing application frameworks which may already have the capabilities we need. Spring was one of the frameworks I considered since it appears to be one of the more lightweight solutions available. We are currently using Guice for our DI needs but I see I can get similar features from the Spring container as well.
Would Spring be a good fit for building Java Swing applications or should I be considering other application frameworks?
You can use Spring to do this, take a look at the following articles for an idea of how to use it to build Swing applications:
http://java.dzone.com/news/spring-enabling-decoupled-swin
Spring is the best framework to do this.
We're using Spring in a huge energy trading application on client (Swing) as well middle tier side. It deserves all the prising.

http/AJAX (GWT) vs Eclipse gui for thin client deployment

I am starting a project for which we will have a thin client, sending requests and getting responses from a server.
We are still in the planning stages, so we have a choice to settle on either an Eclipse based GUI (Eclipse plugin) or using GWT as a fromtend for the application.
I am not very familiar with Eclipse as a GUI (Nor with GWT) but do know 'normal' Java.
What would be the main benefits and drawbacks of either approach?
Edit: Addressing the questions posed:
The project, if Eclipse based, would be using the core Eclipse gui (No coding tools, just bare bones) and the GUI would be packaged with it.
I have been looking at GWT and so far seems the best choice, but still have some research to do.
Communication method is a variant of CORBA (In house libraries)
If you are thinking of using Eclipse to build a standalone client or a plugin that's just added to an existing Eclipse install, how are you planning to communicate with your server?
Our team tried building an Eclipse Rich Client Platform application and having that communicate with a J2EE EJB-based middle tier over RMI, and that worked pretty well, except for when we got to security and couldn't use any of the standard J2EE security patterns to create a login on the Eclipse client that would authenticate against the server.
This seems to be a known issue in Eclipse circles, but I haven't seen anything thats a good solution for it.
GWT seems pretty advanced for what it is, and there's several IDEs that added tooling for working with it, but I have no first hand experience developing with it. Everything that I have seen in terms of demos and examples makes it look really powerful and easy to use.
So my basic point is, Eclipse is an exciting platform, but you will face difficulties which you might have to solve yourself. GWT seems to be an easier alternative for now.
Coming from someone who has just as much experience as you do (haven't developed any Eclipse based plugins or anything with GWT), this is purely an opinion from another set of eyes on your problem.
Purely from the standpoint of this application being served from a thin client, I would think GWT would fit the bill for this situation a bit better. It would certainly be a bit lighter and would not require the overhead that an Eclipse Plugin would.
I also think this would make deploying updates a lot easier.

Categories