Hi Davide,

It does appear to be a bug with TS, please can you share your configuration file for TS so I can take a look, particularly the parts related to the JDBC store? The propertyprefix is used to help configure the system, setting it incorrectly will result in unexpected behavior.

Tom

The no PropertyPrefix found thing is indeed a bug. When the bean property handling was initially written, that requirement was added as a safeguard to ensure all pre-existing properties in the old format remained valid. However, we have now moved on and some newly added properties have no legacy equivalent representation, so the global check no longer makes sense.  Whilst adding a bogus prefix is a valid workaround, IMO the proper solution is to remove the presence check from BeanPopulator. Thanks for letting us know, I'll sort it for the next release.

Orthogonal to that, some bean properties that previously used type name i.e. String arguments, now use pre-instantiated type instance arguments, whilst a new setter of the form 'fooClassName' takes the type name if you prefer.  You probably need RecoveryEnvironmentBean.expiryScannerClassNames

Hi Jonathan,

I'm a coworker of Davide and I'm re-checking his work and going further in the JBossTS 4.11.0 => 4.15.0 upgrade in our web application.

Here, I quite understood the issue, but I have still some dobuts.

First of all, let's see our original configuration of the object store in jbossts-properties.xml:

<entry key="CoordinatorEnvironmentBean.actionStore">com.arjuna.ats.internal.arjuna.objectstore.JDBCActionStore</entry>

<entry key="ObjectStoreEnvironmentBean.objectStoreType">JDBCStore"</entry>

<entry key="ObjectStoreEnvironmentBean.jdbcTxDbAccess">com.cardinis.cardinis.support.io.server.db.h2_accessor</entry>

<entry key="ObjectStoreEnvironmentBean.jdbcUserDbAccess">com.cardinis.cardinis.support.io.server.db.h2_accessor</entry>

<entry key="ObjectStoreEnvironmentBean.jdbcPoolSizeMaximum">20</entry>

I need now to convert this in order to make it work with 4.15.0. I see that  with issue https://issues.jboss.org/browse/JBTM-788 you changed the init/config of the object store, but the ArjunaCore-4.15.0-ArjunaCore_Development_Guide-en-US documentation has not been updated to reflect the changes (should I file an issue?) . So, the first thing to change is that com.arjuna.ats.internal.arjuna.objectstore.JDBCActionStore has now become com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCActionStore. However, troubles are on the following. The ObjectStoreEnvironmentBean now is free of configuration properties related to the JDBC implementation. These properties are now handled by the JDBCStoreEnvironmentBean class. However, from JBTM-788 I also understood the fact that environment beans now can have a name (so you can have more than one configuration for the same environment bean in the jbossts-properties.xml file) and that the StoreManager now uses a specific environment bean instance to initialize the object store. So, the first question is: which JDBCStoreEnvironmentBean should I configure in my jbossts-properties.xml file to make JBossTS use a JDBCActionStore? The default (unnamed one)? If so, it should be enough to rename those  ObjectStoreEnvironmentBean.jdbcXYZ entries to JDBCStoreEnvironmentBean.jdbcXYZ ones (maybe adding "ClassName" suffixes if needed), shouldn't it?

But as I understand the specific problem described here, this still wouldn't work because JDBCStoreEnvironmentBean class has no @PropertyPrefix annotation... So, how should I change my jbossts-properties.xml to make the whole thing work?

Thanks in advance,

Mauro.

Investigating further, it seems like:

- the CoordinatorEnvironmentBean.actionStore property is not used anymore, so I think it should be deleted to avoid confusion...

- that was completely replaced by ObjectStoreEnvironmentBean.objectStoreType, which now wants a full class name, instead of just a "symbolic name" (as it was previously and the Javadoc still says...); however, in this case it isn't clear to me what is the actual difference between using com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCActionStore or a com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore here...

- the StoreManager now seems to initialize the ObjectStore with the default (unnamed) ObjectStoreEnvironmentBean

- the same name (null in this case) is used to create the JDBCStoreEnvironmentBean to be passed to the ObjectStoreAPI implementation constructor (in my case: JDBCActionStore); so the JDBCStoreEnvironmentBean used to configure my action store must be the default (unnamed) one

Now, when my code needs to access the  JDBCStoreEnvironmentBean instance used to configure the action store, is BeanPopulator.getNamedInstance(JDBCStoreEnvironmentBean.class, null) the right way to get it? In fact, com.arjuna.ats.arjuna.common.arjPropertyManager does not provide a corresponding getter, but I can't find another way... However, it sounds too much dangerous to me to use the BeanPopulator directly, because this binds my code to the fact that the right JDBCStoreEnvironmentBean instance I need is the default one (i.e.: there's no interface that hides this implementation detail, doing some sort of IoC...).

Please note that I need to get to the JDBCStoreEnvironmentBean instance because I'm writing an accessor which is need to make the ObjectStore operate with an H2 database.

BTW: to add H2 support for the ObjectStore implementation, we needed to write our com.arjuna.ats.internal.arjuna.objectstore.jdbc.h2_driver class. Is it still mandatory for this class to be in the com.arjuna.ats.internal.arjuna.objectstore.jdbc package?

Thanks in advance,

Mauro.

> - the CoordinatorEnvironmentBean.actionStore property is not used anymore, so I think it should be deleted to avoid confusion...

yeah, then we can upset the people whose build we broke instead :-)

> - that was completely replaced by ObjectStoreEnvironmentBean.objectStoreType, which now wants a full class name, instead of just a "symbolic name" (as it was previously and the Javadoc still says...);

oops. you're right, the javadoc is wrong.

> however, in this case it isn't clear to me what is the actual difference between using com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCActionStore or a com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore here.

you probably want the action store version.

> - the StoreManager now seems to initialize the ObjectStore with the default (unnamed) ObjectStoreEnvironmentBean

StoreManager actually sets up three distinct stores for different purposes. The action store uses the default bean name, whilst the others use 'stateStore' and 'communicationStore'.

> - the same name (null in this case) is used to create the JDBCStoreEnvironmentBean to be passed to the ObjectStoreAPI implementation constructor (in my case: JDBCActionStore);

right. the name for any secondary beans needed by the primary bean is just passed through [ClassloadingUtility.loadAndInstantiateClass]. In this instance that's the default name. If you were setting up e.g the state store instead then you'd use 'stateStore' to quality the JDBCStoreEnvironmentBean instance you wanted.

> Now, when my code needs to access the  JDBCStoreEnvironmentBean instance used to configure the action store, is BeanPopulator.getNamedInstance(JDBCStoreEnvironmentBean.class, null) the right way to get it?

hmm, that's a slightly weird question. In general you don't mix the config file way of wiring things up with the programmatic way. In short, you should not need to access it at all in java. If you really do, that is indeed the right way. You'll need to do it really early in the bootstrap though, otherwise the system will already have been initialized using the default values on that bean instance before you have a chance to change them.

> I need to get to the JDBCStoreEnvironmentBean instance because I'm writing an accessor

So you call 'setJDBCAccess' directly in java?  The store initialization should call jdbcStoreEnvironmentBean.getJdbcUserDbAccess() and pass that value to the setter for you, so why not set JDBCStoreEnvironmentBean.jdbcUserDbAccessClassName=your.class.name in the properties file instead?  Alternatively if you want to go the programmatic route you can instantiate the whole object chain yourself - create a JDBCStoreEnvironmentBean, create a JDBCActionStore using it, then create a StoreManager using that.  Which is basically what a bean wiring framework would do.

Hi Jonathan!

Jonathan Halliday ha scritto:

 

> - the StoreManager now seems to initialize the ObjectStore with the default (unnamed) ObjectStoreEnvironmentBean

 

StoreManager actually sets up three distinct stores for different purposes. The action store uses the default bean name, whilst the others use 'stateStore' and 'communicationStore'.

These stores must be something new... I'll try to look at the documentation to know if it's something useful or not in our case.

Jonathan Halliday ha scritto:

 

> - the CoordinatorEnvironmentBean.actionStore property is not used anymore, so I think it should be deleted to avoid confusion...

 

yeah, then we can upset the people whose build we broke instead :-).

Ahem... you already broke the build by changing the JDBC action store configuration mechanism, so I don't think removing that useless option would really make any difference... On the contrary, it would avoid confusion ;-)

Jonathan Halliday ha scritto:

 

> I need to get to the JDBCStoreEnvironmentBean instance because I'm writing an accessor

 

So you call 'setJDBCAccess' directly in java?  The store initialization should call jdbcStoreEnvironmentBean.getJdbcUserDbAccess() and pass that value to the setter for you, so why not set JDBCStoreEnvironmentBean.jdbcUserDbAccessClassName=your.class.name in the properties file instead?  Alternatively if you want to go the programmatic route you can instantiate the whole object chain yourself - create a JDBCStoreEnvironmentBean, create a JDBCActionStore using it, then create a StoreManager using that.  Which is basically what a bean wiring framework would do.

Actually, I just need to READ configuration properties. Because of issue JBTM-465, our accessor must track all the connections given away, in order to close them on system shutdown. To optimise this task, we need to read com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStoreEnvironmentBean.getJdbcPoolSizeMaximum(): this is why we need to access the right instance of JDBCStoreEnvironmentBean. Of course, we could do the same without reading any configuration value, but we used to do that and I wanted to know how to do it with the new configuration mechanism.

Thanks for your support!

Mauro.