Hi Andre,
I will have a look into this issue tomorrow, as I don't have any access
to code repository, etc. at the moment. But let me address one of your
questions right now.
Werner
Andre Teubner wrote:
> Hello list,
>
> once again occurs some mirgration problems to 0.9.7. This time we
> present a nice TransactionManagerAcquireException:
>
> org.exolab.castor.jdo.transactionmanager.TransactionManagerAcquireException:
> Problem obtaining JDO configuration: Nested error: Stream closed
> at
> org.exolab.castor.jdo.transactionmanager.TransactionManagerFactoryRegistry.load(TransactionManagerFactoryRegistry.java:199)
> at org.exolab.castor.jdo.JDOManager.getDatabase(JDOManager.java:690)
> at com.morixs.mcare.ds.castor.CastorDS.getDB(CastorDS.java:121)
> at com.morixs.mcare.ds.castor.CastorDS.init(CastorDS.java:106)
> [...]
> Caused by: org.exolab.castor.mapping.MappingException: Nested error:
> Stream closed
> at
> org.exolab.castor.jdo.engine.JDOConfLoader.loadConfiguration(JDOConfLoader.java:98)
> at
> org.exolab.castor.jdo.engine.JDOConfLoader.getTransactionDemarcation(JDOConfLoader.java:145)
> at
> org.exolab.castor.jdo.transactionmanager.TransactionManagerFactoryRegistry.load(TransactionManagerFactoryRegistry.java:160)
> ... 8 more
>
> Please remember, we only relaced castor.jar in our app and replace
> depracted JDO code with JDOManager. No other changes. I wonder why every
> new version is incompatible against predecessors.
There's a simple reason: because we fix bugs (about 120 since I joined
Castor JDO as a committer), go about implementing feature requests, add
new functionality, refactor code. And at the same time we are trying to
bring down the time between releases to two or three months at most. As
a result of these actions, failures can happen (like the one you are
experiencing at the moment). Now, it's not like we are not taking steps
to ensure that we don't break existing code between releases. There's a
test suite out there that we use to check whether we have broken
anything and whether everything still runs as intended. But as always,
this test suite is not complete, and does not cover all aspects of
Castor JDO. In addition, when it comes down on configuration, we have
got a dependency on Castor XML.
Let me ask you a simple question: how come I have not seen this kind of
problem report when I put out a release candidate for the 0.9.7 release.
I always thought that's the main raison d'etre for milestone builds.
Provide a build, and have some feedback provided to you. If I remember
correctly, there was one issue raised for 0.9.7M1. Just one ... and I am
sure there will be more in the next few days. If people had reported
more issues in the two weeks after I have released 0.9.7M1, I had
postponed the 0.9.7 release and made available a 0.9.7M2. Well, if
there's no feedback, why delay a release that you assume to be error free.
Wrt your issue, let's see what the problem is. If it turns out that
there's a regression issue, it's absolutely no problem to release
0.9.7.1 within a few days (after testing it).
>
> Code to init JDOManager
>
> JarEntityResolver pResolver = new JarEntityResolver();
> String strMappingLocation = Configuration.getValue(CastorDS.class,
> "CastorMapping");
> InputSource pDatabaseConfiguration = pResolver.resolveEntity(null,
> strMappingLocation);
>
> //JDO.loadConfiguration(pDatabaseConfiguration, pResolver, null);
> JDOManager.loadConfiguration(pDatabaseConfiguration, pResolver, null);
> manager = JDOManager.createInstance("MobileCare");
> manager .getDatabase();
>
>
> Any suggestions or hints?
>
> Thanks in advance
>
> Andre Teubner
>
>
>
> -------------------------------------------------
> If you wish to unsubscribe from this list, please
> send an empty message to the following address:
>
> [EMAIL PROTECTED]
> -------------------------------------------------
>
>
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
