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 J. <rod...@in...> - 2003-11-01 16:02:32
|
I'm happy with Jira and Atlassian. Thanks Mike! ----- Original Message ----- From: "Alef Arendsen (JTeam)" <al...@jt...> To: <spr...@li...> Sent: Saturday, November 01, 2003 3:26 PM Subject: RE: [Springframework-developer] JIRA > Will, I think the majority likes Jira and Atlassian (Mike > Cannon-Brookes) has already offered to look into hosting it at their > place, so as far as I'm concerned, we could go ahead... > > Rod, Juergen, everybody else agrees? > > Alef > > > -----Oorspronkelijk bericht----- > > Van: spr...@li... > > [mailto:spr...@li...] > > Namens Kopylenko, Dmitry > > Verzonden: Saturday, November 01, 2003 2:30 PM > > Aan: 'spr...@li...' > > Onderwerp: [Springframework-developer] JIRA > > > > > > So, what have we decided on JIRA? And how we're going to proceed? > > > > Regards, > > Dmitriy. > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > Does SourceForge.net help you be more productive? Does it > > help you create better code? SHARE THE LOVE, and help us help > > YOU! Click Here: http://sourceforge.net/donate/ > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-11-01 15:27:27
|
Will, I think the majority likes Jira and Atlassian (Mike Cannon-Brookes) has already offered to look into hosting it at their place, so as far as I'm concerned, we could go ahead... Rod, Juergen, everybody else agrees? Alef > -----Oorspronkelijk bericht----- > Van: spr...@li... > [mailto:spr...@li...] > Namens Kopylenko, Dmitry > Verzonden: Saturday, November 01, 2003 2:30 PM > Aan: 'spr...@li...' > Onderwerp: [Springframework-developer] JIRA > > > So, what have we decided on JIRA? And how we're going to proceed? > > Regards, > Dmitriy. > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: roger h. <apo...@sn...> - 2003-11-01 13:40:11
|
Greetings to you all !
I've been lurking about for a fair while, being thoroughly impressed by
Springframework - the conception, the code, this excellent list, Rod's book,
in short the whole shebang - it seems quite a while since I encountered a
project that more than anything, just seems to make me smile ;) Many
thanks.
Anyway - having spent a wee while trying to work out what's going on in the
code, it's feels like time to start asking a few questions...
First up is the subject line & the method
AbstractApplicationContext.getBeanFactory()
I am wondering if the signature for this method might have been changed
inadvertently ? Prior to the introduction of support for
BeanFactoryPostProcessor's, the method was returning the ListableBeanFactory
interface, but thereafter it has been ListableBeanFactoryImpl. As the
latter comes with a final modifier on each of the methods implementing that
interface, the opportunity for Plug'nPlay appears to have gone missing... &
if I'm not mistaken, a first casualty would be the loss of a JdbcBeanFactory
within an AbstractApplicationContext. Can someone shed some
light - am I just missing something ?
By the way, on my wanderings I noticed the following typo in
AbstractBeanDefinition.equals()
public boolean equals(Object other) {
if (!(other instanceof AbstractBeanDefinition))
return false;
AbstractBeanDefinition obd = (AbstractBeanDefinition) other;
- return this.singleton = obd.singleton &&
+ return this.singleton == obd.singleton &&
this.pvs.changesSince(obd.pvs).getPropertyValues().length == 0;
}
Anyway, I hope to be a little less retiring in the future - as you're
such an inspiring bunch ;)
Roger Holbrook
|
|
From: Kopylenko, D. <dko...@ac...> - 2003-11-01 13:30:10
|
So, what have we decided on JIRA? And how we're going to proceed? Regards, Dmitriy. |
|
From: Cameron B. <ca...@da...> - 2003-11-01 12:48:40
|
Actually .. after further investigation.. I can't seem to get the beanDefinitions anyway :( Any ideas ? Thanks. Cameron Braid wrote: > I just wanted to add that I for the second part of my question > (obtaining the bean ID for the current bean) I would implement > BeanFactoryAware and iterate through all of the bean names, calling > getBean(name) and checking for object identity. > > Does it make sense to add the ID and aliases into the > AbstractBeanDefinition and then to create a BeanDefinitionAware > interface that allows the bean to become aware ? > > Thanks again, > > Cameron > > Cameron Braid wrote: > >> Is there any way that I can allow a bean factory to find out its id >> attribute from the applicationContext.xml >> >> i.e. I am trying to get a grip on how spring works, and therefore I >> am trying to write a little integration layer to make spring an >> action factory for xwork, to allow me to use spring components and >> interceptors. I want to try and avoid repetition of configuration >> wherever possible. >> >> I have it at the stage where I have a bean declaration like this : >> >> <bean id="defaultActionTransactionAttributes" >> class="com.datacodex.spring.beans.PropertiesFactoryBean"> >> <property name="properties"> >> <props> >> <prop key="execute">PROPAGATION_REQUIRED</prop> >> </props> >> </property> >> </bean> >> >> <bean id="admin.SpringAdminAction" class="WebworkActionFactoryBean"> >> <property >> name="action"><value>/admin/SpringAdminAction</value></property> >> <property name="transactionManager"><ref >> local="transactionManager"/></property> >> <property name="transactionAttributes"><ref >> local="defaultActionTransactionAttributes"/></property> >> </bean> >> >> I would like to be able to access the id="admin.SpringAdminAction" >> value (or the bean name attribute) from within the >> WebworkActionFactoryBean therefore removing the need to have the >> extra 'action' property <property >> name="action"><value>/admin/SpringAdminAction</value></property>. >> >> Idealy I would like to use the /admin/SpringAdminAction as the bean >> id to make mapping from WebWork seamless, and without needing the >> conversion to '.' style. >> Therefore - is there any way that the bean id can be changed to allow >> any valid xml string ? Currently I am receiving an exception, from >> the xml validator. Can the id atttribuet be changed to be a >> >> [22:12:29]INFO [XmlBeanFactory] Loading XmlBeanFactory from >> InputStream [[ReadStream com.caucho.vfs.FileReadStream@190a0d6]] >> [22:12:29]ERROR[ContextLoader] Failed to initialize beans in >> application context: Line 44 in XML document is invalid; nested >> exception is: >> org.xml.sax.SAXParseException: Attribute value >> "/admin/SpringAdminAction" of type ID must be a name. >> org.xml.sax.SAXParseException: Attribute value >> "/admin/SpringAdminAction" of type ID must be a name. >> at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) >> at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) >> at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:76) >> >> The dtd states that it myst be a valid XML ID, and to use the >> optional name attribute if you want an illegal name. Though this >> will require two identifyers for the bean, which I think is >> pointless. Does the ID have to be mandatory. Can't a validation be >> implemented in java to check that atleast the name or the id is >> supplied ? Then the same for the <!ATTLIST ref local IDREF >> #IMPLIED> this could be a CDATA with java based validation. >> >> Cheers, >> >> Cameron >> > > -- Any damn fool can write code that a computer can understand... The trick is to write code that humans can understand. [Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf] |
|
From: Cameron B. <ca...@da...> - 2003-11-01 12:41:49
|
I just wanted to add that I for the second part of my question (obtaining the bean ID for the current bean) I would implement BeanFactoryAware and iterate through all of the bean names, calling getBean(name) and checking for object identity. Does it make sense to add the ID and aliases into the AbstractBeanDefinition and then to create a BeanDefinitionAware interface that allows the bean to become aware ? Thanks again, Cameron Cameron Braid wrote: > Is there any way that I can allow a bean factory to find out its id > attribute from the applicationContext.xml > > i.e. I am trying to get a grip on how spring works, and therefore I am > trying to write a little integration layer to make spring an action > factory for xwork, to allow me to use spring components and > interceptors. I want to try and avoid repetition of configuration > wherever possible. > > I have it at the stage where I have a bean declaration like this : > > <bean id="defaultActionTransactionAttributes" > class="com.datacodex.spring.beans.PropertiesFactoryBean"> > <property name="properties"> > <props> > <prop key="execute">PROPAGATION_REQUIRED</prop> > </props> > </property> > </bean> > > <bean id="admin.SpringAdminAction" class="WebworkActionFactoryBean"> > <property > name="action"><value>/admin/SpringAdminAction</value></property> > <property name="transactionManager"><ref > local="transactionManager"/></property> > <property name="transactionAttributes"><ref > local="defaultActionTransactionAttributes"/></property> > </bean> > > I would like to be able to access the id="admin.SpringAdminAction" > value (or the bean name attribute) from within the > WebworkActionFactoryBean therefore removing the need to have the extra > 'action' property <property > name="action"><value>/admin/SpringAdminAction</value></property>. > > Idealy I would like to use the /admin/SpringAdminAction as the bean id > to make mapping from WebWork seamless, and without needing the > conversion to '.' style. > Therefore - is there any way that the bean id can be changed to allow > any valid xml string ? Currently I am receiving an exception, from > the xml validator. Can the id atttribuet be changed to be a > > [22:12:29]INFO [XmlBeanFactory] Loading XmlBeanFactory from > InputStream [[ReadStream com.caucho.vfs.FileReadStream@190a0d6]] > [22:12:29]ERROR[ContextLoader] Failed to initialize beans in > application context: Line 44 in XML document is invalid; nested > exception is: > org.xml.sax.SAXParseException: Attribute value > "/admin/SpringAdminAction" of type ID must be a name. > org.xml.sax.SAXParseException: Attribute value > "/admin/SpringAdminAction" of type ID must be a name. > at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) > at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) > at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:76) > > The dtd states that it myst be a valid XML ID, and to use the optional > name attribute if you want an illegal name. Though this will require > two identifyers for the bean, which I think is pointless. Does the ID > have to be mandatory. Can't a validation be implemented in java to > check that atleast the name or the id is supplied ? Then the same for > the <!ATTLIST ref local IDREF #IMPLIED> this could be a CDATA with > java based validation. > > Cheers, > > Cameron > -- Any damn fool can write code that a computer can understand... The trick is to write code that humans can understand. [Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf] |
|
From: Cameron B. <ca...@da...> - 2003-11-01 12:22:00
|
Is there any way that I can allow a bean factory to find out its id
attribute from the applicationContext.xml
i.e. I am trying to get a grip on how spring works, and therefore I am
trying to write a little integration layer to make spring an action
factory for xwork, to allow me to use spring components and
interceptors. I want to try and avoid repetition of configuration
wherever possible.
I have it at the stage where I have a bean declaration like this :
<bean id="defaultActionTransactionAttributes"
class="com.datacodex.spring.beans.PropertiesFactoryBean">
<property name="properties">
<props>
<prop key="execute">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
<bean id="admin.SpringAdminAction" class="WebworkActionFactoryBean">
<property
name="action"><value>/admin/SpringAdminAction</value></property>
<property name="transactionManager"><ref
local="transactionManager"/></property>
<property name="transactionAttributes"><ref
local="defaultActionTransactionAttributes"/></property>
</bean>
I would like to be able to access the id="admin.SpringAdminAction" value
(or the bean name attribute) from within the WebworkActionFactoryBean
therefore removing the need to have the extra 'action' property
<property name="action"><value>/admin/SpringAdminAction</value></property>.
Idealy I would like to use the /admin/SpringAdminAction as the bean id
to make mapping from WebWork seamless, and without needing the
conversion to '.' style.
Therefore - is there any way that the bean id can be changed to allow
any valid xml string ? Currently I am receiving an exception, from the
xml validator. Can the id atttribuet be changed to be a
[22:12:29]INFO [XmlBeanFactory] Loading XmlBeanFactory from InputStream
[[ReadStream com.caucho.vfs.FileReadStream@190a0d6]]
[22:12:29]ERROR[ContextLoader] Failed to initialize beans in application
context: Line 44 in XML document is invalid; nested exception is:
org.xml.sax.SAXParseException: Attribute value
"/admin/SpringAdminAction" of type ID must be a name.
org.xml.sax.SAXParseException: Attribute value
"/admin/SpringAdminAction" of type ID must be a name.
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:76)
The dtd states that it myst be a valid XML ID, and to use the optional
name attribute if you want an illegal name. Though this will require
two identifyers for the bean, which I think is pointless. Does the ID
have to be mandatory. Can't a validation be implemented in java to
check that atleast the name or the id is supplied ? Then the same for
the <!ATTLIST ref local IDREF #IMPLIED> this could be a CDATA with java
based validation.
Cheers,
Cameron
--
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]
|
|
From: <jue...@we...> - 2003-11-01 11:13:11
|
SSd2ZSBjb21taXR0ZWQgYWxsIG9mIHRoZSBjaGFuZ2VzLCBleGNlcHQgdGhlIG9wdGlvbmFsIG9i amVjdCBkZXBlbmRlbmNpZXMgZG9jdSBzdHVmZi4gRmFjdG9yeUJlYW4gaGFzIGEgZ2V0T2JqZWN0 VHlwZSBtZXRob2Qgbm93LCByZXR1cm5pbmcgYW4gYWR2YW5jZSBndWVzcyBvbiB3aGljaCB0eXBl IGdldE9iamVjdCB3aWxsIHJldHVybiAob3IgbnVsbCBpZiBub3Qga25vd24pLiBUaGF0IGlzIHBh cnRpY3VsYXJseSB1c2VmdWwgZm9yIHByb3RvdHlwZSBGYWN0b3J5QmVhbnMgdGhhdCBjcmVhdGUg bmV3IGluc3RhbmNlcyBvbiBlYWNoIGdldE9iamVjdCBjYWxsOyBhdXRvd2lyaW5nIHdpbGwgc3Rp bGwgd29yayBpZiB0aGV5IGltcGxlbWVudCBnZXRPYmplY3RUeXBlIGNvcnJlY3RseS4NCiANCkZv ciBzaW5nbGV0b24gRmFjdG9yeUJlYW5zLCBhdXRvd2lyaW5nIHdpbGwgY2hlY2sgdGhlIGNyZWF0 ZWQgc2luZ2xldG9ucyB0aGVtc2VsdmVzIGlmIGdldE9iamVjdFR5cGUgcmV0dXJucyBudWxsLCBh cyBzaW5nbGV0b25zIGFyZSBhc3N1bWVkIHRvIGJlIGNyZWF0ZWQgb24gaW5pdGlhbGl6YXRpb24g YW55d2F5IC0tIGNoZWNraW5nIHRoZW0gb24gYXV0b3dpcmluZyB3aWxsIG5vdCBpbmN1ciBhbiBp bmVmZmljaWVuY3kuIFRoYXQgd2F5LCBEYXRhU291cmNlIGRlcGVuZGVuY2llcyB3aWxsIGF1dG9t YXRpY2FsbHkgZ2V0IHJlc29sdmVkIHdpdGggYSBKbmRpT2JqZWN0RmFjdG9yeUJlYW4sIGV2ZW4g dGhvdWdoIHRoZSB0eXBlIGlzIG5vdCBrbm93biBpbiBhZHZhbmNlIHdpdGggdGhlIGxhdHRlci4g Tm90ZSB0aGF0IGdldE9iamVjdFR5cGUgd2lsbCBiZSBpbnZva2VkIG9uIHRoZSBmdWxseSBjb25m aWd1cmVkIEZhY3RvcnlCZWFuLCBpdCBjYW4gdGhlcmVmb3JlIHJlbHkgb24gaW5pdGlhbGl6YXRp b24uDQogDQpFdmVyeW9uZSB3aG8ncyBpbnRlcmVzdGVkLCBwbGVhc2UgaXQgZ2l2ZSB0aGlzIHN0 dWZmIGEgdHJ5IC0tIGl0IHdvcmtzIHByZXR0eSBuaWNlbHkgd2l0aCBvbmUgb2Ygb3VyIHdlcmsz QVQgYXBwcyAoYWx0aG91Z2ggd2Ugd29uJ3QgdXNlIGF1dG93aXJpbmcgaW4gdGhlIGVuZCBhcyB3 ZSBiZWxpZXZlIGluIHRoZSB2YWx1ZSBvZiBleHBsaWNpdCBhc3NvY2lhdGlvbnM7IHdlIHdpbGwg dXNlIGRlcGVuZGVuY3kgY2hlY2tzIHRob3VnaCkuIE5vdGUgdGhhdCB5b3UgY2FuIHN0aWxsIHNl dCBleHBsaWNpdCBhc3NvY2lhdGlvbnMgZm9yIGRlcGVuZGVuY2llcyB0aGF0IGF1dG93aXJlIGNh bid0IHJlc29sdmU7IGF1dG93aXJlIHdpbGwgdGhlbiBqdXN0IGFkZHJlc3MgYWxsIHJlbWFpbmlu ZyBkZXBlbmRlbmNpZXMuIEFuZCBhcyBhbHJlYWR5IHN1Z2dlc3RlZCwgaXQgd2lsbCBpZ25vcmUg ZGVwZW5kZW5jaWVzIHdoZXJlIG5vIG1hdGNoaW5nIGJlYW4gaXMgZm91bmQsIGFsbG93aW5nIGZv ciBvcHRpb25hbCBkZXBlbmRlbmNpZXMuIEFkZCBkZXBlbmRlbmN5LWNoZWNrPSJvYmplY3RzIiBm b3Igc3RyaWN0IGF1dG93aXJpbmcgdGhhdCByZXF1aXJlcyBhbGwgZGVwZW5kZW5jaWVzIHRvIGJl IHNhdGlzZmllZC4NCiANCkp1ZXJnZW4NCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJp Y2h0LS0tLS0gDQoJVm9uOiBSb2QgSm9obnNvbiBbbWFpbHRvOnJvZC5qb2huc29uQGludGVyZmFj ZTIxLmNvbV0gDQoJR2VzZW5kZXQ6IERvIDMwLjEwLjIwMDMgMTE6MzEgDQoJQW46IHNwcmluZ2Zy YW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglCZXRyZWZm OiBSZTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIEF1dG93aXJpbmcgYW5kIGRlcGVuZGVu Y3kgY2hlY2tzDQoJDQoJDQoNCglKdWVyZ2VuLA0KCQ0KCUkgYmFzaWNhbGx5IGFncmVlIHdpdGgg eW91ciBwb2ludHMuDQoJDQoJPiBTbyBhcyBhIHN1bW1hcnksIEkgcHJvcG9zZSB0aGUgZm9sbG93 aW5nIGNoYW5nZXM6DQoJPiAxLiAiZGVmYXVsdC1kZXBlbmRlbmN5LWNoZWNrIiBhbmQgImRlZmF1 bHQtYXV0b3dpcmUiIChhbHJlYWR5IGRvbmUgYnV0IG5vdA0KCWNvbW1pdHRlZCB5ZXQpDQoJWWVz Lg0KCQ0KCT4gMi4gaWdub3JlIGNlcnRhaW4gZGVwZW5kZW5jeSB0eXBlcyBmb3IgYXV0b3dpcmlu ZywgQmVhbkZhY3RvcnkgYW5kDQoJQXBwbGljYXRpb25Db250ZXh0IGluIHBhcnRpY3VsYXIgKGRv bmUgdG9vKQ0KCVllcy4NCgkNCgk+IDMuIGV4cGxpY2l0bHkgZG9jdW1lbnQgb3B0aW9uYWwgb2Jq ZWN0IGRlcGVuZGVuY2llcyBpbiBmcmFtZXdvcmsgYmVhbnMgdG8NCgllYXNlIGRlcGVuZGVuY3kg Y2hlY2sgc2V0dGluZ3MNCgkNCglXZSBtYXkgYmUgYWJsZSB0byBkbyBiZXR0ZXIgdGhhbiByZWx5 IG9uIGRvY3MuDQoJDQoJU29tZSBraW5kIG9mIG1ldGFkYXRhIGNvdWxkIGJlIHByb3ZpZGVkIHRv IGF1dG93aXJpbmcgc3BlY2lmeWluZyB3aGF0J3MNCglvcHRpb25hbCBhbmQgd2hhdCdzIG5vdC4g VGhpcyBtaWdodCBtYWtlIHNlbnNlIGZvciBmcmFtZXdvcmsgY29tcG9uZW50cy4NCglPcHRpb25z Og0KCTEuIEF0dGFjaCBtZXRhZGF0YSBhdHRyaWJ1dGVzIHRvIHByb3BlcnRpZXMgd2l0aCBzb21l dGhpbmcgbGlrZQ0KCUBPcHRpb25hbFByb3BlcnR5LiBXZSBjb3VsZCBjb21waWxlIHRoaXMgbWV0 YWRhdGEgaW4gd2l0aCBTcHJpbmcgaWYgb3VyDQoJbWV0YWRhdGEgc3VwcG9ydCBjYW1lIG9uIGZh ciBlbm91Z2ggc28gdGhhdCBvdXIgcnVudGltZSBpbmZvcm1hdGlvbiB3b3VsZA0KCWZpbmQgaXQu IElmIHRoZXJlIHdhcyBubyBhdmFpbGFibGUgbWV0YWRhdGEgaXQgd291bGQganVzdCBhc3N1bWUg dGhhdCBhbGwNCglwcm9wZXJ0aWVzIHdlcmUgb3B0aW9uYWwgb3IgcmVxdWlyZWQuIFRoaXMgd291 bGQgaGF2ZSB0aGUgYWR2YW50YWdlIG9mDQoJZGVmaW5pbmcgYSBwb3dlcmZ1bCB3YXkgZm9yIHVz ZXJzIHRvIHNwZWNpZnkgd2hldGhlciBvciBub3QgdGhlaXIgcHJvcGVydGllcw0KCXdlcmUgcmVx dWlyZWQuDQoJMi4gQWRkIEJlYW5JbmZvIGxpa2UgY2xhc3NlcyAoY2hlY2tpbmcgd2hldGhlciB0 aGVyZSBhcmUgYW55IGZlYXR1cmVzIHdlIGNhbg0KCXVzZSBmcm9tIHRoZSBKYXZhQmVhbnMgQmVh bkluZm8gc3R1ZmYsIHdoaWNoIEkgdGhpbmsgd2FzIHBhaW5mdWwgdG8gdXNlKQ0KCTMuIFVzZSBY TUwgb3IgcHJvcGVydGllcyBtZXRhZGF0YSBwYWNrYWdlZCBhbG9uZyB3aXRoIHRoZSBjbGFzc2Vz Lg0KCQ0KCT4gNC4gcmVkZWZpbmUgYXV0b3dpcmluZyB0byBub3QgY29tcGxhaW4gaWYgbm8gbWF0 Y2hpbmcgYmVhbiBmb3VuZCAocHJvbW90ZQ0KCWFkZGl0aW9uYWwgIm9iamVjdHMiIGRlcGVuZGVu Y3kgY2hlY2sgYXMgYW4gb3B0aW9uKQ0KCQ0KCVllcy4NCgkNCgk+IDUuIGludHJvZHVjZSBhIExp c3RhYmxlQmVhbkZhY3RvcnkuZ2V0QmVhbnNPZlR5cGUoQ2xhc3MgdHlwZSkgbWV0aG9kIGFuZA0K CWJ1aWxkIGF1dG93aXJlLWJ5LXR5cGUgb24gaXQNCglZZXMsIGEgZ2V0QmVhbnNPZlR5cGUoKSBt ZXRob2Qgd291bGQgYmUgdXNlZnVsLiBBbmQgdGhlIEZhY3RvcnlCZWFuIHR5cGUNCglpc3N1ZSBp cyBvdmVyZHVlIGZvciBjbGFyaWZpY2F0aW9uLiBTaG91bGQgdGhlIEZhY3RvcnlCZWFuIGhhdmUg YSBnZXRUeXBlKCkNCgltZXRob2Qgb24gaXQsIHRvIHJldHVybiBudWxsIGlmIGl0IGNhbid0IGtu b3cgKGFzIHdpdGggSk5ESSk/IE9yIGENCglzdWJpbnRlcmZhY2UsIFR5cGVkRmFjdG9yeUJlYW4/ IFRoaXMgd291bGQgZW5hYmxlIG1vc3QgZmFjdG9yeSBiZWFucyB0byB3b3JrDQoJd2l0aCBnZXRC ZWFuTmFtZXNPZlR5cGUoKSBhcyB3ZWxsLiBPZiBjb3Vyc2UgZXZlbiB3aXRoIEpOREkgdGhlIHVz ZXIgY291bGQNCglzcGVjaWZ5IGEgdHlwZSBsaWtlIGphdmF4LnNxbC5EYXRhU291cmNlIGFuZCBp dCB3b3VsZCBnaXZlIHRoZSBGYWN0b3J5QmVhbiBhDQoJd2F5IG9mIGNoZWNraW5nIHRoYXQgdGhl IHZhbHVlIGluIGZpbmRzIGluIEpOREkgbWFrZXMgc2Vuc2UuDQoJDQoJUmVnYXJkcywNCglSb2QN CgkNCgkNCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoJVGhpcyBTRi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBTRi5uZXQg R2l2ZWJhY2sgUHJvZ3JhbS4NCglEb2VzIFNvdXJjZUZvcmdlLm5ldCBoZWxwIHlvdSBiZSBtb3Jl IHByb2R1Y3RpdmU/ICBEb2VzIGl0DQoJaGVscCB5b3UgY3JlYXRlIGJldHRlciBjb2RlPyAgIFNI QVJFIFRIRSBMT1ZFLCBhbmQgaGVscCB1cyBoZWxwDQoJWU9VISAgQ2xpY2sgSGVyZTogaHR0cDov L3NvdXJjZWZvcmdlLm5ldC9kb25hdGUvDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlz dA0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJaHR0 cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3Jr LWRldmVsb3Blcg0KCQ0KDQo= |
|
From: Jason W. S. - S. B. S. <jso...@en...> - 2003-10-31 05:59:31
|
I'm no expert on JSP 2.0, but at first glance it appears that the new EL =
API is no longer excessively tied into web objects.
They seem to have introduced a VariableResolver interface. Each time an =
EL expression is evaluated, the VariableResolver is used to map top =
level variable names into Objects. Presumably the default =
VariableResolver maps everything into the PageContext, but if I =
understand things correctly, EL implementations compatible with JSP 2.0 =
(one of which is presumably part of Tomcat) are necessarily going to be =
usable outside of web applications, simply by implementing an =
appropriate VariableResolver.
I bring this up now because I too would be a big fan of using JSTL EL =
syntax as one of (or even the default) bean mapping syntaxes.
JWS
-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Friday, October 24, 2003 7:19 AM
To: spr...@li...
Subject: Re: [Springframework-developer] FW: [springframework - Help] =
Index properties in forms
Peter,
I tend to agree that JSP EL syntax is preferable, although we are not =
talking about a web-specific thing here. We have to build this into =
BeanWrapperImpl in any case, as we need to do lookups of custom property =
editors etc to provide the same level of functionality as for current =
nested properties. I doubt that we could reuse any existing EL =
implementation for this, as they all work on a JSP PageContext. =
Generally, we should try to avoid any additional dependencies for the =
core bean factory.
Juergen
-----Original Message-----
From: Peter den Haan [mailto:pe...@de...]
Sent: Friday, October 24, 2003 1:25 AM
To: spr...@li...
Subject: [[W3-SPAM]] - Re: [Springframework-developer] FW: =
[springframework - Help] Index properties in forms - Email found in =
subject
Juergen wrote:
> The question is: When and how to we add support for indexed and mapped
properties?
> I guess that if we do, we should adopt the Commons BeanUtils style of
specifying property
> paths for index and map access.
I disagree. I feel we should use (a subset of) the JSTL Expression =
Language
(EL) syntax as our starting point rather than BeanUtils style syntax. =
Please consider that this EL will be part of JSP itself as of version =
2.0 of the spec; why introduce another language into the mix? If in a =
JSP you say ${foo.bar}, shouldn't you be able to name the corresponding =
field foo.bar rather than foo(bar)?
For simple and indexed properties, users won't notice any difference =
anyway. The most important differences are that the precise meaning of =
a[b] is determined by whether "a" evaluates to a List or a Map, and that =
a.b is fully equivalent to a["b"]. BeanUtils-style mapped properties =
(i.e. a(b)) aren't part of the EL; they could be supported in a =
compatible way but IMHO stick with core JavaBeans stuff -- do this only =
if we can come up with a compelling use case for it.
And if this is being refactored anyway, it's probably worth taking a =
look at what would be involved in making the EL implementation =
pluggable.
- Peter
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program. Do you =
like what SourceForge.net is doing for the Open Source Community? Make =
a contribution, and help us add new features and functionality. Click =
here: http://sourceforge.net/donate/ =
_______________________________________________
Springframework-developer mailing list =
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program. Do you =
like what SourceForge.net is doing for the Open Source Community? Make =
a contribution, and help us add new features and functionality. Click =
here: http://sourceforge.net/donate/ =
_______________________________________________
Springframework-developer mailing list =
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Yanger <y-...@26...> - 2003-10-31 05:57:12
|
SGksUm9kIA0KV2UgYXJlIGJhY2tlciBhYm91dCBTcHJpbmcgYXBwbGljYXRpb24gZnJhbWV3b3Jr IGFuZCB3ZSBidWlsZCBhIGZvdXJtIGZvciBDaGluZXNlIHNwZWFrZXJzLCANCnRoZXJlIGlzIGEg bmV3IGZvcnVtLiBBbHNvLCBzb21lIFNwcmluZyBmcmFtZXdvcmsgdXNlcnMgaGF2ZSBiZWd1biB1 c2luZyAjU3ByaW5nZnJhbWV3b3JrIG9uIGh0dHA6Ly94Z2x3LjUxLm5ldC81dGVhbS9zcHJpbmdm cmFtZXdvcmsNCg0KSSBhbSBZYW5nZXIsYSBkZXZlbG9wZXIgdXNlaW5nIHNwcmluZ2ZyYW1ld29y ay5JIGhvcGUgeW91IGFuZCB0aGUgZGV2ZWxvcGVycyB3aXRoIHNwcmluZyBjYW4gc3VwcG9ydCB0 aGUgZm9ydW0uDQpUaGFua3MuDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQpZYW5nZXINCnktZ2VAMjYz Lm5ldA0KoaGhoaGhoaGhoaGhoaGhoaGhoaEJCTIwMDMtMTAtMzEgMTM6NDM6MTkNCg== |
|
From: Rod J. <rod...@in...> - 2003-10-30 17:36:25
|
> I would suggest that one good approach is to go pluggable like this, but > have only a basic implementation in Spring, which wouldn't add much to > the size of Spring, and then people could add in support for other > expression languages if they wanted to. I would probably add OGNL for > example, since I think its great. +1 |
|
From: Colin S. <col...@ex...> - 2003-10-30 17:09:05
|
Depending on how the expression language is implemented (or rather, what syntax the expression language has), I think there is a bit of a potential conflict with PropertyOverrideConfigurer and PropertyPlaceHolderConfigurer, so this is one area that maybe has to be thought about. I think I wrote about this before, but my other suggestion is to make the impl. pluggable, with a namespace prefix to indicate which impl. to actually use, e.g. "ognl:bean1.bean2['key']" would use the ognl impl. Lack of a prefix would default to something. I would suggest that one good approach is to go pluggable like this, but have only a basic implementation in Spring, which wouldn't add much to the size of Spring, and then people could add in support for other expression languages if they wanted to. I would probably add OGNL for example, since I think its great. OGNL btw is at: http://www.ognl.org http://www.ognl.org/2.6.3/Documentation/html/UsersGuide.html. Regards, Colin jürgen höller [werk3AT] wrote: >FYI, we've now got actual requirements for indexed properties in a werk3AT product -- to be implemented by the end of next week. So I'm gonna work on it early next week, suggestions and help are welcome of course. It shouldn't be too hard to do even if fully implemented on our own; the harder part is to settle on a certain syntax. > >Juergen > > > -----Ursprüngliche Nachricht----- > Von: Rod Johnson [mailto:rod...@in...] > Gesendet: Do 23.10.2003 17:32 > An: jürgen höller [werk3AT] > Cc: spr...@li... > Betreff: [Springframework-developer] Re: [springframework - Help] Index properties in forms > > > > Juergen, > > I think we should provide indexed property support for M3. I think you were > right to remove the inadequate support for now. > > I think supporting the Commons syntax makes sense. I think at one point I > envisaged having an IndexedPropertyValue class, but that's probably > unnecessary. > > Regards, > Rod > > -----Original Message----- > From: jürgen höller [werk3AT] > Sent: Thursday, October 23, 2003 4:50 PM > To: spr...@li... > Subject: FW: [springframework - Help] Index properties in forms > > > Everybody, > > Seems like we've got two people inquiring for indexed property support. The > second already dates back to mid-September :-( > > I've just rechecked the BeanWrapper implementation and discovered that there > is no proper support for indexed properties yet. The existing > getIndexedProperty method was not complete (e.g. no support for nesting) and > untested (no unit test covered it), so I've decided to remove it for the > time being (for 1.0 M2). It just confused both of those guys that were > looking for indexed property support. > > Jakarta Commons BeanUtils does support nested and mapped properties, quoting > from the javadocs of their PropertyUtils class: > > <quote> > For the purposes of this class, five formats for referencing a particular > property value of a bean are defined, with the layout of an identifying > String in parentheses: > > * Simple (name) - The specified name identifies an individual property of a > particular JavaBean. The name of the actual getter or setter method to be > used is determined using standard JavaBeans instrospection, so that (unless > overridden by a BeanInfo class, a property named "xyz" will have a getter > method named getXyz() or (for boolean properties only) isXyz(), and a setter > method named setXyz(). > > * Nested (name1.name2.name3) The first name element is used to select a > property getter, as for simple references above. The object returned for > this property is then consulted, using the same approach, for a property > getter for a property named name2, and so on. The property value that is > ultimately retrieved or modified is the one identified by the last name > element. > > * Indexed (name[index]) - The underlying property value is assumed to be an > array, or this JavaBean is assumed to have indexed property getter and > setter methods. The appropriate (zero-relative) entry in the array is > selected. List objects are now also supported for read/write. You simply > need to define a getter that returns the List > > * Mapped (name(key)) - The JavaBean is assumed to have an property getter > and setter methods with an additional attribute of type java.lang.String. > > * Combined (name1.name2[index].name3(key)) - Combining mapped, nested, and > indexed references is also supported > </quote> > > The question is: When and how to we add support for indexed and mapped > properties? I guess that if we do, we should adopt the Commons BeanUtils > style of specifying property paths for index and map access. This means that > we wouldn't need additional methods in the BeanWrapper interface but rather > just support for respective property paths in the BeanWrapperImpl > implementation. > > Any thoughts on this? I've completely forgotten about these things in face > of all the enterprise stuff we've been addressing lately ;-) > > Juergen > > > https://sourceforge.net/forum/message.php?msg_id=2251775 > By: breidenr > > I am using a SimpleFormController to help create an object using an HTTP > form. > Obviously, if my form object is a Vendor, that object has a setName(String) > method, and my HTTP form has a field named "name", the Controller will try > call > Vendor.setName(String) and pass in the value from the form. This also goes > for > nested properties: address.setCity -> vendor.getAddress().setCity(String). > > My question is, is there any support for *indexed* properties? By that, I > mean > purchaseOrder[0].number -> ( (PurchaseOrder) > vendor.getPurchaseOrders().get(0)).setNumber(). I know that some expression > languages support something like this. IIRC, Struts has something like this, > but it has a little kludgy. > > From what I can tell, nested porperies are supported by the Spring > BeanWrapperImpl, > but that is it. If this is correct and I want to implement nested > properties, > any suggestion as to the best route. > > Thanks. > > Ryan > > > > Read and respond to this message at: > https://sourceforge.net/forum/message.php?msg_id=2193984 > By: hogie > > Hi, > > > > If I have a command object that stores a collection and I want the data > binder > to populate that collection from the servlet request, how should I name the > parameters in my servlet request? > > > In Struts I can do field[index], but I can't see if the same is possible in > Spring. I see BeanWrapper.getIndexedPropertyValue() , but no set() > equivalent. > > > Many thanks, > > Mike. > > |
|
From: Rod J. <rod...@in...> - 2003-10-30 16:36:21
|
Juergen, I basically agree with your points. > So as a summary, I propose the following changes: > 1. "default-dependency-check" and "default-autowire" (already done but not committed yet) Yes. > 2. ignore certain dependency types for autowiring, BeanFactory and ApplicationContext in particular (done too) Yes. > 3. explicitly document optional object dependencies in framework beans to ease dependency check settings We may be able to do better than rely on docs. Some kind of metadata could be provided to autowiring specifying what's optional and what's not. This might make sense for framework components. Options: 1. Attach metadata attributes to properties with something like @OptionalProperty. We could compile this metadata in with Spring if our metadata support came on far enough so that our runtime information would find it. If there was no available metadata it would just assume that all properties were optional or required. This would have the advantage of defining a powerful way for users to specify whether or not their properties were required. 2. Add BeanInfo like classes (checking whether there are any features we can use from the JavaBeans BeanInfo stuff, which I think was painful to use) 3. Use XML or properties metadata packaged along with the classes. > 4. redefine autowiring to not complain if no matching bean found (promote additional "objects" dependency check as an option) Yes. > 5. introduce a ListableBeanFactory.getBeansOfType(Class type) method and build autowire-by-type on it Yes, a getBeansOfType() method would be useful. And the FactoryBean type issue is overdue for clarification. Should the FactoryBean have a getType() method on it, to return null if it can't know (as with JNDI)? Or a subinterface, TypedFactoryBean? This would enable most factory beans to work with getBeanNamesOfType() as well. Of course even with JNDI the user could specify a type like javax.sql.DataSource and it would give the FactoryBean a way of checking that the value in finds in JNDI makes sense. Regards, Rod |
|
From: Eduardo I. I. <zi...@su...> - 2003-10-30 16:17:03
|
You can take a look at XWeb as an option to generate the web site (http://xweb.sourceforge.net/) For the documentation itself, I would like to see an outline of all topics that will be described. -- Eduardo Issao Ito |
|
From: <tri...@tr...> - 2003-10-30 14:11:31
|
Sime more statistics: Hits on the www.springframework.org domain are up drastically since the last TSS threads. See: http://www.springframework.org/usage/Spring_hits.htm Thomas > FYI, a little statistics: We had 970 downloads of 1.0 M2 as of tomorrow > morning, after just 6 days! 1.0 M1 has 2800 after 2 months. 0.9 just had 400 > till 0.9.1 came out. Great numbers, IMO! > > For a comparison, WebWork 1.3 has 2300 in the 6 months since end of April. Of > course, Hibernate 2.0.3 has 11600 after 2 months now... but 2.0 and 2.0.1 > together had "just" 2700 in the 2 months till 2.0.2 came out. > > Juergen > > > -----Original Message----- > From: tri...@tr... [mailto:tri...@tr...] > Sent: Friday, October 24, 2003 2:58 AM > To: spr...@li...; jürgen höller > [werk3AT] > Cc: spr...@li... > Subject: Re: [Springframework-developer] Re: Spring Framework 1.0 M2 > released > > > Juergen, > > I have updated the website - let me know if I missed something. > > Thomas > > > > Thomas, > > > > Can you please update the website accordingly, including the documentation > > articles? > > > > Thanks, > > Juergen > > > > > > > > -----Ursprüngliche Nachricht----- > > Von: jürgen höller [werk3AT] > > Gesendet: Fr 24.10.2003 01:08 > > An: spr...@li... > > Cc: spr...@li... > > Betreff: Spring Framework 1.0 M2 released > > > > > > Hi Spring followers, > > > > I'm pleased to announce that we've just released 1.0 M2, the second > > milestone release towards 1.0 and fourth public release in total. It > contains > > numerous bug fixes and new features; see the change log for details. > > > > A major change in terms of samples is that Petclinic is now available in > > alternative implementations for JDBC and Hibernate; therefore, the minimum > > Hibernate jars are now included in the distribution. Furthermore, the > > skeletons have been repackaged into "webapp-minimal" and "webapp-typical", > > the latter with multiple application context configurations. > > > > An important change in recommendation is for the <ref .../> tag in XML > bean > > definitions: <ref bean="..."/> is now a general reference to any bean name > in > > the context, while <ref local="..."/> references a bean id in the same XML > > file (allowing for validation by the XML parser). <ref external="..."/> is > > deprecated now; it behaves the same as <ref bean="..."/> for the time > being. > > > > > > So consider <ref bean="..."/> as the general reference now, no matter if > > local or in a parent context, and <ref local="..."/> as the optional one > for > > strong validation in the local XML file. All existing bean definitions > will > > still work, although we recommend to replace <ref external="..."/> tags > with > > <ref bean="..."/>. > > > > Finally, I'd like to note one minor incompatible API change: > > AbstractFormController's former "processSubmit" method is now called > > "processFormSubmission" to avoid confusion with the "onSubmit" callback of > > SimpleFormController. This will only affect you if you have subclassed > > AbstractFormController directly; simply rename your implementation method > > then. > > > > Regards, > > Juergen > > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: <jue...@we...> - 2003-10-30 10:17:42
|
Of course, take those numbers with a grain of salt: I'm not sure how = trustworthy SourceForge download numbers are after their technical = problems in summer. I consider the ones since August as reliable, = though. Juergen -----Original Message----- From: j=FCrgen h=F6ller [werk3AT]=20 Sent: Thursday, October 30, 2003 11:09 AM To: spr...@li... Subject: RE: [Springframework-developer] Re: Spring Framework 1.0 M2 released FYI, a little statistics: We had 970 downloads of 1.0 M2 as of tomorrow = morning, after just 6 days! 1.0 M1 has 2800 after 2 months. 0.9 just had = 400 till 0.9.1 came out. Great numbers, IMO! For a comparison, WebWork 1.3 has 2300 in the 6 months since end of = April. Of course, Hibernate 2.0.3 has 11600 after 2 months now... but = 2.0 and 2.0.1 together had "just" 2700 in the 2 months till 2.0.2 came = out. Juergen -----Original Message----- From: tri...@tr... [mailto:tri...@tr...] Sent: Friday, October 24, 2003 2:58 AM To: spr...@li...; j=FCrgen h=F6ller [werk3AT] Cc: spr...@li... Subject: Re: [Springframework-developer] Re: Spring Framework 1.0 M2 released Juergen, I have updated the website - let me know if I missed something. Thomas > Thomas, > =20 > Can you please update the website accordingly, including the = documentation > articles? > =20 > Thanks, > Juergen > =20 > =20 >=20 > -----Urspr=C3=BCngliche Nachricht-----=20 > Von: j=C3=BCrgen h=C3=B6ller [werk3AT]=20 > Gesendet: Fr 24.10.2003 01:08=20 > An: spr...@li...=20 > Cc: spr...@li...=20 > Betreff: Spring Framework 1.0 M2 released > =09 > =09 > Hi Spring followers, > =20 > I'm pleased to announce that we've just released 1.0 M2, the second > milestone release towards 1.0 and fourth public release in total. It = contains > numerous bug fixes and new features; see the change log for details. > =20 > A major change in terms of samples is that Petclinic is now available = in > alternative implementations for JDBC and Hibernate; therefore, the = minimum > Hibernate jars are now included in the distribution. Furthermore, the > skeletons have been repackaged into "webapp-minimal" and = "webapp-typical", > the latter with multiple application context configurations. > =20 > An important change in recommendation is for the <ref .../> tag in = XML bean > definitions: <ref bean=3D"..."/> is now a general reference to any = bean name in > the context, while <ref local=3D"..."/> references a bean id in the = same XML > file (allowing for validation by the XML parser). <ref = external=3D"..."/> is > deprecated now; it behaves the same as <ref bean=3D"..."/> for the = time being. >=20 > =20 > So consider <ref bean=3D"..."/> as the general reference now, no = matter if > local or in a parent context, and <ref local=3D"..."/> as the optional = one for > strong validation in the local XML file. All existing bean definitions = will > still work, although we recommend to replace <ref external=3D"..."/> = tags with > <ref bean=3D"..."/>. > =20 > Finally, I'd like to note one minor incompatible API change: > AbstractFormController's former "processSubmit" method is now called > "processFormSubmission" to avoid confusion with the "onSubmit" = callback of > SimpleFormController. This will only affect you if you have subclassed > AbstractFormController directly; simply rename your implementation = method > then. > =20 > Regards, > Juergen >=20 >=20 ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2003-10-30 10:10:48
|
FYI, a little statistics: We had 970 downloads of 1.0 M2 as of tomorrow = morning, after just 6 days! 1.0 M1 has 2800 after 2 months. 0.9 just had = 400 till 0.9.1 came out. Great numbers, IMO! For a comparison, WebWork 1.3 has 2300 in the 6 months since end of = April. Of course, Hibernate 2.0.3 has 11600 after 2 months now... but = 2.0 and 2.0.1 together had "just" 2700 in the 2 months till 2.0.2 came = out. Juergen -----Original Message----- From: tri...@tr... [mailto:tri...@tr...] Sent: Friday, October 24, 2003 2:58 AM To: spr...@li...; j=FCrgen h=F6ller [werk3AT] Cc: spr...@li... Subject: Re: [Springframework-developer] Re: Spring Framework 1.0 M2 released Juergen, I have updated the website - let me know if I missed something. Thomas > Thomas, > =20 > Can you please update the website accordingly, including the = documentation > articles? > =20 > Thanks, > Juergen > =20 > =20 >=20 > -----Urspr=C3=BCngliche Nachricht-----=20 > Von: j=C3=BCrgen h=C3=B6ller [werk3AT]=20 > Gesendet: Fr 24.10.2003 01:08=20 > An: spr...@li...=20 > Cc: spr...@li...=20 > Betreff: Spring Framework 1.0 M2 released > =09 > =09 > Hi Spring followers, > =20 > I'm pleased to announce that we've just released 1.0 M2, the second > milestone release towards 1.0 and fourth public release in total. It = contains > numerous bug fixes and new features; see the change log for details. > =20 > A major change in terms of samples is that Petclinic is now available = in > alternative implementations for JDBC and Hibernate; therefore, the = minimum > Hibernate jars are now included in the distribution. Furthermore, the > skeletons have been repackaged into "webapp-minimal" and = "webapp-typical", > the latter with multiple application context configurations. > =20 > An important change in recommendation is for the <ref .../> tag in = XML bean > definitions: <ref bean=3D"..."/> is now a general reference to any = bean name in > the context, while <ref local=3D"..."/> references a bean id in the = same XML > file (allowing for validation by the XML parser). <ref = external=3D"..."/> is > deprecated now; it behaves the same as <ref bean=3D"..."/> for the = time being. >=20 > =20 > So consider <ref bean=3D"..."/> as the general reference now, no = matter if > local or in a parent context, and <ref local=3D"..."/> as the optional = one for > strong validation in the local XML file. All existing bean definitions = will > still work, although we recommend to replace <ref external=3D"..."/> = tags with > <ref bean=3D"..."/>. > =20 > Finally, I'd like to note one minor incompatible API change: > AbstractFormController's former "processSubmit" method is now called > "processFormSubmission" to avoid confusion with the "onSubmit" = callback of > SimpleFormController. This will only affect you if you have subclassed > AbstractFormController directly; simply rename your implementation = method > then. > =20 > Regards, > Juergen >=20 >=20 |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-10-30 06:42:17
|
> One approach is obviously the Maven or Forrest one, where it > puts out a site in a consistent format. This is pretty easy to use obviously. On > the other hand, what I _really_ appreciate about the coWiki approach > used by Hibernate to run their site is that it encourages > end-users to > document their own tips and tricks, and makes it much easier for > _anybody_ to add spontaneous documentation, which can > possibly later be > incorporated into the real docs. I definitely like the Hibernate approach. Keep the website small, easily accesible and very consistent documentation because it's maintained by the developers and put in a consistent format plus a lot of user communication via the Wiki. But that's just me... <darren>So would all future documentation be created and maintained as source in DocBook XML if it's agreed to adopt it? </darren> I like the two-step approach, let users contribute in the form of a userfriendly Wiki, then merge it in into the DocBook documentation... Might generate some more work for the developers but keeps things _very_ consistent... > So if Maven/Forest is used to produce the site, I think there should > still be a friendly/usable wiki (like coWiki, as opposed to > most Wikis, > which scare people off), for supplemental documentation. Alternately, > coWiki could be used for the entire site, the disadvantage there that > it's pretty much harder to put it together as part of the build. We at least have to have a decent uplink then for the times when Spring becomes really popular :) Regards, Alef |
|
From: Mike Cannon-B. <mi...@at...> - 2003-10-30 00:30:31
|
Yah - it's a pretty good product, +1 from me ;) I think we'd be happy to host an instance for the Spring Framework (especially as we're starting to use it in house), but the only problem is you won't get a nice domain (like jira.springframework.org) - not sure how much of a drama that is! Let me know. Cheers, Mike ATLASSIAN - http://www.atlassian.com On 30/10/03 7:01 AM, "Kopylenko, Dmitry" (dko...@su...) penned the words: > I did send them an email, asking if it was possible to host an instance for > Spring Framework on one of their servers. > > Regards, > Dmitriy. > > -----Original Message----- > From: Alef Arendsen (JTeam) [mailto:al...@jt...] > Sent: Wednesday, October 29, 2003 2:39 PM > To: spr...@li... > Subject: RE: [Springframework-developer] JIRA > > > Hmmm, hibernate is running their JIRA instance at Atlassian itself, they > probably wouldn't mind running a Spring one as well, would they? We might as > well just conatct them... > > Any volunteers? > > Alef > > P.s. that doesn't mean I don't wanna give up the bandwidth, it's just that > it's probably no worry for htem :) > >> -----Oorspronkelijk bericht----- >> Van: spr...@li... >> [mailto:spr...@li...] >> Namens Kopylenko, Dmitry >> Verzonden: Wednesday, October 29, 2003 7:30 PM >> Aan: 'spr...@li...' >> Onderwerp: RE: [Springframework-developer] JIRA >> >> >> Sounds good. >> >> -----Original Message----- >> From: Alef Arendsen (JTeam) [mailto:al...@jt...] >> Sent: Wednesday, October 29, 2003 12:37 PM >> To: spr...@li... >> Subject: RE: [Springframework-developer] JIRA >> >> >> Codehaus sounds good, however, if it isn't possible (they're >> hosting picocontainer, maybe they don't like us there :), I >> don't care about running it here... There a 512kb uplink (and >> way too much down) so that should suffice... As long as it >> fits in our current live environment >> (JBoss/MySQL) and it does not require huge memory footprints... >> >> Alef >> >>> -----Oorspronkelijk bericht----- >>> Van: spr...@li... >>> [mailto:spr...@li...] >>> Namens Colin Sampaleanu >>> Verzonden: Wednesday, October 29, 2003 6:04 PM >>> Aan: spr...@li... >>> Onderwerp: Re: [Springframework-developer] JIRA >>> >>> >>> +1 on the idea. There is a question as to where it would >> be hosted >>> though. Maybe we could convince the CodeHaus guys to use theirs: >>> http://jira.codehaus.org/secure/Dashboard.jspa >>> >>> >>> Kopylenko, Dmitry wrote: >>> >>>> Hello everyone, >>>> >>>> Would it be a good idea to use JIRA for Spring project tracking? I >>>> just saw on their site that they have a free license for >>> open source >>>> projects. >>>> >>>> What do you think? >>>> >>>> Regards, >>>> Dmitriy. >>>> >>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: SF.net Giveback Program. Does >>> SourceForge.net help you be more productive? Does it >>> help you create better code? SHARE THE LOVE, and help us help >>> YOU! Click Here: http://sourceforge.net/donate/ >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> >> https://lists.sourceforge.net/lists/listinfo/s> > pringframework-developer >>> >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: SF.net Giveback Program. >> Does SourceForge.net help you be more productive? Does it >> help you create better code? SHARE THE LOVE, and help us help >> YOU! Click Here: http://sourceforge.net/donate/ >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: SF.net Giveback Program. >> Does SourceForge.net help you be more productive? Does it >> help you create better code? SHARE THE LOVE, and help us help >> YOU! Click Here: http://sourceforge.net/donate/ >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Darren D. <da...@da...> - 2003-10-29 23:48:05
|
On Wednesday 29 October 2003 23:15, Alef Arendsen (JTeam) wrote: > What do you think??? looks like it works pretty well. So would all future documentation be created and maintained as source in DocBook XML if it's agreed to adopt it? -- Darren Davison Public Key: http://www.davison.uk.net/key.jsp |
|
From: Colin S. <col...@ex...> - 2003-10-29 23:35:42
|
That's pretty cool! Aside from the question of generating HTML/PDF/whatever for individual docs, there is the question of the best mechanism to produce the web site. One approach is obviously the Maven or Forrest one, where it puts out a site in a consistent format. This is pretty easy to use obviously. On the other hand, what I _really_ appreciate about the coWiki approach used by Hibernate to run their site is that it encourages end-users to document their own tips and tricks, and makes it much easier for _anybody_ to add spontaneous documentation, which can possibly later be incorporated into the real docs. So if Maven/Forest is used to produce the site, I think there should still be a friendly/usable wiki (like coWiki, as opposed to most Wikis, which scare people off), for supplemental documentation. Alternately, coWiki could be used for the entire site, the disadvantage there that it's pretty much harder to put it together as part of the build. Regards, Colin Alef Arendsen (JTeam) wrote: >I've been spending some time on the documentation question (summary of >what's been discussed can be found below). > >Basically when the KISS principle applies, the Hibernate approach is >pretty cool. Documentation defined in DocBook, transformation done using >DocBook XSL (found on SourceForge) to both PDF and HTML (singlepage and >multi-page)... > >I've also had look at Forrest. To be able to run it, I needed to >checkout the sources from forrest and build it. The CVS was somehow >corrupt, so far for Forrest :)... No, without jokes: Forrest has this >concept of the generating a site and from there on, generate other >documentation. With some advanced configuration you can aggregate >multiple pages into a singel PDF file (but like I said, advanced >configuration, not really documented and stuff). Then there is the >problem that the default document format is XDoc and we'll have to tweak >forrest to get DocBook working (won't really be a big problem, but >still). Also, I don't really like to get stuck to Forrest for the site >as well! > >Ok, like I said, I've took a look at the Hibernate approach and copied >some of our docs into the structure they have. Within half an hour I got >everything running... Results at >http://www2.jteam.nl/spring/index.html... It's just DocBook xml files, >generation takes about 30 seconds... > >I'd like to transform all documentation we have (which is pretty much >including the tutorialpdf and stuff) to some sort of reference doc to >achieve consistency. I can transform some of the documentation we >already have, but still, it's probably a lot of work to get something >like the Hibernate referecne docuemntation ready... > >What do you think??? > >Alef > >Summary of discussion: > ><colin> >As for docs, most people generating docs with maven are using the XDOC >plugin. It works pretty well, but the XML dialect is not any sort of >standard. In that respect, while doing DocBook (with Forrest, or >whatever mechanism) is a bit more complicated, there will be more >advantages later as tool support picks up. ></colin> > ><darren> >I think docBook (or any other format that would allow generation of >multiple user formats) is a good idea. Don't have any experience of >Forrest but it seems to have some good reviews and looks pretty simple >to pick up. ></darren> > ><alef> >I was thinking about having somewhat more integrated docs like >Hibernate. Hibernate's using DocBook as the structure of their >documentation. I think that's quite good sice you can do anything with >it (generate pdf, html, etc). We've discussed Maven shortly, but my >opinion is that it's too much project oriented. Also, we don't really >need the build functionality Maven provides. Forrest sounds like another >option too... Does anyone have experience with it? ></alef> > > |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-10-29 23:16:14
|
I've been spending some time on the documentation question (summary of what's been discussed can be found below). Basically when the KISS principle applies, the Hibernate approach is pretty cool. Documentation defined in DocBook, transformation done using DocBook XSL (found on SourceForge) to both PDF and HTML (singlepage and multi-page)... I've also had look at Forrest. To be able to run it, I needed to checkout the sources from forrest and build it. The CVS was somehow corrupt, so far for Forrest :)... No, without jokes: Forrest has this concept of the generating a site and from there on, generate other documentation. With some advanced configuration you can aggregate multiple pages into a singel PDF file (but like I said, advanced configuration, not really documented and stuff). Then there is the problem that the default document format is XDoc and we'll have to tweak forrest to get DocBook working (won't really be a big problem, but still). Also, I don't really like to get stuck to Forrest for the site as well! Ok, like I said, I've took a look at the Hibernate approach and copied some of our docs into the structure they have. Within half an hour I got everything running... Results at http://www2.jteam.nl/spring/index.html... It's just DocBook xml files, generation takes about 30 seconds... I'd like to transform all documentation we have (which is pretty much including the tutorialpdf and stuff) to some sort of reference doc to achieve consistency. I can transform some of the documentation we already have, but still, it's probably a lot of work to get something like the Hibernate referecne docuemntation ready... What do you think??? Alef Summary of discussion: <colin> As for docs, most people generating docs with maven are using the XDOC plugin. It works pretty well, but the XML dialect is not any sort of standard. In that respect, while doing DocBook (with Forrest, or whatever mechanism) is a bit more complicated, there will be more advantages later as tool support picks up. </colin> <darren> I think docBook (or any other format that would allow generation of multiple user formats) is a good idea. Don't have any experience of Forrest but it seems to have some good reviews and looks pretty simple to pick up. </darren> <alef> I was thinking about having somewhat more integrated docs like Hibernate. Hibernate's using DocBook as the structure of their documentation. I think that's quite good sice you can do anything with it (generate pdf, html, etc). We've discussed Maven shortly, but my opinion is that it's too much project oriented. Also, we don't really need the build functionality Maven provides. Forrest sounds like another option too... Does anyone have experience with it? </alef> == JTeam B.V. Donker Curtiusstraat 7-412 1051 JL Amsterdam T: +31 20 486 20 36 M: +31 6 24 11 1996 F: +31 84 837 00 00 E: al...@jt... W: http://www.jbosssupport.nl W: http://www.jteam.nl |
|
From: <jue...@we...> - 2003-10-29 22:27:59
|
RllJLCB3ZSd2ZSBub3cgZ290IGFjdHVhbCByZXF1aXJlbWVudHMgZm9yIGluZGV4ZWQgcHJvcGVy dGllcyBpbiBhIHdlcmszQVQgcHJvZHVjdCAtLSB0byBiZSBpbXBsZW1lbnRlZCBieSB0aGUgZW5k IG9mIG5leHQgd2Vlay4gU28gSSdtIGdvbm5hIHdvcmsgb24gaXQgZWFybHkgbmV4dCB3ZWVrLCBz dWdnZXN0aW9ucyBhbmQgaGVscCBhcmUgd2VsY29tZSBvZiBjb3Vyc2UuIEl0IHNob3VsZG4ndCBi ZSB0b28gaGFyZCB0byBkbyBldmVuIGlmIGZ1bGx5IGltcGxlbWVudGVkIG9uIG91ciBvd247IHRo ZSBoYXJkZXIgcGFydCBpcyB0byBzZXR0bGUgb24gYSBjZXJ0YWluIHN5bnRheC4NCiANCkp1ZXJn ZW4NCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBSb2Qg Sm9obnNvbiBbbWFpbHRvOnJvZC5qb2huc29uQGludGVyZmFjZTIxLmNvbV0gDQoJR2VzZW5kZXQ6 IERvIDIzLjEwLjIwMDMgMTc6MzIgDQoJQW46IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF0gDQoJ Q2M6IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUJl dHJlZmY6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBSZTogW3NwcmluZ2ZyYW1ld29yayAt IEhlbHBdIEluZGV4IHByb3BlcnRpZXMgaW4gZm9ybXMNCgkNCgkNCg0KCUp1ZXJnZW4sDQoJDQoJ SSB0aGluayB3ZSBzaG91bGQgcHJvdmlkZSBpbmRleGVkIHByb3BlcnR5IHN1cHBvcnQgZm9yIE0z LiAgSSB0aGluayB5b3Ugd2VyZQ0KCXJpZ2h0IHRvIHJlbW92ZSB0aGUgaW5hZGVxdWF0ZSBzdXBw b3J0IGZvciBub3cuDQoJDQoJSSB0aGluayBzdXBwb3J0aW5nIHRoZSBDb21tb25zIHN5bnRheCBt YWtlcyBzZW5zZS4gSSB0aGluayBhdCBvbmUgcG9pbnQgSQ0KCWVudmlzYWdlZCBoYXZpbmcgYW4g SW5kZXhlZFByb3BlcnR5VmFsdWUgY2xhc3MsIGJ1dCB0aGF0J3MgcHJvYmFibHkNCgl1bm5lY2Vz c2FyeS4NCgkNCglSZWdhcmRzLA0KCVJvZA0KCQ0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQoJRnJvbTogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXQ0KCVNlbnQ6IFRodXJzZGF5LCBPY3Rv YmVyIDIzLCAyMDAzIDQ6NTAgUE0NCglUbzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0 cy5zb3VyY2Vmb3JnZS5uZXQNCglTdWJqZWN0OiBGVzogW3NwcmluZ2ZyYW1ld29yayAtIEhlbHBd IEluZGV4IHByb3BlcnRpZXMgaW4gZm9ybXMNCgkNCgkNCglFdmVyeWJvZHksDQoJDQoJU2VlbXMg bGlrZSB3ZSd2ZSBnb3QgdHdvIHBlb3BsZSBpbnF1aXJpbmcgZm9yIGluZGV4ZWQgcHJvcGVydHkg c3VwcG9ydC4gVGhlDQoJc2Vjb25kIGFscmVhZHkgZGF0ZXMgYmFjayB0byBtaWQtU2VwdGVtYmVy IDotKA0KCQ0KCUkndmUganVzdCByZWNoZWNrZWQgdGhlIEJlYW5XcmFwcGVyIGltcGxlbWVudGF0 aW9uIGFuZCBkaXNjb3ZlcmVkIHRoYXQgdGhlcmUNCglpcyBubyBwcm9wZXIgc3VwcG9ydCBmb3Ig aW5kZXhlZCBwcm9wZXJ0aWVzIHlldC4gVGhlIGV4aXN0aW5nDQoJZ2V0SW5kZXhlZFByb3BlcnR5 IG1ldGhvZCB3YXMgbm90IGNvbXBsZXRlIChlLmcuIG5vIHN1cHBvcnQgZm9yIG5lc3RpbmcpIGFu ZA0KCXVudGVzdGVkIChubyB1bml0IHRlc3QgY292ZXJlZCBpdCksIHNvIEkndmUgZGVjaWRlZCB0 byByZW1vdmUgaXQgZm9yIHRoZQ0KCXRpbWUgYmVpbmcgKGZvciAxLjAgTTIpLiBJdCBqdXN0IGNv bmZ1c2VkIGJvdGggb2YgdGhvc2UgZ3V5cyB0aGF0IHdlcmUNCglsb29raW5nIGZvciBpbmRleGVk IHByb3BlcnR5IHN1cHBvcnQuDQoJDQoJSmFrYXJ0YSBDb21tb25zIEJlYW5VdGlscyBkb2VzIHN1 cHBvcnQgbmVzdGVkIGFuZCBtYXBwZWQgcHJvcGVydGllcywgcXVvdGluZw0KCWZyb20gdGhlIGph dmFkb2NzIG9mIHRoZWlyIFByb3BlcnR5VXRpbHMgY2xhc3M6DQoJDQoJPHF1b3RlPg0KCUZvciB0 aGUgcHVycG9zZXMgb2YgdGhpcyBjbGFzcywgZml2ZSBmb3JtYXRzIGZvciByZWZlcmVuY2luZyBh IHBhcnRpY3VsYXINCglwcm9wZXJ0eSB2YWx1ZSBvZiBhIGJlYW4gYXJlIGRlZmluZWQsIHdpdGgg dGhlIGxheW91dCBvZiBhbiBpZGVudGlmeWluZw0KCVN0cmluZyBpbiBwYXJlbnRoZXNlczoNCgkN CgkqIFNpbXBsZSAobmFtZSkgLSBUaGUgc3BlY2lmaWVkIG5hbWUgaWRlbnRpZmllcyBhbiBpbmRp dmlkdWFsIHByb3BlcnR5IG9mIGENCglwYXJ0aWN1bGFyIEphdmFCZWFuLiBUaGUgbmFtZSBvZiB0 aGUgYWN0dWFsIGdldHRlciBvciBzZXR0ZXIgbWV0aG9kIHRvIGJlDQoJdXNlZCBpcyBkZXRlcm1p bmVkIHVzaW5nIHN0YW5kYXJkIEphdmFCZWFucyBpbnN0cm9zcGVjdGlvbiwgc28gdGhhdCAodW5s ZXNzDQoJb3ZlcnJpZGRlbiBieSBhIEJlYW5JbmZvIGNsYXNzLCBhIHByb3BlcnR5IG5hbWVkICJ4 eXoiIHdpbGwgaGF2ZSBhIGdldHRlcg0KCW1ldGhvZCBuYW1lZCBnZXRYeXooKSBvciAoZm9yIGJv b2xlYW4gcHJvcGVydGllcyBvbmx5KSBpc1h5eigpLCBhbmQgYSBzZXR0ZXINCgltZXRob2QgbmFt ZWQgc2V0WHl6KCkuDQoJDQoJKiBOZXN0ZWQgKG5hbWUxLm5hbWUyLm5hbWUzKSBUaGUgZmlyc3Qg bmFtZSBlbGVtZW50IGlzIHVzZWQgdG8gc2VsZWN0IGENCglwcm9wZXJ0eSBnZXR0ZXIsIGFzIGZv ciBzaW1wbGUgcmVmZXJlbmNlcyBhYm92ZS4gVGhlIG9iamVjdCByZXR1cm5lZCBmb3INCgl0aGlz IHByb3BlcnR5IGlzIHRoZW4gY29uc3VsdGVkLCB1c2luZyB0aGUgc2FtZSBhcHByb2FjaCwgZm9y IGEgcHJvcGVydHkNCglnZXR0ZXIgZm9yIGEgcHJvcGVydHkgbmFtZWQgbmFtZTIsIGFuZCBzbyBv bi4gVGhlIHByb3BlcnR5IHZhbHVlIHRoYXQgaXMNCgl1bHRpbWF0ZWx5IHJldHJpZXZlZCBvciBt b2RpZmllZCBpcyB0aGUgb25lIGlkZW50aWZpZWQgYnkgdGhlIGxhc3QgbmFtZQ0KCWVsZW1lbnQu DQoJDQoJKiBJbmRleGVkIChuYW1lW2luZGV4XSkgLSBUaGUgdW5kZXJseWluZyBwcm9wZXJ0eSB2 YWx1ZSBpcyBhc3N1bWVkIHRvIGJlIGFuDQoJYXJyYXksIG9yIHRoaXMgSmF2YUJlYW4gaXMgYXNz dW1lZCB0byBoYXZlIGluZGV4ZWQgcHJvcGVydHkgZ2V0dGVyIGFuZA0KCXNldHRlciBtZXRob2Rz LiBUaGUgYXBwcm9wcmlhdGUgKHplcm8tcmVsYXRpdmUpIGVudHJ5IGluIHRoZSBhcnJheSBpcw0K CXNlbGVjdGVkLiBMaXN0IG9iamVjdHMgYXJlIG5vdyBhbHNvIHN1cHBvcnRlZCBmb3IgcmVhZC93 cml0ZS4gWW91IHNpbXBseQ0KCW5lZWQgdG8gZGVmaW5lIGEgZ2V0dGVyIHRoYXQgcmV0dXJucyB0 aGUgTGlzdA0KCQ0KCSogTWFwcGVkIChuYW1lKGtleSkpIC0gVGhlIEphdmFCZWFuIGlzIGFzc3Vt ZWQgdG8gaGF2ZSBhbiBwcm9wZXJ0eSBnZXR0ZXINCglhbmQgc2V0dGVyIG1ldGhvZHMgd2l0aCBh biBhZGRpdGlvbmFsIGF0dHJpYnV0ZSBvZiB0eXBlIGphdmEubGFuZy5TdHJpbmcuDQoJDQoJKiBD b21iaW5lZCAobmFtZTEubmFtZTJbaW5kZXhdLm5hbWUzKGtleSkpIC0gQ29tYmluaW5nIG1hcHBl ZCwgbmVzdGVkLCBhbmQNCglpbmRleGVkIHJlZmVyZW5jZXMgaXMgYWxzbyBzdXBwb3J0ZWQNCgk8 L3F1b3RlPg0KCQ0KCVRoZSBxdWVzdGlvbiBpczogV2hlbiBhbmQgaG93IHRvIHdlIGFkZCBzdXBw b3J0IGZvciBpbmRleGVkIGFuZCBtYXBwZWQNCglwcm9wZXJ0aWVzPyBJIGd1ZXNzIHRoYXQgaWYg d2UgZG8sIHdlIHNob3VsZCBhZG9wdCB0aGUgQ29tbW9ucyBCZWFuVXRpbHMNCglzdHlsZSBvZiBz cGVjaWZ5aW5nIHByb3BlcnR5IHBhdGhzIGZvciBpbmRleCBhbmQgbWFwIGFjY2Vzcy4gVGhpcyBt ZWFucyB0aGF0DQoJd2Ugd291bGRuJ3QgbmVlZCBhZGRpdGlvbmFsIG1ldGhvZHMgaW4gdGhlIEJl YW5XcmFwcGVyIGludGVyZmFjZSBidXQgcmF0aGVyDQoJanVzdCBzdXBwb3J0IGZvciByZXNwZWN0 aXZlIHByb3BlcnR5IHBhdGhzIGluIHRoZSBCZWFuV3JhcHBlckltcGwNCglpbXBsZW1lbnRhdGlv bi4NCgkNCglBbnkgdGhvdWdodHMgb24gdGhpcz8gSSd2ZSBjb21wbGV0ZWx5IGZvcmdvdHRlbiBh Ym91dCB0aGVzZSB0aGluZ3MgaW4gZmFjZQ0KCW9mIGFsbCB0aGUgZW50ZXJwcmlzZSBzdHVmZiB3 ZSd2ZSBiZWVuIGFkZHJlc3NpbmcgbGF0ZWx5IDstKQ0KCQ0KCUp1ZXJnZW4NCgkNCgkNCglodHRw czovL3NvdXJjZWZvcmdlLm5ldC9mb3J1bS9tZXNzYWdlLnBocD9tc2dfaWQ9MjI1MTc3NQ0KCUJ5 OiBicmVpZGVucg0KCQ0KCUkgYW0gdXNpbmcgYSBTaW1wbGVGb3JtQ29udHJvbGxlciB0byBoZWxw IGNyZWF0ZSBhbiBvYmplY3QgdXNpbmcgYW4gSFRUUA0KCWZvcm0uDQoJT2J2aW91c2x5LCBpZiBt eSBmb3JtIG9iamVjdCBpcyBhIFZlbmRvciwgdGhhdCBvYmplY3QgaGFzIGEgc2V0TmFtZShTdHJp bmcpDQoJbWV0aG9kLCBhbmQgbXkgSFRUUCBmb3JtIGhhcyBhIGZpZWxkIG5hbWVkICJuYW1lIiwg dGhlIENvbnRyb2xsZXIgd2lsbCB0cnkNCgljYWxsDQoJVmVuZG9yLnNldE5hbWUoU3RyaW5nKSBh bmQgcGFzcyBpbiB0aGUgdmFsdWUgZnJvbSB0aGUgZm9ybS4gVGhpcyBhbHNvIGdvZXMNCglmb3IN CgluZXN0ZWQgcHJvcGVydGllczogYWRkcmVzcy5zZXRDaXR5IC0+IHZlbmRvci5nZXRBZGRyZXNz KCkuc2V0Q2l0eShTdHJpbmcpLg0KCQ0KCU15IHF1ZXN0aW9uIGlzLCBpcyB0aGVyZSBhbnkgc3Vw cG9ydCBmb3IgKmluZGV4ZWQqIHByb3BlcnRpZXM/IEJ5IHRoYXQsIEkNCgltZWFuDQoJcHVyY2hh c2VPcmRlclswXS5udW1iZXIgLT4gKCAoUHVyY2hhc2VPcmRlcikNCgl2ZW5kb3IuZ2V0UHVyY2hh c2VPcmRlcnMoKS5nZXQoMCkpLnNldE51bWJlcigpLiBJIGtub3cgdGhhdCBzb21lIGV4cHJlc3Np b24NCglsYW5ndWFnZXMgc3VwcG9ydCBzb21ldGhpbmcgbGlrZSB0aGlzLiBJSVJDLCBTdHJ1dHMg aGFzIHNvbWV0aGluZyBsaWtlIHRoaXMsDQoJYnV0IGl0IGhhcyBhIGxpdHRsZSBrbHVkZ3kuDQoJ DQoJRnJvbSB3aGF0IEkgY2FuIHRlbGwsIG5lc3RlZCBwb3JwZXJpZXMgYXJlIHN1cHBvcnRlZCBi eSB0aGUgU3ByaW5nDQoJQmVhbldyYXBwZXJJbXBsLA0KCWJ1dCB0aGF0IGlzIGl0LiBJZiB0aGlz IGlzIGNvcnJlY3QgYW5kIEkgd2FudCB0byBpbXBsZW1lbnQgbmVzdGVkDQoJcHJvcGVydGllcywN Cglhbnkgc3VnZ2VzdGlvbiBhcyB0byB0aGUgYmVzdCByb3V0ZS4NCgkNCglUaGFua3MuDQoJDQoJ Unlhbg0KCQ0KCQ0KCQ0KCVJlYWQgYW5kIHJlc3BvbmQgdG8gdGhpcyBtZXNzYWdlIGF0Og0KCWh0 dHBzOi8vc291cmNlZm9yZ2UubmV0L2ZvcnVtL21lc3NhZ2UucGhwP21zZ19pZD0yMTkzOTg0DQoJ Qnk6IGhvZ2llDQoJDQoJSGksDQoJDQoJDQoJDQoJSWYgSSBoYXZlIGEgY29tbWFuZCBvYmplY3Qg dGhhdCBzdG9yZXMgYSBjb2xsZWN0aW9uIGFuZCBJIHdhbnQgdGhlIGRhdGENCgliaW5kZXINCgl0 byBwb3B1bGF0ZSB0aGF0IGNvbGxlY3Rpb24gZnJvbSB0aGUgc2VydmxldCByZXF1ZXN0LCBob3cg c2hvdWxkIEkgbmFtZSB0aGUNCglwYXJhbWV0ZXJzIGluIG15IHNlcnZsZXQgcmVxdWVzdD8NCgkN CgkNCglJbiBTdHJ1dHMgSSBjYW4gZG8gZmllbGRbaW5kZXhdLCBidXQgSSBjYW4ndCBzZWUgaWYg dGhlIHNhbWUgaXMgcG9zc2libGUgaW4NCglTcHJpbmcuICBJIHNlZSBCZWFuV3JhcHBlci5nZXRJ bmRleGVkUHJvcGVydHlWYWx1ZSgpICwgYnV0IG5vIHNldCgpDQoJZXF1aXZhbGVudC4NCgkNCgkN CglNYW55IHRoYW5rcywNCgkNCglNaWtlLg0KCQ0KCQ0KCQ0KCQ0KCS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCglUaGlzIFNGLm5ldCBlbWFp bCBpcyBzcG9uc29yZWQgYnk6IFRoZSBTRi5uZXQgRG9uYXRpb24gUHJvZ3JhbS4NCglEbyB5b3Ug bGlrZSB3aGF0IFNvdXJjZUZvcmdlLm5ldCBpcyBkb2luZyBmb3IgdGhlIE9wZW4NCglTb3VyY2Ug Q29tbXVuaXR5PyAgTWFrZSBhIGNvbnRyaWJ1dGlvbiwgYW5kIGhlbHAgdXMgYWRkIG5ldw0KCWZl YXR1cmVzIGFuZCBmdW5jdGlvbmFsaXR5LiBDbGljayBoZXJlOiBodHRwOi8vc291cmNlZm9yZ2Uu bmV0L2RvbmF0ZS8NCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJh bWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNv dXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoJ DQoNCg== |
|
From: <jue...@we...> - 2003-10-29 21:56:04
|
SSd2ZSBkaWdnZWQgaW50byBvdXIgY3VycmVudCBhdXRvd2lyZSBhbmQgZGVwZW5kZW5jeSBjaGVj ayBzdXBwb3J0IHRvZGF5IGFuZCBjb21lIGFjcm9zcyBzb21lIGlzc3VlczoNCiANCjEuIEl0IHdv dWxkIGJlIGNvbnZlbmllbnQgdG8gYmUgYWJsZSB0byBzZXQgZGVmYXVsdHMgZm9yIGRlcGVuZGVu Y3kgY2hlY2sgYW5kIGF1dG93aXJlIGFuZCB0aGUgWE1MIGZpbGUgbGV2ZWwuIFRodXMsIEkndmUg aW50cm9kdWNlZCAiZGVmYXVsdC1kZXBlbmRlbmN5LWNoZWNrIiBhbmQgImRlZmF1bHQtYXV0b3dp cmUiIGF0dHJpYnV0ZXMgZm9yIHRoZSByb290IGVsZW1lbnQsIGkuZS4gdGhlICJiZWFuIiB0YWcu IFRoZXkgY2FuIGJlIG92ZXJyaWRkZW4gYXQgdGhlIGJlYW4gbGV2ZWwsIG9mIGNvdXJzZS4NCiAN CjIuIFRoZSBjdXJyZW50IGF1dG93aXJlIGltcGxlbWVudGF0aW9uIGp1c3QgY2hlY2tzIGRlZmlu ZWQgcHJvcGVydHkgdmFsdWVzLiBBcyBhIGNvbnNlcXVlbmNlLCBpdCBjb21wbGFpbnMgYWJvdXQg dW5zYXRpc2ZpZWQgImJlYW5GYWN0b3J5IiBhbmQgImFwcGxpY2F0aW9uQ29udGV4dCIgZGVwZW5k ZW5jaWVzIGZyb20gQmVhbkZhY3RvcnlBd2FyZSBhbmQgQXBwbGljYXRpb25Db250ZXh0QXdhcmUg YmVhbnMgLS0gdGhvc2UgZ2V0IHNldCBieSB0aGUgZmFjdG9yeSwgbm90IHZpYSBwcm9wZXJ0eSB2 YWx1ZXMuIEkndmUgaW50cm9kdWNlZCBhIHNldHRpbmcgZm9yIGRlcGVuZGVuY3kgdHlwZXMgdG8g aWdub3JlIGZvciBhdXRvd2lyaW5nLCBieSBkZWZhdWx0IEJlYW5GYWN0b3J5IGFuZCBBcHBsaWNh dGlvbkNvbnRleHQgKHNwZWNpZmllZCBieSBBYnN0cmFjdEJlYW5GYWN0b3J5IGFuZCBBYnN0cmFj dEFwcGxpY2F0aW9uQ29udGV4dCwgcmVzcGVjdGl2ZWx5KS4NCiANCjMuIFdpdGggdGhlIHR3byBh Ym92ZSwgYSBkZWZhdWx0IGRlcGVuZGVuY3kgY2hlY2sgY2FuIGJlIGFwcGxpZWQgdG8gYSB0eXBp Y2FsIHdlYiBhcHBsaWNhdGlvbiBjb250ZXh0LiBVbmZvcnR1bmF0ZWx5LCBhIGxvdCBvZiBvdXIg ZnJhbWV3b3JrIGJlYW5zIGhhdmUgbnVtZXJvdXMgb3B0aW9uYWwgcHJvcGVydGllcyBvciBvdGhl ciBzZXR0ZXJzIHRoYXQgdGhlICJvYmplY3RzIiBkZXBlbmRlbmN5IGNoZWNrIGNvbXBsYWlucyBh Ym91dC4gU2V0dGluZyB0aGUgZGVwZW5kZW5jeSBjaGVjayB0byAibm9uZSIgZm9yIHRob3NlIGJl YW5zIGhlbHBzIG9mIGNvdXJzZSwgYnV0IGl0J3Mgbm9ybWFsbHkgbW9yZSBhZHZpc2FibGUgdG8g cmVzb3J0IHRvIHBlci1iZWFuIGRlcGVuZGVuY3kgY2hlY2sgc2V0dGluZ3MuDQogDQo0LiBBdXRv d2lyaW5nIGlzIGEgYml0IHN0cmljdCBjdXJyZW50bHksIGFzIGl0IGNvbXBsYWlucyBmb3IgYW55 IHByb3BlcnR5IHRoYXQgY2FuJ3QgZ2V0IHJlc29sdmVkIHRvIGEgc2luZ2xlIGJlYW4gaW4gdGhl IGNvbnRleHQuIEZvciBhIGRlZmF1bHQgYXV0b3dpcmUgc2V0dGluZ3MgZm9yIGEgd2hvbGUgWE1M IGZpbGUsIGl0IHdvdWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUgdG8gdHJ5IHRvIHJlc29sdmUgYWxs IG9iamVjdCBkZXBlbmRlbmNpZXMgaWYgdGhlcmUgaXMgYSBiZWFuIG9mIHRoYXQgdHlwZSBpbiB0 aGUgY29udGV4dCwgY29tcGxhaW4gaWYgdGhlcmUgaXMgbW9yZSB0aGFuIDEgYmVhbiBvZiBhIHJl cXVpcmVkIHR5cGUgLS0gYnV0IHNpbXBseSBwcm9jZWVkIGlmIHRoZXJlIGlzIG5vbmUsIGxlYXZp bmcgdGhlIGRlcGVuZGVuY3kgdW5zYXRpc2ZpZWQuIFRoaXMgd29ya3MgbmljZWx5IGZvciBiZWFu cyBsaWtlIExvY2FsU2Vzc2lvbkZhY3RvcnlCZWFuIHRoYXQgaGF2ZSBvcHRpb25hbCBvYmplY3Qg ZGVwZW5kZW5jaWVzIGxpa2UgImVudGl0eUludGVyY2VwdG9yIi4gSWYgb25lIG5lZWRzIHN0cmlj dCBhdXRvd2lyaW5nLCBvbmUgY2FuIGFsd2F5cyBhZGQgYW4gIm9iamVjdHMiIGRlcGVuZGVuY3kg Y2hlY2sgaW4gYWRkaXRpb24gdG8gdGhlIGF1dG93aXJlIHNldHRpbmcuIE5vdGUgdGhhdCBpbiBj YXNlIG9mIG11bHRpcGxlIGNvbnN0cnVjdG9ycywgUGljbyB3aWxsIGFsc28gY2hvb3NlIG9uZSB0 aGF0IGl0IGlzIGFibGUgdG8gcmVzb2x2ZTsgZGVwZW5kaW5nIG9uIHRoZSBhY3R1YWxseSBkZWZp bmVkIGNvbXBvbmVudHMsIGRpZmZlcmVudCBjb25zdHJ1Y3RvcnMgd2l0aCBvciB3aXRob3V0IGNl cnRhaW4gZGVwZW5kZW5jaWVzIG1pZ2h0IGdldCB1c2VkLg0KIA0KNS4gQXV0b3dpcmluZyBkb2Vz IG5vdCBkZXRlY3Qgb2JqZWN0cyBjcmVhdGVkIGJ5IEZhY3RvcnlCZWFucyB5ZXQsIGxpa2UgYSBT ZXNzaW9uRmFjdG9yeSB0aGF0IGNvbWVzIG91dCBvZiBhIExvY2FsU2Vzc2lvbkZhY3RvcnlCZWFu LCBvciBBT1AgcHJveGllcy4gVGhlIHJvb3Qgb2YgdGhlIHByb2JsZW0gaXMgTGlzdGFibGVCZWFu RmFjdG9yeSdzIGdldEJlYW5EZWZpbml0aW9uTmFtZXMoQ2xhc3MgdHlwZSkgbWV0aG9kIHRoYXQg anVzdCBjaGVja3MgdGhlIGJlYW4gZGVmaW5pdGlvbnMgYW5kIHRodXMgY29uc2lkZXIgRmFjdG9y eUJlYW5zIHRvIGJlIG9mIHR5cGUsIHdlbGwsIEZhY3RvcnlCZWFuLiBBdCB0aGUgZGVmaW5pdGlv biBsZXZlbCwgaXQncyBpbXBvc3NpYmxlIHRvIGZpbmQgb3V0IHdoYXQgYSBGYWN0b3J5QmVhbiBt aWdodCBjcmVhdGUuIEZvciB1c2FnZXMgbGlrZSBhdXRvd2lyaW5nLCBhIGdldEJlYW5zT2ZUeXBl KENsYXNzIHR5cGUpIG1ldGhvZCBpcyBuZWNlc3NhcnkgdGhhdCByZXR1cm5zIHRoZSBjcmVhdGVk IGJlYW5zIGluIGNhc2Ugb2YgRmFjdG9yeUJlYW4gZGVmaW5pdGlvbnMuIEJlYW5GYWN0b3J5VXRp bHMuYmVhbnNPZlR5cGUgaXMgbm8gaGVscCBoZXJlLCBhcyBpdCB3b3JrcyB2aWEgZ2V0QmVhbkRl ZmluaXRpb25OYW1lcy4gRm9yIGVmZmljaWVuY3kgaW4gY2FzZSBvZiBwcm90b3R5cGUgYmVhbnMs IHRoZSBhdXRvd2lyZS1ieS10eXBlIGltcGxlbWVudGF0aW9uIHNob3VsZCBwcm9iYWJseSBiZSBt b3ZlZCB0byB0aGUgYWN0dWFsIGJlYW4gY3JlYXRpb24sIHRvIGF2b2lkIGRvdWJsZSBjcmVhdGlv biBvZiBwcm90b3R5cGUgYmVhbnMuDQogDQpTbyBhcyBhIHN1bW1hcnksIEkgcHJvcG9zZSB0aGUg Zm9sbG93aW5nIGNoYW5nZXM6DQoxLiAiZGVmYXVsdC1kZXBlbmRlbmN5LWNoZWNrIiBhbmQgImRl ZmF1bHQtYXV0b3dpcmUiIChhbHJlYWR5IGRvbmUgYnV0IG5vdCBjb21taXR0ZWQgeWV0KQ0KMi4g aWdub3JlIGNlcnRhaW4gZGVwZW5kZW5jeSB0eXBlcyBmb3IgYXV0b3dpcmluZywgQmVhbkZhY3Rv cnkgYW5kIEFwcGxpY2F0aW9uQ29udGV4dCBpbiBwYXJ0aWN1bGFyIChkb25lIHRvbykNCjMuIGV4 cGxpY2l0bHkgZG9jdW1lbnQgb3B0aW9uYWwgb2JqZWN0IGRlcGVuZGVuY2llcyBpbiBmcmFtZXdv cmsgYmVhbnMgdG8gZWFzZSBkZXBlbmRlbmN5IGNoZWNrIHNldHRpbmdzDQo0LiByZWRlZmluZSBh dXRvd2lyaW5nIHRvIG5vdCBjb21wbGFpbiBpZiBubyBtYXRjaGluZyBiZWFuIGZvdW5kIChwcm9t b3RlIGFkZGl0aW9uYWwgIm9iamVjdHMiIGRlcGVuZGVuY3kgY2hlY2sgYXMgYW4gb3B0aW9uKQ0K NS4gaW50cm9kdWNlIGEgTGlzdGFibGVCZWFuRmFjdG9yeS5nZXRCZWFuc09mVHlwZShDbGFzcyB0 eXBlKSBtZXRob2QgYW5kIGJ1aWxkIGF1dG93aXJlLWJ5LXR5cGUgb24gaXQNCiANCkkgZ3Vlc3Mg dGhhdCAxIGFuZCAyIGFyZSBvYnZpb3VzIHRoaW5ncyB0byBkbywgYW5kIDMgaXMgYSBoZWxwIGZv ciBhdXRvd2lyZSB1c2Vycy4gNCBhbmQgNSBub3RhYmx5IGNoYW5nZSBjdXJyZW50IHNlbWFudGlj cywgYnV0IEkgY29uc2lkZXIgdGhlbSBpbXBvcnRhbnQgaW1wcm92ZW1lbnRzIC0tIDQgZm9yIG1v cmUgZmxleGlibGUgYXV0b3dpcmUgb3B0aW9ucywgNSBhcyBGYWN0b3J5QmVhbnMgYW5kIGluIHBh cnRpY3VsYXIgQU9QIHByb3hpZXMgYXJlIGNvbW1vbiB0aGluZ3MgdG8gd2lyZSB1cC4gRG9lcyBh bnlvbmUgb2JqZWN0IHRvIGFueSBvZiB0aG9zZSBjaGFuZ2VzIG9yIGhhdmUgYSBiZXR0ZXIgaWRl YSB0byBzb2x2ZSB0aGUgdW5kZXJseWluZyBpc3N1ZXM/IElmIG5vdCwgSSdsbCBhcHBseSBhbmQg Y29tbWl0IHRoZSBwcm9wb3NlZCBjaGFuZ2VzIGJ5IEZyaWRheS4NCiANCkp1ZXJnZW4NCg== |
|
From: Kopylenko, D. <dko...@ac...> - 2003-10-29 20:01:47
|
I did send them an email, asking if it was possible to host an instance for Spring Framework on one of their servers. Regards, Dmitriy. -----Original Message----- From: Alef Arendsen (JTeam) [mailto:al...@jt...] Sent: Wednesday, October 29, 2003 2:39 PM To: spr...@li... Subject: RE: [Springframework-developer] JIRA Hmmm, hibernate is running their JIRA instance at Atlassian itself, they probably wouldn't mind running a Spring one as well, would they? We might as well just conatct them... Any volunteers? Alef P.s. that doesn't mean I don't wanna give up the bandwidth, it's just that it's probably no worry for htem :) > -----Oorspronkelijk bericht----- > Van: spr...@li... > [mailto:spr...@li...] > Namens Kopylenko, Dmitry > Verzonden: Wednesday, October 29, 2003 7:30 PM > Aan: 'spr...@li...' > Onderwerp: RE: [Springframework-developer] JIRA > > > Sounds good. > > -----Original Message----- > From: Alef Arendsen (JTeam) [mailto:al...@jt...] > Sent: Wednesday, October 29, 2003 12:37 PM > To: spr...@li... > Subject: RE: [Springframework-developer] JIRA > > > Codehaus sounds good, however, if it isn't possible (they're > hosting picocontainer, maybe they don't like us there :), I > don't care about running it here... There a 512kb uplink (and > way too much down) so that should suffice... As long as it > fits in our current live environment > (JBoss/MySQL) and it does not require huge memory footprints... > > Alef > > > -----Oorspronkelijk bericht----- > > Van: spr...@li... > > [mailto:spr...@li...] > > Namens Colin Sampaleanu > > Verzonden: Wednesday, October 29, 2003 6:04 PM > > Aan: spr...@li... > > Onderwerp: Re: [Springframework-developer] JIRA > > > > > > +1 on the idea. There is a question as to where it would > be hosted > > though. Maybe we could convince the CodeHaus guys to use theirs: > > http://jira.codehaus.org/secure/Dashboard.jspa > > > > > > Kopylenko, Dmitry wrote: > > > > > Hello everyone, > > > > > > Would it be a good idea to use JIRA for Spring project tracking? I > > > just saw on their site that they have a free license for > > open source > > > projects. > > > > > > What do you think? > > > > > > Regards, > > > Dmitriy. > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. Does > > SourceForge.net help you be more productive? Does it > > help you create better code? SHARE THE LOVE, and help us help > > YOU! Click Here: http://sourceforge.net/donate/ > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > > https://lists.sourceforge.net/lists/listinfo/s> pringframework-developer > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ 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.
