Topic
  • 5 replies
  • Latest Post - ‏2013-12-17T19:26:27Z by 5CK5
BFR3_Peter_Thorson
BFR3_Peter_Thorson
5 Posts

Pinned topic URL Resource Configuration for Liberty

‏2013-05-24T21:00:55Z |

This article describes a method to make Property files available using URL Resources:

http://www.ibm.com/developerworks/websphere/library/techarticles/0502_botzum/0502_botzum.html

The technique is for an older version of WAS. Is there anything similar supported for Liberty?

I have read 

 

But am unsure how the URL technique could be replicated in Liberty.

Thank you for your help.

  • JoeChacko
    JoeChacko
    15 Posts
    ACCEPTED ANSWER

    Re: URL Resource Configuration for Liberty

    ‏2013-05-31T11:54:34Z  

    Hi Peter,

    Good question!  Liberty has no exact equivalent - but do please request it if it is a feature you would like to see.  I can suggest some alternatives, which will work straight away.

     

    A) Using JNDI entries in server.xml to specify config properties

    This involves looking up config values directly from JNDI, and editing them in server.xml.  Jacek Lakowski's article on this also shows how to use an @Resource annotation for the JNDI lookup.

     

    B) Using a JNDI entry in server.xml to locate the config resource

    You can bind the properties file URL into JNDI as a String.  You would need some config like this:

    <jndiEntry jndiName="com/acme/foo/config.url" value="http://www.acme.com/foo/config.properties"/>

    And the Acme Foo application would need code like this to retrieve the properties (plus some exception handling):

    String address = (String) new InitialContext().lookup("com/acme/foo/config.url");
    URL url = new URL(address);
    Properties props = new Properties();
    props.load(url.openConnection().getInputStream());

     

    C) Using an exploded app class path location

    Alternatively, you could just run the app exploded, by unzipping it into a folder with the name of the original file, e.g.:

    cd wlp/usr/servers/defaultServer/apps
    mv foo.war foo.zip
    unzip foo.zip -d foo.war

    Then you would have direct access to edit the resources in WEB-INF/classes.  

     

    D) Using a library folder class path location (8.5.5 onwards)

    If you are using the 8.5.5 beta, you could also add a folder to the class path of your application, like so:

    <library id="configResources">
        <folder="${server.config.dir}/config" />
    </library>

    <application location="foo.war">
        <classloader privateLibraryRef="configResources" />
    </application>

     

    Where to locate class loader resources on the file system

    For options C and D, remember that the resource is looked up within the location, just like a class would be, so for the following Java code (imports and exception handling omitted):

    p​ackage com.acme.foo;

    public class FooServlet extends HttpServlet {
        private final Properties config;
        public FooServlet() {
            InputStream is = getClass().getResourceAsStream("config.properties");
            config = new Properties();        config.load(is);
        }
    }

    the actual resource files would be found in a package-level sub directory, as follows.

    • For the exploded WAR:
      • wlp/usr/servers/defaultServer/apps/foo.war/WEB-INF/classes/com/acme/foo/config.properties

    • For the library folder:
      • wlp/usr/servers/defaultServer/config/com/acme/foo/config.properties

    ​See how the location of the resource is in a sub-directory of the class path location in each case? This baffles many people who expect resource files to be entered on the class path directly, so I have called it out explicitly to avoid any confusion.

    -- Joe Chacko, Liberty Profile development team

  • JoeChacko
    JoeChacko
    15 Posts

    Re: URL Resource Configuration for Liberty

    ‏2013-05-31T11:54:34Z  

    Hi Peter,

    Good question!  Liberty has no exact equivalent - but do please request it if it is a feature you would like to see.  I can suggest some alternatives, which will work straight away.

     

    A) Using JNDI entries in server.xml to specify config properties

    This involves looking up config values directly from JNDI, and editing them in server.xml.  Jacek Lakowski's article on this also shows how to use an @Resource annotation for the JNDI lookup.

     

    B) Using a JNDI entry in server.xml to locate the config resource

    You can bind the properties file URL into JNDI as a String.  You would need some config like this:

    <jndiEntry jndiName="com/acme/foo/config.url" value="http://www.acme.com/foo/config.properties"/>

    And the Acme Foo application would need code like this to retrieve the properties (plus some exception handling):

    String address = (String) new InitialContext().lookup("com/acme/foo/config.url");
    URL url = new URL(address);
    Properties props = new Properties();
    props.load(url.openConnection().getInputStream());

     

    C) Using an exploded app class path location

    Alternatively, you could just run the app exploded, by unzipping it into a folder with the name of the original file, e.g.:

    cd wlp/usr/servers/defaultServer/apps
    mv foo.war foo.zip
    unzip foo.zip -d foo.war

    Then you would have direct access to edit the resources in WEB-INF/classes.  

     

    D) Using a library folder class path location (8.5.5 onwards)

    If you are using the 8.5.5 beta, you could also add a folder to the class path of your application, like so:

    <library id="configResources">
        <folder="${server.config.dir}/config" />
    </library>

    <application location="foo.war">
        <classloader privateLibraryRef="configResources" />
    </application>

     

    Where to locate class loader resources on the file system

    For options C and D, remember that the resource is looked up within the location, just like a class would be, so for the following Java code (imports and exception handling omitted):

    p​ackage com.acme.foo;

    public class FooServlet extends HttpServlet {
        private final Properties config;
        public FooServlet() {
            InputStream is = getClass().getResourceAsStream("config.properties");
            config = new Properties();        config.load(is);
        }
    }

    the actual resource files would be found in a package-level sub directory, as follows.

    • For the exploded WAR:
      • wlp/usr/servers/defaultServer/apps/foo.war/WEB-INF/classes/com/acme/foo/config.properties

    • For the library folder:
      • wlp/usr/servers/defaultServer/config/com/acme/foo/config.properties

    ​See how the location of the resource is in a sub-directory of the class path location in each case? This baffles many people who expect resource files to be entered on the class path directly, so I have called it out explicitly to avoid any confusion.

    -- Joe Chacko, Liberty Profile development team

  • 5CK5
    5CK5
    6 Posts

    Feature Request

    ‏2013-09-26T12:53:05Z  
    • JoeChacko
    • ‏2013-05-31T11:54:34Z

    Hi Peter,

    Good question!  Liberty has no exact equivalent - but do please request it if it is a feature you would like to see.  I can suggest some alternatives, which will work straight away.

     

    A) Using JNDI entries in server.xml to specify config properties

    This involves looking up config values directly from JNDI, and editing them in server.xml.  Jacek Lakowski's article on this also shows how to use an @Resource annotation for the JNDI lookup.

     

    B) Using a JNDI entry in server.xml to locate the config resource

    You can bind the properties file URL into JNDI as a String.  You would need some config like this:

    <jndiEntry jndiName="com/acme/foo/config.url" value="http://www.acme.com/foo/config.properties"/>

    And the Acme Foo application would need code like this to retrieve the properties (plus some exception handling):

    String address = (String) new InitialContext().lookup("com/acme/foo/config.url");
    URL url = new URL(address);
    Properties props = new Properties();
    props.load(url.openConnection().getInputStream());

     

    C) Using an exploded app class path location

    Alternatively, you could just run the app exploded, by unzipping it into a folder with the name of the original file, e.g.:

    cd wlp/usr/servers/defaultServer/apps
    mv foo.war foo.zip
    unzip foo.zip -d foo.war

    Then you would have direct access to edit the resources in WEB-INF/classes.  

     

    D) Using a library folder class path location (8.5.5 onwards)

    If you are using the 8.5.5 beta, you could also add a folder to the class path of your application, like so:

    <library id="configResources">
        <folder="${server.config.dir}/config" />
    </library>

    <application location="foo.war">
        <classloader privateLibraryRef="configResources" />
    </application>

     

    Where to locate class loader resources on the file system

    For options C and D, remember that the resource is looked up within the location, just like a class would be, so for the following Java code (imports and exception handling omitted):

    p​ackage com.acme.foo;

    public class FooServlet extends HttpServlet {
        private final Properties config;
        public FooServlet() {
            InputStream is = getClass().getResourceAsStream("config.properties");
            config = new Properties();        config.load(is);
        }
    }

    the actual resource files would be found in a package-level sub directory, as follows.

    • For the exploded WAR:
      • wlp/usr/servers/defaultServer/apps/foo.war/WEB-INF/classes/com/acme/foo/config.properties

    • For the library folder:
      • wlp/usr/servers/defaultServer/config/com/acme/foo/config.properties

    ​See how the location of the resource is in a sub-directory of the class path location in each case? This baffles many people who expect resource files to be entered on the class path directly, so I have called it out explicitly to avoid any confusion.

    -- Joe Chacko, Liberty Profile development team

    Hi Joe,

    I would like to request the feature that would allow to register and use custom URL Resource Providers. Although the options that you described are useful in some cases, the use of URL Resource Provider is more convenient sometimes. This would also help with migrating applications from older WAS versions (or other app servers) to Liberty Profile.

    It also would be great if Liberty Profile provided out of the box implementation that could access configuration parameters as java.util.Properties. Something like org.glassfish.resources.custom.factory.PropertiesFactory that GlassFish provides for ages:

    <custom-resource res-type="java.util.Properties" jndi-name="config"
    factory-class="org.glassfish.resources.custom.factory.PropertiesFactory">
         <property name="property" value="value"></property>
    </custom-resource>

    Thank you.

  • Alasdair
    Alasdair
    55 Posts

    Re: Feature Request

    ‏2013-09-26T13:06:46Z  
    • 5CK5
    • ‏2013-09-26T12:53:05Z

    Hi Joe,

    I would like to request the feature that would allow to register and use custom URL Resource Providers. Although the options that you described are useful in some cases, the use of URL Resource Provider is more convenient sometimes. This would also help with migrating applications from older WAS versions (or other app servers) to Liberty Profile.

    It also would be great if Liberty Profile provided out of the box implementation that could access configuration parameters as java.util.Properties. Something like org.glassfish.resources.custom.factory.PropertiesFactory that GlassFish provides for ages:

    <custom-resource res-type="java.util.Properties" jndi-name="config"
    factory-class="org.glassfish.resources.custom.factory.PropertiesFactory">
         <property name="property" value="value"></property>
    </custom-resource>

    Thank you.

    Hi,

    The best thing to do would be to submit your request using the Request for Enhancements tool. This will allow you to track the progress of your requirement and allow other people to vote for it.

    Thanks
    Alasdair

  • 5CK5
    5CK5
    6 Posts

    Re: Feature Request

    ‏2013-09-26T13:11:19Z  
    • Alasdair
    • ‏2013-09-26T13:06:46Z

    Hi,

    The best thing to do would be to submit your request using the Request for Enhancements tool. This will allow you to track the progress of your requirement and allow other people to vote for it.

    Thanks
    Alasdair

    I will do that. Thanks.

  • 5CK5
    5CK5
    6 Posts

    Re: Feature Request

    ‏2013-12-17T19:26:27Z  
    • Alasdair
    • ‏2013-09-26T13:06:46Z

    Hi,

    The best thing to do would be to submit your request using the Request for Enhancements tool. This will allow you to track the progress of your requirement and allow other people to vote for it.

    Thanks
    Alasdair

    Request filed - http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=42819