11 Replies Latest reply: Jul 26, 2012 10:16 AM by pugsherpa RSS

JBoss AS7 and properties-service.xml

David Robison Newbie

I am currently using the properties-service.xml in JBoss 5.1.0.GA. I am looking to migrate to AS7 and I do not see the properties service. Does it exist in AS7? Is there another option in AS7?

  • 1. Re: JBoss AS7 and properties-service.xml
    jaikiran pai Master

    David Robison wrote:

     

    I am currently using the properties-service.xml in JBoss 5.1.0.GA. I am looking to migrate to AS7 and I do not see the properties service. Does it exist in AS7?

    It doesn't exist in AS7.

     

     

    David Robison wrote:

     

    Is there another option in AS7?

    See https://docs.jboss.org/author/display/AS71/Admin+Guide#AdminGuide-SystemProperties

  • 2. Re: JBoss AS7 and properties-service.xml
    pugsherpa Newbie

    This is a big problem for us too.  We had been using the properties-service.xml file to list properties files in the order that their properties should be loaded as System Properties available to the app.  Sometimes there would be a variable defined in two properties files, but the variable that became available as a system property for the app was the variable defined in the last property file listed in the "URLList".  We used it that way to handle differences in server locations.  Now I don't know if using the -P commandline option will work for us (which order will the properties files be loaded?  Can we list more than one property file at the command line?  If so, how?  Can the -P parameter be added as a JAVA_OPT argument?), but I guess we'll have to trial and error to find out.  The link about defining System Properties in standalone.xml, this is not a solution for us. 

     

    I can give a use case example.

    We have 100 deployment locations.  For each location, install one standalone instance of jboss to run the application.  In our properties file on each server (external to the jboss directory structure and external to the application's artifacts), there is a property called administrator.email defined in /apps/ourapp/ourapp.properties, which is listed in properties-service.xml UrlList.  All of our deployments, when jboss starts, it loads the name-value pairs listed in /apps/ourapp/ourapp.properties as system variables available to the app - and for 80 of the 100 locations, that default property value works just fine and doesn't have to be overridden.  But for 20 of the 100, we have to add another properties file to the properties-service.xml UrlList(eg:  /apps/ourapp/ourapp.properties, /apps/ourapp/exception.properties), and over-rode the system variable called administrator.email.  We were using the properties service to do this.  Our maven build knows how to filter the properies file list into the properties-service.xml UrlList file for the one-off cases.  The adminstrator.email property defined in exception.properties became the value available to the app because it over-rode the value defined in ourapp.properties

     

    Is there a way to solve this problem in the new Jboss 7? I've just used a simplified example here, but for our real deployment it is more than one variable.

     

    For 80 of 100 locations:

    <mbean code="org.jboss.varia.property.SystemPropertiesService" 
         name="jboss:type=Service,name=SystemProperties">
    
        <!-- 
           | Load properties from each of the given comma seperated URLs
        -->
        <attribute name="URLList">
          /apps/ourapp/ourapp.properties
        </attribute>
    
        <!-- 
           | Set raw properties file style properties.
        -->
        <attribute name="Properties">
        </attribute>
      </mbean>
    </server>
    

     

     

     

    For 20 of 100 locations:

     

    <mbean code="org.jboss.varia.property.SystemPropertiesService" 
         name="jboss:type=Service,name=SystemProperties">
    
        <!-- 
           | Load properties from each of the given comma seperated URLs
        -->
        <attribute name="URLList">
          /apps/ourapp/ourapp.properties,
          /apps/ourapp/exception.properties
        </attribute>
    
        <!-- 
           | Set raw properties file style properties.
        -->
        <attribute name="Properties">
        </attribute>
      </mbean>
    </server>
    

     

  • 3. Re: JBoss AS7 and properties-service.xml
    metallist Newbie

    Here's a helpful article on the subject: https://community.jboss.org/wiki/HowToPutAnExternalFileInTheClasspath
    Although the approach described there has a drawback: you'll have to redeploy your app every time you change your properties so that your app is aware of changes.

  • 4. Re: JBoss AS7 and properties-service.xml
    pugsherpa Newbie

    Now we feel like fools for having ripped out this very old and inflexible solution (getResourceAsStream) to go with the cleaner, less clunky method of using properties-service.xml.  We were grateful for Jboss making things easier for us.  Now we have no choice but to go back to the classpath and bootstrap loader nightmares that come with using getResourceAsStream.  I guess that makes it easier to switch application servers in the future.  We probably shouldn't have started depending on an app-server specific feature, even though it did make our lives easier.  If we use the getResourceAsStream approach, we have to add deployment-environment logic into the code base, which we hate to do.

  • 5. Re: JBoss AS7 and properties-service.xml
    metallist Newbie

    You know, you can still put your .properties file into your application archive, load properties with getResourceAsStream and thus avoid app-server dependent code. Although, I agree, properties-service.xml was rather easy to use. Still, you can write your own properties-service as an mbean and then work with it via the MBean server just like you did with the properties-service.xml.


  • 6. Re: JBoss AS7 and properties-service.xml
    pugsherpa Newbie

    Thanks Dmytro.  I know you're just trying to be helpful.  And I believe you're not responsible for the development of the new app server, so none of this is directed at you personally.

     

    I think it's a terrible business model to rip out useful functionality and then when asked for work-arounds the proposed solution is to "write it yourself".  I know it's not the first or the last time that a product will make such outlandish demands of its users.

     

    I just want it noted by Jboss that this is not one of those features that people don't care about.  This one feature may be the reason we don't upgrade to Jboss 7 - with the work-around being to wait until a version of Jboss that re-introduces the properties-service-like functionality, or to switch to another app server all together.  It is a shame because there are really good features in the new versions that we'd like to take advantage of. 

     

    Hopefully they'll reconsider support for the properties service.  It was one of the more elegant solutions that we loved about the app server.

  • 7. Re: JBoss AS7 and properties-service.xml
    Justin Bertram Master

    I think it's a terrible business model to rip out useful functionality and then when asked for work-arounds the proposed solution is to "write it yourself".  I know it's not the first or the last time that a product will make such outlandish demands of its users.

    To be fair, I don't think your specific use-case is terribly common or even part of the conscious design of the previous properties service.  I believe the functionality you've used to this point has been the result of an implementation detail.  That said, I think you're use-case is legitimate, worth supporting, and likely will be supported in the future as the AS7 system-properties subsystem improves.  I don't see any open JIRAs requesting this functionality.  Please open one here outlining exactly what you need and respond here with the link.

     

    Furthermore, I don't see anywhere in this thread where any of the authors of JBoss AS 7 have proposed that you "write it yourself" (althlough I don't think that would be such an "outlandish" demand as you suggest since AS 7 is indeed open source and patches aren't hard to submit via github).

     

    Lastly, ripping out useful functionality isn't part of any model here - business or otherwise - and frankly I don't see how anybody could legitimately come to that conclusion.  AS 7 is a radical departure from the previous containers (dating back to the first incarnations of JBoss AS).  The previous kernel and accompanying services have been around so long that they've been adopted for uses which the original designers never imagined and have hitherto been unaware.  Hopefully you can appreciate that and work with us to make 7 the best version of JBoss AS ever.

  • 8. Re: JBoss AS7 and properties-service.xml
    pugsherpa Newbie

    Justin Bertram wrote:

     

     

    Furthermore, I don't see anywhere in this thread where any of the authors of JBoss AS 7 have proposed that you "write it yourself" (althlough I don't think that would be such an "outlandish" demand as you suggest since AS 7 is indeed open source and patches aren't hard to submit via github).

    Sorry, here's the link where a contributor (jaikiran pai) suggested that we "roll our own": https://community.jboss.org/message/645418#645418

    I've seen this suggestion a few places in the discussion forum directed towards other people who are trying to figure out what to do with their properties-service files from previous Jboss versions.

     

    While I do appreciate the amount of work that gets contributed by open-source developers who don't get paid for the contributions they make, the community of IT developers for profit have come to depend on Jboss as a first-class open source option that we can turn to and know it works well.  I do not intend to contribute  functionality that is already implemented in a previous version of Jboss.  I'm busy - I've been tasked to upgrade our app to Jboss 7 - I thought it'd be fairly straight forward, but I'm finding that I may miss my deadline or have to tell them that it's not a feasible option at this time.  I do plan to submit a JIRA ticket, thanks for the suggestion.  I do like a lot of the features I see in the new Jboss 7.

  • 9. Re: JBoss AS7 and properties-service.xml
    Justin Bertram Master

    It would be worth trying to specify multiple property files on the command line to see if that accomplishes your goal.  For example:

     

      ./standalone.sh --properties=1.properties --properties=2.properties

     

    The command-line parsing logic will load each file sequentially and load the contents into the System properties so it looks like the latter files will override the values specified in the previous ones.

  • 10. Re: JBoss AS7 and properties-service.xml
    pugsherpa Newbie

    I think this might work.  I'll do a little prototype test and report back. 

  • 11. Re: JBoss AS7 and properties-service.xml
    pugsherpa Newbie

    It does work the way we expect it to.  Great.  Thanks!