JBossDeveloper

Yes - there will be a blog entry and quickstart  

We aren't actually intending to document the use case with the object store purely local to the docker container. The configurations we do intend to document are:

1. Using a shared/mapped folder from the docker host to the docker container for storing the contents of the default ShadowNoFileLockStore. Here we will override the single configuration setting of the object store location with a system property (-DObjectStoreEnvironmentBean.objectStoreDir="/home/docker/tx-object-store") as this is going to be OK for any user.

2. We then intend to illustrate how a user can configure a jbossts-properties.xml file in a shared folder to customize any options (including the object store location). This will be demonstrated by configuring the use case where a user wishes to store the logs in an H2 database running on the docker host (but could be anywhere or any vendor). It would be possible to just override the object store config with system properties similar to option 1, something like:

-DObjectStoreEnvironmentBean.objectStoreType="com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore" --DObjectStoreEnvironmentBean.jdbcAccess="com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=org.h2.jdbcx.JdbcDataSource;URL=jdbc:h2:./h2/JBTMDB;User=sa;Password=sa"

The reason we think overriding the entire config file is a better option for variant 2 is because those JDBCObjectStore config options are much more likely to be environmental (database location/credentials) is going to be most flexible.

It all needs testing then

I'd still document the purely local object store case, i.e., within the docker image. This is the simplest use case for a developer and whilst it's not something they should use in production, it's probably the easiest to get someone going - it has the least steps to go through and hence the least chance of making a mistake.

BTW why wouldn't we simply make a docker image for each external object store use case? Ideally I'd want to be able to go download an image and it's all configured for me. Of course I may need to make some changes on my local machine, but I don't want to touch the docker image. Maybe that is what you're describing?

Mark Little wrote:

 

I'd still document the purely local object store case, i.e., within the docker image. This is the simplest use case for a developer and whilst it's not something they should use in production, it's probably the easiest to get someone going - it has the least steps to go through and hence the least chance of making a mistake.

 

BTW why wouldn't we simply make a docker image for each external object store use case? Ideally I'd want to be able to go download an image and it's all configured for me. Of course I may need to make some changes on my local machine, but I don't want to touch the docker image. Maybe that is what you're describing?

Sure, we can have a third variant that has the purely local storage option.

In terms of creating images for all of the external object store use cases, that could be quite an undertaking. Initially I think a docker image of a postgres database for the ObjectStore should be enough and jbossts-properties.xml to access the same should be the initial scope of the work. I do agree that Gytis should create the structure in our repo such that the community (and devs) can then contribute PRs of the variants as they are then developed. It would be useful for Gytis to create Jiras for the various object stores before completing the task.