Hello Gavin,
I had to change only one thing: java:/DefaultDS to java:/MSSQLDS.
I get the same output for both methods. The difference is only in id
values:
****************************************
Bar id through foo: 4
Bar id through bars foos:
Number of foos associated with bar: 1
Foo id: 4
Bar id: 4
****************************************
alex
Wednesday, July 30, 2003, 3:20:26 AM, Gavin Matthews wrote:
GM> Alex,
GM> Attached is the standalone case - it exhibits the same behaviour (i.e. the
GM> cmr problem).
GM> It's hacked out of our inhouse environment so the build scripts could be
GM> cleaner, however they should work fine for you. I believe all you will need
GM> to modify some of the paths in cmrtest-config.xml:
GM> <property name="build.root" location="y:/CmrTest/build" />
GM> <property name="xdoclet.lib"
GM> value="y:/External/Java/XDocLet/xdoclet-1.2.0-beta3/lib" />
GM> <property name="jboss3.home"
GM> value="y:/External/Java/JBoss/jboss-3.2.2RC2_jetty-4.2.11"/>
GM> <property name="commons-logging.home"
GM> value="y:/External/Java/commons-logging/commons-logging-1.0.2"/>
GM> Just run ant to build it, the build files should go into CmrTest/build. It
GM> generates 2 files to deploy:
GM> CmrTest/build/ejb/target/cmrtest-ejb.jar - which contains the entities &
GM> session.
GM> CmrTest/build/service/jboss3/target/cmrtest-service-jboss3.sar - This is a
GM> mbean service (it was faster than writing a cactus testcase) used to run the
GM> test case.
GM> Deploy the ejb jar and then the service. Open up the service in the JMX
GM> console and start it. You'll see the service has two relevant methods,
GM> testWithFinder & testWithoutFinder. They both execute the same code the only
GM> difference is that in the middle of testWithFinder a finder is called which
GM> causes a db sync. testWithFinder behaves as expected testWithoutFinder is
GM> the bug I'm seeing.
GM> Let me know if I can provide anything other info or if you've problems with
GM> the test case.
GM> gavin
>> -----Original Message-----
>> From: Alexey Loubyansky [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, July 29, 2003 12:23 AM
>> To: '[EMAIL PROTECTED]'
>> Subject: Re[2]: [JBoss-user] CMR Problem in 3.2.2RC2
>>
>>
>> Hello Gavin,
>>
>> can you provide a testcase? Previously, you posted the source files
>> and I integrated them into a testcase. Can you send me a ready-to-run
>> testcase so I need just issue 'build run' or like that?
>> I'll correct it and send it back to you fixed.
>>
>> alex
>>
>> Tuesday, July 29, 2003, 12:20:04 AM, Gavin Matthews wrote:
>>
>>
>> GM> Alex,
>> GM> I've double checked everything and it definitely does
>> not work for me. I'm
>> GM> not sure what the cause could be unless there's some
>> weird config issue (I
>> GM> fixed the known/unknown config - but that didn't affect
>> the behaviour I'm
>> GM> seeing). I'm using the JBoss-3.2.2RC2_Jetty-4.2.11
>> release bundle, commit
>> GM> option C (tried with B also).
>>
>> GM> The fact that this is working for you is a bit
>> perplexing and I'm not
>> GM> really sure where to go from here. Any suggestions on
>> what I should look
>> GM> for? Where in the code should I focus my efforts to
>> figure out what's
>> GM> happening - at a rough high-level guess it looks like
>> something is wrong
>> GM> with the caching of objects at a transaction level, any
>> way I can easily
>> GM> prove/disprove this?
>>
>> GM> thanks,
>> GM> gavin
>>
>>
>>
>>
>> >> -----Original Message-----
>> >> From: Alexey Loubyansky [mailto:[EMAIL PROTECTED]
>> >> Sent: Friday, July 25, 2003 4:30 AM
>> >> To: Gavin Matthews
>> >> Subject: Re: [JBoss-user] CMR Problem in 3.2.2RC2
>> >>
>> >>
>> >> Hello Gavin,
>> >>
>> >> I am sorry, it works for me! I used your source files, MS
>> SQL Server
>> >> 2000 and your testSchema.sql.
>> >>
>> >> Anyway, I have some remarks. You are using unknown pk with name id,
>> >> while there is a CMP field id. You should not do it.
>> >> If you want a "known" pk and use a pk generation command, then just
>> >> mark the pk field as @jboss.persistence auto-increment="true".
>> >>
>> >> alex
>> >>
>> >> Thursday, July 24, 2003, 11:48:19 PM, Gavin Matthews wrote:
>> >>
>> >> GM> Hi,
>> >> GM> I posted this to the group a couple of weeks ago when
>> >> trying to get
>> >> GM> 3.2.2RC1 working. Alex had a look at it and figured it
>> >> was fixed for RC2. As
>> >> GM> RC2 was only a couple of weeks away I decided it'd be
>> >> easier for me to wait
>> >> GM> for RC2 than build it, my mistake, I've just grabbed RC2
>> >> - it's still there.
>> >> GM> (I'll log a bug this time).
>> >>
>> >> GM> gavin
>> >>
>> >> >> -----Original Message-----
>> >> >> From: Gavin Matthews
>> >> >> Sent: Thursday, July 03, 2003 7:05 PM
>> >> >> To: [EMAIL PROTECTED]
>> >> >> Cc: '[EMAIL PROTECTED]'
>> >> >> Subject: CMR Problem in 3.2.2?
>> >> >>
>> >> >>
>> >> >> Hi,
>> >> >> I posted yesterday and last week about a problem I was
>> >> >> having with CMR when I upgraded from 3.2.0 to 3.2.2. I've
>> >> >> done more investigation and I don't think my previous mails
>> >> >> were entirely accurate (or very clear) so let me start over.
>> >> >>
>> >> >> The Problem:
>> >> >> I'm experiencing NPE in our app because the CMR
>> >> >> relationships are (apparently) not being created. This didn't
>> >> >> occur with our app in 3.2.0.
>> >> >>
>> >> >> I have a sample case which I believe is representitive of
>> >> >> the problem I'm seeing in our app. The beans are Foo & Bar
>> >> >> (sorry about the naming). The relationship is N-Foo-1-Bar.
>> >> >> The relation is being set in post create:
>> >> >>
>> >> >> public abstract class FooEJB extends AbstractEntityBean {
>> >> >> ...
>> >> >> public void ejbPostCreate(BarLocal bar, String fooValue)
>> >> >> throws CreateException {
>> >> >> sLog.debug("ejbPostCreate(" + getId() + ")");
>> >> >>
>> >> >> this.setBar(bar);
>> >> >> }
>> >> >> ...
>> >> >> }
>> >> >>
>> >> >> And I have a test session which does the following:
>> >> >>
>> >> >> ...
>> >> >> BarLocal bar = createBar("This is a bar");
>> >> >> FooLocal foo = createFoo(bar, "This is a foo");
>> >> >>
>> >> >>
>> sLog.info("****************************************");
>> >> >> sLog.info("Bar id through foo: " +
>> >> foo.getBar().getId());
>> >> >> sLog.info("Bar id through bars foos: ");
>> >> >>
>> >> >> Collection foos = bar.getFoos();
>> >> >> sLog.info("Number of foos associated with bar: "
>> >> >> + foos.size());
>> >> >>
>> >> >> Iterator fooIter = bar.getFoos().iterator();
>> >> >> while (fooIter.hasNext()) {
>> >> >> FooLocal tmpFoo = (FooLocal) fooIter.next();
>> >> >> sLog.info("Foo id: " + tmpFoo.getId());
>> >> >> sLog.info("Bar id: " + tmpFoo.getBar().getId());
>> >> >> }
>> >> >>
>> sLog.info("****************************************");
>> >> >> ...
>> >> >>
>> >> >> I'd expect the output of this test case to be:
>> >> >>
>> >> >> 18:58:38,875 INFO [FooBarSessionEJB]
>> >> >> ****************************************
>> >> >> 18:58:38,890 INFO [FooBarSessionEJB] Bar id through foo: 1011
>> >> >> 18:58:38,890 INFO [FooBarSessionEJB] Bar id through bars foos:
>> >> >> 18:58:38,890 INFO [FooBarSessionEJB] Number of foos
>> >> >> associated with bar: 1
>> >> >> 18:58:38,906 INFO [FooBarSessionEJB] Foo id: 1017
>> >> >> 18:58:38,906 INFO [FooBarSessionEJB] Bar id: 1011
>> >> >> 18:58:38,906 INFO [FooBarSessionEJB]
>> >> >> ****************************************
>> >> >>
>> >> >> What I'm actually seeing is:
>> >> >>
>> >> >> 18:58:38,875 INFO [FooBarSessionEJB]
>> >> >> ****************************************
>> >> >> 18:58:38,890 INFO [FooBarSessionEJB] Bar id through foo: 1011
>> >> >> 18:58:38,890 INFO [FooBarSessionEJB] Bar id through bars foos:
>> >> >> 18:58:38,890 INFO [FooBarSessionEJB] Number of foos
>> >> >> associated with bar: 0
>> >> >> 18:58:38,906 INFO [FooBarSessionEJB]
>> >> >> *******************************************
>> >> >>
>> >> >> If I add a finder call after the beans are created (which
>> >> >> forces the beans to be synchronized to the database) then I
>> >> >> get the results I expect. This makes me think that there's a
>> >> >> problem with the caching - the "bar" returned by the
>> >> >> create() call is not the same Bar instance as returned by
>> >> >> foo.getBar(). Which means that I have 2 instances of the same
>> >> >> bean within the same transaction which have different state -
>> >> >> seems like a bug to me, I'd have expected the foo.getBar()
>> >> >> call to return the same "bar" as was passed to the
>> create() call.
>> >> >>
>> >> >> I've attached the source. For the sample, let me know what
>> >> you think,
>> >> >>
>> >> >> thanks,
>> >> >> gavin
>> >>
>> >>
>> >>
>> >> -------------------------------------------------------
>> >> This SF.Net email sponsored by: Free pre-built ASP.NET
>> sites including
>> >> Data Reports, E-commerce, Portals, and Forums are available now.
>> >> Download today and enter to win an XBOX or Visual Studio .NET.
>> >> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet
>> GM> _072303_01/01
>> GM> _______________________________________________
>> GM> JBoss-user mailing list
>> GM> [EMAIL PROTECTED]
>> GM> https://lists.sourceforge.net/lists/listinfo/jboss-user
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> Data Reports, E-commerce, Portals, and Forums are available now.
>> Download today and enter to win an XBOX or Visual Studio .NET.
>> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet
GM> _072303_01/01
GM> _______________________________________________
GM> JBoss-user mailing list
GM> [EMAIL PROTECTED]
GM> https://lists.sourceforge.net/lists/listinfo/jboss-user
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
