Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WFLY-19790] Remove batch-processing DS file #960

Closed
wants to merge 1 commit into from

Conversation

liweinan
Copy link
Contributor

@liweinan liweinan commented Sep 30, 2024

@liweinan liweinan changed the title WFLY-19790 Remove batch-processing DS file [WFLY-19790] Remove batch-processing DS file Sep 30, 2024
@liweinan
Copy link
Contributor Author

@jfdenise I don't know how to fix this error:

As the h2-database has already been added. Could you please help check this? Thanks!

@liweinan liweinan marked this pull request as draft October 1, 2024 15:15
batch-processing/configure-server.cli Outdated Show resolved Hide resolved
@emmartins
Copy link
Contributor

Besides the script change, guess we need instructions wrt the script execution when used with bare-metal standard distribution, and a config restore script too? You can reuse content from

=== Configure the Server

@emmartins
Copy link
Contributor

Btw I really thought you would just need to update the persistence.xml, ie no need for config change script...
@scottmarlow I wonder if this (replace usage of the DS file with just persistence.xml) would be possible?

@liweinan
Copy link
Contributor Author

liweinan commented Oct 7, 2024

@emmartins Thanks for checking this PR!

I discussed this issue with @jamezp, and the DS file may still be used in the future, so I am holding off on this work.

@emmartins
Copy link
Contributor

@jamezp can you please clarify what @liweinan said above about new use for DS files? We have those deprecated for long, and we are logging a log warning (the reason for this issue) when deploying such files...

@jamezp
Copy link
Member

jamezp commented Oct 28, 2024

I do understand the log message is a bit annoying and really we should have a look at that. There are quite a few comments on https://issues.redhat.com/browse/WFLY-4296 as to why this support should not be removed.

The problem is there is no good way to create a test data source without the *-ds.xml files.

One option is to simply use the default data source, however I'm not sure if we purposely do not do that in Quickstarts for a reason.

@liweinan
Copy link
Contributor Author

One option is to simply use the default data source

btw here is one blog post that I'm writing on this topic: wildfly/wildfly.org#677

If this is a better solution for this example, I can work on it.

@emmartins
Copy link
Contributor

emmartins commented Oct 29, 2024

really up to you guys what you want to use as datasource, be it standard or not I'm fine with it, just agree with QE it's no longer ok to use a -ds file to config a database, you now have the standard persistence.xml and DatasourceDefinition annotation that should be the alternative, or at least the first alternative, if the vendor requires something more (like a cli script) then be it

@liweinan
Copy link
Contributor Author

liweinan commented Oct 30, 2024

@emmartins Thanks for the comment!

According to all your opinions, I'd prefer to use the CLI script to do this.

James has provided an example showing the CLI usage here: jberet/jberet-examples#13

I'll use the above example as a reference and update the PR.

@liweinan liweinan marked this pull request as ready for review October 30, 2024 17:08
@liweinan
Copy link
Contributor Author

@emmartins I have replaced Glow with the data source feature pack in combination with the CLI script to create the database and configure the datasource. Could you please check if this solution is acceptable? Thanks!

@liweinan
Copy link
Contributor Author

@jamezp I'm not sure how to fix the Kubernetes CI test failure. Could you please help to check it when you have time? Thanks!

@jamezp
Copy link
Member

jamezp commented Oct 30, 2024

@liweinan I have no idea why the Kubernetes tests are failing. There seems to be no indication as to why.

@@ -200,12 +203,32 @@
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<configuration>
<discover-provisioning-info>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are we going back to directly using galleon layers, instead of glow's discovery? This seems a mistake

Copy link
Contributor

@emmartins emmartins Oct 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe you are just doing copy paste of outdated (in the sense of not using glow) configuration? You can use glow and pack a script. In short the only change you do here is to add

                            <packaging-scripts>
                                <packaging-script>
                                    <scripts>
                                        <script>${configure.ds.script}</script>
                                    </scripts>
                                    <!-- Expressions resolved during server execution -->
                                    <resolve-expressions>false</resolve-expressions>
                                </packaging-script>
                            </packaging-scripts>

@@ -0,0 +1 @@
xa-data-source add --name=batch_db --enabled=true --use-java-context=true --use-ccm=true --jndi-name=java:jboss/datasources/batch-processingDS --xa-datasource-properties={"URL"=>"jdbc:h2:mem:batch-processing;DB_CLOSE_ON_EXIT=FALSE;DB_CLOSE_DELAY=-1"} --driver-name=h2 --password=sa --user-name=sa --same-rm-override=false --no-recovery=true
Copy link
Contributor

@emmartins emmartins Oct 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think you could do this op using only Jakarta specs, which would make this app portable among vendors. But I tried to use a DataSourceDefinition like the one below (you can add this for instance to Contact class) but first Glow complained and required me to prevent fail on error, and then boot failed with a CNFE for org.h2.jdbcx.JdbcDataSource. I guess we can try to explore the specs way and clarify how should users use the specs DataSourceDefinition later...

@DataSourceDefinition(name="java:jboss/datasources/batch-processingDS",
className="org.h2.jdbcx.JdbcDataSource",
url="jdbc:h2:mem:batch-processing;DB_CLOSE_ON_EXIT=FALSE;DB_CLOSE_DELAY=-1",
user="sa",
password="sa"
)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nevermind, I was able to make it work, I will send an alternative PR for you to have a look

<addOn>h2-database:default</addOn>
</addOns>
</discover-provisioning-info>
<feature-packs>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should revert this change too, other than adding the script of course

Copy link
Contributor

@emmartins emmartins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see my comments

@emmartins
Copy link
Contributor

@liweinan @jamezp alternative PR using the specs DataSourceDefinition at #973

@liweinan
Copy link
Contributor Author

@emmartins Thanks for the review! I'll check it.

alternative PR using the specs DataSourceDefinition at #973

Cool! I'll see if this can work with this example.

@liweinan
Copy link
Contributor Author

I closed this PR because it's been replaced by the PR mentioned above.

@liweinan liweinan closed this Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants