Tag: jboss

Changing Default HSQLDB to Use Database in Jboss 4.2.3 for JMS

As we know jboss uses HSQLDB for the jms persistence to modify this to persist the JMS messages to user Database like mysql, oracle, etc. Following changes as to be made in jboss 4.2.3. We assume the Postgres Database for this purpose.

1. Delete the hsqldb-ds.xml from JBOSS_HOME/server/[instance]/deploy folder.

2. Copy the respective database related ds file from JBOSS_HOME/docs/examples/jca/*-ds.xml file to deploy folder of your [instance].

3. Change the jndi-name in *-ds.xml file to “DefaultDS“.

4. Delete hsqldb-jdbc2-service.xml file from JBOSS_HOME/server/[instance]/jms folder.

5. Copy the respective database persitence manager service xml file *-jdbc2-service.xml from JBOSS_HOME/docs/examples/jms to JBOSS_HOME/server/[instance]/deploy/jms folder.

6. Change the jndi name in the *-jdbc2-service.xml to “DefaultDS“, jboss.jca:service=DataSourceBinding,name=DefaultDS

7. Rename the hsqldb-jdbc-state-service.xml to respective database name *-jdbc-state-service.xml, its optional you can keep the file as it is.

8. Copy the respective database connector jar file to /JBOSS_HOME/server/[instance]/lib folder.

Now the configuration is modified for the jms persistence to user database and data will persist to jms_message table only when the huge number of jms are generated and its a temporary storage once the jms message is consumed it will deleted automatically from the jms_message table.

Hibernate ORM 4.1.0 Release

Hibernate ORM 4.1.0 has just been released. This release adds a few new features, as well as a bunch of improvements and bug fixes. Some features in particular include:

  • A new (actual) API for loading by natural identifiers. See mainly HHH-2879 and HHH-6974. Additionally, see my earlier post on this feature.
  • Addition of a TenantIdentifierResolver for use with multitenancy in getCurrentSession use cases. See HHH-6336
  • The ability to provide custom dirty handling. See HHH-3910 and HHH-6998

See the 4.1 release notes for the full details.

Additionally, quite a bit of work went into the documentation for this release. The JPA/HEM documentation has been completely consumed into Hibernate Reference Documentation and Hibernate Developer Guide. Mostly annotation/mapping information went into the former, while everything else went into the latter. Other efforts such as documenting multitenancy, services, etc when intoHibernate Developer Guide as well. The focus now, as we move ahead will be folding the information from Hibernate Reference Documentation into Hibernate Developer Guide.

3.6.10 was released today as well. It contains some bugfixes. Again, see the release notes for the details.

P.S. A quick note about the name Hibernate ORM. This refers to exactly what we previously called Hibernate Core. A brief history is that initially there was just Hibernate, but as the team started working on related projects (Hibernate Search, etc.) we agreed to refer to what had been just Hibernate as Hibernate Core. We recently decided that the core portion of the name was just a bad choice, as it doe not give any clue as to the intent. Hence Hibernate ORM.

Securing JBOSS 4.2.x JMX and Web Console, and JBoss Web Service

Always I want to protect the jmx-console and web-console on JBoss 4.2.x I look forward something that works effectivelly… let’s go.

After installing the JBOSS Application Server, the jmx console can be accessed by anybody without providing any username/password. This is a big security risk as anybody can perform changes though the jmx and web console. Setting up basic username/password security for the jboss jmx/web console can be accomplished by performing the following steps on the JBoss Application Server.

  • Edit $JBOSS_HOME/server/all/conf/props/jmx-console-users.properties to add jmx console users. Replace “all” with your JBOSS profile name. The syntax to add users is username=password. By default admin user would be available in this file with admin as password.
  • o provide admin privileges on jmx and web console to the newly created user, edit jmx-console-roles.properties file available in $JBOSS_HOME/server/all/conf/props folder and add username=JBossAdmin.
  • Edit $JBOSS_HOME/server/all/deploy/jmx-console.war/WEB-INF/jboss-web.xml file and uncomment the security domain as shown below.
<jboss-web>
  <security-domain>java:/jaas/jmx-console</security-domain>
</jboss-web>
  • Edit $JBOSS_HOME/server/all/deploy/jmx-console.war/WEB-INF/web.xml file and uncomment the security constraint as shown below.
<security-constraint>
  <web-resource-collection>
    <web-resource-name>HtmlAdaptor</web-resource-name>
    <description>An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application</description>
    <url-pattern>/*</url-pattern>
    <http-method>GET</http-method>
    <http-method>POST</http-method>
  </web-resource-collection>
  <auth-constraint>
    <role-name>JBossAdmin</role-name>
  </auth-constraint>
</security-constraint>
  • The location, path or name of the users and roles configuration files i.e. jmx-console-users.properties or jmx-console-roles.properties can be changed by editing $JBOSS_HOME/server/all/conf/login-config.xml file. Sample configuration is given below.
<application-policy name=”jmx-console”>
  <authentication>
    <login-module code=“org.jboss.security.auth.spi.UsersRolesLoginModule” flag=”required”>
      <module-option name=”usersProperties”>props/jmx-console-users.properties</module-option>
      <module-option name=”rolesProperties”>props/jmx-console-roles.properties</module-option>
    </login-module>
  </authentication>
</application-policy>
  • So, you still need protect the web-console on the same file; just copy jmx-console-users.properties and jmx-console-roles.properties to web-console-users.properties or web-console-roles.properties and modify it (take care to put props before the configuration files)
<application-policy name = "web-console">
   <authentication>
      <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
         flag = "required">
         <module-option name="usersProperties">props/web-console-users.properties</module-option>
         <module-option name="rolesProperties">props/web-console-roles.properties</module-option>
      </login-module>
   </authentication>
</application-policy>
  • Edit $JBOSS_HOME/server/all/deploy/management/console-mgr.sar/ web-console.war/WEB-INF/jboss-web.xml file and remove the comment of the security domain as shown below.
<jboss-web>
  <security-domain>java:/jaas/web-console</security-domain>
  <depends>jboss.admin:service=PluginManager</depends>
</jboss-web>
  • Edit $JBOSS_HOME/server/all/deploy/management/console-mgr.sar/ web-console.war/WEB-INF/web.xml file and remove the comment of the security constraint as shown below.
<security-constraint>
  <web-resource-collection>
    <web-resource-name>HtmlAdaptor</web-resource-name>
      <description>An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application
      </description>
      <url-pattern>/*</url-pattern>
      <http-method>GET</http-method>
      <http-method>POST</http-method>
  </web-resource-collection>
  <auth-constraint>
  <role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>
  • Finally, let protect JBoss web service console…
  • Edit $JBOSS_HOME/server/all/deploy/jbossws.sar/jbossws-context.war/WEB-INF/jboss-web.xml file and remove the comment of the security domain as shown below.
<jboss-web>
  <!-- A security domain that restricts access -->
  <security-domain>java:/jaas/JBossWS</security-domain>
  <context-root>jbossws</context-root>
</jboss-web>
  • Edit $JBOSS_HOME/server/all/deploy/jbossws.sar/jbossws-context.war/WEB-INF/web.xml file and remove the comment of the security constraint as shown below.
   <security-constraint>
     <web-resource-collection>
       <web-resource-name>ContextServlet</web-resource-name>
       <description>An example security config that only allows users with the
         role 'friend' to access the JBossWS console web application
       </description>
       <url-pattern>/*</url-pattern>
       <http-method>GET</http-method>
       <http-method>POST</http-method>
     </web-resource-collection>
     <auth-constraint>
       <role-name>friend</role-name>
     </auth-constraint>
   </security-constraint>
  • The location, path or name of the users and roles configuration files i.e. jbossws-users.properties or jbossws-roles.properties can be changed by editing $JBOSS_HOME/server/all/conf/login-config.xml file. Coment the option “unauthenticatedIdentity“. Sample configuration is given below.
    <application-policy name="JBossWS">
      <authentication>
        <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
          flag="required">
          <module-option name="usersProperties">props/jbossws-users.properties</module-option>
          <module-option name="rolesProperties">props/jbossws-roles.properties</module-option>
          <!-- module-option name="unauthenticatedIdentity">anonymous</module-option -->
        </login-module>
      </authentication>
    </application-policy>
  • Restart JBOSS.

Note: this post is result from cut/copy/insert/modify from some others posts provided from jboss community; it belongs to us. Thanks all!

JBoss: Application server baixa, mas as conexões continuam ativas no Oracle

Contribuição Marcos Esplugues

A conexão de fato não existirá mais desde que o application server esteja desligado; quem estaria ligado então? Só faltaria desligar a máquina e a conexão continuar… onde estará o problema.

Realmente não tem nada a ver com a aplicação. O Oracle mantém as sessões porque ele não sabe que o client caiu. Há um parâmetro que pode  ser configurado no arquivo sqlnet.ora que faz com que o Oracle, de tempos em tempos, verifique se o cliente está vivo. É o sqlnet_expire_time, configurado em segundos. Um valor muto baixo pode causar excesso de tráfego de rede. Um valor muito alto pode não ter serventia. A Oracle recomenda colocar 10 segundos neste parâmetro:

SQLNET.EXPIRE_TIME=10

É importante que isso não seja passado como uma recomendação ao cliente, mas como uma sugestão ao DBA do ambiente.