Menu
▾
▴
springframework-developer — Spring Framework developers list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <rod...@in...> - 2003-05-30 13:49:21
|
JP proposed: >One tag for every kind of Collection including arrays which are not really collections but have the same structure. One tag for the maps. Yes, this should work. We don't need a special XML tag for arrays, as introspection results should allow us to convert the values to arrays in AbstractBeanFactory. Regards, Rod |
|
From: Isabelle M. <isa...@me...> - 2003-05-30 13:31:56
|
Hi Rod, I agree with one tag for collections and one for maps as well. Isabelle On Fri, May 30, 2003 at 08:57:29AM -0400, rod...@in... wrote: > JP proposed: > > >One tag for every kind of Collection including arrays which > are not really collections but have the same structure. > One tag for the maps. > > Yes, this should work. We don't need a special XML tag for > arrays, as introspection results should allow us to convert > the values to arrays in AbstractBeanFactory. > > Regards, > Rod > > -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: Kopylenko, D. <dko...@ac...> - 2003-05-30 13:16:42
|
I'm for one tag for Collections and one tag for Maps Regards, Dmitriy. -----Original Message----- From: JP Pawlak [mailto:jp....@ti...]=20 Sent: Friday, May 30, 2003 8:40 AM To: 'Isabelle Muszynski'; 'Rod Johnson' Cc: spr...@li... Subject: RE : RE : [Springframework-developer] DTD Hi Isabelle, If a Map could be a Collection, make sure that it would be so in Java.=20 Elements in a collection are single: an Object. Elements in a Map are double: a key + an Object. The structure cannot be the same as a Map element always needs a key = and a collection never. I don't see a more generic solution as Rod's: One tag for every kind of Collection including arrays which are not = really collections but have the same structure. One tag for the maps. The difference will be the presence of a key attribute or sub-element = in map-entries which will not exist in collection-entries. In all cases, the XML will dictate between Maps and Collections by the = use of a key descriptor, even if we use the same envelopping tag.=20 We have not the choice. Regards, Jean-Pierre > -----Message d'origine----- > De : spr...@li...=20 > [mailto:spr...@li...] > De la part de Isabelle Muszynski > Envoy=C3=A9 : vendredi 30 mai 2003 13:55 > =C3=80 : Rod Johnson > Cc : spr...@li... > Objet : Re: RE : [Springframework-developer] DTD >=20 >=20 > Hi Rod, >=20 > I think it all depencs what the point is. If we want the xml=20 > to dictate the data structure used to represent the bean,=20 > then yes, we need a map, list, array etc tag. If the point is=20 > for the xml to indicate a collection, then a single=20 > collection tag should be sufficient. >=20 > Isabelle >=20 > On Fri, May 30, 2003 at 11:36:03AM +0100, Rod Johnson wrote: > > JP, > >=20 > > I like this. It's an improvement. We could even support=20 > object keys by=20 > > having a <key> subelement that supports a<value> or ref.=20 > But that's=20 > > in the future. > >=20 > > Isabelle wrote "I like the collections idea, but not the different=20 > > keywords for it (map, collection). All the user has to know is that = > > it's a collection, not how we implment it internally." (I=20 > don't think=20 > > you sent this to the list.) But aren't maps different to=20 > collections=20 > > or arrays (which we might also want to support eventually?)=20 > Two values=20 > > to manage, not just one? > >=20 > > I'm inclined to support Maps like this in 0.8. > >=20 > > Regards, > > Rod > >=20 > > ----- Original Message ----- > > From: "JP Pawlak" <jp....@ti...> > > To: <rod...@in...> > > Cc: <spr...@li...> > > Sent: Friday, May 30, 2003 11:05 AM > > Subject: RE : RE : [Springframework-developer] DTD > >=20 > >=20 > > Rod, > >=20 > > I'm inclined too to favor this. > > But I see another improvement without having now the right solution = > > about the map. In UrlHandlerMapping the data is in fact a bean=20 > > reference and this is not already checked. > > In methodNameResolver in contrast, it's a simple text (method = name). > > Perhaps will we have an unique value/ref in the map entry=20 > body instead > > of simple text? > >=20 > > <property name=3D"mappings"> > > <map> > > <entry key=3D"/welcome.html"><ref=20 > bean=3D"pagedListController"/></entry> > > <entry key=3D"/detail.html"><ref=20 > bean=3D"pagedListController"/></entry> > > </map> > > </property> > >=20 > > <property name=3D"mappings"> > > <map> > > <entry key=3D"/welcome.html"><value>showMain</value></entry> > > <entry key=3D"/detail.html"><value>showDetail</value></entry> > > </map> > > </property> > >=20 > > Regards, > > Jean-Pierre > >=20 > >=20 > > > -----Message d'origine----- > > > De : rod...@in...=20 > > > [mailto:rod...@in...] > > > Envoy=C3=83=C2=A9 : vendredi 30 mai 2003 11:24 > > > =C3=83=E2=82=AC : JP Pawlak > > > Cc : 'Rod Johnson';=20 > spr...@li... > > > Objet : Re: RE : [Springframework-developer] DTD > > > > > > > > > JP, > > > > > > I agree, formalizing map support would be an improvement. I'm not = > > > sure we can do it for 0.8, though. Presently it's handled by a=20 > > > PropertyEditor. > > > > > > I wonder if it means we should introduce additional container=20 > > > elements <list> and <map> into our DTD? e.g.: > > > > > > <property name=3D"simple"><value>val</value></property> > > > <property name=3D"mappings"> > > > <map> > > > <entry key=3D"/welcome.html">pagedListController</entry> > > > <entry key=3D"/detail.html">pagedListController</entry> > > > </map> > > > </property> > > > > > > <property name=3D"coll"> > > > <collection> > > > <value>val</value> > > > <ref bean=3D"foo"/> > > > </collection> > > > </property> > > > > > > It's getting still more verbose, but it would be easier=20 > to parse and=20 > > > is more elegant. (Don't need to guess whether a value/ref=20 > is part of=20 > > > a collection.) > > > > > > I'm inclined to favour this. I could probably implement=20 > it by early=20 > > > next week (including maps). > > > > > > Regards, > > > Rod > > > > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.net email is sponsored by: eBay > > Get office equipment for less on eBay!=20 > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > > _______________________________________________ > > Springframework-developer mailing list=20 > > Spr...@li... > >=20 > https://lists.sourceforge.net/lists/listinfo/s> = pringframework-developer > >=20 > >=20 >=20 > --=20 > Isabelle Muszynski > Software Engineer > Zandweellaan 4 > 2660 Antwerpen > Belgium > Tel. 32-(0)3-830 18 54 > Mobile: 32-(0)485 49 50 89 > Email: isa...@me... > Website: www.meta-logix.com >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay!=20 > http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5 >=20 > _______________________________________________ >=20 > Springframework-developer mailing list=20 > Spr...@li... > = https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 ------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: JP P. <jp....@ti...> - 2003-05-30 13:07:42
|
Hi Isabelle, If a Map could be a Collection, make sure that it would be so in Java.=20 Elements in a collection are single: an Object. Elements in a Map are double: a key + an Object. The structure cannot be the same as a Map element always needs a key and = a collection never. I don't see a more generic solution as Rod's: One tag for every kind of Collection including arrays which are not = really collections but have the same structure. One tag for the maps. The difference will be the presence of a key attribute or sub-element in = map-entries which will not exist in collection-entries. In all cases, the XML will dictate between Maps and Collections by the = use of a key descriptor, even if we use the same envelopping tag.=20 We have not the choice. Regards, Jean-Pierre > -----Message d'origine----- > De : spr...@li...=20 > [mailto:spr...@li...] > De la part de Isabelle Muszynski > Envoy=C3=A9 : vendredi 30 mai 2003 13:55 > =C3=80 : Rod Johnson > Cc : spr...@li... > Objet : Re: RE : [Springframework-developer] DTD >=20 >=20 > Hi Rod, >=20 > I think it all depencs what the point is. If we want the xml=20 > to dictate the data structure used to represent the bean,=20 > then yes, we need a map, list, array etc tag. If the point is=20 > for the xml to indicate a collection, then a single=20 > collection tag should be sufficient. >=20 > Isabelle >=20 > On Fri, May 30, 2003 at 11:36:03AM +0100, Rod Johnson wrote: > > JP, > >=20 > > I like this. It's an improvement. We could even support=20 > object keys by=20 > > having a <key> subelement that supports a<value> or ref.=20 > But that's=20 > > in the future. > >=20 > > Isabelle wrote "I like the collections idea, but not the different=20 > > keywords for it (map, collection). All the user has to know is that=20 > > it's a collection, not how we implment it internally." (I=20 > don't think=20 > > you sent this to the list.) But aren't maps different to=20 > collections=20 > > or arrays (which we might also want to support eventually?)=20 > Two values=20 > > to manage, not just one? > >=20 > > I'm inclined to support Maps like this in 0.8. > >=20 > > Regards, > > Rod > >=20 > > ----- Original Message ----- > > From: "JP Pawlak" <jp....@ti...> > > To: <rod...@in...> > > Cc: <spr...@li...> > > Sent: Friday, May 30, 2003 11:05 AM > > Subject: RE : RE : [Springframework-developer] DTD > >=20 > >=20 > > Rod, > >=20 > > I'm inclined too to favor this. > > But I see another improvement without having now the right solution=20 > > about the map. In UrlHandlerMapping the data is in fact a bean=20 > > reference and this is not already checked. > > In methodNameResolver in contrast, it's a simple text (method name). > > Perhaps will we have an unique value/ref in the map entry=20 > body instead > > of simple text? > >=20 > > <property name=3D"mappings"> > > <map> > > <entry key=3D"/welcome.html"><ref=20 > bean=3D"pagedListController"/></entry> > > <entry key=3D"/detail.html"><ref=20 > bean=3D"pagedListController"/></entry> > > </map> > > </property> > >=20 > > <property name=3D"mappings"> > > <map> > > <entry key=3D"/welcome.html"><value>showMain</value></entry> > > <entry key=3D"/detail.html"><value>showDetail</value></entry> > > </map> > > </property> > >=20 > > Regards, > > Jean-Pierre > >=20 > >=20 > > > -----Message d'origine----- > > > De : rod...@in...=20 > > > [mailto:rod...@in...] > > > Envoy=C3=83=C2=A9 : vendredi 30 mai 2003 11:24 > > > =C3=83=E2=82=AC : JP Pawlak > > > Cc : 'Rod Johnson';=20 > spr...@li... > > > Objet : Re: RE : [Springframework-developer] DTD > > > > > > > > > JP, > > > > > > I agree, formalizing map support would be an improvement. I'm not=20 > > > sure we can do it for 0.8, though. Presently it's handled by a=20 > > > PropertyEditor. > > > > > > I wonder if it means we should introduce additional container=20 > > > elements <list> and <map> into our DTD? e.g.: > > > > > > <property name=3D"simple"><value>val</value></property> > > > <property name=3D"mappings"> > > > <map> > > > <entry key=3D"/welcome.html">pagedListController</entry> > > > <entry key=3D"/detail.html">pagedListController</entry> > > > </map> > > > </property> > > > > > > <property name=3D"coll"> > > > <collection> > > > <value>val</value> > > > <ref bean=3D"foo"/> > > > </collection> > > > </property> > > > > > > It's getting still more verbose, but it would be easier=20 > to parse and=20 > > > is more elegant. (Don't need to guess whether a value/ref=20 > is part of=20 > > > a collection.) > > > > > > I'm inclined to favour this. I could probably implement=20 > it by early=20 > > > next week (including maps). > > > > > > Regards, > > > Rod > > > > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.net email is sponsored by: eBay > > Get office equipment for less on eBay!=20 > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > > _______________________________________________ > > Springframework-developer mailing list=20 > > Spr...@li... > >=20 > https://lists.sourceforge.net/lists/listinfo/s> = pringframework-developer > >=20 > >=20 >=20 > --=20 > Isabelle Muszynski > Software Engineer > Zandweellaan 4 > 2660 Antwerpen > Belgium > Tel. 32-(0)3-830 18 54 > Mobile: 32-(0)485 49 50 89 > Email: isa...@me... > Website: www.meta-logix.com >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay!=20 > http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5 >=20 > _______________________________________________ >=20 > Springframework-developer mailing list=20 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 |
|
From: Isabelle M. <isa...@me...> - 2003-05-30 11:55:29
|
Hi Rod, I think it all depencs what the point is. If we want the xml to dictate the data structure used to represent the bean, then yes, we need a map, list, array etc tag. If the point is for the xml to indicate a collection, then a single collection tag should be sufficient. Isabelle On Fri, May 30, 2003 at 11:36:03AM +0100, Rod Johnson wrote: > JP, > > I like this. It's an improvement. We could even support object keys by > having a <key> subelement that supports a<value> or ref. But that's in the > future. > > Isabelle wrote "I like the collections idea, but not the different keywords > for it (map, collection). All the user has to know is that it's a > collection, not how we implment it internally." (I don't think you sent this > to the list.) But aren't maps different to collections or arrays (which we > might also want to support eventually?) Two values to manage, not just one? > > I'm inclined to support Maps like this in 0.8. > > Regards, > Rod > > ----- Original Message ----- > From: "JP Pawlak" <jp....@ti...> > To: <rod...@in...> > Cc: <spr...@li...> > Sent: Friday, May 30, 2003 11:05 AM > Subject: RE : RE : [Springframework-developer] DTD > > > Rod, > > I'm inclined too to favor this. > But I see another improvement without having now the right solution > about the map. > In UrlHandlerMapping the data is in fact a bean reference and this is > not already checked. > In methodNameResolver in contrast, it's a simple text (method name). > Perhaps will we have an unique value/ref in the map entry body instead > of simple text? > > <property name="mappings"> > <map> > <entry key="/welcome.html"><ref bean="pagedListController"/></entry> > <entry key="/detail.html"><ref bean="pagedListController"/></entry> > </map> > </property> > > <property name="mappings"> > <map> > <entry key="/welcome.html"><value>showMain</value></entry> > <entry key="/detail.html"><value>showDetail</value></entry> > </map> > </property> > > Regards, > Jean-Pierre > > > > -----Message d'origine----- > > De : rod...@in... [mailto:rod...@in...] > > Envoyé : vendredi 30 mai 2003 11:24 > > à : JP Pawlak > > Cc : 'Rod Johnson'; spr...@li... > > Objet : Re: RE : [Springframework-developer] DTD > > > > > > JP, > > > > I agree, formalizing map support would be an improvement. I'm > > not sure we can do it for 0.8, though. Presently it's handled > > by a PropertyEditor. > > > > I wonder if it means we should introduce additional container > > elements <list> and <map> into our DTD? e.g.: > > > > <property name="simple"><value>val</value></property> > > <property name="mappings"> > > <map> > > <entry key="/welcome.html">pagedListController</entry> > > <entry key="/detail.html">pagedListController</entry> > > </map> > > </property> > > > > <property name="coll"> > > <collection> > > <value>val</value> > > <ref bean="foo"/> > > </collection> > > </property> > > > > It's getting still more verbose, but it would be easier to > > parse and is more elegant. (Don't need to guess whether a > > value/ref is part of a collection.) > > > > I'm inclined to favour this. I could probably implement it by > > early next week (including maps). > > > > Regards, > > Rod > > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: Rod J. <rod...@in...> - 2003-05-30 10:37:56
|
JP, I like this. It's an improvement. We could even support object keys by having a <key> subelement that supports a<value> or ref. But that's in the future. Isabelle wrote "I like the collections idea, but not the different keywords for it (map, collection). All the user has to know is that it's a collection, not how we implment it internally." (I don't think you sent this to the list.) But aren't maps different to collections or arrays (which we might also want to support eventually?) Two values to manage, not just one? I'm inclined to support Maps like this in 0.8. Regards, Rod ----- Original Message ----- From: "JP Pawlak" <jp....@ti...> To: <rod...@in...> Cc: <spr...@li...> Sent: Friday, May 30, 2003 11:05 AM Subject: RE : RE : [Springframework-developer] DTD Rod, I'm inclined too to favor this. But I see another improvement without having now the right solution about the map. In UrlHandlerMapping the data is in fact a bean reference and this is not already checked. In methodNameResolver in contrast, it's a simple text (method name). Perhaps will we have an unique value/ref in the map entry body instead of simple text? <property name="mappings"> <map> <entry key="/welcome.html"><ref bean="pagedListController"/></entry> <entry key="/detail.html"><ref bean="pagedListController"/></entry> </map> </property> <property name="mappings"> <map> <entry key="/welcome.html"><value>showMain</value></entry> <entry key="/detail.html"><value>showDetail</value></entry> </map> </property> Regards, Jean-Pierre > -----Message d'origine----- > De : rod...@in... [mailto:rod...@in...] > Envoyé : vendredi 30 mai 2003 11:24 > À : JP Pawlak > Cc : 'Rod Johnson'; spr...@li... > Objet : Re: RE : [Springframework-developer] DTD > > > JP, > > I agree, formalizing map support would be an improvement. I'm > not sure we can do it for 0.8, though. Presently it's handled > by a PropertyEditor. > > I wonder if it means we should introduce additional container > elements <list> and <map> into our DTD? e.g.: > > <property name="simple"><value>val</value></property> > <property name="mappings"> > <map> > <entry key="/welcome.html">pagedListController</entry> > <entry key="/detail.html">pagedListController</entry> > </map> > </property> > > <property name="coll"> > <collection> > <value>val</value> > <ref bean="foo"/> > </collection> > </property> > > It's getting still more verbose, but it would be easier to > parse and is more elegant. (Don't need to guess whether a > value/ref is part of a collection.) > > I'm inclined to favour this. I could probably implement it by > early next week (including maps). > > Regards, > Rod > |
|
From: Isabelle M. <isa...@me...> - 2003-05-30 10:16:51
|
Hi JP, everyone, I like that. Isabelle On Fri, May 30, 2003 at 12:05:08PM +0200, JP Pawlak wrote: > Rod, > > I'm inclined too to favor this. > But I see another improvement without having now the right solution > about the map. > In UrlHandlerMapping the data is in fact a bean reference and this is > not already checked. > In methodNameResolver in contrast, it's a simple text (method name). > Perhaps will we have an unique value/ref in the map entry body instead > of simple text? > > <property name="mappings"> > <map> > <entry key="/welcome.html"><ref bean="pagedListController"/></entry> > <entry key="/detail.html"><ref bean="pagedListController"/></entry> > </map> > </property> > > <property name="mappings"> > <map> > <entry key="/welcome.html"><value>showMain</value></entry> > <entry key="/detail.html"><value>showDetail</value></entry> > </map> > </property> > > Regards, > Jean-Pierre > > > > -----Message d'origine----- > > De : rod...@in... [mailto:rod...@in...] > > Envoyé : vendredi 30 mai 2003 11:24 > > à : JP Pawlak > > Cc : 'Rod Johnson'; spr...@li... > > Objet : Re: RE : [Springframework-developer] DTD > > > > > > JP, > > > > I agree, formalizing map support would be an improvement. I'm > > not sure we can do it for 0.8, though. Presently it's handled > > by a PropertyEditor. > > > > I wonder if it means we should introduce additional container > > elements <list> and <map> into our DTD? e.g.: > > > > <property name="simple"><value>val</value></property> > > <property name="mappings"> > > <map> > > <entry key="/welcome.html">pagedListController</entry> > > <entry key="/detail.html">pagedListController</entry> > > </map> > > </property> > > > > <property name="coll"> > > <collection> > > <value>val</value> > > <ref bean="foo"/> > > </collection> > > </property> > > > > It's getting still more verbose, but it would be easier to > > parse and is more elegant. (Don't need to guess whether a > > value/ref is part of a collection.) > > > > I'm inclined to favour this. I could probably implement it by > > early next week (including maps). > > > > Regards, > > Rod > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: JP P. <jp....@ti...> - 2003-05-30 10:05:25
|
Rod, I'm inclined too to favor this. But I see another improvement without having now the right solution about the map. In UrlHandlerMapping the data is in fact a bean reference and this is not already checked. In methodNameResolver in contrast, it's a simple text (method name). Perhaps will we have an unique value/ref in the map entry body instead of simple text? <property name=3D"mappings"> <map> <entry key=3D"/welcome.html"><ref = bean=3D"pagedListController"/></entry> <entry key=3D"/detail.html"><ref = bean=3D"pagedListController"/></entry> </map> </property> <property name=3D"mappings"> <map> <entry key=3D"/welcome.html"><value>showMain</value></entry> <entry key=3D"/detail.html"><value>showDetail</value></entry> </map> </property> Regards, Jean-Pierre > -----Message d'origine----- > De : rod...@in... [mailto:rod...@in...]=20 > Envoy=E9 : vendredi 30 mai 2003 11:24 > =C0 : JP Pawlak > Cc : 'Rod Johnson'; spr...@li... > Objet : Re: RE : [Springframework-developer] DTD >=20 >=20 > JP, >=20 > I agree, formalizing map support would be an improvement. I'm=20 > not sure we can do it for 0.8, though. Presently it's handled=20 > by a PropertyEditor. >=20 > I wonder if it means we should introduce additional container=20 > elements <list> and <map> into our DTD? e.g.: >=20 > <property name=3D"simple"><value>val</value></property> > <property name=3D"mappings"> > <map> > <entry key=3D"/welcome.html">pagedListController</entry> > <entry key=3D"/detail.html">pagedListController</entry> > </map> > </property> >=20 > <property name=3D"coll"> > <collection> > <value>val</value> > <ref bean=3D"foo"/> > </collection> > </property> >=20 > It's getting still more verbose, but it would be easier to=20 > parse and is more elegant. (Don't need to guess whether a=20 > value/ref is part of a collection.) >=20 > I'm inclined to favour this. I could probably implement it by=20 > early next week (including maps). >=20 > Regards, > Rod >=20 |
|
From: <jue...@we...> - 2003-05-30 09:35:18
|
RmluZSwgSSdsbCBoYXZlIGEgbG9vayBhdCBpdC4NCg0KSnVlcmdlbg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiByb2Quam9obnNvbkBpbnRlcmZhY2UyMS5jb20gW21haWx0 bzpyb2Quam9obnNvbkBpbnRlcmZhY2UyMS5jb21dDQpTZW50OiBGcmlkYXksIE1heSAzMCwgMjAw MyAxMToyOSBBTQ0KVG86IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF0NCkNjOiBzcHJpbmdmcmFt ZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KU3ViamVjdDogUkU6IFJFIDog W1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIERURA0KDQoNCkp1ZXJnZW4sDQoNCk1heWJlIHlv dSBjYW4gc29ydCBvdXQgdGhlIHZhbGlkYXRpb24gaXNzdWU/IEkgd2lsbCBpbXBsZW1lbnQgDQp3 aGF0ZXZlciBwYXJzaW5nIHdlIGRlY2lkZSBvbi4NCg0KUmVnYXJkcywNClJvZA0K |
|
From: <rod...@in...> - 2003-05-30 09:28:35
|
Juergen, Maybe you can sort out the validation issue? I will implement whatever parsing we decide on. Regards, Rod |
|
From: <rod...@in...> - 2003-05-30 09:24:21
|
JP, I agree, formalizing map support would be an improvement. I'm not sure we can do it for 0.8, though. Presently it's handled by a PropertyEditor. I wonder if it means we should introduce additional container elements <list> and <map> into our DTD? e.g.: <property name="simple"><value>val</value></property> <property name="mappings"> <map> <entry key="/welcome.html">pagedListController</entry> <entry key="/detail.html">pagedListController</entry> </map> </property> <property name="coll"> <collection> <value>val</value> <ref bean="foo"/> </collection> </property> It's getting still more verbose, but it would be easier to parse and is more elegant. (Don't need to guess whether a value/ref is part of a collection.) I'm inclined to favour this. I could probably implement it by early next week (including maps). Regards, Rod |
|
From: <jue...@we...> - 2003-05-30 08:52:28
|
I forgot to mention that Hibernate uses a Dom4J SAXReader that it = registers the EntityResolver with. But according to the docs, a JAXP = DocumentBuilder supports EntityResolver too. So let's simply adopt the = idea! I've attached the DTDEntityResolver implementation from Hibernate = 2.0 RC2. Juergen -----Original Message----- From: j=FCrgen h=F6ller [werk3AT]=20 Sent: Friday, May 30, 2003 9:47 AM To: spr...@li... Subject: RE: RE : [Springframework-developer] DTD Hi everyone, I'm also for breaking backward compatibility now. I guess the hassle = will only get more if we don't. Regarding DTD retrieval: Hibernate uses a respective implementation of = org.xml.sax.EntityResolver to avoid loading public URIs via HTTP, = looking up "http://hibernate.sourceforge.net/" URIs in the classpath = under "net/sf/hibernate/" (contained in the Hibernate JAR). Maybe we can = adopt a similar approach. Unfortunately, there's an issue when executing Hibernate within JUnit = (console version): It doesn't find its classpath DTDs then, falling back = to the HTTP download. This has probably something to do with JUnit's = classloading behavior, but I haven't been able to figure it out yet. I currently have an issue with Hibernate when executing within JUnit. Juergen -----Original Message----- From: JP Pawlak [mailto:jp....@ti...] Sent: Friday, May 30, 2003 4:00 AM To: tri...@tr...; 'Rod Johnson' Cc: spr...@li... Subject: RE : [Springframework-developer] DTD Hi Rod, I agree with Thomas for breaking backward compatibility now. As long as it is not released, only a few people have to change their files. For validating: it has to be checked how the parser retrieve the DTD based on its name (before the URI). It's normally parser dependent. The URI gives a chance to found it anyway. This name has to be fixed using the convention "-//<organisation>//<format inside the organisation>//<language>". Jean-Pierre > -----Message d'origine----- > De : spr...@li...=20 > [mailto:spr...@li...] > De la part de tri...@tr... > Envoy=E9 : vendredi 30 mai 2003 03:31 > =C0 : Rod Johnson > Cc : spr...@li... > Objet : Re: [Springframework-developer] DTD >=20 >=20 > Rod, >=20 > I vote for breaking backward compatibility now, before the=20 > first release. As soon as you release a deprecated feature,=20 > you know that there is always someone that is going to use it=20 > and later complain when it is gone :-) >=20 > As for the DTD, could it go in the package where the=20 > DocumentBuilderFactory lives? If the XML files are not=20 > valid, how are you going to use them - guess what is missing?=20 > I'd say force them to be valid as long as whe throw a=20 > clearly worded exception if they are not. >=20 > --Thomas >=20 >=20 > > I knew I forgot some further questions: > >=20 > > - Where should the DTD go? > > - Should we require all XML files to be valid? > >=20 > > - How long should I retain the present backward compatibility in=20 > > parsing XML? 0.8? 0.9? Break it now? > >=20 > > Regards, > > Rod > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.net email is sponsored by: eBay > > Get office equipment for less on eBay!=20 > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > > _______________________________________________ > > Springframework-developer mailing list=20 > > Spr...@li... > >=20 > https://lists.sourceforge.net/lists/listinfo/s> pringframework-developer > >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay!=20 > http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5 >=20 > _______________________________________________ >=20 > Springframework-developer mailing list=20 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 ------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: JP P. <jp....@ti...> - 2003-05-30 08:38:14
|
Rod, - Juergen has advanced on DTD retrieving. - I will try to examine the behavior of the code. - Mappings Yes, what I made is the more stupid. Nevertheless, I didn't see that our DTD doesn't solve the main issue in our xml file. It will be very difficult to explain why a property style comes in the middle of the xml. This irritate me and will surely provoquing a bunch of criticisms. XMl can aceept it, but not understand. Imagine that a user will not have an equality sign in a line or have many or if lines were assembled. In all these cases, the document will be valid! It's not clean, we have to rest in a unique logic even if it's a little more verbose. My proposal is to create a third subelement of property, saying map, not mixable with others. <property name=3D"mappings"> <map key=3D"/welcome.html">pagedListController</value> <map key=3D"/detail.html">pagedListController</value> </property> And in the DTD <!ELEMENT property ((value | ref)+ | map+)> ... <!ELEMENT map (#PCDATA)> <!ATTLIST map key CDATA #REQUIRED > > -----Message d'origine----- > De : spr...@li...=20 > [mailto:spr...@li...] > De la part de Rod Johnson > Envoy=E9 : vendredi 30 mai 2003 09:49 > =C0 : JP Pawlak; spr...@li... > Objet : Re: [Springframework-developer] DTD >=20 >=20 > JP, >=20 > Thanks for this. And thanks for putting the DTD on your=20 > website so we can test PUBLIC. >=20 > Yes, all files use the same DTD. It's also possible to use a=20 > standalone bean factory (for example in a Swing app or=20 > command-line app). >=20 > You're correct: I forgot the singleton attribute. Optional,=20 > default is "true". I'll add this tonight. >=20 > Either class or parent att is required. Unfortunately I don't=20 > think DTD allows this kind of control. The class attribute=20 > will be "inherited" from ancestor definitions. This is useful=20 > when one bean's properties are used as a basis for other definitions. >=20 > We need a definitive home for the DTD, but I guess that will=20 > be part of the website. However, there must be a fallback=20 > option so that users can validate without being online (this=20 > can be a big irritation). >=20 > I still can't get proper validation, even against your public=20 > DTD. I'm using the following code: >=20 > DocumentBuilderFactory factory =3D = DocumentBuilderFactory.newInstance(); > factory.setValidating(true); > DocumentBuilder db =3D factory.newDocumentBuilder(); > Document doc =3D db.parse(is); >=20 > One note about your changed XML file: >=20 > Your change to map properties is over-enthusiastic: >=20 > <property name=3D"mappings"> > <value>/welcome.html=3DpagedListController</value> > <value>/detail.html=3DpagedListController</value> > </property> >=20 > This is only one value, parsed by the relevant PropertyEditor: >=20 > <value> > /welcome.html=3DpagedListController > /detail.html=3DpagedListController > </value> >=20 >=20 > Thomas, Isabelle: >=20 > I agree about breaking compatibility now. I would like to=20 > enforce validation in all cases, but we'd have to solve how=20 > to get the DTD locally. >=20 > Regards, > Rod >=20 >=20 > ----- Original Message ----- > From: "JP Pawlak" <jp....@ti...> > To: "'Rod Johnson'" <rod...@in...>;=20 > <spr...@li...> > Sent: Friday, May 30, 2003 2:34 AM > Subject: RE : [Springframework-developer] DTD >=20 >=20 > Hi Rod, >=20 > First, some remarks: > - You have changed the attribute of ref elements from refid=20 > to bean. It's better, but has to be noticed. > - It seems you forgot the singleton attribute. I don't=20 > remember its default value. It will be better set the DEFAULT=20 > in the DTD. > - Can really the class attribute be omitted for beans? > - Where should be the DTD? Clearly somewhere in the jar.=20 > Perhaps in a ressource directory. I don't remember what is to=20 > do to retrieve locally a PUBLIC DTD. As we have no official=20 > URI to put the DTD, I have put the attached one on my=20 > personal site for testing PUBLIC DOCTYPE. But is it possible=20 > to put our DTD somewhere in SourceForge? > - Should we require all XML files to be valid. > * For this one, the DOCTYPE should only be used for files=20 > using the new syntax. The files whithout the DOCTYPE will=20 > only be checked for well forming. > * For now, we have only the applicationContext and the=20 > servlet-definition in XML. Both are using the same DTD. Have=20 > I missing somewhat? >=20 > I have transformed the old pagedlist bean definition to the=20 > new syntax as it was the smallest I have. I tested it against=20 > the DTD as SYSTEM and PUBLIC with XmlSpy. I have attached the=20 > two files to this mail. >=20 > Regards, > Jean-Pierre >=20 >=20 > > -----Message d'origine----- > > De : spr...@li... > > [mailto:spr...@li...] > > De la part de Rod Johnson > > Envoy=E9 : jeudi 29 mai 2003 23:49 > > =C0 : spr...@li... > > Objet : [Springframework-developer] DTD > > > > > > I knew I forgot some further questions: > > > > - Where should the DTD go? > > - Should we require all XML files to be valid? > > > > - How long should I retain the present backward compatibility in=20 > > parsing XML? 0.8? 0.9? Break it now? > > > > Regards, > > Rod > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: eBay > > Get office equipment for less on eBay!=20 > > http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5 > > > > _______________________________________________ > > > > Springframework-developer mailing list=20 > > Spr...@li... > >=20 > https://lists.sourceforge.net/lists/listinfo/s> pringframework-developer > > >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay!=20 > http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5 >=20 > _______________________________________________ >=20 > Springframework-developer mailing list=20 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 |
|
From: <jue...@we...> - 2003-05-30 08:05:44
|
Hi everyone, I'm also for breaking backward compatibility now. I guess the hassle = will only get more if we don't. Regarding DTD retrieval: Hibernate uses a respective implementation of = org.xml.sax.EntityResolver to avoid loading public URIs via HTTP, = looking up "http://hibernate.sourceforge.net/" URIs in the classpath = under "net/sf/hibernate/" (contained in the Hibernate JAR). Maybe we can = adopt a similar approach. Unfortunately, there's an issue when executing Hibernate within JUnit = (console version): It doesn't find its classpath DTDs then, falling back = to the HTTP download. This has probably something to do with JUnit's = classloading behavior, but I haven't been able to figure it out yet. I currently have an issue with Hibernate when executing within JUnit. Juergen -----Original Message----- From: JP Pawlak [mailto:jp....@ti...] Sent: Friday, May 30, 2003 4:00 AM To: tri...@tr...; 'Rod Johnson' Cc: spr...@li... Subject: RE : [Springframework-developer] DTD Hi Rod, I agree with Thomas for breaking backward compatibility now. As long as it is not released, only a few people have to change their files. For validating: it has to be checked how the parser retrieve the DTD based on its name (before the URI). It's normally parser dependent. The URI gives a chance to found it anyway. This name has to be fixed using the convention "-//<organisation>//<format inside the organisation>//<language>". Jean-Pierre > -----Message d'origine----- > De : spr...@li...=20 > [mailto:spr...@li...] > De la part de tri...@tr... > Envoy=E9 : vendredi 30 mai 2003 03:31 > =C0 : Rod Johnson > Cc : spr...@li... > Objet : Re: [Springframework-developer] DTD >=20 >=20 > Rod, >=20 > I vote for breaking backward compatibility now, before the=20 > first release. As soon as you release a deprecated feature,=20 > you know that there is always someone that is going to use it=20 > and later complain when it is gone :-) >=20 > As for the DTD, could it go in the package where the=20 > DocumentBuilderFactory lives? If the XML files are not=20 > valid, how are you going to use them - guess what is missing?=20 > I'd say force them to be valid as long as whe throw a=20 > clearly worded exception if they are not. >=20 > --Thomas >=20 >=20 > > I knew I forgot some further questions: > >=20 > > - Where should the DTD go? > > - Should we require all XML files to be valid? > >=20 > > - How long should I retain the present backward compatibility in=20 > > parsing XML? 0.8? 0.9? Break it now? > >=20 > > Regards, > > Rod > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.net email is sponsored by: eBay > > Get office equipment for less on eBay!=20 > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > > _______________________________________________ > > Springframework-developer mailing list=20 > > Spr...@li... > >=20 > https://lists.sourceforge.net/lists/listinfo/s> pringframework-developer > >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay!=20 > http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5 >=20 > _______________________________________________ >=20 > Springframework-developer mailing list=20 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 ------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rod J. <rod...@in...> - 2003-05-30 07:59:19
|
JP,
Thanks for this. And thanks for putting the DTD on your website so we can
test PUBLIC.
Yes, all files use the same DTD. It's also possible to use a standalone bean
factory (for example in a Swing app or command-line app).
You're correct: I forgot the singleton attribute. Optional, default is
"true". I'll add this tonight.
Either class or parent att is required. Unfortunately I don't think DTD
allows this kind of control. The class attribute will be "inherited" from
ancestor definitions. This is useful when one bean's properties are used as
a basis for other definitions.
We need a definitive home for the DTD, but I guess that will be part of the
website. However, there must be a fallback option so that users can validate
without being online (this can be a big irritation).
I still can't get proper validation, even against your public DTD. I'm
using the following code:
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setValidating(true);
DocumentBuilder db = factory.newDocumentBuilder();
Document doc = db.parse(is);
One note about your changed XML file:
Your change to map properties is over-enthusiastic:
<property name="mappings">
<value>/welcome.html=pagedListController</value>
<value>/detail.html=pagedListController</value>
</property>
This is only one value, parsed by the relevant PropertyEditor:
<value>
/welcome.html=pagedListController
/detail.html=pagedListController
</value>
Thomas, Isabelle:
I agree about breaking compatibility now. I would like to enforce validation
in all cases, but we'd have to solve how to get the DTD locally.
Regards,
Rod
----- Original Message -----
From: "JP Pawlak" <jp....@ti...>
To: "'Rod Johnson'" <rod...@in...>;
<spr...@li...>
Sent: Friday, May 30, 2003 2:34 AM
Subject: RE : [Springframework-developer] DTD
Hi Rod,
First, some remarks:
- You have changed the attribute of ref elements from refid to bean.
It's better, but has to be noticed.
- It seems you forgot the singleton attribute. I don't remember its
default value. It will be better set the DEFAULT in the DTD.
- Can really the class attribute be omitted for beans?
- Where should be the DTD? Clearly somewhere in the jar. Perhaps in a
ressource directory. I don't remember what is to do to retrieve locally
a PUBLIC DTD. As we have no official URI to put the DTD, I have put the
attached one on my personal site for testing PUBLIC DOCTYPE. But is it
possible to put our DTD somewhere in SourceForge?
- Should we require all XML files to be valid.
* For this one, the DOCTYPE should only be used for files using
the new syntax. The files whithout the DOCTYPE will only be checked for
well forming.
* For now, we have only the applicationContext and the
servlet-definition in XML. Both are using the same DTD. Have I missing
somewhat?
I have transformed the old pagedlist bean definition to the new syntax
as it was the smallest I have. I tested it against the DTD as SYSTEM and
PUBLIC with XmlSpy. I have attached the two files to this mail.
Regards,
Jean-Pierre
> -----Message d'origine-----
> De : spr...@li...
> [mailto:spr...@li...]
> De la part de Rod Johnson
> Envoyé : jeudi 29 mai 2003 23:49
> À : spr...@li...
> Objet : [Springframework-developer] DTD
>
>
> I knew I forgot some further questions:
>
> - Where should the DTD go?
> - Should we require all XML files to be valid?
>
> - How long should I retain the present backward compatibility
> in parsing XML? 0.8? 0.9? Break it now?
>
> Regards,
> Rod
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5
>
> _______________________________________________
>
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
|
From: Isabelle M. <isa...@me...> - 2003-05-30 07:23:05
|
Hi everyone, Sorry for missing yesterday's discussion, but I'm fine too and vote for breaking compatibility before release. Isabelle -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: JP P. <jp....@ti...> - 2003-05-30 02:00:46
|
Hi Rod, I agree with Thomas for breaking backward compatibility now. As long as it is not released, only a few people have to change their files. For validating: it has to be checked how the parser retrieve the DTD based on its name (before the URI). It's normally parser dependent. The URI gives a chance to found it anyway. This name has to be fixed using the convention "-//<organisation>//<format inside the organisation>//<language>". Jean-Pierre > -----Message d'origine----- > De : spr...@li...=20 > [mailto:spr...@li...] > De la part de tri...@tr... > Envoy=E9 : vendredi 30 mai 2003 03:31 > =C0 : Rod Johnson > Cc : spr...@li... > Objet : Re: [Springframework-developer] DTD >=20 >=20 > Rod, >=20 > I vote for breaking backward compatibility now, before the=20 > first release. As soon as you release a deprecated feature,=20 > you know that there is always someone that is going to use it=20 > and later complain when it is gone :-) >=20 > As for the DTD, could it go in the package where the=20 > DocumentBuilderFactory lives? If the XML files are not=20 > valid, how are you going to use them - guess what is missing?=20 > I'd say force them to be valid as long as whe throw a=20 > clearly worded exception if they are not. >=20 > --Thomas >=20 >=20 > > I knew I forgot some further questions: > >=20 > > - Where should the DTD go? > > - Should we require all XML files to be valid? > >=20 > > - How long should I retain the present backward compatibility in=20 > > parsing XML? 0.8? 0.9? Break it now? > >=20 > > Regards, > > Rod > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.net email is sponsored by: eBay > > Get office equipment for less on eBay!=20 > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > > _______________________________________________ > > Springframework-developer mailing list=20 > > Spr...@li... > >=20 > https://lists.sourceforge.net/lists/listinfo/s> pringframework-developer > >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay!=20 > http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5 >=20 > _______________________________________________ >=20 > Springframework-developer mailing list=20 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 |
|
From: JP P. <jp....@ti...> - 2003-05-30 01:34:40
|
Hi Rod, First, some remarks: - You have changed the attribute of ref elements from refid to bean. It's better, but has to be noticed. - It seems you forgot the singleton attribute. I don't remember its default value. It will be better set the DEFAULT in the DTD. - Can really the class attribute be omitted for beans? - Where should be the DTD? Clearly somewhere in the jar. Perhaps in a ressource directory. I don't remember what is to do to retrieve locally a PUBLIC DTD. As we have no official URI to put the DTD, I have put the attached one on my personal site for testing PUBLIC DOCTYPE. But is it possible to put our DTD somewhere in SourceForge? - Should we require all XML files to be valid. * For this one, the DOCTYPE should only be used for files using the new syntax. The files whithout the DOCTYPE will only be checked for well forming. * For now, we have only the applicationContext and the servlet-definition in XML. Both are using the same DTD. Have I missing somewhat? I have transformed the old pagedlist bean definition to the new syntax as it was the smallest I have. I tested it against the DTD as SYSTEM and PUBLIC with XmlSpy. I have attached the two files to this mail. Regards, Jean-Pierre =20 > -----Message d'origine----- > De : spr...@li...=20 > [mailto:spr...@li...] > De la part de Rod Johnson > Envoy=E9 : jeudi 29 mai 2003 23:49 > =C0 : spr...@li... > Objet : [Springframework-developer] DTD >=20 >=20 > I knew I forgot some further questions: >=20 > - Where should the DTD go? > - Should we require all XML files to be valid? >=20 > - How long should I retain the present backward compatibility=20 > in parsing XML? 0.8? 0.9? Break it now? >=20 > Regards, > Rod >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay!=20 > http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5 >=20 > _______________________________________________ >=20 > Springframework-developer mailing list=20 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 |
|
From: <tri...@tr...> - 2003-05-30 01:29:51
|
Rod, I vote for breaking backward compatibility now, before the first release. As soon as you release a deprecated feature, you know that there is always someone that is going to use it and later complain when it is gone :-) As for the DTD, could it go in the package where the DocumentBuilderFactory lives? If the XML files are not valid, how are you going to use them - guess what is missing? I'd say force them to be valid as long as whe throw a clearly worded exception if they are not. --Thomas > I knew I forgot some further questions: > > - Where should the DTD go? > - Should we require all XML files to be valid? > > - How long should I retain the present backward compatibility in parsing > XML? 0.8? 0.9? Break it now? > > Regards, > Rod > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Rod J. <rod...@in...> - 2003-05-29 21:50:29
|
I knew I forgot some further questions: - Where should the DTD go? - Should we require all XML files to be valid? - How long should I retain the present backward compatibility in parsing XML? 0.8? 0.9? Break it now? Regards, Rod |
|
From: Rod J. <rod...@in...> - 2003-05-29 21:47:39
|
I've checked a preliminary DTD for beans definitions into the root directory of Spring main. - improvements/abuse welcome...it's a while since I've written a DTD - I'm having problems getting the XmlBeanFactory to validate against it. When I call setValidating(true) on the DocumentBuilderFactory, it goes and checks the DTD exists and can be parsed, but doesn't actually check structure against it, as far as I can see. Can anyone shed any light on this? I guess we could use schema, but this seems overkill for such a simple structure to my mind. Regards, Rod |
|
From: Ken K. <kk...@kk...> - 2003-05-29 02:05:02
|
Juergen,
You're right about the old classes hanging around. I'm back in business.
My relative inexperience is showing. Just paying my dues ;=)
Ken
jürgen höller [werk3AT] wrote:
>Ken,
>
>According to your stack trace, you haven't recompiled the whole Spring source. NoClassDefFoundError and NoSuchMethodError indicate inconsistent classes. You could also have some copies of old Spring classes lying around in the classpath, getting picked up before the current ones.
>
>The new ContextRefreshedEvent version should work, it just specializes ApplicationEvent's source object. On my setup, all tests and all my applications work, and everything should be committed. Please clean your classpath, recompile everything, and see if it works then :-)
>
>Juergen
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Ken Krebs [mailto:kk...@kk...]
> Gesendet: Mi 28.05.2003 18:59
> An: jürgen höller [werk3AT]
> Cc: 'spring-dev-list'
> Betreff: [Springframework-developer] new context init problem
>
>
>
> Juergen,
>
> I just updated my build of Spring with the latest file changes made
> since Isabelle updated MySqlMaxValueIncrementer on 26-may.
>
> My petclinic app will no longer initialize properly. There seems to be a
> problem with ContextRefreshedEvent. It was recently changed to add a
> getApplicationContext convenience method which casts the source object
> to an ApplicationContext. The constructor was also changed to used to
> initialize the source using an ApplicationContext parameter instead of
> an Object param. This seems to be what causes the problem as the
> ApplicationEvent constructor doesn't expect to see an
> ApplicationContext. The fact that getApplicationContext does this cast
> seems to imply that the param class change was inadvertent and should be
> changed back to using an Object param.
>
> I made the change in my own local copy , recompiled, and it works.
>
> BTW, the petclinic web.xml no longer specifies a ContextLoader but uses
> a listener, i.e.
>
> <listener>
>
> <listener-class>com.interface21.web.context.ContextLoaderListener</listener-class>
> </listener>
>
>
> Ken
>
>
>
> The server log shows the following :
>
> blah, blah, blah
>
> 2003-05-28 09:56:56 StandardManager[/petclinic_demo_tutorial-1.0]:
> Seeding of random number generator has been completed
> 2003-05-28 09:56:57 StandardContext[/petclinic_demo_tutorial-1.0]:
> Exception sending context initialized event to listener instance of
> class com.interface21.web.context.ContextLoaderListener
> java.lang.NoSuchMethodError:
> com.interface21.context.support.ContextRefreshedEvent: method
> <init>(Ljava/lang/Object;)V not found
> at
> com.interface21.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:237)
> at
> com.interface21.web.context.support.XmlWebApplicationContext.setServletContext(XmlWebApplicationContext.java:121)
> at
> com.interface21.web.context.ContextLoader.initContext(ContextLoader.java:55)
> at
> com.interface21.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:20)
> at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3269)
>
> blah,blah,blah
>
>
>
>
>
>?????????????????????????????????????????ӆ+?隊X???'???u??x??h}?yꮊ?????W????????i???u??v&????r??i?ܓ????u?????z?????????????????????????????????????*k?x ?????ׯzZ)z???X??X??*k?x ?????ׯzZ)z???l??.?ǟ?? ?w???i????+-??(?? ~??{??b????+-?w???k?x ?????ׯzZ)
>
>
>
>
|
|
From: <jue...@we...> - 2003-05-28 19:13:27
|
RmluZSwgYXMgZmFyIGFzIEknbSBjb25jZXJuZWQgOi0pDQogDQpKdWVyZ2VuDQogDQoNCgktLS0t LVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogUm9kIEpvaG5zb24gW21haWx0 bzpyb2Quam9obnNvbkBpbnRlcmZhY2UyMS5jb21dIA0KCUdlc2VuZGV0OiBNaSAyOC4wNS4yMDAz IDE4OjE2IA0KCUFuOiBqcC5wYXdsYWtAdGlzY2FsaS5mciANCglDYzogaXNhYmVsbGU7IHNwcmlu Z2ZyYW1ld29yay1kZXZlbG9wZXIgDQoJQmV0cmVmZjogUmU6IFJlOiBbU3ByaW5nZnJhbWV3b3Jr LWRldmVsb3Blcl0gU3ByaW5nIGJlYW4gZmFjdG9yeSBYTUwgZm9ybWF0DQoJDQoJDQoNCglMZXQn cyB0YWtlIHRoZSBmb2xsb3dpbmcgKHdoaWNoIEkgcG9zdGVkIGVhcmxpZXIgdG9kYXkpIGFzIHRo ZSBiYXNpcyBmb3INCglkaXNjdXNzaW9uLg0KCQ0KCUpQIGlzIGhhcHB5LiAgSXMgZXZlcnlvbmUg ZWxzZSBoYXBweSB3aXRoIHRoaXMsIG9yIGhhdmUgYW55IHN1Z2dlc3Rpb25zPw0KCQ0KCUkndmUg d3JpdHRlbiBhIERURCwgd2hpY2ggbWFrZXMgYXV0aG9yaW5nIGZhaXJseSBlYXN5IChhbHRob3Vn aCB0aGUgRWNsaXBzZQ0KCVhNTCBlZGl0b3IgaXNuJ3QgZW5mb3JjaW5nIGNvcnJlY3QgcmVmZXJl bmNpbmcpOg0KCQ0KCQ0KCTxiZWFuIGNsYXNzPSJNeUNsYXNzIiBpZD0iZm9vcyIgc2luZ2xldG9u PSJmYWxzZT4NCgk8cHJvcGVydHkgbmFtZT0iZm9vIj48dmFsdWU+Rk9PPC92YWx1ZT48L3Byb3Bl cnR5Pg0KCQ0KCTxwcm9wZXJ0eSBuYW1lPSJmb28zIj4NCgkgIDxyZWYgcmVmaWQ9ImZvbzMiLz4N Cgk8L3Byb3BlcnR5Pg0KCTxwcm9wZXJ0eSBuYW1lPSJmb280Ij4NCgkgICA8dmFsdWU+Rk9PNC4x PC92YWx1ZT4NCgkgICA8dmFsdWU+Rk9PNC4yPC92YWx1ZT4NCgkgICA8cmVmIHJlZmlkPSJmb280 LjMiLz4NCgk8L3Byb3BlcnR5Pg0KCTwvYmVhbj4NCgkNCglBbHdheXMgY29uc2lzdGVudDogYWx3 YXlzIGF0IGxlYXN0IG9uZSB2YWx1ZSBvciByZWYNCglzdWJlbGVtZW50IG9mIGEgcHJvcGVydHkg ZWx0OyA8dmFsdWU+IGNvbnRhaW5zIG9ubHkgdGV4dA0KCWRhdGE7IHJlZiBib2R5IG11c3QgYmUg ZW1wdHkuDQoJDQoJU2xpZ2h0bHkgbW9yZSB2ZXJib3NlLCBidXQgcHJvYmFibHkgZWFzaWVyIHRv IGF1dGhvciB3aXRoIGFuDQoJWE1MIGVkaXRvciAoZXZlbiB0aGUgYmFzaWMgRWNsaXBzZSBYTUwg ZWRpdG9yIEkgdXNlIG1vc3Qgb2YNCgl0aGUgdGltZSkuDQoJDQoJSSBkb24ndCBjYXJlIHdoZXRo ZXIgaXQncyBjYWxsZWQgdmFsdWUgb3IgZGF0YSwgb3IgYW55dGhpbmcNCgllbHNlLi4uYW55IGlk ZWFzPw0KCQ0KCVJlZ2FyZHMsDQoJUm9kDQoJDQoJDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YubmV0IGVt YWlsIGlzIHNwb25zb3JlZCBieTogT2JqZWN0U3RvcmUuDQoJSWYgZmxhdHRlbmluZyBvdXQgQysr IG9yIEphdmEgY29kZSB0byBtYWtlIHlvdXIgYXBwbGljYXRpb24gZml0IGluIGENCglyZWxhdGlv bmFsIGRhdGFiYXNlIGlzIHBhaW5mdWwsIGRvbid0IGRvIGl0ISBDaGVjayBvdXQgT2JqZWN0U3Rv cmUuDQoJTm93IHBhcnQgb2YgUHJvZ3Jlc3MgU29mdHdhcmUuIGh0dHA6Ly93d3cub2JqZWN0c3Rv cmUubmV0L3NvdXJjZWZvcmdlDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0KCVNw cmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJaHR0cHM6Ly9s aXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVs b3Blcg0KCQ0KDQo= |
|
From: <jue...@we...> - 2003-05-28 19:12:25
|
S2VuLA0KIA0KQWNjb3JkaW5nIHRvIHlvdXIgc3RhY2sgdHJhY2UsIHlvdSBoYXZlbid0IHJlY29t cGlsZWQgdGhlIHdob2xlIFNwcmluZyBzb3VyY2UuIE5vQ2xhc3NEZWZGb3VuZEVycm9yIGFuZCBO b1N1Y2hNZXRob2RFcnJvciBpbmRpY2F0ZSBpbmNvbnNpc3RlbnQgY2xhc3Nlcy4gWW91IGNvdWxk IGFsc28gaGF2ZSBzb21lIGNvcGllcyBvZiBvbGQgU3ByaW5nIGNsYXNzZXMgbHlpbmcgYXJvdW5k IGluIHRoZSBjbGFzc3BhdGgsIGdldHRpbmcgcGlja2VkIHVwIGJlZm9yZSB0aGUgY3VycmVudCBv bmVzLg0KIA0KVGhlIG5ldyBDb250ZXh0UmVmcmVzaGVkRXZlbnQgdmVyc2lvbiBzaG91bGQgd29y aywgaXQganVzdCBzcGVjaWFsaXplcyBBcHBsaWNhdGlvbkV2ZW50J3Mgc291cmNlIG9iamVjdC4g T24gbXkgc2V0dXAsIGFsbCB0ZXN0cyBhbmQgYWxsIG15IGFwcGxpY2F0aW9ucyB3b3JrLCBhbmQg ZXZlcnl0aGluZyBzaG91bGQgYmUgY29tbWl0dGVkLiBQbGVhc2UgY2xlYW4geW91ciBjbGFzc3Bh dGgsIHJlY29tcGlsZSBldmVyeXRoaW5nLCBhbmQgc2VlIGlmIGl0IHdvcmtzIHRoZW4gOi0pDQog DQpKdWVyZ2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0K CVZvbjogS2VuIEtyZWJzIFttYWlsdG86a2tAa2t0ZWMuY29tXSANCglHZXNlbmRldDogTWkgMjgu MDUuMjAwMyAxODo1OSANCglBbjogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSANCglDYzogJ3Nw cmluZy1kZXYtbGlzdCcgDQoJQmV0cmVmZjogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIG5l dyBjb250ZXh0IGluaXQgcHJvYmxlbQ0KCQ0KCQ0KDQoJSnVlcmdlbiwNCgkNCglJIGp1c3QgdXBk YXRlZCBteSBidWlsZCBvZiBTcHJpbmcgd2l0aCB0aGUgbGF0ZXN0IGZpbGUgY2hhbmdlcyBtYWRl DQoJc2luY2UgSXNhYmVsbGUgdXBkYXRlZCBNeVNxbE1heFZhbHVlSW5jcmVtZW50ZXIgb24gMjYt bWF5Lg0KCQ0KCU15IHBldGNsaW5pYyBhcHAgd2lsbCBubyBsb25nZXIgaW5pdGlhbGl6ZSBwcm9w ZXJseS4gVGhlcmUgc2VlbXMgdG8gYmUgYQ0KCXByb2JsZW0gd2l0aCBDb250ZXh0UmVmcmVzaGVk RXZlbnQuIEl0IHdhcyByZWNlbnRseSBjaGFuZ2VkIHRvIGFkZCBhDQoJZ2V0QXBwbGljYXRpb25D b250ZXh0IGNvbnZlbmllbmNlIG1ldGhvZCB3aGljaCBjYXN0cyB0aGUgc291cmNlIG9iamVjdA0K CXRvIGFuIEFwcGxpY2F0aW9uQ29udGV4dC4gVGhlIGNvbnN0cnVjdG9yIHdhcyBhbHNvIGNoYW5n ZWQgdG8gdXNlZCB0bw0KCWluaXRpYWxpemUgdGhlIHNvdXJjZSB1c2luZyBhbiBBcHBsaWNhdGlv bkNvbnRleHQgcGFyYW1ldGVyICBpbnN0ZWFkIG9mDQoJYW4gT2JqZWN0IHBhcmFtLiBUaGlzIHNl ZW1zIHRvIGJlIHdoYXQgY2F1c2VzIHRoZSBwcm9ibGVtIGFzIHRoZQ0KCUFwcGxpY2F0aW9uRXZl bnQgY29uc3RydWN0b3IgZG9lc24ndCBleHBlY3QgdG8gc2VlIGFuDQoJQXBwbGljYXRpb25Db250 ZXh0LiBUaGUgZmFjdCB0aGF0IGdldEFwcGxpY2F0aW9uQ29udGV4dCBkb2VzIHRoaXMgY2FzdA0K CXNlZW1zIHRvIGltcGx5IHRoYXQgdGhlIHBhcmFtIGNsYXNzIGNoYW5nZSB3YXMgaW5hZHZlcnRl bnQgYW5kIHNob3VsZCBiZQ0KCWNoYW5nZWQgYmFjayB0byB1c2luZyBhbiBPYmplY3QgcGFyYW0u DQoJDQoJSSBtYWRlIHRoZSBjaGFuZ2UgaW4gbXkgb3duIGxvY2FsIGNvcHkgLCByZWNvbXBpbGVk LCBhbmQgaXQgd29ya3MuDQoJDQoJQlRXLCB0aGUgcGV0Y2xpbmljIHdlYi54bWwgbm8gbG9uZ2Vy IHNwZWNpZmllcyBhIENvbnRleHRMb2FkZXIgYnV0IHVzZXMNCglhIGxpc3RlbmVyLCBpLmUuDQoJ DQoJICAgIDxsaXN0ZW5lcj4NCgkgICAgICAgDQoJPGxpc3RlbmVyLWNsYXNzPmNvbS5pbnRlcmZh Y2UyMS53ZWIuY29udGV4dC5Db250ZXh0TG9hZGVyTGlzdGVuZXI8L2xpc3RlbmVyLWNsYXNzPg0K CSAgICA8L2xpc3RlbmVyPg0KCQ0KCQ0KCUtlbg0KCQ0KCQ0KCQ0KCVRoZSBzZXJ2ZXIgbG9nIHNo b3dzIHRoZSBmb2xsb3dpbmcgOg0KCQ0KCWJsYWgsIGJsYWgsIGJsYWgNCgkNCgkyMDAzLTA1LTI4 IDA5OjU2OjU2IFN0YW5kYXJkTWFuYWdlclsvcGV0Y2xpbmljX2RlbW9fdHV0b3JpYWwtMS4wXToN CglTZWVkaW5nIG9mIHJhbmRvbSBudW1iZXIgZ2VuZXJhdG9yIGhhcyBiZWVuIGNvbXBsZXRlZA0K CTIwMDMtMDUtMjggMDk6NTY6NTcgU3RhbmRhcmRDb250ZXh0Wy9wZXRjbGluaWNfZGVtb190dXRv cmlhbC0xLjBdOg0KCUV4Y2VwdGlvbiBzZW5kaW5nIGNvbnRleHQgaW5pdGlhbGl6ZWQgZXZlbnQg dG8gbGlzdGVuZXIgaW5zdGFuY2Ugb2YNCgljbGFzcyBjb20uaW50ZXJmYWNlMjEud2ViLmNvbnRl eHQuQ29udGV4dExvYWRlckxpc3RlbmVyDQoJamF2YS5sYW5nLk5vU3VjaE1ldGhvZEVycm9yOg0K CWNvbS5pbnRlcmZhY2UyMS5jb250ZXh0LnN1cHBvcnQuQ29udGV4dFJlZnJlc2hlZEV2ZW50OiBt ZXRob2QNCgk8aW5pdD4oTGphdmEvbGFuZy9PYmplY3Q7KVYgbm90IGZvdW5kDQoJICAgIGF0DQoJ Y29tLmludGVyZmFjZTIxLmNvbnRleHQuc3VwcG9ydC5BYnN0cmFjdEFwcGxpY2F0aW9uQ29udGV4 dC5yZWZyZXNoKEFic3RyYWN0QXBwbGljYXRpb25Db250ZXh0LmphdmE6MjM3KQ0KCSAgICBhdA0K CWNvbS5pbnRlcmZhY2UyMS53ZWIuY29udGV4dC5zdXBwb3J0LlhtbFdlYkFwcGxpY2F0aW9uQ29u dGV4dC5zZXRTZXJ2bGV0Q29udGV4dChYbWxXZWJBcHBsaWNhdGlvbkNvbnRleHQuamF2YToxMjEp DQoJICAgIGF0DQoJY29tLmludGVyZmFjZTIxLndlYi5jb250ZXh0LkNvbnRleHRMb2FkZXIuaW5p dENvbnRleHQoQ29udGV4dExvYWRlci5qYXZhOjU1KQ0KCSAgICBhdA0KCWNvbS5pbnRlcmZhY2Uy MS53ZWIuY29udGV4dC5Db250ZXh0TG9hZGVyTGlzdGVuZXIuY29udGV4dEluaXRpYWxpemVkKENv bnRleHRMb2FkZXJMaXN0ZW5lci5qYXZhOjIwKQ0KCSAgICBhdA0KCW9yZy5hcGFjaGUuY2F0YWxp bmEuY29yZS5TdGFuZGFyZENvbnRleHQubGlzdGVuZXJTdGFydChTdGFuZGFyZENvbnRleHQuamF2 YTozMjY5KQ0KCQ0KCWJsYWgsYmxhaCxibGFoDQoJDQoJDQoJDQoJDQoNCg== |
|
From: Kopylenko, D. <dko...@ac...> - 2003-05-28 17:50:57
|
I'm happy here :-) -----Original Message----- From: Rod Johnson [mailto:rod...@in...] Sent: Wednesday, May 28, 2003 12:16 PM To: jp....@ti... Cc: isabelle; springframework-developer Subject: Re: Re: [Springframework-developer] Spring bean factory XML format Let's take the following (which I posted earlier today) as the basis for discussion. JP is happy. Is everyone else happy with this, or have any suggestions? I've written a DTD, which makes authoring fairly easy (although the Eclipse XML editor isn't enforcing correct referencing): <bean class="MyClass" id="foos" singleton="false> <property name="foo"><value>FOO</value></property> <property name="foo3"> <ref refid="foo3"/> </property> <property name="foo4"> <value>FOO4.1</value> <value>FOO4.2</value> <ref refid="foo4.3"/> </property> </bean> Always consistent: always at least one value or ref subelement of a property elt; <value> contains only text data; ref body must be empty. Slightly more verbose, but probably easier to author with an XML editor (even the basic Eclipse XML editor I use most of the time). I don't care whether it's called value or data, or anything else...any ideas? Regards, Rod ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
1239 messages has been excluded from this view by a project administrator.
