Hitting the Jackpot

In many cases we, as developers, will come across a situation where we need to refactor lots of code in a very specific way. To explain I'll use a recent example I've run into... upgrading an enterprise application for Java EE 7. Java EE 7 applies more constraints onto the PostConstruct method, specifically preventing you from throwing checked exceptions from the method. Glassfish 4 fails deployment with the following message:

Exception while deploying the app [my.fake.company.enterpriseportal_application_war_2.7.0-A8-SNAPSHOT] : The lifecycle method [initialize] must not throw a checked exception. Related annotation information: annotation [@javax.annotation.PostConstruct()] on annotated element [public void my.fake.company.enterpriseportal.ui.admin.livecycle.ecn.MissingEcnJdbcDao.initialize() throws my.fake.company.enterpriseportal.ui.admin.livecycle.ecn.MissingEcnDaoException] of type [METHOD]

Well, the good news here is that it's a very explicit message. I know exactly what I have to do, but how many places have we done just that? Glassfish tells me about one instance of this problem, but there might be many scattered through our 50+ artifacts. Now we could fix the problem by hand, scouring each of our libraries one at a time looking for this problem, or we could hit the  Jackpot . Jackpot is a tool developed by one of the NetBeans developers that allows for large-scale refactoring from the command line.

How it works?

At it's heart Jackpot is a fairly simple tool, once you figure out the ins and outs. The first being, don't try to build it from source code, the build available for download may be slightly out of date but will save you some large headaches; trust me. Go ahead, download it. Once you have it downloaded and unzipped you can execute it on your source code with a command like 

jackpot --hint "System out / err" src/main/java/

For a list of all available hints run "jackpot --list"

In this example we're using one of the built-in features of Jackpot. Since it is somewhat integrated with NetBeans, all the NetBeans refactoring patterns are available to you via the "–hint" argument. This hint checks for any lines that print directly to System.out or System.err; but that's not that helpful.  Firstly, this will only tell you about the problems, it's not going to fix them; and secondly, that's not what we're looking for! Let's talk about automatic refactoring first... because it's easier. To have jackpot automatically fix any issues that it can, you just add the "–apply" argument to you command, so you'll have something like this

jackpot --apply --hint "System out / err" src/main/java/

In this example the offending lines will simply be removed. I hope you didn't do any real computing in a println command!

Custom Rules

The rules formatting has been integrated into Netbeans as of NetBeans 7.1, but I'm not sure where it's used.

Now, to fix our problem. No rule that NetBeans provides will fix our problem, instead we'll need to create our own. The formatting of rules is specific to Jackpot/NetBeans. The documentation available is a little scarce, I've searched through the NetBeans site and the wiki space and have found only these four pieces of documentation:

1. https://bitbucket.org/jlahoda/jackpot30/wiki/RulesLanguage
2. https://bitbucket.org/jlahoda/jackpot30/wiki/RulesLanguageAdditionalDocs
3. https://bitbucket.org/jlahoda/jackpot30-demo-examples/src/0f396ef509cb5ae88933abf50e39442e8aea7923/src/META-INF/upgrade/j.l.Thread.sleep.hint?at=default
4. http://webcache.googleusercontent.com/search?q=cache:Bej5PnlBPH8J:netbeans.org/kb/docs/java/editor-inspect-transform.html+&cd=2&hl=en&ct=clnk&gl=ca (the NetBeans site was down while I was trying to access it)

Each of these documents only provide a small amount of information regarding the rules, but it was enough to get me going. The rules are divided into two main pieces, the pattern to match and the fix-pattern to apply. If you're only searching and not planning on fixing, you don't need the fix-pattern section, but if you run jackpot with "–apply" it will remove the lines, that's the default action. 

Pattern Matching

The first section, the pattern matching section, is used to tell the system what needs to be found for this rule. In our case we want to look for all methods that are annotated with @PostConstruct. Jackpot is not looking for the specific text "@PostConstruct" and if you set a rule with that text it wouldn't likely find anything. That's because it requires fully qualified class names (unless using custom imports, but let's not go there). This means we're really looking for @javax.annotation.PostConstruct. OK, that's easy enough, but we also need to look for the method, because we need to see if it has an exception too.

To look for the method we'll need two different types of variables. The different variable types are described in this document. The two types we need are:

This rule only catches PostConstruct methods that throw a single exception, you can use $exception$ to catch multiple exceptions, but it can't be used for the fix-pattern.

1. The "any expression" one, simply noted by using the $ at the beginning of the variable name. This type of variable will be used for the method name and the exception type that is thrown.
2. The "any number of statements" one, noted by a $ at the beginning an $; at the ned of the variable name. This type of variable will be used for the method body.

Using this information about variables, we'll end up with a pattern like

@javax.annotation.PostConstruct
public void $name() throws $exception { $stmts$; }
;;

Note the ";;" at the end of the rule. This deinfes the end of the rule and emans you can have multiple rules in one file. The rule we created is likely fine and will likely only catch what we're looking for anyway, but, the Exception we're trying to deal with specifically says checked exceptions. If we defined a method that "throws MyRuntimeException" in the definition for documentation purposes, we'd catch that method as well. So far we haven't seen a way to deal with that, so... introducing "Conditions."

Conditions can be added to the end of both sections, I'll explain how conditions work on fix-patterns later, but for now lets focus on the pattern for matching. A condition helps determine if the pattern actually does match by providing more validation capabilities. In our case we'll check the type of the "exception" variable. For more conditions see this document. In Java to check the type of an object against a class we use "instanceof," and in the Jackpot rule language we do the same. Conditions are defined at the end of the rule so our new rule looks like this

@javax.annotation.PostConstruct
public void $name() throws $exception { $stmts$; } :: $exception instanceof java.lang.Exception
;;

Now, we can run this rule right now using 

jackpot --hint-file /path/to/rule src/main/java/

This will list all occurrences that match our custom rule.

Fixing the Problem

To start the fix pattern of the rule you use the "=>" on a new line. When defining the fix you can reuse the variables that you defined in the pattern matching section of the hint. In our case, we'd just like to catch whatever exception is thrown and maybe print it out. Our fix for this pattern should look something like:

public void $name() {
    try{
       $stmts$;
    }catch($exception ex){
       ex.printStackTrace();
    }
}

which means our resulting rule will be:

@javax.annotation.PostConstruct
public void $name() throws $exception { $stmts$; } :: $exception instanceof java.lang.Exception
=>
public void $name() {
   try{
      $stmts$;
   }catch($exception ex){
      ex.printStackTrace();
   }
}
;;

I mentioned earlier that you can apply conditions to fix-patterns as well and I wasn't lying. The truth is that you can have many fixes and Jackpot will use the first applicable fix. This is not applicable in this scenario, but if we hop over to the Jackpot demos we can look at j.l.String.hint. This rule defines two different ways to fix the problem, one if the JDK is greater than or equal to JDK6 and one to use otherwise. Each fix gets started with the "=>" delimiter and have conditions appended to them with the "::" operator.

Conclusion

Jackpot is very powerful, and even more powerful when you consider the scripting capabilities. For example, we could write a script to download all of our repositories and crawl through them fixing new problems we have defined. Whether those new problems are based on upgrade woes as described above, or simply to deal with API changes we make within our code we can automatically refactor all of our code and not miss any required change.

Injecting power with the CDI Instance Interface - Part 2

In my last post I described a way to programmatically inject a specific instance via the Instance interface. In this post I'll use the Instance interface again, but this time to inject many instances of an Object.

To start, I'll discuss why you might want to do this. One of the most common reasons I've found is in a modular application where you include different modules into one larger application. When you do this things like installers or the menu system needs to be set-up for each module. In this example we'll look at providing a dynamic menu system.

Menu Classes

Our menu is not going to be fully featured, it actually won't do anything but provide categories and options. We're going to create the following simple classes

MenuCategory.java
    public class MenuCategory {
        private String name;
        ... Accessors and Equals and HashCode Here... 
    }

MenuOption.java
    public class MenuOption {
        private MenuCategory category;
        private String name;
        ... Accessors and Equals and HashCode Here...
    }

We'll also create a Menu class that we can add all of our Options. Adding them to this class will push them into a map that uses the category as the key. You'll also notice the @Alternative qualifier. This is so that when we inject the Menu later the CDI container won't be confused.

Menu.java
    @Alternative
    public class Menu {
        private Map<MenuCategory, List<MenuOption>> menuOptions;
    
        public Menu(){
            menuOptions = new HashMap<MenuCategory, List>(10);
        }
    
        public void addOption(MenuOption option){
            if(!menuOptions.containsKey(option.getCategory())){
                menuOptions.put(option.getCategory(), new ArrayList());
            }
            menuOptions.get(option.getCategory()).add(option);
        }

        public Map<MenuCategory, List<MenuOption>> getMenuOptions() {
            return menuOptions;
        }
    }

Menu Option Provider and Menu Producer

Next we need a common way to provide the Menu Options, and we have an interface to the rescue.

public interface MenuOptionProvider {
    List<MenuOption> getMenuOptions();
}

And now we can start the fun with instances, first we'll start by making our class

public class MenuProducer {
    ...
}

And next we'll inject our Instance interface.

    @Inject @Any Instance optionProviders;

Now that we have our Instance, instead of limiting it with a qualifier, like we did in the last post, we're going to use all Instances it can find. So, instead of using the select and get methods, we're going to take advantage of the fact that it is Iterable.

    @Produces public Menu produceMenu(){
        Menu menu = new Menu();
        for(MenuOptionProvider provider:optionProviders){
            for(MenuOption option:provider.getMenuOptions()){
                menu.addOption(option);
            }
        }
        return menu;
    }
}

And that's it, we now have our dynamic menu, if you want to see it at work implement the MenuProvider like this:

public class FileMenu implements MenuOptionProvider {

    @Override
    public List getMenuOptions() {
        MenuCategory category = new MenuCategory();
        category.setName("File");

        List options = new ArrayList();

        String[] optionNames = {"Open", "Save", "Close"};

        for (String optionName : optionNames) {
            MenuOption option = new MenuOption();
            option.setCategory(category);
            option.setName(optionName);
            options.add(option);
        }

        return options;

    }
}

Download the source of this example here.

And that concludes our example today. I hope you've enjoyed this post and that it has helped you in some way.

Injecting power with the CDI Instance Interface - Part 1

The Instance interface in CDI is a powerful tool for creating flexible libraries and applications. In this post I'll examine a couple different ways to use Instance in your application and gain the power of programmatic injection. First, lets talk about Instance a bit. For detailed informaiton, see the Weld Reference. Instance allows a programmer to decide, at run-time, via code, which Object should be injected. This is very powerful and can be used in a few different ways. You can use the Instance interface to select a specific instance, or you can use it to run through all instances. We'll look at both of these cases with some simple examples. The first example will be creating a Factory object and will only use one instance at a time. The second example, where we'll run through many instances will wait until another post.

The factory example

In this example we'll dynamically inject a single instance that will construct an Object for us. Using this method we can create a factory that is so easy to extend that you don't need to modify it to add functionality. In this example we'll have a couple different Objects we want to create in our factory, and for fun, they won't be related whatsoever.

FirstObject.java

    public class FirstObject{
        public String value;
    }

SecondObject.java

    public class SecondObject{
        public Integer intVal;
    }

OK, we have two really simple objects that share no inheritance, and we'll have our factory create both of them; but our factory is actually going to ship the work off-shore, it will out source the work to specialized shops that we'll call ObjectBuilder.

public interface ObjectBuilder {
    Object build(String value);
}

We're providing it with some extra information just so that we can see it do more than just create a new instance. These builders will be simple to write and here they are:

FirstObjectBuilder.java

    public class FirstObjectBuilder implements ObjectBuilder{
        public Object build(String value) {
            FirstObject object = new FirstObject();
            object.value = value;
            return object;
        }
    }

SecondObjectBuilder.java

    public class SecondObjectBuilder implements ObjectBuilder{
        public Object build(String value) {
            SecondObject object = new SecondObject();
            object.intVal = Integer.parseInt(value);
            return object;
        }
    }

Finally, before we get to making our factory we need a Qualifier. This qualifier will allow us to inject the specific ObjectBuilder that we want.

@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE,ElementType.METHOD,ElementType.FIELD,ElementType.PARAMETER})
public @interface BuilderFor {
    Class value();
}

We also need an Annotation Literal that we can manipulate during the CDI look-up.

public class BuilderForLiteral 
    extends AnnotationLiteral 
    implements BuilderFor{

    private Class clazz;

    public BuilderForLiteral(Class clazz) {
        this.clazz = clazz;
    }

    public Class value() {
        return clazz;
    }
}

The annotation literal provides a "physical" object that we can manipulate programmatically to represent what we're looking for.

Now that everything is in place, lets play with Instance and make our factory.

public class MyFactory{
    ...
}

The first thing we need in our factory is an Instance, so we'll inject that.

@Inject @Any Instance objectBuilderInstances;

Next, lets define our method for building:

public Object build(Class typeToBuild, String value){
    ...
}

Now, we're going to add a qualification to our Instance. This will limit the look-up to the specific ObjectBuilder we're looking for.

    BuilderForLiteral builderForQualifier = new BuilderForLiteral(typeToBuild);
    Instance qualifiedInstance 
        = objectBuilderInstances.select(builderForQualifier);

So, we now have a qualified Instance... great... we still don't have the object. But don't worry, that's the next step.

    ObjectBuilder builder = qualifiedInstance.get();

We've now injected our ObjectBuilder programmatically, the rest is pretty straight-forward.

    return builder.build(value);

And the Factory class altogether looks like this:

public class MyFactory {
    @Inject @Any Instance objectBuilderInstances;
    
    public Object build(Class typeToBuild, String value){
        BuilderForLiteral builderForQualifier = new BuilderForLiteral(typeToBuild);
        Instance qualifiedInstance 
                = objectBuilderInstances.select(builderForQualifier);
        ObjectBuilder builder = qualifiedInstance.get();
        return builder.build(value);
    }
}

This is a very powerful pattern that you can use throughout your applications, and this is just one example of using the Instance interface. Soon I'll post again about using the Instance interface to access multiple instances.

I once again want to say that this code is not production ready. For example, before we get the ObjectBuilder you should check to see if the Instance is unsatisfied or ambiguous and throw an Exception. You can use qualifiedInstance.isUnsatisfied() and qualifiedInstance.isAmbiguous() to do this.

I hope you've enjoyed this post and come back again later for more.

Injecting Configuration Values with CDI in a Java EE environment

Commonly while developing a web application there is need to configure an application differently per deployment. This configuration is generally handled by an external data source such as a properties or XML file. In this post I will examine a novel way of retrieving these configuration values using CDI injection.

My first thought about injecting Configuration values led me to inject a Configuration object and using this object I could access the configuration values. This is kind of clunky as I never really wanted the configuration object just the values. My code would end up looking like this:

@Inject Configuration conf;

private void useConfig(){
    System.out.println(conf.getValue("myConfig"));
}

But why can't I just inject the value directly. What I would like to do is this

@Inject @Config("myConfig") String myConfig;

Well, I'm not quite able to do that either but I can get pretty close to this. Ultimately, I was able to come up with a configuration library that allows me to inject configuration like this

@Inject @Config @ConfigName("myConfig") String myConfig;

So how did I do it? There's a few pieces to this puzzle. There is a CDI producer, a CDI qualifier, a plain old annotation and a data access object to retrieve the configuration values. Let's start with the qualifer.

Configuration Qualifier

A qualifier in CDI is a way to limit what will be injected. We will use this qualifier on String objects to allow our producer, which we'll come to later, to provide the values. A CDI Qualifier is actually just a regular annotation that is annotated with @Qualifier. Below is the qualifier we will use.

@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE,ElementType.METHOD,ElementType.FIELD,ElementType.PARAMETER})
public @interface Config {
}

Configuration Name Annotation

The configuration name allows us to inject the value by the name that we refer to them in the configuration data source. This annotation is quite simple and will contain a value, which will be the configuration name. If you already know about qualifiers, you may be asking why we have this annotation and why not include the name in the qualifier. The problem is that if you included the name in the qualifier you'd have to have a separate producer for every configuration value. This is because when CDI does it's look up for objects and producers that match the injection, the value of the qualifier is actually used.

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE,ElementType.METHOD,ElementType.FIELD,ElementType.PARAMETER})
public @interface ConfigName {
   public String value();
}

Configuration Data Access Object

We will need some way of accessing our configuration values, whether they're stored in a properties file, and XML file, a database, or somewhere else, we just need a common way to access them. To this end, we'll just describe an interface and you can provide an implementation.

public interface ConfigurationDao{
    String readValue(String name);
}

Now that all of that is out of the way, let's see the producer.

Configuration Producer

So, to start, we need a class that will produce the configuration values, lets call it ConfigurationProducer.

public class ConfigurationProducer {

Next, we'll need access to the configuration data, so let's inject that.

   @Inject ConfigurationDao dao;

And now the actual producer method. A producer method, as defined by the weld reference,

... is a method that acts as a source of bean instances.

More information on Producer Methods can be found in the Weld Reference. This needs to be annotated as a Producer and qualified with Config, the qualifier we made earlier.

   @Produces @Config public String getConfigurationValue(...){

Next, we need more details about where we're injecting, maybe information about the point of injection. Well, it just so happens that part of the CDI specification is that Producers can have access to the InjectionPoint.

   @Produces @Config public String getConfigurationValue(InjectionPoint p){

You can see the Weld Reference for more information on the Injection Point. With the injection point, we can actually access the ConfigName annotation.

       String valueName = null;
       for(Annotation annot:p.getAnnotated().getAnnotations()){
           if(annot instanceof ConfigName){
               log.debug("Found a config name annotation");
               ConfigName configNameAnnot = (ConfigName)annot;
               valueName = configNameAnnot.value();
           }
       }
 

And now that we've determined the Configuration Name all we have to do is look it up and return the value.

       return dao.readValue(valueName);

And that's it. Now, in any class (that supports injection) you can simply code

@Inject @Config @ConfigName("super.awesome.config") String configValue;

and the producer will handle the rest. On top of this, you have further options with the producer. You can add another annotation for default values. If this annotation is found and there is nothing in the configuration data source this value would be used. You can also have it provide types other than String, simply add another method to your producer that provides, lets say, an Integer instead of a String. There are many further options that you could tackle, you could even include multiple data sources with some simple tweaks.

Finally, i just want to point out that the code on this page is not production ready. The DAO should likely be able to throw an Exception if there is an error accessing the data source, and it might be wise for the Producer to throw an exception if the ConfigName annotation is not found, but, for simplicity's sake these things are not here.

Sapping up your Java Code - Part 2: Functionality

If you're coming in late to this series, you might want to first read Part 1, since you can't really do anything without it.

The JCoFunction

A JCoFunction is an object in Java that represents a Remote Function Call. That is, a function in SAP that is "remote enabled." If you don't know of any of these, ask your SAP Team, probably an ABAP developer, to provide one for you. Nothing on the Java side will work without a RFC in SAP. Here's how it works:

1. The Java program connects to the SAP system (see Part 1)
2. The Java Program requests the function from the SAP system.
3. The SAP system returns the meta-data of the function which is then turned into a JCoFunction object.
4. The Java program populates the fields of the JCoFunction
5. The Java program sends the function to SAP to be executed
6. SAP sends the data back from the SAP call and it gets shoved right back into the same object.
7. The Java program reads the information out of the JCoFunction and does whatever is needed.

This is essentially how SAP JCo works to communicate between systems. There are other things that can be done, like having SAP call out to a remote Java system, but that is outside the scope of this post. The code to do all of this is quite simple, requiring only a few objects, and the JCoDestination that we learned about in the previous post. I told you that previous post would be important.

In our demo, we'll try to connect to an SAP system and retrieve information about a customer. The Function in SAP will be named "Z_GET_CUSTOMER." If you're new to SAP, you might ask, why the 'Z?' The 'Z' actually means that the function that is being called was created by the customer, the customer being your company. In some rare cases, they also use 'Y' but that is not very common. The structure of the data will be similar to this:

Import Parameters (to be sent to SAP):
   CUSTOMER_ID     INT       An ID that identifies the Customer in SAP
Export Parameters (to be retrieved from SAP):
   STATUS          STRING    'S' is successful
   NAME            STRING
   LOCATION        STRING

As you can see from our example structure, we're not expecting this call to do much, but at least it's something.

Retrieving the Function from SAP

In step 2 listed above, the Java application request the function from SAP. How do we accomplish this? Well, the first thing we need is the JCoDestination object. The JCoDestination is your connection to SAP. From it, you have access to the JCoRepository through getRepository(). This is our first step. Our next step is to retrieve the function, and this couldn't be simpler. All we need to do is request the JCoFunction from the Repository through getFunction(String functionName).

Boiling that last paragraph down into a succinct hierarchy, you get this:

JCoDestination provides
   - JCoRepository provides
      - JCoFunction

So now the code. Generally, when I do this, I perform all actions in one line. This makes the line slightly more complex, but the repository is only used (in most cases) for providing functions, and can be disregarded right afterwards, so it makes little sense to store it in a variable, even temporarily.

JCoDestination _destination = ...;
JCoFunction f = _destination.getRepository().getFunction("Z_GET_CUSTOMER");

This provides the JCoFunction to you, but it also does quite a bit more behind the scenes. The repository actually caches the meta-data in the background. This means that the next time you request the same JCoFunction, it takes less time because the repository already has the meta-data required for creating the JCoFunction.

Populating the JCoFunction

Providing data to SAP, is quite a simple procedure. All you need to do is set values in the ImportParameterList. The ImportParameterList is actually a JCoParameterList, which is also used for export, and has one method for setting all the values you require. To use this method, you provide the name of the field within the Import Parameters, in our case "CUSTOMER_ID." So we provide it our Customer ID, we'll just say 1.

JCoParameterList imports = f.getImportParameterList();
imports.setValue("CUSTOMER_ID", 1);

Here we see, setting a value with an int. But an int is only one type of data we might want to provide. Sure, we could say that auto-boxing in Java 5 makes this possible by wrapping it as an Integer object and supposing that the setValue just accepts objects, but that's not what has happened here. The truth is, that the SAP Programmers have overloaded the setValue method to accept pretty much anything you can throw at it. This means that, even in Java 1.4, you can provide all your import parameters by using this one function.

Executing the call on the SAP System

Assuming that you have all your security settings are correct, making the call should be as simple as calling the execute method on the function. To call this method you need to provide the JCoDestination again, but this is a minor matter.

f.execute(_destination);

Done. Nothing else to do to execute the function. There is no return value, which in my opinion is unfortunate. I would have preferred the separation of input and output into different objects, like the way SQL Statements provide a ResultSet, but that is not how SAP designed the JCo Connector.

Reading the Information

All the information that SAP returned will be held within your original JCoFunction. You'll access them from ExportParameterList, and in some cases, TableParameterList. ExportParameterList, is where all your data should reside, as is what SAP recommends; but depending on the version of SAP, and the age of your SAP Programmers, that may not be true. TableParameterList was where lists of data would be returned, like if we wanted to return multiple customers, but at some point, SAP allowed import and export parameters to be tables as well.

So, reading from the ExportParameterList is as simple as this:

String status = f.getExportParameterList.getString("STATUS");
if("S".equals(status)){
    System.out.println("Customer Name is " + f.getExportParameterList.getString("NAME"));
}else{
    System.err.println("No customer found");
}

And that is all, in this post, I've shown how to use our previously established JCoDestination to retrieve and execute a function. As a side note, the JCo Connector version 3 was leaps and bounds above JCo 2. JCo 2 suffered from an API that didn't makes sense and complexity that was not required.

Sapping up your Java Code - Part 1: The connection

SAP is an Enterprise Resource Planning system which controls a large market share. In many big companies SAP is the backbone that provides and relates information from most, if not all, departments. Having so much data, being able to access that information from outside the system becomes imperative. At the company I work for, we use Adobe LiveCycle to create paperless workflows that send and retrieve information from the SAP system. This enables our users to have a clear, concise... pretty... interface into SAP for common tasks. We are currently supporting 1000 users with this method. (Also, it only uses up one license on the SAP side). So, how does it work...


Let's talk about setting up a connection to SAP. Well, the first thing that you need is the SAP JCo. This is not freely available to everyone, you need an account at the SAP Service Marketplace. This site very poorly laid out, and it might be hard to find... I'd include a link right to the page, but I'm not sure that it would be reliable. I recommend doing a search for "JCo Download" and then when that search fails to return anything, click on the "Documents" section. You will have multiple options available for download, Windows/Linux/etc... pick whichever one applies to you. Make sure you add the jar and dll/so to your classpath properly. This post only talks about JCo3, I had worked with JCo2 previously but it wasn't very reliable under large amounts of processing, so I'd recommend going straight to JCo3.

Wahoo... we have the SAP JCo, now, how do we connect? The easiest way is not very efficient at all. In fact, it's a pretty dumb way to do it. The first thing you'll do is create a Properties object in your java code. You'll then populate it with some data, and then you'll write it to a file with the extension ".jcoDestination." You then tell JCoDestinationManager to get the destination by providing it the file name without the extension, here, let me show you some code:

//Other Class definition up here
...

//Don't just throw the exception, do actual error handling, this is just for
//demo sake

private JCoDestination makeConnection() throws Exception {
//Make the properties object
Properties p = new Properties();
p.setProperty(DestinationDataProvider.JCO_ASHOST, host);
p.setProperty(DestinationDataProvider.JCO_SYSNR, systemNumber);
p.setProperty(DestinationDataProvider.JCO_CLIENT, client);
p.setProperty(DestinationDataProvider.JCO_USER, userName);
p.setProperty(DestinationDataProvider.JCO_PASSWD, password);
p.setProperty(DestinationDataProvider.JCO_LANG, language);
p.setProperty(DestinationDataProvider.JCO_POOL_CAPACITY, poolSize);
p.setProperty(DestinationDataProvider.JCO_PEAK_LIMIT, poolPeakSize);

//Write it out to a file... because file I/O is so nice
FileOutputStream fos = new FileOutputStream("sapconn.jcoConnection");
toProp().store(fos, "SAP System Connection");
fos.close();

//And read it back in...
JCoDestination destination = JCoDestinationManager
.getDestination("sapconn");
return destination;
}

As you can see it's a lot of pointless work to get the connection object. you could circumvent much of this by saving the first jcoDestination file that you create and re-using for every time you need to make your connection. Nonetheless, I think SAP made a very poor design choice when they limited the creation of "Destinations" to file I/O. There is an alternative to this method which is probably much more efficient, but also much more work. It involves implementing the DestinationDataProvider, registering it with the SAP JCo, and then creating the Destination.

The JCoDestination object is not quite a connection to SAP, but it's the closest thing you'll get. The JCoDestination is essentially a pointer to the connection pool. When you execute anything that needs to contact SAP it uses a JCoDestination to see exactly where it should be going. Now, let's talk about those properties we were just setting.

Table 1: SAP Configuration Properties

Property Name	Description
JCO_ASHOST	This is the host, or server, that is running your SAP instance.
JCO_SYSNR	The is the System Number for your SAP system. If you're strictly a Java programmer, you're probably best to just ask what this is from someone in your SAP team. As far as I can tell, this is generally used to segregate Development and Production systems.
JCO_CLIENT	Again, this is something you'll have to ask for. The client seems to be a way to segregate some functionality of the system. Such as, functionality for different plants.
JCO_USER	This is the user that your Java code will use to connect to the SAP system.
JCO_PASSWD	And this is the password related to that user.
JCO_LANG	The Language you want to use for the connection. I use EN, for English.
JCO_POOL_CAPACITY	This setting is for performance. It determines how many connections to SAP it will open at a time. You'll have to play with this setting, I'd start at 50, or 100 for moderate user load.
JCO_PEAK_LIMIT	On top of the capacity limit, there is a peak limit. The capacity is for normal operation, whereas the peak, is for those times when your server is being pounded by user requests. The peak limit will allow for extra connections to be created as needed, over the initial capacity. These connections will be destroyed as soon as they are not in use, where as the connections specified in the capacity setting, will remain. This setting should be something larger than the CAPACITY, but it is up to you to determine what value is best for your application.

And there you go, you're connected to SAP. From here you're going to need access to an RFC (Remote Function Call) if you really want to make the system do something. Coming soon will be a discussion on the JCoFunction object and how to use it.

Glassfish Startup Script for Linux Systems

I found a better resource for this than mine:
Run GlassFish V3 as a non-root Service

The above link covers Fedora/Ubuntu, but works for Red Hat as well.

Recently I was setting up a server that was to run Glassfish V3 on Red Hat EL5. The problem here is that Glassfish does not provide a start-up script for unix based systems. Also, the asadmin tool is unable to add Glassfish as a service like it does in Windows and Solaris, so where does that leave us, writing our own init script.

I will be honest, I'm not really a hardcore LINUX user, so there may be a better way to do this, but here's what I did.

In the {gfinstall}/glassfish/bin directory I created a new file, simply named glassfish. In this file I added the following script:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          glassfish
# Required-Start:    $network
# Required-Stop:
# Default-Start:     3 5
# Default-Stop:      0 1 2 6
# Short-Description: Glassfish Web Server
# Description:       Glassfish Web Server
### END INIT INFO


gfbin=/path/to/your/gfinstall/glassfish/bin


function usage
{
   echo "Must pass command line param start or stop"
}

while [ "$1" != "" ]; do
    case $1 in
        start )
               nohup $gfbin/startserv > /dev/null &
                                ;;
        stop )
               $gfbin/stopserv
                                ;;
        * )                     usage
                                exit 1
    esac
    shift
done

This script accepts the parameters start and stop, and that is all. No restart, no help, just start and stop. I did this because, it's really the only functionality you need, and it would have been a pain to try to do the restart (the stopserv command exits before the server has shut down).

Next, I linked this script into the /etc/init.d folder (using 'ln -s'). From that point, we can do a 'chkconfig glassfish on' and everything will be good to go. The information in the '### BEGIN INIT INFO' is what enables chkconfig to work. So don't remove it, you might want to change it though, depending on what you need.