Access WebSphere Variables from Code - Websphere

This is a discussion on Access WebSphere Variables from Code - Websphere ; A client asked about a specific requirement they have where the name of the file they need to access is different on each physical machine (it is a keystore certificate they use to access another system and it is tied ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Access WebSphere Variables from Code

  1. Access WebSphere Variables from Code

    A client asked about a specific requirement they have where the name of the file they need to access is different on each physical machine (it is a keystore certificate they use to access another system and it is tied to the hostname and NIC). They want to deploy this application (in an EAR file) to a cluster that spans multiple machines.



    We need a way where we can provide the name of the file as something that will change on every machine but deploy the same code. This way they can release one EAR file that is deployed to the entire cluster instead of different EAR files for the servers on each machine.



    One way I thought about doing this is by using WebSphere Variables. This way the name of the file that should be used is configured on each Node and the code to locate the value will always be the same.



    Does anyone have ideas on if this would be possible? I would be interested in J2EE standard ways this might be done as well as any WebSphere APIs that could do this. I know using WebSphere APIs would not be ideal but it would help evaluate options.



    Of course any other suggestion (besides WebSphere Variables) about how to do this as an administrative property as opposed to something configured in the EAR itself is appreciated.

  2. Re: Access WebSphere Variables from Code

    > We need a way where we can provide the name of the file as something that
    > will change on every machine


    I suppose this file will be created and deployed separately from the EAR.

    So, why a different filename and not the same filename but with different
    content on every machine ?

    To avoid bothering with the exact location of the file, you can define a
    Shared Library containing the file entry and associate the library with the
    application, so it's automatically on the classpath and you can look it up
    as a regular classpath entry.


  3. Re: Access WebSphere Variables from Code

    You can base it on WebSphere variables with code similar to the following:



    try


    {


    AdminService adminService = AdminServiceFactory.getAdminService();


    ObjectName queryName = new ObjectName
    ( "WebSphere:*,type=AdminOperations" );


    Set objs = adminService.queryNames( queryName, null );


    if ( !objs.isEmpty() )


    {


    ObjectName thisObj = (ObjectName)objs.iterator().next();


    String opName = "expandVariable";


    String signature[] = { "java.lang.String" };


    String params[] = {"${MY_VARIABLE}" } ;


    Object retVal = adminService.invoke( thisObj, opName, params, signature );


    System.out.println( retVal );


    }


    } catch (MalformedObjectNameException e) {


    e.printStackTrace();


    } catch (InstanceNotFoundException e) {


    e.printStackTrace();


    } catch (MBeanException e) {


    e.printStackTrace();


    } catch (ReflectionException e) {


    e.printStackTrace();


    }


    Unfortunately, using that approach (IIRC) requires special permissions.


    The better choice is to bind a value into the JNDI name space at the desired level. Then, your program can look up the value using a JNDI lookup.

  4. Re: Access WebSphere Variables from Code

    Thanks for the suggestions so far. The AdminService code looks complete and I'll try that solution if it comes to it but I'll probably try standard approaches first.



    Unfortunately I don't have a whole lot of information on the situation since I only spoke briefly with the person that asked the question. I guess I'm assuming somewhat that if it were as easy as using the same file name on each machine this would not be an issue they were having. They had talked about having all of these keystore files in a shared directory so it sounded like they had management of these that was separate from the application itself.



    The shared library option is a very interesting idea and I will explore that further. This would have the node scope that I think is important for this but not involve JNDI which just doesn't seem to feel right for this.



    Thanks,

    Stuart

+ Reply to Thread