Add GlassFish / Jakarta EE shopservice with CI#20
Conversation
Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>
Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>
| --> | ||
| <resources> | ||
|
|
||
| <jdbc-connection-pool |
There was a problem hiding this comment.
@copilot is this really a connection pool? OJP does not work if there is a connection pool active in the client as per pooling is handled in the service, if you check all other pojects of shopservice in this repo they all have local pooling disable, and instead they create and close every connection.
There was a problem hiding this comment.
You're right — fixed in 5483ccb. The pool now has steady-pool-size="0" (no idle connections) and max-connection-usage-count="1" (connection discarded after each use), which makes GlassFish open a fresh connection per request and never cache/recycle it. This matches the approach in the other modules: Spring Boot's SimpleDriverDataSource, Micronaut's bare DriverManager wrapper, and Quarkus's unpooled=true.
Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>
Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>
Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>
Done in ff78555. Added a |
|
@copilot Glassfish integration tests are failing, one of the errors is Error: xtActionReporterFAILUREApplication shopservice is not deployed on this target [server][ERROR] Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.287 s <<< FAILURE! -- in com.example.shopservice.resource.OrderResourceTest |
…beans.xml Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>
Fixed in cc7eb57. Two root causes identified:
Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
Done in 05068f0. Reverted in all 5 entities back to |
|
@copilot |
…e.sql runs for IDENTITY entities Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>
Fixed in 90cc535. Root cause: Switched back to |
|
@copilot the auto-generated key issue has been fixed in ojp but still getting this error Caused by: java.sql.SQLException: NULL not allowed for column "ID"; SQL statement: Remember how was the setup when we fixed it without OJP? the settings for DDL and how to configure everything should be the same as in that commit only adding OJP as a pass trough proxy. We should not be having to do all these fixing. Make sure that only required OJP changes are in place and everything else is exactly the same as when it worked without OJP. So I want you to keep ojp but revert everything else to be the same as in the commit that worked connecting directly to H2 |
… OJP getGeneratedKeys() is fixed Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>
... Fixed in 597fda3. The three changes that restore the working direct-H2 baseline with OJP as the only difference:
The only OJP-specific change remaining is Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
|
@copilot Still failing with the auto generated problem. Remove OJP again and leave in the working baseline version accessing H2 directly. I try this locally later. |
…configuration Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>
Done in 58362b0. Reverted to the direct H2 baseline:
This is exactly the working state from before OJP was introduced into the tests. Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
|
@copilot explain how exactly these integration tests are working. Where is the URL to H2 configured? |
The H2 URL is configured in @DataSourceDefinition(
name = "java:app/jdbc/shopservice",
className = "org.h2.jdbcx.JdbcDataSource",
url = "jdbc:h2:mem:shopdb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE;MODE=LEGACY",
user = "sa",
password = "")Here's how it flows end-to-end:
The H2 URL is configured in @DataSourceDefinition(
name = "java:app/jdbc/shopservice",
className = "org.h2.jdbcx.JdbcDataSource",
url = "jdbc:h2:mem:shopdb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE;MODE=LEGACY",
user = "sa",
password = "")
@ApplicationScoped
public class TestDataSourceProducer {}Here's how the whole chain works:
|
|
@copilot I have fixed the issues in relation to the auto generated indexes not working on glassfish, the trouble was that glassfish was running after many other tests in the workflow (spring boot, quarkus, micronout) which created the tables already, so when glassfish tried to recriate them they were already there and it would use the ones there, but the other tests do not configure autoincrement in the manner glassfish needed. Correct me if I am missing something here. Now I want you to add these explanations you gave me about where things are configured for the test. I also want you to fix the OJP port in the postgres connection url inside the glassfish-resources.xml Also I want you to add an alert in every README of every test app in this repo stating that these apps were run only for integration tests, if someone wants to really run them (outside integration testing context) there might be changes required. |
… setup Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>
Done in b30a0de. Your analysis is correct — the GlassFish test was sharing H2 with prior test jobs (Spring Boot, Quarkus, Micronaut) in the same workflow run. Those frameworks create the tables without Three changes in this commit:
|
Adds a complete Jakarta EE 10 / GlassFish 7 implementation of the shopservice to this repo, covered by Arquillian integration tests running in CI. OJP integration is in place for both production and test datasources.
Production datasource (
glassfish-resources.xml)Uses
org.openjproxy.jdbc.OjpDataSource— thejavax.sql.DataSourceimplementation shipped with the OJP JDBC driver. This lets GlassFish register the JNDI resource asjavax.sql.DataSource, which is what its JTA resource validator requires.Client-side pooling is suppressed (
steady-pool-size="0",max-connection-usage-count="1") so OJP handles all pooling server-side, consistent with every other module in this repo.Test datasource (
TestDataSourceProducer)@DataSourceDefinitionconnects through OJP to H2 in-memory. Registered in thejava:app/namespace so it is visible toResourceValidatorbefore it runs —glassfish-resources.xmlinside a WAR is never bound in JNDI early enough in GlassFish Embedded.MODE=LEGACYis included so H2 2.x accepts EclipseLink'sBIGINT IDENTITYDDL syntax. Schema generation uses standard EclipseLinkdrop-and-createwith no custom scripts.How integration tests work
@DataSourceDefinitiononTestDataSourceProducerregisters the datasource underjava:app/jdbc/shopservicein the embedded GlassFish JNDI tree.DeploymentFactory.createDeployment()builds the ShrinkWrap WAR and includesTestDataSourceProducer.class, substitutingpersistence-test.xmlasMETA-INF/persistence.xml.persistence-test.xmlpoints EclipseLink at that JNDI name and usesdrop-and-create+H2Platformso EclipseLink generates H2-compatible DDL.@RunWith(Arquillian)test class callsDeploymentFactory.createDeployment()from its@Deploymentmethod, deploying to embedded GlassFish with that datasource.TestDataSourceProduceris only included in the test archive — it is never bundled in the production WAR.Notable GlassFish / Jakarta EE specifics addressed
--add-opensflags added to SurefireargLine— GlassFish Embedded doesn't run its normal startup scripts that provide these.eclipselink.target-database=org.eclipse.persistence.platform.database.H2Platform(FQN required; the short aliasH2throwsClassNotFoundExceptionin EclipseLink 4.x).beans.xmlusesbean-discovery-mode="annotated"to prevent Weld from proxying server-side built-in beans it can't load from the WAR classloader.$GLASSFISH_HOME/domains/domain1/lib/so the server-level pool manager can load it.GenerationType.IDENTITY. EclipseLink omits theidcolumn from INSERT statements and retrieves the generated key viaStatement.getGeneratedKeys().Integration-test-only notice
All app READMEs in this repo include a
> [!WARNING]alert noting that these applications were built for integration testing purposes only and may require configuration changes to run outside the CI context.CI
mvn clean verifyforglassfish/shopserviceadded to.github/workflows/main.yml.✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.