Thanks Thomas,
I updated the method to support the try with resources to ensure that
the FileInputStream is properly closed. I am still not completely happy
with the way exceptions are bubbling up, so I may spend some more time
cleaning that up soon. (per your other email about testing
FileInputStream are properly closed).
Everything now appears to be working fine in parallel deployment. I
imagine we will need to publish a new intake artifact (1.2.3) as well
before we can call turbine 4.0.1 complete.
One other note - while working on this bug, I checked out all of the
fulcrum modules. I have a problem getting fulcrum-cache to complete its
tests successfully, but everything else looks fine. The test phase for
fulcrum-cache takes a long time to complete, but fails with the
following message. It doesn't look like any activity there in a while
(13 months), so I will come back to it as well when I have some time if
someone else doesn't take it on before me :-)
[INFO] YaffiContainer has been disposed.
Tests run: 10, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 141.992
sec <<< FAILURE! - in org.apache.fulcrum.cache.JCSCacheTest
testSimpleAddGetCacheObject(org.apache.fulcrum.cache.JCSCacheTest) Time
elapsed: 0.01 sec <<< ERROR!
org.apache.fulcrum.cache.ObjectExpiredException
at
org.apache.fulcrum.cache.impl.JCSCacheService.getObject(JCSCacheService.java:189)
at
org.apache.fulcrum.cache.CacheTest.testSimpleAddGetCacheObject(CacheTest.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:99)
at
org.apache.maven.surefire.junit.JUnit3Provider.executeTestSet(JUnit3Provider.java:136)
at
org.apache.maven.surefire.junit.JUnit3Provider.invoke(JUnit3Provider.java:109)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
testObjectCount(org.apache.fulcrum.cache.JCSCacheTest) Time elapsed:
18.35 sec <<< FAILURE!
junit.framework.AssertionFailedError: After three refreshes expected:<0>
but was:<1>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at
org.apache.fulcrum.cache.CacheTest.testObjectCount(CacheTest.java:299)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:99)
at
org.apache.maven.surefire.junit.JUnit3Provider.executeTestSet(JUnit3Provider.java:136)
at
org.apache.maven.surefire.junit.JUnit3Provider.invoke(JUnit3Provider.java:109)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
Results :
Failed tests:
org.apache.fulcrum.cache.JCSCacheTest#testObjectCount
AssertionFailedError Aft...
Tests in error:
org.apache.fulcrum.cache.EHCacheTest#testSimpleAddGetCacheObject
ObjectExpiredException
org.apache.fulcrum.cache.JCSCacheTest#testSimpleAddGetCacheObject
ObjectExpiredException
Tests run: 30, Failures: 1, Errors: 2, Skipped: 0
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 07:09 min
[INFO] Finished at: 2018-01-29T13:56:28-05:00
[INFO] Final Memory: 22M/377M
[INFO]
------------------------------------------------------------------------
Thanks,
Jeff
On 01/29/2018 01:45 PM, Thomas Vandahl wrote:
Hi Jeffery,
On 29.01.18 16:13, Jeffery Painter wrote:
Hi Georg,
I have a fix, but I don't understand "why" it works. From all my
debugging, this should not be a bug, but the exception is occurring in
the JAXB unmarshalling method when the intake xml file is passed as a
file reference.
The following snippet works in parallel deployment. I would like to
understand the difference, but since this is a class from Oracle, it is
not giving me great insight from the debugger (also hard to test in
Eclipse since it wants to debug with the application root set to just
"/testapp" and I can't figure out how to deploy in debug mode with
"/testapp##001"). I am happy to push this upstream if you think this
looks OK to you.
If you look at lines 724 and following, you'll see that a check for
readability of the xml file is already there. If that is not successful,
you should never reach the unmarshalling code. What does the debug log
tell you?
Nevertheless, my blood runs cold when looking at the code of
javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(File)
For some strange reason the file path is converted to a string, massaged
heavily, then converted to a file-URL and then to an InputSource.
It is probably way better to open the FileInputStream as you did. Just
leave out the test for existence and add some exception handling to make
sure the file is being closed if something blows up.
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
