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.

These articles have performed so well that we thought we'd give them an encore. Check out Dzone's best Performance articles from July, plus a few more items of interest.

Following the first episode, Robert goes to his first organizational audit meeting in this famous startup known for its ''disruptive and agile'' organization.

In the third part of this series, we dive into the deployment of an application and the configuration of Kubernetes.

We will take a Kubernetes feature and break its implementation to understand how it interacts with Kubernetes system components.

Jira is feature-rich and exceptionally flexible, bending to meet your needs. Here are the add-ons and integrations to improve your software delivery processes.

this article is part 2 of a tutorial that will walk through adapting an open source javafx radialmenu ( http://jfxtras.org/ ) to replace the netbeans platform system menu. it will build upon both previous tutorials and part 1 that demonstrate complete replacements for the default netbeans swing components using javafx. code examples will feature netbeans platform, javafx and css. part 1 of the article walks through some of the code upgrades necessary for the task. as of this article’s writing the open-source jfxtras radialmenu needed a few upgrades to act as a system menu replacement for a netbeans platform rcp. part 2 will show the specific algorithm and code to then utilize the upgraded radialmenu as described. when complete you should be able to produce a slick radial system menu like this: previous tutorials in the integrating javafx with the netbeans platform series we showed how to replace the netbeans swing menubar with javafx components. you can find these tutorials here (first link is part 1): https://dzone.com/articles/javafx-accordion-slide-out https://dzone.com/articles/tabs-tabuless-netbeans and they are extensions themselves of these great articles written by geertjan wielenga: https://dzone.com/articles/how-integrate-javafx-netbeans-part2 to fully understand and follow this tutorial you will need to start with the previous tutorials mentioned above, especially part 1. create recursive container building method like most of the previous menu replacement articles, we are going to use recursion to build our components. in this situation we want to recursively build our extended radialcontainermenuitemsp components that we upgraded in part 1 of this tutorial. add this recursive method to your jfxradial component class: private void buildradialcontainermenuitem(fileobject fo, final radialcontainermenuitemsp rcmi) { datafolder df = datafolder.findfolder(fo); dataobject[] childs = df.getchildren(); for (dataobject onechild : childs) { //create filler graphic for container imageview filler = imageviewbuilder .create() .image(new image("jfxradial/dark_compass_icon_16.png")).build(); if(fo.getname().equals("web browser")) { system.out.println(); } //if child is folder we need to build recursively if (onechild.getprimaryfile().isfolder()) { fileobject childfo = onechild.getprimaryfile(); //create radialmenucontaineritemsp final radialcontainermenuitemsp newcontaineritem = new radialcontainermenuitemsp(containersize, childfo.getname(), filler, false); //recursively build submenu buildradialcontainermenuitem(childfo, newcontaineritem); //add radialmenucontaineritem to radialmenu rcmi.addmenuitem(newcontaineritem); } else { object instanceobj = fileutil.getconfigobject(onechild.getprimaryfile().getpath(), object.class); if (instanceobj instanceof action) { //if it is an action we have reached an endpoint final action a = (action) instanceobj; string name = (string) a.getvalue(action.name); string cutampersand = actions.cutampersand(name); //create radialmenuitemsp final menueventhandler meh = new menueventhandler(a); //add action to radialmenuitemsp and hide graphic filler final radialmenuitemsp menuitem = new radialmenuitemsp(menusize, cutampersand, filler, false, meh); //add radialmenuitemsp to radialcontainermenuitem rcmi.addmenuitem(menuitem); } } } } the recursion process of course looks very similar to that found in our previous articles. one thing to note here that the way that because the radialcontainermenuitem class extends the radialmenuitem class and because of the logic we added to dynamically provide mouseclicked event handling, we can recursively build a radialcontainermenuitemsp with as many nested levels as the jdk has memory. then only the root node in the chain needs to be added to the radialmenu itself. feed the netbeans platform system folders into the recursion add this block of code to the end of your createradialmenu() method: fileobject menufolder = fileutil.getconfigfile("menu"); fileobject[] menukids = menufolder.getchildren(); //for each menu folder need to create either radialmenuitemsp or a radialmenucontaineritem to hold sub menus for (fileobject menukid : fileutil.getorder(arrays.aslist(menukids), true)) { try { datafolder.findfolder(menukid); //create filler graphic for container imageview filler = imageviewbuilder .create() .image(new image("jfxradial/dark_compass_icon_16.png")).build(); //create radialmenucontaineritem and recurse //extend a custom container that uses text labels like we did for radialmenuitemsp radialcontainermenuitemsp newcontaineritem = new radialcontainermenuitemsp(containersize, menukid.getname(), filler, false); buildradialcontainermenuitem(menukid, newcontaineritem); //add radialmenucontaineritem to radialmenu radialmenu.addmenuitem(newcontaineritem); } catch (exception ex) { //we couldn’t load so drop it on the floor } } again it looks very similar to all our previous examples. one small note here, i don’t want to actually show any graphics in my menus, only menu text labels. so the filler imageview object is just that… an invisible filler to satisfy the available constructors. adding this code should provide you with a view similar to this: this view of course is after i’ve started clicking around expanding layers. wow. that’s a lot of options. it makes you appreciate how efficient a traditional menu is in terms of space. so right here we’ve already encountered a problem that plagues radial menu’s in general… they take up a ton of space and block out whats behind them. but javafx to the rescue… lets reduce the opacity of the menu to a really low number like 0.1. you can do this by changing the fourth component of the “slightlytrans" color object defined at the top of the createradialmenu() method and recompile. let’s try it with something in the background like a javafx web browsing component: hmmm… a lot of those menu items are too transparent and they don’t show well over dark patterns and backgrounds. let’s up the opacity to 0.3… so we’re getting closer… not bad at all on a light background and a bit better on dark/mixed backgrounds. we should probably increase the opacity a bit more to 0.6. let’s try it on a deeply dark background like a worldwind application! ugh. that grey box represents the specified scene size inside the transparent jfxpanel component. this is a bug when trying to overlay transparent javafx scenery on native/heavyweight components. basically the z-ordering gets mucked up. the non-transparent nodes in the javafx scene are rendered properly but everything else not so much. if someone out there has a workaround please let me and everyone else know. so from now on we will all agree to keep our heavyweight and translucent javafx separate and our opacity around half for all to see. if you follow those rules and these articles you should be able to make lot’s of cool looking menus and interfaces like the one at the start of this article and the one below:

Keyboard-centric bug and issue tracker YouTrack 1.0 that we have previously announced has been finally released to the general public! You can download YouTrack as a JAR or WAR distribution, evaluate it for 60 days, and choose between two editions: Enterprise Edition with unlimited functionality for $1,200. Professional Edition that is limited to 20 users and 10 projects, and doesn't provide LDAP support for $300. Both editions sell at 50% off before the New Year! YouTrack provides keyboard-centric approach with shortcuts for major operations, issue search with natural-language-like search queries aided with intelligent query completion, powerful commands letting modify multiple selected issues, integration with external tools including JIRA, LDAP, and JetBrains TeamCity, instant installation, and other features that you can explore at YouTrack website. Since going beta, YouTrack has introduced OpenID authentication support, improved e-mail notifications, "Select all" feature to modify all found issues at once, and restructured access permissions for clearer administration. You can try YouTrack in action right away since it's used to track issues in JetBrains' own products including IntelliJ IDEA, RubyMine, TeamCity, dotTrace, MPS, and Web IDE. Use the following resources to learn more about YouTrack: YouTrack features YouTrack demos and documentation YouTrack blog YouTrack on Twitter

Check out one of the more exciting features from JDK 13 — text blocks!

Continue learning about managing Jenkins configuration as code in this tutorial on migration to JCasC from your current Jenkins master node.

Learn how to manage Jenkins master configuration with simple, declarative YAML files with Jenkins Configuration as Code.

JDK 14 Early Access Build #23 is now available.

You can put JDev files on NetBeans for brand-new creations.

To virtualize and make use of your data, you need to bring it into your platform. See how to do this with JBoss and OpenShift so you can get your data when you need it.

This JavaScript quiz will test your knowledge of arrays along with the order of operations. If you don't know the answer, you'll want to brush up on Array.prototype.map.