Print

[mikep]

Hi!

 Just started looking at JPPF for an application. From what I have read, it would seem that JPPF has a relatively open architecture for the node side, particularly if security is disabled. Would like to confirm though with you that we can have the task access these types of facilities on the node:

 - JDBC
 - web services
 - EJB3s (this would be nice)
 - JMS

how would the task differ from a normal every day POJO on the node machine?

If I have a body of legacy code running in a JBOSS EJB3 environment, the ideal would be that I can essentially duplicate that into each node, so that I have multiple JBOSS nodes running, managed by JPPF. Do you see any issues with this? What would those issues be?

Much thanks. I think you have an unique approach with this product here.

Mike

[lolo]

Hello Mike,

To properly answer your questions, I decided the best was to try and run a JBoss instance as a JPPFTask.
It almost works. I'm still having issues with the web services components (probably forgot some configuration parameters), but it appears that the rest is working properly. I could see that the web server, EJB container, JMS, JDBC, JCA connectors are all started and deployed properly and I was able to play with the web and JMX consoles.

To achieve this with JBoss 4.2.2, I had to perform the following:
- some reverse engineering (as permitted by the JBoss LGPL license, using the source code is really helping!) to figure out which JBoss class to start and what configuration properties to set
- add the proper JBOSS libraries to either JPPF client, server or node's classpath (i.e. jars in JBOSS_HOME/lib, JBOSS_HOME/lib/endorsed, JBOSS_HOME/server/<server_config>/lib)
Where you set this classpath has a significant impact on how long it takes for JBoss to startup
- I had to modify the JPPF class loader to ensure that java packages are defined - see ClassLoader.definePackage(). In effect JBoss checks that its packages are defined by the class loader, and if not, it will fail at startup. This modification is currently only available in the JPPF CVS trunk, and not part of any distribution.
- JBoss must be installed on the same machine as the node, or at least on a file system it can access, as it relies on a specific file structure

For your information, here is the code for the JPPF task I used:

Code: [Select]

package sample.jboss;

import java.io.File;
import java.net.URL;
import java.util.Properties;

import org.jboss.system.server.*;
import org.jppf.JPPFException;
import org.jppf.server.protocol.JPPFTask;

/**
 * This task runs an instance of JBoss.
 */
public class JBossTask extends JPPFTask
{
  public void run()
  {
    try
    {
      String path = "C:/Tools/jboss-4.2.2.GA";
      URL url = new File(path).toURI().toURL();
      Properties props = new Properties();
      props.setProperty("jboss.home.dir", path);
      props.setProperty("jboss.home.url", url.toString());
      props.setProperty("jboss.server.name", "default");
      props.setProperty("jboss.bind.address", "localhost");
      System.setProperty("jboss.bind.address", "localhost");

      Server server = new ServerImpl();
      server.init(props);
      server.start();
      synchronized(this)
      {
        wait();
      }
    }
    catch(Throwable e)
    {
      setException(new JPPFException(e));
      e.printStackTrace();
    }
  }
}

In conclusion, I believe what you seek would is possible, provided we can resolve the last hurtles in the JBoss startup process, but I'm quite confident that it's only a matter of time.

I'm interested in your feedback on this, I think it's an interesting approach and it may open many horizons for JPPF.

Sincerely,
-Laurent

[mikep]

Hi Laurent,

thank you for your hard work and detailed answer. Yes, we see this as a major situation that is not supported by other grid solutions. We have an application specialty that causes us to have to deal with clients with this kind of situation.

Mike