Enjoy this new collection of microservices tutorials to help you learn in-demand skills like monitoring, testing, and service discovery.

Learn more about how to use Ionic 4 with JHipster 6 and Spring Boot to build a secure mobile app.

Go in-depth on what's new in Angular.

See what's new in this beloved PHP framework.

There's only one weekend left until we get to EclipseCon 2009 - and I can't wait! You'll have already seen what talks I'm looking forward to. We'll have lots of coverage of the conference here at EclipseZone. Another really easy way to follow the conference is by using Twitter to follow EclipseCon people. All you need to do to find these people is head over to the EclipseCon Birds Nest. There's four different ways to partipate - as a standard follower, as a speaker, an exhibitor or an attendee. There's going to be a Twitter monitor in the lounge area for people to watch what people are saying about the conference. Twittervision - how cool is that?! Ian Skerrett is also planning a tweetup on Sunday night. Over the last few weeks I've become a Twitter addict myself - it's a great way to keep in touch with the latest goings on. (If you want to follow me, just go to my profile as dzonejames.) In other EclipseCon news, Sun Microsystems have become a Gold Sponsor for the conference. They will be showing their Eclipse support for JavaFX, GlassFish and Solaris. It's good to see Sun there. If you haven't registered yet, there's still time for advance registration, ending today. Make sure to use your DZone coupon to get 10% off, using the DZONE10 code. Otherwise you can register on site. So, if you want to stay in the loop for EclipseCon, become part of the Birds Nest , follow me around on Twitter and keep visiting EclipseZone.

JXSE and Equinox Tutorial, Part 2 NOTE: As of January 2015, you can integrate JXTA in OSGI through an update site. The WIKI At chaupal.org gives detailed instructions on how to use the new 2.8.x JXSE bundles for OSGI.Many of the features covered here are implemented by default. Abstract In the first post of this series, we covered the quickest way to get JXSE 2.7x working in Equinox and, with some considerations, probably other OSGI frameworks as well. The approach aimed to get the same functionality as you would get by using the jar file in a regular JAVA setting, but as I demonstrated, Equinox does have the benefit of allowing multiple JXSE instances to run simultaneously, which is a great benefit when developing JXSE applications. In this second tutorial, we will cover some ways of improving the functionality by severing the dependency on the 4.2x version of Jetty (which has just released it's 9.0 version!) and we will introduce some basic tools to visualize the properties and functions of JXSE. This will improve the development cycle of JXSE applications even more. NOTE: This tutorial will use a modified JXSE jar, which currently has only been sparsely tested. If you want to develop in a fail-safe environment, I would recommend that you stick to approach of adding the 2.7x and org.mortbay.jetty 4.2x jars to your plugin structure. If you are more adventurous or, even better, want to help to improve the tooling, then this post is for you! Updating Jetty The approach we covered earlier involves including a Jetty server for every JXSE bundle you want to deploy. The Jetty server is used for HTTP tunneling and basically starts a simple HTTP server with one servlet. If we want to optimize this approach when running multiple JXSE bundle projects, it would stand to reason that we run one server instance, which registers multiple servlets, which is basically the way that Jetty runs in most OSGI environments. Ideally we would utilize the http service for Equinox to register our servlets, but because every JXSE bundle needs to run on a different network port, registration of the servlets is a bit more involved. The implication of breaking the dependency on the org.mortbay.jetty 4.2x jar (i.e. removing the jar-file from the lib directory and putting it in a separate bundle) is that the JXSE code has to be changed as well, and so we might just as well create a JXSE 2.7x bundle! This bundle will be a client for a declarative service that is offered by the Jetty plugin, and which allows registration of the specific servlets that JXSE uses. The necessary bundles can be found in the extended.zip, which offers functionality that extends the base porting of JXSE applications to Equinox. can be included in your target definition: NOTE: The zip file has been modified as of January 2014, and some package names have been renamed. If you downloaded a previous version, some of your code will not compile with the new bundles! Download the zip-file and unpack it in the same target root as the other target plugins (e.g. C:\Projects\Target\Extended) In the Eclipse IDE, select Window → Preferences → Plug-in Development → Target Platform, and select the active target we assembled in the previous posting Press 'Edit' and 'Add' a new 'Directory' by selecting the appropriate controls. Browse to the folder where the unzipped files are located and add the folder to your target definition. Press 'Finish' to complete the Wizard TIP: Extending a target definition with new directories can be a RSI-ridden chore. Luckily the 'Location' field stores previous entries, and so if you select one of these before pressing the 'Browse' button, you may win quite a few mouse-clicks The target definition has been extended with a number of bundles, three of which are important for this part of the tutorial: net.jxse (2.7.x) org.mortbay.jetty (4.2.x) org.eclipse.jetty.jxse.bridge (1.x.y) I try to follow the convention to use the version of a jar-file when it is converted to OSGI, and from this it becomes evident that the first two bundles are basically the original jar-files that were deployed in part one of the tutorial. The only difference is that these bundles share their dependencies through a declarative service. NOTE: Internally, the necessary modifications were performed with minimal impact of the code. To my knowledge, the core functionality should therefore not be affected. The major differences only come into play when multiple JXSE bundles are deployed simultaneously, which I consider to be new functionality anyway. When developing fail-safe applications, the two bundles should therefore be good to use, but keep a sharp eye on the HTTP logs to be certain! With this, we can now modify the two JXSE Plugin project we developed in the previous post to work with these bundles. We will also use a different example from the book Practical JXTA II to make things more interesting. We will try to connect Edge_Anna with Rendezvous_Jack. Modify the two JXSE 2.7x Bundle Projects you made in the previous tutorial : Remove the lib folder and the references to lib/jxse-2.7.jar and lib/org.mortbay.jetty.jar in the bundle classpath settings. Solve the compiler errors by importing the necessary bundle dependencies in the 'imported packages' tab of the Manifest editor. Include the org.mortbay.jettybundle (not the bridge!) The resulting Manifest.MF file should look something like this: Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Practical JXTA II: Anna the Edge Peer Bundle-SymbolicName: net.practical.jxta.decoupled.anna Bundle-Version: 1.0.0.v20130816 Bundle-Activator: net.practical.jxta.decoupled.anna.Activator Bundle-Vendor: MyCompany Bundle-RequiredExecutionEnvironment: JavaSE-1.7 Bundle-ActivationPolicy: lazy Bundle-ClassPath: . Import-Package: net.jxta, net.jxta.document, net.jxta.endpoint, net.jxta.exception, net.jxta.id, net.jxta.peer, net.jxta.peergroup, net.jxta.platform, net.jxta.rendezvous, org.osgi.framework;version="1.7.0" We can now copy Edge_Anna.java and Rendezvous_Jack.javafrom the folder B_Exploring_Connectivity_Issuesfrom the examples that are covered by Practical JXTA II as replacement for the previous examples. Last we need to make a slight adjustment to the Activators in order to ensure concurrency: import java.util.concurrent.Executors; import org.osgi.framework.BundleActivator; import org.osgi.framework.BundleContext; public class Activator implements BundleActivator, Runnable { private static Activator activator; private ExecutorService executor; static Activator getDefault() { return activator; } public void start(BundleContext bundleContext) throws Exception { activator = this; executor = Executors.newSingleThreadExecutor(); executor.execute(this); } public void stop(BundleContext bundleContext) throws Exception { if( !executor.isShutdown() && !executor.isTerminated()) executor.shutdown(); Activator.context = null; } @Override public void run() { Edge_Anna.main(null); } } When the bundles are added to your run configuration, you will see that the various pop-up messages are spawned as the two bundles are activated. But hidden deep in the log messages, you will also find that a -if all went well: INFO: Jetty Server for JXTA found! And, a bit later: INFO: Line 679 net.jxta.impl.peergroup.GenericPeerGroup.loadModule() Loaded privileged module : Reference Implementation of the HTTP Message Transport (net.jxta.impl.endpoint.servlethttp.ServletHttpTransport) As Rendezvous_Jack is starting up HTTP transport. If this doesn't seem to happen, then the most likely reason is that the org.mortbay.jettybundle has not started (type 'ss' in the Eclipse console for the status of the bundles). You can also check if the declarative services that forge the connection between the two bundles have started correctly by typing in the OSGI console: 'attendees': this should return (at least) osgi> attendees net.jxse.petitioner.ServerStarterPetitioner org.mortbay.jetty.provider.ServerProvider 'matched': this should return: osgi> matched net.jxse.petitioner.ServerStarterPetitioner is matched with: org.mortbay.jetty.provider.ServerProvider The bundles use a light-weight wrapper around OSGI's standard declarative services called a secure broker (org.eclipselabs.osgi.ds.broker) to make the connection. This bundle is also provided by the target addition that was downloaded .One of the added functions are three console commands to check the connections (the third one is 'waiting'). The first command lists the (broker) services that are registered, the second one which services are matched with one another. Above you can see that the bunle net.jxseis connected with the bundle org.mortbay.jetty. If these commands are not recognized, it means that the broker plugin is not activated yet. Integration with Jetty 6 to Jetty 8 (inclusive) If you are a bit more adventurous, you may want to try the Jetty Bridge that has also been included in the additions to the target. This bundle requires the org.eclipse.jetty bundles from 6.0.0 to 8.9.9, which are often shipped with certain Eclipse distributions. Simply deactivate the org.mortbay.jettybundle and activate org.eclipse.jetty.jxse.bridge. (and Jetty, of course). If all is well, you should see the same behavior as previously, but now more recent versions of Jetty can be used. NOTE: Please consider that I have only tested this option with Jetty 8, and not extensively. The sources are available on eclipselabs, so a Jetty expert (JXTA knowledge is hardly required) may be able to improve the current code considerably! Enabling JXSE Tools for Eclipse The previous examples probably have made clear that pop-up messages and log messages are not going to be very helpful when developing multiple JXSE Bundle projects simultaneously. Although this is work in progress (and probably will always be so), a start has been made to develop JXSE tools that can be used in an Eclipse IDE. I hope to add more posts to this tutorial as functionality becomes available, but here we can begin by demonstrating what needs to be done at minimum to make your JXSE Bundle Projects visible to the tools. In order to enable the Eclipse tooling, a new target is needed which replaces equinox with an Eclipse version (which, of course, includes an Equinox version). As we have ample experience with target definition management by now, I will just list the three directories that are needed to get things up and running An Eclipse version. You can opt to copy the Kepler installation to the target environment (recommended), or use the ${eclipse-home} option as location (quickest) the core JXSE bundles that were downloaded for the previous post The extended JXSE bundles that were downloaded for the first part of this tutorial Next we need to create a new Eclipse application ( File → New → Plugin Project). Select the option that the 'plug-in is targeted to run with' an Eclipse version, and (in the second tab) that we will develop a Rich Client application. Clicking 'Finish' will generate a bare-bones Eclipse RCP. We will include one perspective to the RCP by hardcoding it in the ApplicationWorkbenchAdvisor: package org.{my-company}.jxse.ui; import org.eclipse.ui.application.IWorkbenchWindowConfigurer; import org.eclipse.ui.application.WorkbenchAdvisor; import org.eclipse.ui.application.WorkbenchWindowAdvisor; public class ApplicationWorkbenchAdvisor extends WorkbenchAdvisor { private static final String PERSPECTIVE_ID = "org.eclipse.jxse.perspective"; @Override public WorkbenchWindowAdvisor createWorkbenchWindowAdvisor( IWorkbenchWindowConfigurer configurer) { return new ApplicationWorkbenchWindowAdvisor(configurer); } @Override public String getInitialWindowPerspectiveId() { return PERSPECTIVE_ID; } } Next, remove the Tools.java file from the JXSE bundles and rename the faulty imports in the JXSE bundles to 'net.osgi.jxse.compatibility.Tools'. We also need to make some changes to the code from Practical JXTA II: Make the class that run the examples extend net.osgi.jxse.compatibility.AbstractExampleContext Include addModule( MyNetworkManager) after it has been instantiated; NOTE: The static method addModule registers JXTA modules (NetworkManager, the various services, and so on) to the JP2PContainer, by wrapping them in a IJp2pComponent instance. In fact, the JP2P container accepts any object; it mainly serves to create a tree structure of provided modules (objects) with the NetworkManager as primary child. The NetworkConfigurator is also represented internally as a IJp2pComponent, but the service context already takes care of this when the NetworkManager is registered. Last, a new launch configuration is needed for an 'Eclipse Application'. Select the 'Run an Application' option in the first tab, and select the application you just created. The workspace plugins that are needed should include the application, and the two JXSE Bundle projects 'Jack the Rendezvous' and 'Anna the Edge'. Add the 'Required Bundles', and ensure that the following bundles are included: org.eclipse.equinox.console The three org.apache.felix.gogobundles org.eclipselabs.osgi.ds.broker org.mortbay.jetty or org.eclipse.jetty.jxse.bridge net.osgi.jxse.compatibility org.chaupal.jp2p.ui org.chaupal.jp2p.ui.jxta Validate the configuration and 'add Required Bundles' if necessary. If no problems have been detected, you can launch the application. If all went well, you should see the two JXSE bundles start up as they did previously, but instead of the somewhat outdated pop-up boxes from JAVA Swing, the more flashy alternatives from Eclipse's SWT packages should pop up. Also a basic Eclipse application should become visible with some views which are currently empty. The more observant developers will probably spot the WARNING: This bundle is not a valid JXSE Bundle. A JP2P-INF directory is required. Ignore this warning for now. It will become more important in the next part of this series. We are almost there! Stop the run configuration, and make the following modifications to the JXSE Bundle projects: Create a new component definition (File → New→ …) and select as the parent folder /OSGI-INF, and name jxse.xml (or another name of your choosing). This will create a folder OSGI-INFunder the root of your JXSE bundles and add the file. When the component editor opens, fill in the details as follows: After the component definition is completed, the required OsgiComponent.java needs to be present in the designated package. This class should look as follows: Include the following line in the Manifest-MF file: Service-Component: OSGI-INF/jxse.xml The OsgiComponent is very simple: package ; import net.jxta.platform.NetworkManager; import net.osgi.jp2p.chaupal.core.Jp2pDSComponent; import .Activator; public class OsgiComponent extends JxseDSComponent { public OsgiComponent() { super( Activator.getDefault()); } } Modify the Activator as follows: package ; import net.osgi.jp2p.chaupal.activator.AbstractJp2pBundleActivator; import org.osgi.framework.BundleActivator; import org.osgi.framework.BundleContext; public class Activator extends AbstractJp2pBundleActivator{ private static Activator activator; static Activator getDefault() { return activator; } public void start(BundleContext bundleContext) throws Exception { activator = this; } public void stop(BundleContext bundleContext) throws Exception { activator = null; } @Override public IJp2pContainer createContainer(){ return new Edge_Anna(); } } As you can see, the Activator has become much simpler, as the superclass it derives from does most of the work. All that needs to be done is to tell the activator which IJp2pContainer is required, and these rest is taken care of. The OsgiComponent extracts the context from the Activator and offers it as a declarative service. If the changes compile without problems, you can launch the application, and if all went well, you should now see both JXSE bundles become visible in the navigator at the left-hand side of the GUI. Clicking these should show you the NetworkManager, NetworkConfigurator and the NetPeerGroup, while their properties are displayed in the properties editor. NOTE: Currently not all the functionality works flawlessly (as it is an incubator project), but you can set some properties without problems. I am however not sure how JXSE responds to dynamically changing them, so I recommend to use the PropertyViewer for viewing only. Securing your JXSE Bundle When deploying your bundle in a production environment, you have to consider that the declarative service opens up means for 'rogue bundles' to listen to the creation and deployment of your JXSE bundle. As this poses a security risk, it is advised to disable the declarative service before deployment in real-world settings. You can either remove the Service-Component entry in the manifest file in order to achieve this. In the next tutorial I will cover a different way of securing the declarative service. Conclusion This tutorial has demonstrated some improvements on the results of the previous posting, and has opened up a way to view the content of the JXSE Bundles. So far, the main focus has been to modify existing code in order to get it working in Eclipse / Equinox. The next post will concentrate on building a JXSE bundle from scratch, and mixed-method approaches.

Abstract NOTE: As of January 2015, you can integrate JXTA in OSGI through an update site. The WIKI At chaupal.org gives detailed instructions on how to use the new 2.8.x JXSE bundles for OSGI. This extended series of tutorials will cover the various ways that the JAVA P2P framework JXSE (formerly popularly known as JXTA, and currently the most up-to-date JAVA implementation of the JXTA specifications) can be made to work with Equinox (the engine on which Eclipse runs). It would be tempting to replace Equinox with OSGI, and indeed many of the issues covered here will work fine with alternative OSGI implementations such as Apache Felix or Knopflerfish, but I will concentrate on Equinox because it will allow us to do a few things with JXSE that requires a bit more handwork on other OSGI platforms. Besides this, I have tested the code on Equinox alone, so I don't want to get ahead of myself. This tutorial is work in progress, so the document will be re-edited a few times. This tutorial not meant to cover the principles behind P2P in general, and JXTA/JXSE in particular. If you are interested in this, I'd recommend the (free) book Practical Jxta II by Jérôme Verstrynge, or to go through the online manuals for JXTA 2.5, JXSE 2.6 and 2.7. This first tutorial is aimed to get you started with JXSE 2.7x in an Equinox environment. The reader is expected to have a good understanding on developing plugins with the Eclipse IDE. If you are new to Eclipse I would advise you to read the excellent articles on developing plugins by Lars Vogel and brush up on OSGI and Equinox while you're at it. A Bit of History If you have been looking into P2P platforms for JAVA and have stumbled upon the official web sites, you may have seen that its dead silent over there, and has been for about three years. You may even be tempted to believe that JXTA is a dead project, and I could only concur. So what's the story..., and why revive this ghost through this tutorial? I will try to answer these questions as best as I can, but it may be prudent to first tell a bit about my own involvement in the JXTA project. I have been involved in JXTA since 2002 (!), although I was hardly ever one of the more visible contributors to the project. In fact, I consider(ed) myself to be a typical JXTA user; in awe about the wonderful things that the team at SUN and the community around them was trying to achieve, but furthermore mainly interested in the results, as I was trying to use JXTA in a project I was (and am) working on. I decided to port this project to Eclipse/ Equinox in 2004 and that is when I started to encounter problems with the 2.4x release of JXTA that I eventually managed to get working. As I was not very happy with the many third-party libraries that were needed by JXTA by then, and which were evolving at a more rapid pace than the JXTA team could follow -most notably the Jetty Server- I tried to port these third party libraries to stand-alone OSGI plugins and use the official plugins of these third party libraries if possible. The results were offered to the community through the java.net project jxta-eclipse when the 2.4x version finally worked. Sadly, the 2.5x release that was released about a year later forced me to redo a lot of this work, and I never really got it to work flawlessly. At the same time, the team at SUN was finding it hard to keep a steady pace, most likely due to the uncertainties of the future of their company, and personal issues made me loose focus on the developments of JXTA until the announcement of the 2.6x release, which initially was mainly intended to update jxta-eclipse to this new release. I was however struck by a new vibe in the JXTA community, headed by a few enthusiastic individuals such as Jérôme Verstrynge, and so I offered to lend a hand in reviewing the updated documentation, testing and debugging the 2.7x version. There were some early attempts to improve the integration with OSGI, and as I was getting to par with declarative services, I offered to help to make a more serious contribution to the JXTA code in order to make JXSE 2.8x completely OSGI ready... .. then Oracle bought SUN, cancelled JXTA and dead silence remained. Again some personal issues forced me to abandon my attempts to get the 2.7x integration with Equinox up and working, but early 2013 I finally got time to fulfill my promises and started working on a major revamping in order to offer JXSE as OSGI declarative services. I am currently about to commit my work so far on EclipseLabs and want to use this moment to officially revive JXSE, and hopefully get more help from others in the coming months. So what have I done? In chronological order: Changed net.jxta in order to create a full decoupling with the third-party libraries. JXTA works with the latest Jetty, Netty, javax and other relevant plugins, so the jars are no longer needed Changed net.jxta to work with the Derby and H2 plugins, declarative services. In progress Developed an RCP that replaces the Swing-based monitoring application. In progress. Added UI tooling to show the properties of the Network Manager, the configurator and the JXSE modules in property viewers and so on. In progress. Development of JXSE Plugin Projects to quickly deploy JXSE functionality in separate bundles, which can then be monitored by the RCP. Development of the code of Practictal Jxta II to work with JXTA RCP as JXSE Plugins. In progress Development of functionality to generates a basic JXTA plugin through an XML file located in the JXTA-INF directory. In progress. As I hope to complete the majority of the development work in the coming weeks, I hope to have a fully functioning update site with the relevant jars up in the air in the coming months or so, and the source code available on Eclipselabs. Hopefully, by the end of the year, we can have come to a situation that developing JXTA applications in OSGI has finally become easy (ier)! This document reflects these developments. I hope to cover the following issues: Setting up a basic JXSE 2.7x bundle with a minimum of effort. Improving the bundle by removing the required jars and replacing them with the relevant bundles Further improvements by using dedicated JXSE bundles Creating a JXSE Plugin Project from existing code Creating a JXSE Plugin Project from scratch Generating a JXSE Plugin Project skeleton with JXTA-INF components The remaining section will cover the first topic. The reader has to have a good working knowledge of Eclipse and Equinox, but I will fill in the gaps as good as I can. Oh yes, before I forget: JXSE 2.7x works fine! You may experience the usual problems with NAT traversals and firewall access, but that's part of working with JXTA. It is being used, both professionally as by many hobbyists, so the JAVA implementation of the JXTA specs deserve more attention than it's currently getting. JXSE and Equinox This first tutorial is aimed to get you started with JXSE 2.7x in an Equinox environment. For the purposes here, it is important (and many even experienced Eclipse users still often don't realize this) to know that you are developing plugins (or bundles) on an Eclipse IDE, which are deployed on a target, which by default is the same set of plugins that your IDE is using. If you want to be sure that the plugins you develop are as light-weight as possible, then your target needs to contain the bare minimum of plugins available, which is an OSGI implementation, such as Felix, Knopflerfish or Equinox, which is the OSGI implementation that Eclipse runs on. The down side of this choice is that you have to add a lot of plugins yourself, when they are needed. For instance, the J2EE developer IDE of eclipse has Jetty installed by default. If we want to use this functionality on a bare-bone OSGI target, we will have to add the plugins ourselves. We will opt for this choice, both for pedagogical reasons as well as that it allows us to develop light-weight JXSE projects, which can easily be ported to servers or mobile apps. For this tutorial, we will therefore set up Eclipse (Kepler) with a bare Equinox target on Windows. We will use the standard Eclipse IDE (download here), and download the latest SDK release of Equinox, which contains, amongst others, the source files for the code. Unzip the IDE to a preferred location (e.g. C:\Program Files\Eclipse\Kepler) Unzip Equinox to a different location (e.g. C:\Projects\Target\Equinox) Create a shortcut on your desktop to the eclipse.exe of the IDE for easy launching. It is wise to give administrator rights to this link (right-mouse click → properties → compatibility→ check 'run this program as an administrator') in order to prevent some strange errors during development. Apply this to all users if required. Start eclipse and choose an appropriate workspace. This is where you will develop your plugins. The next step is to set up the target platform: Select Window → Preferences → Plug-in Development → Target Platform. You will see that it is set to the 'Running Platform' which is the IDE you've just installed. 'Add' a new target definition by pressing the appropriate button. Start with the default option ('Nothing') and press 'Next'. Give your target definition a new name (e.g. JXSE Target) 'Add' a new directory by pressing the appropriate button and selecting the directory option. Then browse to the location where you unzipped Equinox. Pressing 'Finish' will add Equinox to your target definition and tell you how many plugins are available. If this is zero, then you probably have included a parent directory. The correct location always has a subdirectory called 'plugins'. You can change this by selecting the directory and pressing the 'Edit' button. Complete the wizard by pressing the 'Finish' button and activate the new target by checking the appropriate checkbox. Press OK to end the session. We have now set up eclipse with a basic Equinox target. Now we have to add JXSE 2.7 x to our projects. In order to do so, you can download the latest jar file from the JXTA Project website and get the relevant library dependencies from sourceforge. The 2.7.jar file can be downloaded here. We will be using code from Practical Jxta II by Jérôme Verstrynge, as this is the most up-to-date book on the subject. Besides this, it's free! We now have a bunch of jar files which contains all the functionality to make a working JXTA application. The default way to make a full-fledged JXTA plugin would be to create a new plugin project, add a lib directory where you put all the jars, include these to the classpath of your plugin project and start coding, right? Wrong! Sadly this approach does not work with Equinox (I believe it would in Felix and Knopflerfish, though). The problem is that a jar-file called Bouncycastle.jar, which provides some functionality for encryption and security, will not work properly. One distinct feature of Equinox bundles is that they run in their own classloaders while bouncycastle needs to run in the root classloader. We can solve this problem by creating a fragment bundle for this jar file, which effectively 'OSGI-ifies' this jar. But if we are going to strip the library anyway, we can immediately tackle some of the other jars. Most of these are bundles themselves, or are available as bundles. If these can be used, it is possible to use the most recent bundles (provided, of course, that these still work with JXSE 2.7x). This actually is the case with the following jars in the library we downloaded earlier: Derby H2 Junit (optional, for testing) Netty javax.servlet (in the Jetty package) The most recent versions can be downloaded from the respective websites, or from Orbit. Some of the other libraries are not needed (Felix, for instance, as we are working with Equinox) and some are optional. We can therefore improve the JXTA performance tremendously if we try to reduce the dependencies to these legacy jars. Obviously, you do not need to all this work yourself, but can use the alternative dependencies that I've assembled myself. These can now be added to your target definition in order to enable their functionality! The plugins are fairly recent (as of time of writing), and should work without too much ado. You can unzip the folder next to the Equinox target, and include it to your target definition: Select Window → Preferences → Plug-in Development → Target Platform. Select your target and press 'Edit' 'Add' a new directory by pressing the appropriate button and selecting the directory option. Then browse to the location where you unzipped the dependency bundles. Pressing 'Finish' will add Equinox to your target definition and tell you how many plugins are available. If this is zero, then you probably have included a parent directory. The correct location always has a subdirectory called 'plugins'. You can change this by selecting the directory and pressing the 'Edit' button. Complete the wizard by pressing the 'Finish' button and 'reload' the target by checking the appropriate button. Press OK to end the session. With this we are ready to start programming! Your first JXSE 2.7X Bundle Project For the first JXSE bundle project we will be using an example project from Practical Jxta II. Create a new plugin project: Select File → New → Plugin Project (through 'Other' if it isn't immediately visible). Fill in the required details. Include an activator that starts upon launching. When the project is created, include a new file called 'lib' in the project, and copy the jxse-2.7.jar you downloaded earlier, and the org.mortbay.jetty.jar from the library dependencies to this location. Don't forget to refresh the project after this is done. Add the jars to the plugin's classpath by selecting the 'Runtime' tab in the manifest editor. Press the 'Add' button, browse to the lib folder and select the jars. Create dependencies to the bundles of the additional target we included earlier. The resulting MANIFEST-MF file should look something like this: Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Jxta test Bundle-SymbolicName: org.myorganisation.jxta.example1 Bundle-Version: 1.0.0.v20130816 Bundle-Activator: org.myorganisaton.jxta.example1.Activator Bundle-Vendor: MyOrganisation Require-Bundle: org.eclipse.core.runtime, org.jboss.netty.httptunnel;bundle-version="0.92.0", derby;bundle-version="10.8.2000002", org.h2;bundle-version="1.3.170", javax.servlet;bundle-version="3.0.0", org.jboss.netty;bundle-version="3.2.5" Bundle-RequiredExecutionEnvironment: JavaSE-1.7 Bundle-ActivationPolicy: lazy Bundle-ClassPath: lib/jxse-2.7.jar, ., lib/org.mortbay.jetty.jar Next we add two files from the examples that are covered by Practical JXTA II. Copy the file 100_Starting_And_Stopping_JXTA.java from the folder A_JXTA_Connection_And_Local_Configuration into your project's source location (with the Activator,java) Do the same for Tools.java in Z_Tools_And_Others Refresh your project and fix the errors. The package names are wrong and some of the imports. Include the example in the Activator as follows: import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; .... public void start(BundleContext bundleContext) throws Exception { Activator.context = bundleContext; _100_Starting_And_Stopping_JXTA_Example.main(null); } We are almost there! We only need to create a run configuration in order to get everything working: Select a new debug (or run) configuration: Run → Debug Configuration Add a new launch configuration based on an OSGI Framework. Give it a distinctive name and select the plugin you just made from the 'Workspace' node. Press 'Add Required Bundles' to create a working launch configuration Add the org.eclipse.equinox.console and the three org.apache.felix.gogo bundles Validate the launch configuration. If all went well, you should get the message that 'No problems were detected' Launch the configuration by pressing the appropriate button. If all went well, you should see a lot of messages appear in the console, and three pop-up messages should come up telling you that the Jxta Network is started, connected and stopped. Congratulations, you have just successfully deployed your first JSE Bundle Project! From hence on, it should be fairly easy to integrate the examples from Practical JXTA II in your Equinox projects! NOTE: In the above situation, the NetworkManager is started in the Activator's start method. This can give timeout exceptions during bundle start up. If you experience this, then it may be better to introduce an executor service which runs the example code: public class Activator implements BundleActivator, Runnable{ private ExecutorService executor; public Activator( ) { super(); executor = Executors.newSingleThreadExecutor(); } public void start( ... ){ executor.execute(this); ... } public void stop( ... ){ executor.shutdown(); ... } @Override public void run() { _100_Starting_And_Stopping_JXTA_Example.main(null); System.err.println( "Container started successfully"); } } An Added Bonus Most developers who have worked with JXTA in the past may be pleasantly surprised that Equinox resolves one issue that has long plagued JXTA development, which is that you cannot deploy multiple JXTA projects in one development environment, as JXTA will complain that 'only one world peergroup is allowed to be active'. The fact that Equinox bundles all use their own classloaders is often a major pain for Eclipse newbies, but here it actually is an advantage: you can run multiple JXSE projects in one IDE! In order to demonstrate this, you can copy the project you just made in the workspace, give it a different name in the manifest editor and, for demonstration purposes remove the MyNetworkManager.stopNetwork(); in the example code. NOTE: It is better, of course, to modify the code in such a way that stopNetwork() method is called in the stop() method of the Activator. Launch the projects by including the new project in the launch configuration (this is normally done automatically) and running it. You will see that both projects start without any exceptions. Conclusion This tutorial has given us a start to developing JXSE 2.7x applications with Equinox (and Eclipse). Seasoned Eclipse developers may already see some room for improvements, and indeed I will tackle these issues at a later stage. For now, new developers in JXTA can get started with the book Practical JXTA II and seasoned developers will have an idea to port their code to Equinox (and other OSGI platforms, as it should work there as well..besides the concurrent development of JXSE projects, that is! In the next post , I will discuss further improvements by breaking the dependency on the outdated Jetty jar and the swing-based tools that are used in Practical JXTA II.

In this post, we go over the best article of June from DZone's Web Dev Zone, showcase a couple of great jobs, and link to some of our great web dev publications.

Here's the best of security from June as decided by you, the awesome DZone readership, and a few other cybersecurity items of interest.

In this post, we go over the best article of June from DZone's Web Dev Zone, showcase a couple of great jobs, and link to some of our great web dev publications.

Here's the best of security from July as decided by you, the awesome DZone readership, and a few other cybersecurity items of interest.

You will learn how to integrate front-end with backend by following along with this great tutorial. Read on to get started!

The two main branches of Java development, Enterpise and Desktop, have traditionally been seen as separate skill sets. But some current trends are contributing to blurring the line between the desktop and the web. For years I've been working on desktop Java with Swing and with the Eclipse platform. I've regarded JEE development as a separate activity, targeting the web market. Some changes in the industry have led me to question this assumption. What is an Enterprise Application Anyway? Before we discuss why desktop and enterprise Java aren’t all that different, we should look at what defines an application as an enterprise application An application that involves the integration of many resources An application with high performance requirements Scalable, secure and robust Easy to maintain and extend May run across a network If you look at what you are writing at the moment, I'm sure it must tick at least 3 out of the 5 points above. I would go as far to say that it covers almost 80% of all applications currently being developed. The important thing to take from this is that whether you are developing for your application server, or for your desktop environment, chances are you are developing an enterprise application. Signs of a Welcome Change Analysts at Gartner Group, writing in the report Trends in Platform Middleware state something that has been quite obvious from the past few years of enterprise development, often quoted by Rod Johnson. The popular Java Platform, Enterprise Edition (Java EE) and .NET platform middleware technologies are increasingly inadequate to cover needs for extensive scalability and performance, event-based programming styles, advanced service-oriented architecture (SOA) and dynamic application developments. When the original J2EE architecture was defined, it tried, but failed to predict the future. By attempting to cover all cases, including more than its fair share of “what-if” scenarios, it became an overwhelming specification. Trends over the past few years have seen a rise of innovation in the open source community, giving us frameworks such as Spring and Hibernate, each dealing with a particular piece of the jigsaw. In particular, OSGi has given the chance to produce properly dynamic applications. Each of these frameworks can run as standalone on a desktop, or deployed on an application server. This lack of dependency on the application server gives the freedom to use the same approaches on different platforms. The Desktop Moves to the Web So far we’ve seen that the enterprise applications are becoming more lightweight and more modular thanks to Spring and OSGi. Integration with key third party APIs is easy thanks to the rise of open source. One of the most interesting trends in the past year has been the ramping up of the effort to move desktop quality software onto the web browser. Appcelerator’s Nolan Wright, notes that his RIA development platform will be making a move towards better desktop integration in a recent interview. We see the next big thing for us being desktop integration, but not at the expense of the browser. We want to have the power of the web in a desktop container, where we get to use features like drag n drop and saving files locally. Adobe AIR is already making progress in this area. With the expected spotlight to be on JavaFX at this year's JavaONE, we can see that Sun recognizes that we need to have a useful presentation layer for many target platforms. Google’s GWT API has been written to closely mirror what the Swing API looks like. Developers who previously thought themselves to be pure desktop can now find themselves comfortably developing front ends on either the desktop or the web, thanks to this trend. Online IDEs have been getting a lot more coverage, and are seen as one of the next big things. Eclipse has been making some moves towards this web-enabled future with the announcement of e4, and we can expect to see a lot more companies looking at this convergence of the web and the desktop. IBM’s Mike Wilson, leader of the Eclipse Platform project, explains why this change in focus needs to happen for Eclipse. I think it's very important for the Eclipse code base to move out to the Web, and get involved more in that space, because the world is changing. A lot of business software development is moving to Web-base UIs backed by services. We're also seeing the IDE world moving in that direction. The Part OSGi has to Play This move to service based software has many implications, not least a better, more modular design. It’s a natural evolution for software development to take, and helps to make the field more mature. OSGi plays a central role in this modular approach, providing a dynamic component model. As an example, Eclipse provides the Equinox OSGi framework, which can run in many modes – standalone on any JVM, as part of an Eclipse RCP application or to even deploy the Equinox WAR file on your Java EE server. Ian Skerrett, Director of Marketing for the Eclipse Foundation specifies the problem that the OSGi approach will solve. In Java we have SE (Standard Edition) and ME (Micro Edition) and EE (Enterprise Edition). These all require different models. It's portable, but not properly consistent. Infrastructure technology needs to be a lot more adaptable. It is fair to say that OSGi is one of the most important enabling technologies to get us to this goal of a better infrastructure where we just choose our target platform and deploy accordingly, rather than having to create separate projects to deal with different environments. What This Means for the Industry So how does this affect a daily developer's life? For a start, it's time to break down any barriers and pre-conceptions that you may have about either desktop or enterprise developers. To survive in the industry of the future, and I'm guessing around two years time here, we need to be able to work with both streams. Desktop developers need to ramp up on JEE skills - perhaps even looking at the older J2EE approaches to full appreciate the technologies provided - it's much more than just technologies for the web. On the other hand JEE developers need to familiarize themselves with the traditional user interface technologies such as Swing and SWT. At some point, we'll find a nice middle ground, but this knowledge will help us shape a better future for the Java applications we write. So, what do you think - have you seen this trend happening already where you work? Are there cases where we can't think of enterprise and desktop as the same thing?

Summer is truly behind us, and it's time to get down to business.

With the recent releases of Java 9 and Java EE 8, you can imagine there'll be a lot of news in the world of Java this month, so let's get started!

This month's edition of Java Annotated Monthly not only focuses on news and tutorials for Java, but also looks at cultural issues in the realm of software development.

What's happening in Java this month?

Check out the latest happenings in Java this month.

As usual, Trisha Gee has put together a list of some of the best resources out there. This month, learn more about Java 9 and Jigsaw, how to be better at your job, and more.

To be object-oriented or not to be object-oriented, that is the question. But, really, that's the question we take a look at in this article.