Pete,
I don't think we are arguing componentized or not. It is about the granularity, or the way things should divided. There are a few ways to componentized. For things that are have put together to work, divide them in packages is enough. And, there are cases where plug-in architecture make more senses. Make its own module is not solution for a problems. We can also use the build script to control the package dependency. There are many modules in jBoss. How many modules does jBoss Messaging have? I bet it is not seven. If they are conceptually or functionally separated, then they should be separated. If they are classes specifically written, then they should be kept together. How should code being divided? It is not something somebody can give comment on without pretty good understand of what the code does. For example, should distributed cache, and local cache put together. Sound like it is, right? But, I don't think so. In my opinion, distributed cache should be implemented as cache purging policy. It should actually not part of cache implementation, and they shouldn't be put together. Using MBean or not, I don't know. I am not familiar with JMX or Avalon. That's why I haven't give my comment on any of those thread yet. Thomas -----Original Message----- >From: Pete Carapetyan [mailto:[EMAIL PROTECTED]] >Sent: Monday, April 29, 2002 5:42 PM >To: [EMAIL PROTECTED] >Subject: Re: [castor-dev] Strategy Proposal (repost - was: Castor JDO Status) > >Thomas and Ilia: > >Have been following this thread about componenting up Castor with JMX >and/or JCA and/or Avalon, with great interest, due to a very exact and >specific interest in an Avalon/Castor component. > >Ilia, you have obviously arrived at the same place as many of us, >discovering that the beauty of well written code quickly becomes less >beautiful as it is discovered to be too tightly coupled. >But after many many conversations with others about this problem, it is >my opinion that this topic is not something that someone who is trying >to get some code working can care about, or even understand in their >bones.. It is only after the code is working, and you are trying to get >it to work with something else and hitting a brick wall that the light >goes off, and you suddenly realize that tightly coupled code has been >holding you back as much as it is helping you. Until that moment, no >amount of cajoling or complaining will help the person to that place of >understanding.. > >This is made worse by the fact that a visit to Avalon or another user of >Component Oriented Programming is not always such an easily digested thing. > >To Thomas Yip, I understand completely why this seems like is way out in >left field to you. But the discipline required to component it up can >make your code dramatically easier to maintain and get people to >contribute to, in the long run. Whereas it would definitely slow you >down in the short run. Pick your poison. > >For me the choice is easy, I already have a good short term solution. >The long run is all that is worth worrying about. > > >Ilia Iourovitski wrote: > >>Thomas >> >>The whole point not about feature requests, but about >>dividing Castor JDO in peaces which can be understood >>independently, so developers can add/ modify code in >>timely manner. >>As far as I remember half a year ago I ask you to add >>String FieldMolder::getName() so I can implement query >>by example. At that time I was told >>that it is a Castor's private class and I shouldn't >>touch because it might be change during future >>refactoring. >>Thus the question is which interfaces/classes can be >>accessed freely in order to implement query by >>examples, constraints, SODA API. >> >> >>Modularization in that respect is just publishing >>interfaces and their dependencies. >> >>Splitting castor JDO into bunch of components (Avalon >>style or JMX beans) "might" makes life for castor >>users >>ease because every component will implement some >>interface, life cycle, will have configuration file, >>will publish dependency on other components. >>Particular developer might copy existing component >>and simply modify it, and plug it back. >>Right now I think every body has some version of >>Castor >>from cvs with modifications/patches. >> >> >> >> >> >> >>Thanks >> >>Ilia >> >>Additional comments see below. >> >> >>--- Thomas Yip <[EMAIL PROTECTED]> wrote: >> >>> >>>I see. You submitted a few feature requests. >>>However, my guess are many of those doesn't >>>really solve by modularization. >>> >>>See below. >>> >>>>>>2. Configuration: support for various connection >>>>>>pools/ >>>>>>containers, ability to construct >>>>>> >>>programmatically >>> >>>>>with >>>>> >>>>>>user supplied connection, connection to the >>>>>> >>>>>multiple >>>>> >>>>>>databases. >>>>>> >>>>>Did you confused package with module? >>>>>Configuration highly depends on how the >>>>>configuration >>>>>be used. How can it be a module of it own. I >>>>> >>>don't >>> >>>>>get it. >>>>> >>>>Currently JDO uses database.xml as configuration >>>> >>>file. >>> >>>>There is no way to build it programmatically, i.e >>>>construct DataSource and set it to JDO. >>>>Next there number of JDBC conneciton pools which >>>> >>>have >>> >>>>different configurations. >>>> >>>I think it one is a commonly requested feature too. >>>It >>>can be added to the request list. >>>However, I don't think split it out helps solve the >>>problem, >>>or encourage parallel development. >>> >>>>But is it possible to use this peace of code. >>>> >>>I don't see why you want to use the code that way. >>> >>>>Database lock (FOR UPDATE) doesn't have timeout. >>>>Oracle >>>>provides (FOR UPDATE NO WAIT) but it is not used by >>>>Castor. >>>> >>>While what you said is true... >>> >>>>There is no way to try to get lock of object >>>>for given period of programmatically. >>>> >>>... I don't see, again, splitting it out is a >>>solution. >>> >>>>And distributed cashe needs distributed lock. >>>> >>>I don't think all distributed cache design requires >>>distributed lock. Some does. And, I don't think >>>those uses distributed locks suit what castor is >>>used for. >>> >>>If something is implemented and not used right now, >>>the chance that it will be used later is very >>>unlikely, >>>or at least subject to complete rewrite. It is much >>>wiser >>>to worry it later. >>> >>>>>>6. Transactions. >>>>>> >>>>>Castor is transaction aware. Castor doesn't not >>>>>intent to >>>>>be TP monitor. It simply uses transaction. The >>>>> >>>code >>> >>>>>definitely can't be spun out. >>>>> >>>>Currently there is no way to have object id local >>>> >>>per >>> >>>>transaction. >>>> >>>I don't get what you mean. For Castor, the design >>>is each transaction have its own objects "view" of >>>database. Identity is global. >>> >>For optimistic transaction you might want to have >>identity local and check object version at commit >>time. >>Castor do support long transaction via unlimited cache >>and timestamp, but it is not ideal solution for all >>cases >> >>>I don't see modularize helps, either. >>> >>> >>>Thomas >>> >>> >>----------------------------------------------------------- >> >>>If you wish to unsubscribe from this mailing, send >>>mail to >>>[EMAIL PROTECTED] with a subject of: >>> unsubscribe castor-dev >>> >> >>__________________________________________________ >>Do You Yahoo!? >>Yahoo! Health - your guide to health and wellness >>http://health.yahoo.com >> >>----------------------------------------------------------- >>If you wish to unsubscribe from this mailing, send mail to >>[EMAIL PROTECTED] with a subject of: >> unsubscribe castor-dev >> >> > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
