Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4
On 2002.01.09 23:38:57 -0500 Dmitri Colebatch wrote: > > On 2002.01.09 21:45:44 -0500 Paul McLachlan wrote: > > > How do I do inheritance with cmp2? Maybe that is why Castor will > survive. > > > > Maybe. I don't know how to do polymorphism w/cmp2. But how can you > build > > a big system w/o decarative tx and security ;-)? > > > > From the little I've looked into the jdo spec, it looks to me as if the > > persistence mechanism is pretty similar to what you need for ejb2. So > > perhaps soon we will see something with both the metaprogramming of > ejbs > > and the oo-ness of jdo. > > can I pop my 2c in here take it as you will. > > firstly, David, without seeming rude you do know that castor doesn't > aim > to be compliant with the JDO spec, but rather aims to solve the same > problem > in a similar fashion (my understanding) No problem. I still think the jca spi interfaces are the ideal way for anything with "connections" to interface with an app server. I was kind of disappointed they didn't respond with any interest to my offer to potentially implement it. > > we recently switched back to entity beans, after having a dabble with > castor, attracted by the rich feature set, mainly the polymorphism, > shared > locking etc.. however, the further we got into it, the more problems we > had, specifically with the polymorphism, which was the main advantage it > has > over entity beans. we switched back because it was decided we couldn't > spend any more time looking into the aforementioned issues. > > having said that, castor can run inside an ejb container, and be used in > conjunction with session and message driven beans, and still execute in > the > same tx scope. yes you lose the declaritive tx scoping, and security, > but > I'd argue the pros and bigger than the cons. except of course that > you > are using something that is completely non-spec (but very portable). Whether or not you implement the rest of the jdo spec, using their ideas on jca does or would give you declarative tx scoping and security at the ejb-castor boundary. Ejb2 extends this declarative model down to every object, while reducing the possibility of support for polymorphism. > > I'm not really arguing one way or the other, just sharing our experience > with it... and perhaps my thoughts on what is and isn't important in the > decision... I'd be happy to hear of others' thoughts on both those > issues. I certainly appreciate hearing your experience! Thanks david jencks > > cheesr > dim > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Updating CastorJDO plugin for 2.4.4
I apologize in advance for introducing me in this thread... > Dain, > > full rundown is at http://www.castor.org/locking.html but my > brief version here... (forgive me if any of this comes > across as patronizing, not sure how much exposure you've had > to castor) > > say I had ejb and web tiers in the same jvm, and a jsp was > provided with a collection of objects to display. > > in castor, I could have two requests at the same time, both > given the same collection of objects, and access them in a > read-only fashion concurrently. > > (as I understand) with entity beans, using finder methods, as > soon as one entity was accessed, even in a read-only fashion, > it would be locked for the duration of that tx yes? so the > second request would have to wait until the first tx has > finished. the common workaround is to write the query > yourself in jdbc, and use a non-ejb approach Is this problem not solved using EntityMultiInstanceInterceptor ? I mean commit-option "any" / EntityInstanceInterceptor seems to serialize access to the Cache. Then I agree with you. Have you try to swicth to commit-option B/C / EntityMultiInstanceInterceptor ? What I don't understand yet is that plus the Entity/Method Lock interceptors plus the locking-policy that can be used along with that. That mixed with the fact that finder methods create multiple instances and I am in a black hole... > > I know that read-only beans could solve this in some cases, > but obviously not all. My real problem with the jdbc > approach is that hte container already has all the > information required to create the sql. > > a while back, I tried to create some new functionality for > jboss, got it working nicely, but then faded away - > essentially, for each finder method, I made a query method - > basically following the architecture you have for the jaws > stuff - I mirrored FindEntitiesCOmmand with a > QueryEntitiesCommand (with a little refactoring to suit), and > in jboss.xml had a spot for someone to declare the class the > populate. so the home interface then has: > > public Collection findByXXX(); > public Collection queryByXXX(); > > the finder method of course returns ejbobjects, with all the > spec behaviour. the query method returns a collection of > dataobjects, the dataobject having the same set/get methods > as the entity bean, but is actually a copy of the data. > > I had a fair bit of fun doing this, but got stumped on how to > handle relationships anyway, not sure that you couldn't > think of a much better way to solve the problem, but thought > it might be worth sharing, just seems that using jdbc for > read-only access was quite common, and could be another area > where jboss could make it easier for the user > > would like to hear your thoughts on this, and also any more > feedback on the castor issue. > > cheesr > dim > _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4
Dain, full rundown is at http://www.castor.org/locking.html but my brief version here... (forgive me if any of this comes across as patronizing, not sure how much exposure you've had to castor) say I had ejb and web tiers in the same jvm, and a jsp was provided with a collection of objects to display. in castor, I could have two requests at the same time, both given the same collection of objects, and access them in a read-only fashion concurrently. (as I understand) with entity beans, using finder methods, as soon as one entity was accessed, even in a read-only fashion, it would be locked for the duration of that tx yes? so the second request would have to wait until the first tx has finished. the common workaround is to write the query yourself in jdbc, and use a non-ejb approach I know that read-only beans could solve this in some cases, but obviously not all. My real problem with the jdbc approach is that hte container already has all the information required to create the sql. a while back, I tried to create some new functionality for jboss, got it working nicely, but then faded away - essentially, for each finder method, I made a query method - basically following the architecture you have for the jaws stuff - I mirrored FindEntitiesCOmmand with a QueryEntitiesCommand (with a little refactoring to suit), and in jboss.xml had a spot for someone to declare the class the populate. so the home interface then has: public Collection findByXXX(); public Collection queryByXXX(); the finder method of course returns ejbobjects, with all the spec behaviour. the query method returns a collection of dataobjects, the dataobject having the same set/get methods as the entity bean, but is actually a copy of the data. I had a fair bit of fun doing this, but got stumped on how to handle relationships anyway, not sure that you couldn't think of a much better way to solve the problem, but thought it might be worth sharing, just seems that using jdbc for read-only access was quite common, and could be another area where jboss could make it easier for the user would like to hear your thoughts on this, and also any more feedback on the castor issue. cheesr dim - Original Message - From: "Dain Sundstrom" <[EMAIL PROTECTED]> To: "'Dmitri Colebatch'" <[EMAIL PROTECTED]>; "Ryan Marsh" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, January 11, 2002 10:24 AM Subject: RE: [JBoss-user] Updating CastorJDO plugin for 2.4.4 > > the main reason we looked at castor was the > > shared access on > > query results, so I could have two "findAll" methods running, > > and if they > > were both read only, there would be no lockouts. This to me > > is the biggest > > disadvantage of entity beans as they currently stand, I for > > one dont see why > > the container doesn't provide a read-only equivalent of the finder > > method > > Can you give me more details on this? I'm not sure what you mean by "shared > access on query results." If you can explain this, maybe I can incorporate > it into JBossCMP. > > -dain > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Updating CastorJDO plugin for 2.4.4
> the main reason we looked at castor was the > shared access on > query results, so I could have two "findAll" methods running, > and if they > were both read only, there would be no lockouts. This to me > is the biggest > disadvantage of entity beans as they currently stand, I for > one dont see why > the container doesn't provide a read-only equivalent of the finder > method Can you give me more details on this? I'm not sure what you mean by "shared access on query results." If you can explain this, maybe I can incorporate it into JBossCMP. -dain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4
below... > ... > the cache gives an employee when it wants a developer... > > thats probably a pretty messy way of explaining it - if Victor is still on > this list, he might go into it more for you, but I hope you get the drift. i understand your point. damn, that's disgusting. > using bmp entity beans? and doing the persistence through castor? I'm a > little confused now... Yes, BMP beans, I want a flexible database abstraction layer so i don't have to write jdbc calls. It appears however, that Castor is not as flexible as I thought it was. I'm now leaning towards MVCSoft's Persistance Manager. > tx and security in ejbs can be done to a certain extent in deployment > descriptors, so I can say that every call to this ejb _must_ be in a new tx, > or will join an existing tx if there is already one going, and so on. > security is similar - this role can call this method, blah blah blah... > still doesn't give you ownership of entities though, or state based > security. hrmm... will that then screw with the way JDO does transactions? i'm lost. i need to read up on transactions in EJB containers. whats a good place to start reading? Thanks for all your help. -ryan -- "...visit a dog show. Or a gathering of people who believe they have been abducted by aliens in UFOs. People are demonstrably insane when it comes to assessing non-human sentience." -- Jaron Lanier http://www.ryanmarsh.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4
> > Depending on what you want from castor, it may or may not be a good idea. > > in our case, we found problems in the areas of it we wanted, and there was > > concern in our team over the reliability of it. I would also be considering > > This scares me, where did you find problems? inheritence. here's one of the posts to castor-dev: http://www.mail-archive.com/castor-dev@exolab.org/msg03410.html if you do a search for other posts by Victor, you should get a fair rundown of the issue(s) we had. I personally wasn't looking at it, so cant speak of it too deeply, but essentially the problem was to do with the way castor handles inheritence - say you have your Emplyoee base class, and then have Developer, Manager, etc. etc. (model may not be perfect - but for the example). Castor basically requires Employee to be an object in itself, and have its own table. The Developer table then has the same pk columns, and corresponding values etc... this is all from memory, so comes with a big disclaimer (o: now the problem we faced came when we tried to query all developers with abc... problem was that if castor already had object x cached as an employee, when really its a developer, the developer query would throw the equivalent of a classcast exception when trying to return results, because the cache gives an employee when it wants a developer... thats probably a pretty messy way of explaining it - if Victor is still on this list, he might go into it more for you, but I hope you get the drift. > > entity beans - the main reason we looked at castor was the shared access on > > query results, so I could have two "findAll" methods running, and if > > I plan on using Castor only for the DAO classes (per the J2EE pattern). > I'd like to: > > A) Not write JDBC > B) Take advantage of shared access on query results like you mentioned. > > This means I *will* be using EJB. I'm just wondering if replacing the > innards of DAO classes (or replacing them altogether) with JDO calls > instead of JDBC calls is a smart idea on two fronts: using bmp entity beans? and doing the persistence through castor? I'm a little confused now... > A) System design flaws this might introduce. > B) Quality of Castor when utilized in this fashion. (I don't quite > understand all the transaction and context stuff involved in EJB's yet). tx and security in ejbs can be done to a certain extent in deployment descriptors, so I can say that every call to this ejb _must_ be in a new tx, or will join an existing tx if there is already one going, and so on. security is similar - this role can call this method, blah blah blah... still doesn't give you ownership of entities though, or state based security. > > were both read only, there would be no lockouts. This to me is the biggest > > disadvantage of entity beans as they currently stand, I for one dont see why > > the container doesn't provide a read-only equivalent of the finder > > method > > I'm not sure I understand this. You want read only calls to lock each > other out? no, thats why I was looking at castor... (o: > Thanks, > -ryan hope its helpful.. cheers dim ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4
see below... On Thu, 2002-01-10 at 14:55, Dmitri Colebatch wrote: > My _personal_ view, is that writing jdbc code should be left to frameworks, Ok, so Castor is good then > ... > becomes trickier, and you end up writing your own mini-container of sorts > (imho). I agree... > Depending on what you want from castor, it may or may not be a good idea. > in our case, we found problems in the areas of it we wanted, and there was > concern in our team over the reliability of it. I would also be considering This scares me, where did you find problems? > entity beans - the main reason we looked at castor was the shared access on > query results, so I could have two "findAll" methods running, and if I plan on using Castor only for the DAO classes (per the J2EE pattern). I'd like to: A) Not write JDBC B) Take advantage of shared access on query results like you mentioned. This means I *will* be using EJB. I'm just wondering if replacing the innards of DAO classes (or replacing them altogether) with JDO calls instead of JDBC calls is a smart idea on two fronts: A) System design flaws this might introduce. B) Quality of Castor when utilized in this fashion. (I don't quite understand all the transaction and context stuff involved in EJB's yet). > were both read only, there would be no lockouts. This to me is the biggest > disadvantage of entity beans as they currently stand, I for one dont see why > the container doesn't provide a read-only equivalent of the finder > method I'm not sure I understand this. You want read only calls to lock each other out? Thanks, -ryan > anyway, my 2c, not sure if its any help. > > cheers > dim > > - Original Message - > From: "Ryan Marsh" <[EMAIL PROTECTED]> > To: "Dmitri Colebatch" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, January 11, 2002 4:49 AM > Subject: Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4 > > > > I am considering using Castor with a new J2EE application we are > > developing. I had planned to use it within the DAO classes to simplify > > them and eliminate the need to write jdbc/SQL code by hand. > > > > Is this a good idea in your opinion? Or should I just write the jdbc > > code? > > > > Input from anyone else is welcome too. > > > > -ryan > > > > On Wed, 2002-01-09 at 22:38, Dmitri Colebatch wrote: > > > > On 2002.01.09 21:45:44 -0500 Paul McLachlan wrote: > > > > > How do I do inheritance with cmp2? Maybe that is why Castor will > > > survive. > > > > > > > > Maybe. I don't know how to do polymorphism w/cmp2. But how can you > build > > > > a big system w/o decarative tx and security ;-)? > > > > > > > > From the little I've looked into the jdo spec, it looks to me as if > the > > > > persistence mechanism is pretty similar to what you need for ejb2. So > > > > perhaps soon we will see something with both the metaprogramming of > ejbs > > > > and the oo-ness of jdo. > > > > > > can I pop my 2c in here take it as you will. > > > > > > firstly, David, without seeming rude you do know that castor doesn't > aim > > > to be compliant with the JDO spec, but rather aims to solve the same > problem > > > in a similar fashion (my understanding) > > > > > > we recently switched back to entity beans, after having a dabble with > > > castor, attracted by the rich feature set, mainly the polymorphism, > shared > > > locking etc.. however, the further we got into it, the more problems we > > > had, specifically with the polymorphism, which was the main advantage it > has > > > over entity beans. we switched back because it was decided we couldn't > > > spend any more time looking into the aforementioned issues. > > > > > > having said that, castor can run inside an ejb container, and be used in > > > conjunction with session and message driven beans, and still execute in > the > > > same tx scope. yes you lose the declaritive tx scoping, and security, > but > > > I'd argue the pros and bigger than the cons. except of course that > you > > > are using something that is completely non-spec (but very portable). > > > > > > I'm not really arguing one way or the other, just sharing our experience > > > with it... and perhaps my thoughts on what is and isn't important in > the > > > decision... I'd be happy to hear of others' thoughts on both those > issues.
Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4
My _personal_ view, is that writing jdbc code should be left to frameworks, but there are no doubt people more qualified to offer opinions on this. Of course some queries would be required, but when you start talking about related objects, and persistening and updating them, writing the jdbc becomes trickier, and you end up writing your own mini-container of sorts (imho). Depending on what you want from castor, it may or may not be a good idea. in our case, we found problems in the areas of it we wanted, and there was concern in our team over the reliability of it. I would also be considering entity beans - the main reason we looked at castor was the shared access on query results, so I could have two "findAll" methods running, and if they were both read only, there would be no lockouts. This to me is the biggest disadvantage of entity beans as they currently stand, I for one dont see why the container doesn't provide a read-only equivalent of the finder method anyway, my 2c, not sure if its any help. cheers dim - Original Message - From: "Ryan Marsh" <[EMAIL PROTECTED]> To: "Dmitri Colebatch" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, January 11, 2002 4:49 AM Subject: Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4 > I am considering using Castor with a new J2EE application we are > developing. I had planned to use it within the DAO classes to simplify > them and eliminate the need to write jdbc/SQL code by hand. > > Is this a good idea in your opinion? Or should I just write the jdbc > code? > > Input from anyone else is welcome too. > > -ryan > > On Wed, 2002-01-09 at 22:38, Dmitri Colebatch wrote: > > > On 2002.01.09 21:45:44 -0500 Paul McLachlan wrote: > > > > How do I do inheritance with cmp2? Maybe that is why Castor will > > survive. > > > > > > Maybe. I don't know how to do polymorphism w/cmp2. But how can you build > > > a big system w/o decarative tx and security ;-)? > > > > > > From the little I've looked into the jdo spec, it looks to me as if the > > > persistence mechanism is pretty similar to what you need for ejb2. So > > > perhaps soon we will see something with both the metaprogramming of ejbs > > > and the oo-ness of jdo. > > > > can I pop my 2c in here take it as you will. > > > > firstly, David, without seeming rude you do know that castor doesn't aim > > to be compliant with the JDO spec, but rather aims to solve the same problem > > in a similar fashion (my understanding) > > > > we recently switched back to entity beans, after having a dabble with > > castor, attracted by the rich feature set, mainly the polymorphism, shared > > locking etc.. however, the further we got into it, the more problems we > > had, specifically with the polymorphism, which was the main advantage it has > > over entity beans. we switched back because it was decided we couldn't > > spend any more time looking into the aforementioned issues. > > > > having said that, castor can run inside an ejb container, and be used in > > conjunction with session and message driven beans, and still execute in the > > same tx scope. yes you lose the declaritive tx scoping, and security, but > > I'd argue the pros and bigger than the cons. except of course that you > > are using something that is completely non-spec (but very portable). > > > > I'm not really arguing one way or the other, just sharing our experience > > with it... and perhaps my thoughts on what is and isn't important in the > > decision... I'd be happy to hear of others' thoughts on both those issues. > > > > cheesr > > dim > > > > > > ___ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > -- > "...visit a dog show. Or a gathering of people who believe they have > been abducted by aliens in UFOs. People are demonstrably insane when > it comes to assessing non-human sentience." > -- Jaron Lanier > > http://www.ryanmarsh.com > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4
I am considering using Castor with a new J2EE application we are developing. I had planned to use it within the DAO classes to simplify them and eliminate the need to write jdbc/SQL code by hand. Is this a good idea in your opinion? Or should I just write the jdbc code? Input from anyone else is welcome too. -ryan On Wed, 2002-01-09 at 22:38, Dmitri Colebatch wrote: > > On 2002.01.09 21:45:44 -0500 Paul McLachlan wrote: > > > How do I do inheritance with cmp2? Maybe that is why Castor will > survive. > > > > Maybe. I don't know how to do polymorphism w/cmp2. But how can you build > > a big system w/o decarative tx and security ;-)? > > > > From the little I've looked into the jdo spec, it looks to me as if the > > persistence mechanism is pretty similar to what you need for ejb2. So > > perhaps soon we will see something with both the metaprogramming of ejbs > > and the oo-ness of jdo. > > can I pop my 2c in here take it as you will. > > firstly, David, without seeming rude you do know that castor doesn't aim > to be compliant with the JDO spec, but rather aims to solve the same problem > in a similar fashion (my understanding) > > we recently switched back to entity beans, after having a dabble with > castor, attracted by the rich feature set, mainly the polymorphism, shared > locking etc.. however, the further we got into it, the more problems we > had, specifically with the polymorphism, which was the main advantage it has > over entity beans. we switched back because it was decided we couldn't > spend any more time looking into the aforementioned issues. > > having said that, castor can run inside an ejb container, and be used in > conjunction with session and message driven beans, and still execute in the > same tx scope. yes you lose the declaritive tx scoping, and security, but > I'd argue the pros and bigger than the cons. except of course that you > are using something that is completely non-spec (but very portable). > > I'm not really arguing one way or the other, just sharing our experience > with it... and perhaps my thoughts on what is and isn't important in the > decision... I'd be happy to hear of others' thoughts on both those issues. > > cheesr > dim > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user -- "...visit a dog show. Or a gathering of people who believe they have been abducted by aliens in UFOs. People are demonstrably insane when it comes to assessing non-human sentience." -- Jaron Lanier http://www.ryanmarsh.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4
> On 2002.01.09 21:45:44 -0500 Paul McLachlan wrote: > > How do I do inheritance with cmp2? Maybe that is why Castor will survive. > > Maybe. I don't know how to do polymorphism w/cmp2. But how can you build > a big system w/o decarative tx and security ;-)? > > From the little I've looked into the jdo spec, it looks to me as if the > persistence mechanism is pretty similar to what you need for ejb2. So > perhaps soon we will see something with both the metaprogramming of ejbs > and the oo-ness of jdo. can I pop my 2c in here take it as you will. firstly, David, without seeming rude you do know that castor doesn't aim to be compliant with the JDO spec, but rather aims to solve the same problem in a similar fashion (my understanding) we recently switched back to entity beans, after having a dabble with castor, attracted by the rich feature set, mainly the polymorphism, shared locking etc.. however, the further we got into it, the more problems we had, specifically with the polymorphism, which was the main advantage it has over entity beans. we switched back because it was decided we couldn't spend any more time looking into the aforementioned issues. having said that, castor can run inside an ejb container, and be used in conjunction with session and message driven beans, and still execute in the same tx scope. yes you lose the declaritive tx scoping, and security, but I'd argue the pros and bigger than the cons. except of course that you are using something that is completely non-spec (but very portable). I'm not really arguing one way or the other, just sharing our experience with it... and perhaps my thoughts on what is and isn't important in the decision... I'd be happy to hear of others' thoughts on both those issues. cheesr dim ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4
On 2002.01.09 21:45:44 -0500 Paul McLachlan wrote: > How do I do inheritance with cmp2? Maybe that is why Castor will survive. Maybe. I don't know how to do polymorphism w/cmp2. But how can you build a big system w/o decarative tx and security ;-)? >From the little I've looked into the jdo spec, it looks to me as if the persistence mechanism is pretty similar to what you need for ejb2. So perhaps soon we will see something with both the metaprogramming of ejbs and the oo-ness of jdo. david jencks > > > -Original Message- > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, 10 January 2002 1:04 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4 > > > > > > On 2002.01.09 17:33:15 -0500 Paul McLachlan wrote: > > > A persistence mapping on top of cci spi is what is needed for sure. > > > CAstor would ensure it's future by conforming to jca in my opinion. > > > > I agree, although I'm not entirely sure I understand what you are > > suggesting. The JDO spec has a rather confused view of what > > the jca spec > > says (I'd guess 70% of the specific feature references are > > wrong in some > > detail) but the basic idea they have is that a jdo implementation must > > expose the spi interfaces if it wishes to be useable in an > > app server. I > > thought Castor might be improved by changing its jdbc access > > to be to a > > jca-wrapped jdbc driver, thus making it easy to expose the > > spi interfaces. > > > > I'm not sure of the value of trying to expose cci outside of jdo. The > > jdo-style object navigation is more java-like and easier to > > use than cci. > > > > I think the use of cci is in supporting either a jdo > > implementation or cmp2 > > beans. IMHO cmp2 is kind of similar to jdo access. cmp2 has > > (at least in > > jboss) easily extensible metaprogramming interfaces (the spec includes > > transaction and security support for instance) whereas jdo handles > > inheritance and polymorphism better. > > > > Anyway, just my $0.02 > > > > david jencks > > > > > > > -Original Message- > > > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, 10 January 2002 12:51 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4 > > > > > > > > > > > > On 2002.01.09 01:14:28 -0500 Matthew Baird wrote: > > > > > any plans on using JCA to connect Castor JDO into JBoss? > > > > > > > > Both the jdo spec and I think the way to do this is to have > > > > the jdo layer > > > > act as a cache on top of a resource adapter, or to have the > > > > jca interfaces > > > > exposed from the "middle" of the jdo implementation with > > an additional > > > > Synchronization to the cache layer to make sure it is > > > > persisted before the > > > > tx commits. However when I enquired at Castor whether > > they had any > > > > interest in supporting this I was told that Castor had no > > > > interest in spec > > > > compliance. > > > > > > > > Although I suspect this was mostly due to lack of knowledge > > > > about the jca > > > > spec, it wasn't exactly encouraging. I may try again when I > > > > am done with > > > > my current project. > > > > > > > > david jencks > > > > > > > > > > -Original Message- > > > > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > > > > Sent: Tuesday, January 08, 2002 4:05 PM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4 > > > > > > > > > > > > > > > I think cvsroot/jboss/contrib/castorjdo never got tagged with > > > > > Branch_2_4_4 > > > > > when Jason did the reorganization of the build system. > > I suspect it > > > > > should > > > > > be, there are other changes likely to happen in > > > > > cvsroot/jboss/contrib/varia. Jason is probably the only > > > > one to know for > > > > > sure... > > > > > > > > > > ___ > > > > > JBoss-user mailing list > >
RE: [JBoss-user] Updating CastorJDO plugin for 2.4.4
How do I do inheritance with cmp2? Maybe that is why Castor will survive. > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED]] > Sent: Thursday, 10 January 2002 1:04 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4 > > > On 2002.01.09 17:33:15 -0500 Paul McLachlan wrote: > > A persistence mapping on top of cci spi is what is needed for sure. > > CAstor would ensure it's future by conforming to jca in my opinion. > > I agree, although I'm not entirely sure I understand what you are > suggesting. The JDO spec has a rather confused view of what > the jca spec > says (I'd guess 70% of the specific feature references are > wrong in some > detail) but the basic idea they have is that a jdo implementation must > expose the spi interfaces if it wishes to be useable in an > app server. I > thought Castor might be improved by changing its jdbc access > to be to a > jca-wrapped jdbc driver, thus making it easy to expose the > spi interfaces. > > I'm not sure of the value of trying to expose cci outside of jdo. The > jdo-style object navigation is more java-like and easier to > use than cci. > > I think the use of cci is in supporting either a jdo > implementation or cmp2 > beans. IMHO cmp2 is kind of similar to jdo access. cmp2 has > (at least in > jboss) easily extensible metaprogramming interfaces (the spec includes > transaction and security support for instance) whereas jdo handles > inheritance and polymorphism better. > > Anyway, just my $0.02 > > david jencks > > > > > -Original Message- > > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, 10 January 2002 12:51 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4 > > > > > > > > > On 2002.01.09 01:14:28 -0500 Matthew Baird wrote: > > > > any plans on using JCA to connect Castor JDO into JBoss? > > > > > > Both the jdo spec and I think the way to do this is to have > > > the jdo layer > > > act as a cache on top of a resource adapter, or to have the > > > jca interfaces > > > exposed from the "middle" of the jdo implementation with > an additional > > > Synchronization to the cache layer to make sure it is > > > persisted before the > > > tx commits. However when I enquired at Castor whether > they had any > > > interest in supporting this I was told that Castor had no > > > interest in spec > > > compliance. > > > > > > Although I suspect this was mostly due to lack of knowledge > > > about the jca > > > spec, it wasn't exactly encouraging. I may try again when I > > > am done with > > > my current project. > > > > > > david jencks > > > > > > > > -Original Message- > > > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > > > Sent: Tuesday, January 08, 2002 4:05 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4 > > > > > > > > > > > > I think cvsroot/jboss/contrib/castorjdo never got tagged with > > > > Branch_2_4_4 > > > > when Jason did the reorganization of the build system. > I suspect it > > > > should > > > > be, there are other changes likely to happen in > > > > cvsroot/jboss/contrib/varia. Jason is probably the only > > > one to know for > > > > sure... > > > > > > > > ___ > > > > JBoss-user mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > > > > > > ___ > > > JBoss-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > ___ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4
On 2002.01.09 17:33:15 -0500 Paul McLachlan wrote: > A persistence mapping on top of cci spi is what is needed for sure. > CAstor would ensure it's future by conforming to jca in my opinion. I agree, although I'm not entirely sure I understand what you are suggesting. The JDO spec has a rather confused view of what the jca spec says (I'd guess 70% of the specific feature references are wrong in some detail) but the basic idea they have is that a jdo implementation must expose the spi interfaces if it wishes to be useable in an app server. I thought Castor might be improved by changing its jdbc access to be to a jca-wrapped jdbc driver, thus making it easy to expose the spi interfaces. I'm not sure of the value of trying to expose cci outside of jdo. The jdo-style object navigation is more java-like and easier to use than cci. I think the use of cci is in supporting either a jdo implementation or cmp2 beans. IMHO cmp2 is kind of similar to jdo access. cmp2 has (at least in jboss) easily extensible metaprogramming interfaces (the spec includes transaction and security support for instance) whereas jdo handles inheritance and polymorphism better. Anyway, just my $0.02 david jencks > > > -Original Message- > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, 10 January 2002 12:51 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4 > > > > > > On 2002.01.09 01:14:28 -0500 Matthew Baird wrote: > > > any plans on using JCA to connect Castor JDO into JBoss? > > > > Both the jdo spec and I think the way to do this is to have > > the jdo layer > > act as a cache on top of a resource adapter, or to have the > > jca interfaces > > exposed from the "middle" of the jdo implementation with an additional > > Synchronization to the cache layer to make sure it is > > persisted before the > > tx commits. However when I enquired at Castor whether they had any > > interest in supporting this I was told that Castor had no > > interest in spec > > compliance. > > > > Although I suspect this was mostly due to lack of knowledge > > about the jca > > spec, it wasn't exactly encouraging. I may try again when I > > am done with > > my current project. > > > > david jencks > > > > > > -Original Message- > > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, January 08, 2002 4:05 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4 > > > > > > > > > I think cvsroot/jboss/contrib/castorjdo never got tagged with > > > Branch_2_4_4 > > > when Jason did the reorganization of the build system. I suspect it > > > should > > > be, there are other changes likely to happen in > > > cvsroot/jboss/contrib/varia. Jason is probably the only > > one to know for > > > sure... > > > > > > ___ > > > JBoss-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > > ___ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Updating CastorJDO plugin for 2.4.4
A persistence mapping on top of cci spi is what is needed for sure. CAstor would ensure it's future by conforming to jca in my opinion. > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED]] > Sent: Thursday, 10 January 2002 12:51 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4 > > > On 2002.01.09 01:14:28 -0500 Matthew Baird wrote: > > any plans on using JCA to connect Castor JDO into JBoss? > > Both the jdo spec and I think the way to do this is to have > the jdo layer > act as a cache on top of a resource adapter, or to have the > jca interfaces > exposed from the "middle" of the jdo implementation with an additional > Synchronization to the cache layer to make sure it is > persisted before the > tx commits. However when I enquired at Castor whether they had any > interest in supporting this I was told that Castor had no > interest in spec > compliance. > > Although I suspect this was mostly due to lack of knowledge > about the jca > spec, it wasn't exactly encouraging. I may try again when I > am done with > my current project. > > david jencks > > > > -Original Message- > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, January 08, 2002 4:05 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4 > > > > > > I think cvsroot/jboss/contrib/castorjdo never got tagged with > > Branch_2_4_4 > > when Jason did the reorganization of the build system. I suspect it > > should > > be, there are other changes likely to happen in > > cvsroot/jboss/contrib/varia. Jason is probably the only > one to know for > > sure... > > > > ___ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4
On 2002.01.09 01:14:28 -0500 Matthew Baird wrote: > any plans on using JCA to connect Castor JDO into JBoss? Both the jdo spec and I think the way to do this is to have the jdo layer act as a cache on top of a resource adapter, or to have the jca interfaces exposed from the "middle" of the jdo implementation with an additional Synchronization to the cache layer to make sure it is persisted before the tx commits. However when I enquired at Castor whether they had any interest in supporting this I was told that Castor had no interest in spec compliance. Although I suspect this was mostly due to lack of knowledge about the jca spec, it wasn't exactly encouraging. I may try again when I am done with my current project. david jencks > > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 08, 2002 4:05 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4 > > > I think cvsroot/jboss/contrib/castorjdo never got tagged with > Branch_2_4_4 > when Jason did the reorganization of the build system. I suspect it > should > be, there are other changes likely to happen in > cvsroot/jboss/contrib/varia. Jason is probably the only one to know for > sure... > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Updating CastorJDO plugin for 2.4.4
any plans on using JCA to connect Castor JDO into JBoss? -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 08, 2002 4:05 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4 I think cvsroot/jboss/contrib/castorjdo never got tagged with Branch_2_4_4 when Jason did the reorganization of the build system. I suspect it should be, there are other changes likely to happen in cvsroot/jboss/contrib/varia. Jason is probably the only one to know for sure... ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4
I think cvsroot/jboss/contrib/castorjdo never got tagged with Branch_2_4_4
when Jason did the reorganization of the build system. I suspect it should
be, there are other changes likely to happen in
cvsroot/jboss/contrib/varia. Jason is probably the only one to know for
sure...
david jencks
On 2002.01.08 18:29:58 -0500 Adrian Brock wrote:
> Thanks for the pointer.
>
> There seems to be some confusion with this package.
>
> It was moved to
>
> cvsroot/jboss/contrib/varia
>
> back in August last year, but the old directory was never removed?
>
> cvsroot/jboss/contrib/castorjdo
>
> This fix was done in varia last November.
>
> It never made it into 2.4.4 however :-(
>
> I assume castorjdo is dead and varia now contains the
> real version.
>
> Regards,
> Adrian
>
> >From: "Christopher D. Audley" <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: [JBoss-user] Updating CastorJDO plugin for 2.4.4
> >Date: Tue, 08 Jan 2002 16:55:45 -0500
> >
> >Seems Castor support broke for JBoss 2.4.4, so the jar files were just
> >yanked from the website without a word, despite a few questions from
> >users. I keep getting bad vibes about the viability of castor, things
> >like this don't help. Fortunately, I've only converted two of my EJB's
> >to castor when this happened, so it won't be too much work to back
> track.
> >
> >In the meantime, I've checked out the castorjdo plugin for JBoss and
> >updated it so that it will compile and run under JBoss 2.4.4.
> >Basically, I wrote a specialized java.io.Writer that encapsulates an
> >org.jboss.logging.Logger in the org.jboss.jdo.castor package for the
> >CastorJDO MBean. That class is attached. Then changes are made to
> >CastorJDOImpl.java to instanciate this class for getPrintWriter, patches
> >are attached. I've done some basic testing under 2.4.4, it compiles and
> >runs without generating exceptions and JDO functionality works.
> >
> >YMMV
> >
> >Cheers
> >Chris
> ><< LogWriter.java >>
> >Index: CastorJDOImpl.java
> >===
> >RCS file:
> >/cvsroot/jboss/contrib/castorjdo/src/main/org/jboss/jdo/castor/CastorJDOImpl.java,v
> >retrieving revision 1.12
> >diff -u -r1.12 CastorJDOImpl.java
> >--- CastorJDOImpl.java 2001/10/25 21:28:19 1.12
> >+++ CastorJDOImpl.java 2002/01/08 21:51:16
> >@@ -36,9 +36,6 @@
> > import org.exolab.castor.persist.spi.LogInterceptor;
> > import org.exolab.castor.xml.Unmarshaller;
> >
> >-import org.jboss.logging.Log;
> >-import org.jboss.logging.Logger;
> >-import org.jboss.logging.LogWriter;
> > import org.jboss.util.ServiceMBeanSupport;
> >
> > import org.jboss.proxy.Proxy;
> >@@ -327,12 +324,12 @@
> >
> >
> > public void exception(Exception except) {
> >-log.exception(except);
> >+log.error(except.toString());
> > }
> >
> > public PrintWriter getPrintWriter() {
> > if (writer == null) {
> >-writer = new LogWriter(log);
> >+writer = new PrintWriter( new LogWriter(log) );
> > }
> > return writer;
> > }
>
>
>
>
> _
> Join the worlds largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
>
> ___
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user
>
>
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Updating CastorJDO plugin for 2.4.4
Thanks for the pointer.
There seems to be some confusion with this package.
It was moved to
cvsroot/jboss/contrib/varia
back in August last year, but the old directory was never removed?
cvsroot/jboss/contrib/castorjdo
This fix was done in varia last November.
It never made it into 2.4.4 however :-(
I assume castorjdo is dead and varia now contains the
real version.
Regards,
Adrian
>From: "Christopher D. Audley" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: [JBoss-user] Updating CastorJDO plugin for 2.4.4
>Date: Tue, 08 Jan 2002 16:55:45 -0500
>
>Seems Castor support broke for JBoss 2.4.4, so the jar files were just
>yanked from the website without a word, despite a few questions from
>users. I keep getting bad vibes about the viability of castor, things
>like this don't help. Fortunately, I've only converted two of my EJB's
>to castor when this happened, so it won't be too much work to back track.
>
>In the meantime, I've checked out the castorjdo plugin for JBoss and
>updated it so that it will compile and run under JBoss 2.4.4.
>Basically, I wrote a specialized java.io.Writer that encapsulates an
>org.jboss.logging.Logger in the org.jboss.jdo.castor package for the
>CastorJDO MBean. That class is attached. Then changes are made to
>CastorJDOImpl.java to instanciate this class for getPrintWriter, patches
>are attached. I've done some basic testing under 2.4.4, it compiles and
>runs without generating exceptions and JDO functionality works.
>
>YMMV
>
>Cheers
>Chris
><< LogWriter.java >>
>Index: CastorJDOImpl.java
>===
>RCS file:
>/cvsroot/jboss/contrib/castorjdo/src/main/org/jboss/jdo/castor/CastorJDOImpl.java,v
>retrieving revision 1.12
>diff -u -r1.12 CastorJDOImpl.java
>--- CastorJDOImpl.java 2001/10/25 21:28:19 1.12
>+++ CastorJDOImpl.java 2002/01/08 21:51:16
>@@ -36,9 +36,6 @@
> import org.exolab.castor.persist.spi.LogInterceptor;
> import org.exolab.castor.xml.Unmarshaller;
>
>-import org.jboss.logging.Log;
>-import org.jboss.logging.Logger;
>-import org.jboss.logging.LogWriter;
> import org.jboss.util.ServiceMBeanSupport;
>
> import org.jboss.proxy.Proxy;
>@@ -327,12 +324,12 @@
>
>
> public void exception(Exception except) {
>-log.exception(except);
>+log.error(except.toString());
> }
>
> public PrintWriter getPrintWriter() {
> if (writer == null) {
>-writer = new LogWriter(log);
>+writer = new PrintWriter( new LogWriter(log) );
> }
> return writer;
> }
_
Join the worlds largest e-mail service with MSN Hotmail.
http://www.hotmail.com
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
