Where should resource bundles be located in JBOSS AS 7

[richyclarke]

Hi,

I am migrating an application from JBOSS AS 6 to AS 7 and have a question on resource bundles.

I have a properties file   'searchpoint.properties'  with many key=value pairs.

Under AS 6 this lived in the conf directory i.e. JBOSS_HOME/server/default/conf/searchpoint.properties

I access  these properties via the following code...

ResourceBundle propertiesFile = ResourceBundle.getBundle("searchpoint");

String returnValue = propertiesFile.getString(propertyName).trim();

My question is where should this file be located under AS 7? I have tried  JBOSS_HOME\standalone\configuration\searchpoint.properties but this doesn't work, I get the error... Can't find bundle for base name searchpoint, locale en_GB

Stack trace...

Caused by: org.jboss.weld.exceptions.CreationException: WELD-000079 Could not find the EJB in JNDI:  class com.vesey.searchpoint.session.SearchOrderBean$Proxy$_$$_Weld$Proxy$

        at org.jboss.weld.bean.SessionBean.create(SessionBean.java:357) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]

        at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:122) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]

        at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]

        at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:87) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]

        at com.vesey.searchpoint.session.SearchOrderBean$Proxy$_$$_WeldClientProxy.getPostcodeMatchesFound(SearchOrderBean$Proxy$_$$_WeldClientProxy.java) [classes:]

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]

        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]

        at javax.el.BeanELResolver.getValue(BeanELResolver.java:302) [jboss-el-api_2.2_spec-1.0.0.Final.jar:1.0.0.Final]

        at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]

        at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]

        at org.apache.el.parser.AstValue.getValue(AstValue.java:134) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]

        at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:187) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]

        at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:55) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]

        at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]

        ... 50 more

Caused by: java.lang.IllegalStateException: Failed to construct component instance

        at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:153)

        at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:76)

        at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent$1.createInstance(StatefulSessionComponent.java:92)

        at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent$1.createInstance(StatefulSessionComponent.java:89)

        at org.jboss.as.ejb3.component.stateful.ExpiringCache.create(ExpiringCache.java:143)

        at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:187)

        at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:60) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final]

        at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:60) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final]

        at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:483) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]

        at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:75) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]

        at org.jboss.weld.bean.SessionBean.create(SessionBean.java:340) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]

        ... 65 more

Caused by: java.util.MissingResourceException: Can't find bundle for base name searchpoint, locale en_GB

        at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1427) [:1.6.0_20]

        at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1250) [:1.6.0_20]

        at java.util.ResourceBundle.getBundle(ResourceBundle.java:705) [:1.6.0_20]

        at com.vesey.searchpoint.Utils.getStringProperty(Utils.java:355) [classes:]

        at com.vesey.searchpoint.session.SearchOrderBean.postConstruct(SearchOrderBean.java:208) [classes:]

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]

        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]

        at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:69)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

        at org.jboss.as.jpa.interceptor.SFSBCreateInterceptor.processInvocation(SFSBCreateInterceptor.java:53) [jboss-as-jpa-7.0.0.Final.jar:7.0.0.Final]

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

        at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:73) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final]

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

        at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

        at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:67)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

        at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:46) [jboss-as-jpa-7.0.0.Final.jar:7.0.0.Final]

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

        at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

        at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:151)

Thanks

Rich

[jaikiran]

In previous versions of AS, the JBOSS_HOME/server/<servername>/conf was available in the classpath. Hence the properties files in that location were available in the classpath of the application.

In AS7, to get those properties available in the classpath, package them within your application. For example, if you are deploying a .war then package those properties in .war/WEB-INF/classes folder. If you want those properties accessible to all components in a .ear, then package them at the root of some .jar and place that jar in .ear/lib folder.

[richyclarke]

Jaikiran,

Thanks for the quick response.

The problem is, the properties file holds variables that are specific to a particular deployment, so I can't bundle it with my war file.

For example, I have a 'filestore' property which holds the local folder location for storing some files. This varies across deployments i.e. my test, staging, development and backup servers all have different file paths for this 'filestore' property.

Hope thsi is clear.

Rich

[richyclarke]

Jaikiran,

I have resolved this by using a <system-properties> section within standalone.xml.

I now have..

     <system-properties>

        <property name="MyKey" value="Value 1"/>

        <property name="MyOtherKey" value="Value 2"/>

     </system-properties>

This works well, although I can only see a maximum of 5 values in the administration console (I have many more than 5 properties set).

Is this a valid and correct use of this  <system-properties> section?

Rich

[jaikiran]

It's fine to use system properties. But they are not the same as what ResourceBundle is meant for (which is what your code seems to be using).

[ssilvert]

Richard Clarke wrote:

This works well, although I can only see a maximum of 5 values in the administration console (I have many more than 5 properties set).

Opened jira for the console issue.  https://issues.jboss.org/browse/AS7-1315

Stan

[richyclarke]

Thanks Stan.

I am using System Properties now rather than a resource bundle, and accessing them using System.getProperty(propertyName);

Although this is working, I'm still not convinced (based on Jaikiran's comment) this is the best approach.

Any other comments would be welcome.

Regards

Rich

[ssilvert]

I was going to say that I agree with Jaikiran, but then I re-read what you were using it for.  Typically, resource bundles are used for accessing things that are displayed in the UI.  And it does it in a localized way.  But if that's not what you are using it for then System Properties might be appropriate.  The fact that you can add/remove/edit the props from the console is an added bonus.

Stan

[aupadhyaya2002]

Rich,

I am at the moment migrating to JBoss-4.2.3 to JBoss AS 7 and having the same issues. I have got 5 / 6 properies files used by the application and very difficult to go through system-properties route and at the same time will be happy not to bundle them in the ear. Could you please advise me, if I could deploy the resource bundles outside of my ear. Many thanks in advance.

Antar

[stianst]

If you don't mind tying it to JBoss you could place it in the standalone/configuration (or domain/configuration) and load it as a file using the system property "jboss.server.config.dir".

File f = File(System.getProperty("jboss.server.config.dir"), "my.properties");
Properties p = new Properties();
p.load(new FileInputStream());

If you want to use a ResourceBundle instead of Properties have a look at the last comment on http://stackoverflow.com/questions/1172424/how-to-load-a-resource-bundle-from-a-file-resource-in-java

[aupadhyaya2002]

Thanks Stian for the update. The only issue is this would involve code changes in many places which I am trying to avoid. In JBoss-4.2.3, all resource bundles are copied to server/default/conf/  location and then can referenced in the application using ResourceBundle.getBundle("fileName"). I was thinking if any other way to load these config files without touching the existing code.

Regards

Antar

[stianst]

A few ideas that might work:

* Add a config directory to the classpath by adding it to the Class-Path in the manifest.

* Create a module for configuration files, this would allow you to have a separate jar for configuration files. Then add this to the classpath of the EAR/JARs using either Dependency in the manifest or jboss-deployment-structure.xml

[shaun.kalley]

None of the suggestions I've seen posted here are particularly good.  They're all convoluted workarounds to a basic application need that JBoss AS 7 doesn't seem to want to support, namely the ability to define and maintain environment-specific configurations.  Many such configurations are defined as properties files, but many are more are not.  Configurations often take the form of, for example, XML files.  In any case, the mechanism for loading them into the application is the same, namely using ClassLoader.getResource() or ClassLoader.getResourceAsStream().  Even ResourceBundles use this mechanism under the hood.

So the issue here should not be about HOW to work around the lack of support for environment-specific configurations, but WHY we should be trying to work around it, especially when there is no workaround for non-properties-file configurations.

[bonigv]

I was able to export config files from a folder to the classpath by something similar to what Stian has outlined.  Create a module, put all the resources in it and use the module as a dependency from within the deployment.  Key is that there is no need for a module to be 'jar'.  A module can very well be a folder.  Hence the config files remain outside a jar, is in the application file system, are available on the classpath and the properties can be modified to suite deployment.

https://community.jboss.org/message/721458#721458

[prakrutipathik]

Hi Richard,

I am also facing this issue. I have seen a lot of workarounds in this post. Tried one of them and it was working for me, i.e adding the config path to the jboss classpath by creating a module.

Since these all were workarounds, so were you able to find the real solution to this?