Home/ Questions/Q 6537641
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T10:38:27+00:00

we are developing a set of components that can be used by our applications

  • 0

we are developing a set of components that can be used by our applications which currently run on Jboss 4.2.3.GA.

However, since JBoss 4 is quite old now, we’d like to migrate to JBoss 5+ (most likely JBoss 6.1).
In that case, we have a problems with our components containing stateless session beans annotated with the JBoss specific @PoolClass annotion, which has been renamed to @Pool as of JBoss 5.

As you can see, using that annotation in the components introduces a dependency not only on the application server but on specific versions as well. Thus I’d like to get rid of that annotation and use configuration via XML.

In that case, I’d like not to have to define a pool class per session bean, since almost all of them use the StrictMaxPool class with the same settings. If any session bean needs a different pool or different setting, it’s ok to provide a specific entry, but I’d rather not do that for the majority.

The default pool class is generally defined in ejb3-interceptors-aop.xl. However, that configuration applies to all applications deployed on that server.

What I’d like to do now, is to define a default pool class (with default settings) per application, if possible without adding anything specific to the session beans in our components (like the JBoss specific @AspectDomain annotation).

Is that possible and if yes, how?

I couldn’t manage to find any useful information yet, so I’d be glad if someone could point me in the right direction.

Edit: If you have information on how to do that in JBoss 5+, that would be great too, but JBoss 4 is of higher priority for now.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Seems like I found a solution:

    There’s a problem with JBoss AOP 1.5.6 which is used by JBoss 4.2.3.GA.
    Although there’s no bug filed it seems there is one preventing the scoped use of pool definitions (it looks like the source of the problem is an inverted if-condition 🙂 ).
    Upgrading to JBoss AOP 2.1.8 works like a charm.

    Here’s what I do:

    • Put a jboss-aop.xml file into the root of an ejb jar in the ear (we already have one that contains our persistence.xml).
    • In the jboss-aop.xml create a domain Stateless Bean that extends from the default Stateless Bean domain and inherits all bindings and definitions
    • Inside the extended domain override the pool class definition.
    • 0