PersistenceUnit not updated across multiple deployments /CUSTCOM-65 #1606
Comments
|
Hello, I recreated the case in this very small project, where I just changed the pool name. You can run it by just launching The test case is in the folder //first run => all is fine !
FacadeBeanRemote facade1 = createServer("myDatabase.db", "pool");
String fullName1 = facade1.getUserFullName(USERNAME_TEST);
assertEquals(FULLNAME_TEST, fullName1);
closeServer();
/*
* If you change either 'myDatabase.db' or 'pool' to any other name than
* the line above, you'll get an error.
* - If the database file is changed, then a SQL exception will be inside the EJB because
* it points to the old 'myDatabase.db' specified in the first run.
* - If the pool name is changed, then the deployment will fail because it is
* unable to find the corresponding JDBC connection pool.
*/
FacadeBeanRemote facade2 = createServer("myDatabase.db", "pool");
String fullName2 = facade2.getUserFullName(USERNAME_TEST);
assertEquals(FULLNAME_TEST, fullName2);
closeServer();Let me know if I'm doing something wrong :-) Best regards, |
|
Hi Cédric, Thank you for your test project, it helped greatly in reproducing your issue. You're not doing anything wrong as far as I can see! This bug seems to be from a very similar issue to #1596, as the embedded instance doesn't seem to be responding very well to a second configuration. I'll make an addendum to internal issue PAYARA-1651. In the meantime, if you're running multiple tests against a Payara Embedded instance for your code, might I suggest running Arquillian tests? Alternatively, it might be easier to add the specific JDBC resources to the Payara Embedded rather than create an entirely new instance. Hope this helps, |
MattGill98
added
Status: Accepted
|
Hello Matt, Thanks for your reply. I'll have a look on Arquillian as you suggest :-) I think I've found another another bug related to the JaaS authentication, still appearing after a second restart (JaaS authenticates the user as ANONYMOUS, even when mapped to the correct database). Do you mind if I open another issue ? Best, |
|
Hi Cédric, If you think it is an unrelated bug then of course. Otherwise just let me know of any information to add to the internal issue! Thanks, |
|
Tracked now by |
OndroMih
changed the title
|
Hi, due to how long ago this issue was raised we have decided to close the issue immediately, and not consider the implementation of the fix/improvement that was requested. Please understand that this decision was taken into consideration with the resources that we have available at the moment. In case of having reported a bug, if the issue is still pressing to you, feel free to verify if it’s applicable in the current release of Payara Community edition, and proceed to raise a new issue with details of the test reproducer. Many thanks for your understanding. |
Description
In an embedded payara server, the second time it is deployed, the PersistenceUnit that is used seems to come from the previous deployment.
Warning: I speak about
PersistenceUnitto say it is related with the lookup of the JNDI specified in thepersistence.xml. I don't know if it is effecitvely linked to thePersistenceUnit, it seems likely to be related to the JDBC connection pool handling.Edit: I attached a small project to reproduce the case.
Context
Like in #1596, we want to use the payara server (or GlassFish embedded) for testing our application. Since there are complex workflows, this involves to start/stop GlassFish multiple times with different configurations (
domain.xml).In order to have a full fresh environment for each deployment, we create a new
domain.xmlwhich point to different folders. The problem is that we make H2 point to a different database file:As you can see, before each startup, we replace
${POOL_NAME}with a random string in order to ensure the pool is different and${DATABASE_FILE}with the path to the new file that will host the database. However, since the EAR is already packaged, we cannot change the JNDI name (jdbc/database).Here is the content of the
persistence.xmlfile:Code snippet
Here is the code we use to start/stop Payara:
Now, we change the
domain.xmlto make it point to other files, as described above and we restart the server:In the console, we have the following stacktrace:
As you can see, the server is still searching the pool-name
h2_random_3871instead ofh2_random_1645, indicating that the previous PersistenceUnit seems to be still loaded.What I tried
We made the tests with Hibernate 5.2.10.Final and the default EclipseLink to ensure this is not a bug in the underlying JPA library.
Please also notice that we always pass an empty ClassLoader to the GlassfishRuntime, thinking that all our code would run in a sandbox, but it seems that this ClassLoader has absolutely no effect.
We tried different configurations of the ClassLoader (non, with parent, with delegation), but it seems to be completely ignored. But this might be due to the fact that we are running the instances with JUnit4 ?
Since the EJB project (packaged in the EAR) is a dependence of our testing project, this might be some ClassLoader issue (but since we are giving an empty ClassLoader to the GlassFishRuntime, I don't see what else we could do) ?
More logs
Output during closing of the first run:
Output after the second start:
Maven
Environment
The text was updated successfully, but these errors were encountered: