springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Package renaming

[Rod J. <rod...@in...>]

I think the marketing value is crucial. We know we've got a good framework:
we need to get more people using it, and avoid irritating early adopters.

Rod

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <al...@jt...>; <spr...@li...>
Sent: Tuesday, August 05, 2003 2:28 PM
Subject: Re: [Springframework-developer] Package renaming


> Alef,
>
> Keep in mind that this is by no means a typical package renaming, where
> some packages change and some don't, leading to a lot of potential
> confusion.
>
> After all, the only thing that is changing is
> com.interface21
> to
> org.springframework
>
> You can do a dead simple search and replace across the whole codebase
> and config files, and be assured that you have caught every instance.
> All relative references will remain the same, etc. On top of that,
> Spring has excellent junit test coverage.
>
> Regards,
> Colin
>
>
> Alef Arendsen (JTeam) wrote:
>
> > About the vote about the package renaming. Personally I would vote
> > against it on such a short notice…
> >
> > I've done nthis quite often and it always gives a lot of problems and
> > a week of instability of the codebase (configuration files, tests -
> > are there a a lot of them, etcetera). If you would like to have the
> > 0.9.1 release out in, say, 2 or 3 days, I would advise NOT to do it.
> > If not (release out in a week, I wouldn't have any objections).
> >
> > So juergen, rod, whoever, it’s up to your judgement how to interpret
> > the vote ;-)…
> >
> > But hey, maybe it's already 10 to 1 so maybe my vote doesn't even
> > metter anymore…
> >
> > Alef Arendsen
> >
> > ==
> > 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: _www.jteam.nl_ <file://www.jteam.nl>
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Spring, EJBs and XDoclet

[<tri...@tr...>]

All,

I am extending the com.interface21.ejb.support.AbstractStatelessSessionBean
class for my SLSB.  I'm also trying to use XDoclet, but the home/remote
interfaces that are generated insists on extending some phantom Spring
interfaces and I can not figure out how to get XDoclet to extend the regular
javax.ejb.EJBHome and javax.ejb.EJBObject.

This is what I have:

public class MyServiceBean 
   extends com.interface21.ejb.support.AbstractStatelessSessionBean 


This is what I get:

public interface MyServiceHome
   extends com.interface21.ejb.support.AbstractStatelessSessionHome

public interface MyService
   extends com.interface21.ejb.support.AbstractStatelessSession


Anybody using XDOclet together with Spring?  Any ideas?

Thomas

[Springframework-developer] re: TilesView & Resolver

[Rob B. <rob...@ve...>]

Hello all,

> However I saw someone commenting about the TilesView stuff I posted a
> while ago. I recall you asking about whether or not it would be
> integrated before 1.0. Well, that's the plan indeed. You commented that
> the ViewResolver could better be a view configurer! Good idea!

Integration of Tiles would be very nice.
 
> First of all there's the dependency on Struts. Of course there won't be
> any runtime dependency if you don't use it, but I still strongly object
> to linking in the Struts11.jar, simply because it would send the wrong
> message. 

While not ideal, this is not so horrible.  Plus the rest of the spring framework can be used with Struts if someone so chooses.

> Why in heaven's name link in a competitor-MVC-framework!

In my opinion this is not the best attitude...  Don't think of them as a competitor, think of them as a co-petitor (cooperative-competitor).  A little FRIENDLY competition between different frameworks is a good thing, but if either framework can be improved by some cooperation along the way then why not.  Both projects are open source so it's not like your competing for $$ like corporations are.  

> I just doesn't feel right. However, since Tiles is completely
> integrated into Struts, it will be hard to split the tiles.jar
> from it or something.

Tiles used to be separate, it was only more recently that it was integrated into Struts.  Struts has a fairly decent track record of splitting out functionality that is re-usable by other projects (Digester for example).  If you asked nicely on the Struts list, they would probably consider moving the core of Tiles out of Struts and into a separate jakarta commons package for better re-use (especially if you helped a little).  In that way, both frameworks can make use of the Tiles code without having to "link" with each other.  This is beneficial for all involved because it will make tiles more modular, and thus potentially re-usable for other frameworks too.  Also it will increase the # of developers who maintain Tiles, because now both the struts developers & the spring developers will make use of it.

> We would have to maintain ourselves or something like that, and
> that's a mess too! Well, maybe some plugins feature or part of the
> website would be nice, maybe some people can think about this.

Basically you would be code-forking the tiles portion of struts.  This is unfortunate as forked code will always eventually diverge, and there will be different features in each of the code bases.  The additional work to maintain a separate fork would not be needed if you and the struts group code make it a commons project as I suggest above, and the single tiles code base would hopefully be more robust and featureful since it did not fork.

Hope this helps out
Later
Rob

Re: [Springframework-developer] Package renaming

[Colin S. <col...@ex...>]

Alef,

Keep in mind that this is by no means a typical package renaming, where 
some packages change and some don't, leading to a lot of potential 
confusion.

After all, the only thing that is changing is
com.interface21
to
org.springframework

You can do a dead simple search and replace across the whole codebase 
and config files, and be assured that you have caught every instance. 
All relative references will remain the same, etc. On top of that, 
Spring has excellent junit test coverage.

Regards,
Colin


Alef Arendsen (JTeam) wrote:

> About the vote about the package renaming. Personally I would vote 
> against it on such a short notice…
>
> I've done nthis quite often and it always gives a lot of problems and 
> a week of instability of the codebase (configuration files, tests - 
> are there a a lot of them, etcetera). If you would like to have the 
> 0.9.1 release out in, say, 2 or 3 days, I would advise NOT to do it. 
> If not (release out in a week, I wouldn't have any objections).
>
> So juergen, rod, whoever, it’s up to your judgement how to interpret 
> the vote ;-)…
>
> But hey, maybe it's already 10 to 1 so maybe my vote doesn't even 
> metter anymore…
>
> Alef Arendsen
>
> ==
> 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: _www.jteam.nl_ <file://www.jteam.nl>
>

[Springframework-developer] TilesView & Resolver

[Alef A. \(JTeam\) <al...@jt...>]

Hi all,

Like I said in one of my previous mails, I haven't been able to read
much of the replies lately, since I had major connection problems.

However I saw someone commenting about the TilesView stuff I posted a
while ago. I recall you asking about whether or not it would be
integrated before 1.0. Well, that's the plan indeed. You commented that
the ViewResolver could better be a view configurer! Good idea!

There are still two points I'd like to address while finally putting it
in:

First of all there's the dependency on Struts. Of course there won't be
any runtime dependency if you don't use it, but I still strongly object
to linking in the Struts11.jar, simply because it would send the wrong
message. Why in heaven's name link in a competitor-MVC-framework! I just
doesn't feel right. However, since Tiles is completely integrated into
Struts, it will be hard to split the tiles.jar from it or something. We
would have to maintain ourselves or something like that, and that's a
mess too! Well, maybe some plugins feature or part of the website would
be nice, maybe some people can think about this.

Then there's the testing of the TilesView: it's working quite ok now,
however there's two things up for improvement. When a definition isn't
found, it says 404: [definition name]. This error message should be
improved a little bit. Then there's the issue where pages that are
included by Tiles definitions using the <tiles:insert>-tag. If those
aren't found, you won't get an error-message at all (and this can get
pretty annoying when just mistyping a directory name or something). I
don't know how the normal tiles stuff does this in Struts, but this is
up for improvement like I said.

If anyone (the one commenting about putting it in before te 1.0
release?) has suggestions for improvements in the next 14 days (I'm on a
holiday), just maintain the code in your own codebase and make them. Of
course it would be nice if you would post them back on the list!

Thanx for now,

Alef Arendsen


==
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: www.jteam.nl

[Springframework-developer] Security model comments

[Alef A. \(JTeam\) <al...@jt...>]

Hi all,

Due to connection problems with my laptop I haven't been able to read
any more comments about this. I read Trevor's comment and I feel he's
got a point there! Trevor, you're absolutely right about the fact that
security models can be implemented in many ways and this is just one of
them.

I don't agree about the intrusiveness, it will still be somewhat like
the validator, thus basically not intruding at all, but anyway, the
things you mentioned about overriding the ServletRequestDataBinder is a
perfect option, but I haven't been able to figure out how to exactly do
that (that was one of the main points when trying to integrate it).

Well, Juergen, I don't know if there's any option to override that
thing, if so, could you please give me some indications?

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: www.jteam.nl

[Springframework-developer] Package renaming

[Alef A. \(JTeam\) <al...@jt...>]

About the vote about the package renaming. Personally I would vote
against it on such a short notice.

I've done nthis quite often and it always gives a lot of problems and a
week of instability of the codebase (configuration files, tests - are
there a a lot of them, etcetera). If you would like to have the 0.9.1
release out in, say, 2 or 3 days, I would advise NOT to do it. If not
(release out in a week, I wouldn't have any objections).

So juergen, rod, whoever, it's up to your judgement how to interpret the
vote ;-).

But hey, maybe it's already 10 to 1 so maybe my vote doesn't even metter
anymore.

Alef Arendsen

==
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: www.jteam.nl

Re: [Springframework-developer] Step-by-step tutorial error

[<tri...@tr...>]

It turns out to be an outdated i21.tld that was part of
sample/skeletons/webapp-typical.  The class names of the tag implementations
have changed in the framework, but this is not reflected in this version of the
tld.  It should be replaced with the latest one from
workspace/main/src/com/interface21/web/servlet/tags before next release.

Thomas

> Lars,
> 
> Looks like something is missing for the i21:bind tag.  If you send me your
> jsp,
> then I can compare it to the one I am running with.
> 
> Thomas
> 
> 
> > Just tested the step-by-step tutorial from scratch today.
> > 
> > When calling the priceincrease.jsp from the main menu the error shown below
> 
> > is raised.
> > 
> > Any suggestions ?
> > 
> > Thanks.
> > Lars
> > 
> > org.apache.jasper.JasperException: /WEB-INF/jsp/priceincrease.jsp(11,6)
> > Unable to load class bind
> > 	at
> >
>
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:94)
> > 	at
> >
> org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:428)
> > 	at
> >
> org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:219)
> > 	at org.apache.jasper.compiler.Parser.parseCustomTag(Parser.java:712)
> > 	at org.apache.jasper.compiler.Parser.parseElements(Parser.java:804)
> > 	at org.apache.jasper.compiler.Parser.parse(Parser.java:122)
> > 	at
> >
> org.apache.jasper.compiler.ParserController.parse(ParserController.java:199)
> > 	at
> >
> org.apache.jasper.compiler.ParserController.parse(ParserController.java:153)
> > 	at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:227)
> > 	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:369)
> > 	at
> >
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:473)
> > 	at
> >
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:190)
> > 	at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
> > 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
> > 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> > 	at
> >
>
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
> > 	at
> >
>
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:432)
> > 	at
> >
>
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:356)
> > 	at
> >
>
com.interface21.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:86)
> > 	at
> >
> com.interface21.web.servlet.view.AbstractView.render(AbstractView.java:194)
> > 	at
> >
> com.interface21.web.servlet.DispatcherServlet.render(DispatcherServlet.java:505)
> > 	at
> >
>
com.interface21.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:387)
> > 	at
> >
>
com.interface21.web.servlet.FrameworkServlet.serviceWrapper(FrameworkServlet.java:228)
> > 	at
> >
> com.interface21.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:207)
> > 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
> > 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> > 	at
> >
>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
> > 	at
> >
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
> > 	at
> >
>
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> > 	at
> >
>
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
> > 	at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> > 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> > 	at
> >
>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> > 	at
> >
>
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
> > 	at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> > 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> > 	at
> > org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
> > 	at
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
> > 	at
> >
>
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
> > 	at
> >
>
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
> > 	at
> >
>
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
> > 	at
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
> > 	at
> >
>
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
> > 	at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> > 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> > 	at
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
> > 	at
> >
>
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
> > 	at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> > 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> > 	at
> org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
> > 	at
> > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
> > 	at
> >
>
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
> > 	at
> > org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
> > 	at
> >
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
> > 	at java.lang.Thread.run(Thread.java:534)
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> >
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Current release plan - why delay package renaming?

[<jue...@we...>]

VHJldm9yLCBSb2QsDQogDQpFY2xpcHNlLXN0eWxlIG1pbGVzdG9uZXMgc291bmQgZ29vZCB0byBt
ZSwgdGhleSBkaWRuJ3QgY29tZSB0byBteSBtaW5kIGVhcmxpZXIuIDEuMCBNMSB3b3VsZCBiZSBm
aW5lIGZvciB0aGUgdXBjb21pbmcgcmVsZWFzZSwgMS4wIE0yIGZvciBiZWdpbm5pbmcgb2YgU2Vw
dGVtYmVyLCAxLjAgUkMxIGZvciBPY3RvYmVyLiBPbmx5IHRoZSBsYXR0ZXIgd2lsbCBpbXBseSBh
IGZlYXR1cmUgZnJlZXplLg0KIA0KVGhpcyBzdGlsbCBsZWF2ZXMgdGhlIGdyYW51bGFyaXR5IG9m
IENWUyBtb2R1bGVzLiBPbmUgbW9kdWxlIGZvciAxLngsIG9yIGEgc2VwYXJhdGUgb25lIGZvciAx
LjAsIDEuMSwgZXRjLiBJJ20gaGVhdmlseSBpbmNsaW5lZCB0b3dhcmRzIHRoZSBmb3JtZXIsIGNy
ZWF0aW5nIGJyYW5jaGVzIHdpdGhpbiB0aGUgbW9kdWxlIGZvciBlYWNoIHBvaW50IHJlbGVhc2Uu
IElmIHRoZXJlIGFyZW4ndCBhbnkgcGFja2FnZSBuYW1lIGNoYW5nZXMsIHdlIG1pZ2h0IGV2ZW4g
YnJhbmNoIDIuMCBpbiB0aGVyZS4gV2hhdCBkbyB5b3UgdGhpbms/DQogDQpSZWdhcmRpbmcgdGhl
IG1vZHVsZSBuYW1lLi4uICJzcHJpbmcxMCIgaXMgdG9vIGZpbmUgZ3JhbnVsYXIgdGhlbiwgZXZl
biAic3ByaW5nMSIuIFNvICJzcHJpbmciIGFsb25lIG1pZ2h0IGJlIGFwcHJvcHJpYXRlIGZvciB0
aGUgdGltZSBiZWluZywgYnV0IHdoYXQgdG8gZG8gd2l0aCAibWFpbiI/IE1heWJlIHRlbGwgU291
cmNlRm9yZ2UgdG8gcmVuYW1lIHRoZSAqbW9kdWxlKiB0byAic3ByaW5nLW9sZCI/IDstKSBJbiBh
bnkgY2FzZSwgd2Ugd2lsbCBoYXZlIHRoZSBwcm9wZXIgb2xkIGNvbnRlbnRzIHRoZXJlLCBiZWlu
ZyBhYmxlIHRvIGdyYWIgYSAwLjkgY29tLmludGVyZmFjZTIxIHNuYXBzaG90IHdpdGhvdXQgaGFz
c2xlLg0KIA0KUmVnYXJkcywNCkp1ZXJnZW4NCiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUg
TmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBSb2QgSm9obnNvbiBbbWFpbHRvOnJvZC5qb2huc29uQGlu
dGVyZmFjZTIxLmNvbV0gDQoJR2VzZW5kZXQ6IFNvIDAzLjA4LjIwMDMgMDk6MDkgDQoJQW46IFRy
ZXZvciBDb29rOyBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5l
dCANCglDYzogDQoJQmV0cmVmZjogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBDdXJy
ZW50IHJlbGVhc2UgcGxhbiAtIHdoeSBkZWxheSBwYWNrYWdlIHJlbmFtaW5nPw0KCQ0KCQ0KDQoJ
SSd2ZSBiZWVuIHRoaW5raW5nIGl0IG92ZXIgbGFzdCBuaWdodCBhbmQgSSBjYW4gc2VlIG1ham9y
IG1hcmtldGluZw0KCWFkdmFudGFnZXMgaW4gYSAxLjAgbmFtZS4gKEZvciBUU1MgYXJ0aWNsZSBl
dGMuKQ0KCQ0KCVNvIEknbSBpbmNsaW5lZCB0byBhZ3JlZSB3aXRoIFRyZXZvcnMgc3VnZ2VzdGlv
biBhcyB0byBFY2xpcHNlLXN0eXBlDQoJIm1pbGVzdG9uZXMiLg0KCQ0KCTEuME0xIHNvdW5kcyBn
b29kLg0KCQ0KCUkgYWdyZWUgdGhhdCAiYmV0YSIgaXMgYWxtb3N0IG1lYW5pbmdsZXNzLg0KCQ0K
CVdlIHNob3VsZCBkZWNpZGUgb24gaG93IG1hbnkgbWlsZXN0b25lcyBiZWZvcmUgUkMxLiBJIHRo
aW5rIG9ubHkgMi4NCgkNCglSZWdhcmRzLA0KCVJvZA0KCQ0KCS0tLS0tIE9yaWdpbmFsIE1lc3Nh
Z2UgLS0tLS0NCglGcm9tOiAiVHJldm9yIENvb2siIDxwcmlzZTAzQHNlbnRleC5uZXQ+DQoJVG86
IDxzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldD4NCglTZW50
OiBTYXR1cmRheSwgQXVndXN0IDAyLCAyMDAzIDU6MDUgUE0NCglTdWJqZWN0OiBSRTogW1Nwcmlu
Z2ZyYW1ld29yay1kZXZlbG9wZXJdIEN1cnJlbnQgcmVsZWFzZSBwbGFuIC0gd2h5IGRlbGF5DQoJ
cGFja2FnZSByZW5hbWluZz8NCgkNCgkNCglBcyBmYXIgYXMgIm1haW4iIHZzICJzcHJpbmciLCBt
eSBtYWluIGNvbmNlcm4gaXMgY29uc2lzdGVuY3kuICBJJ2QgY2hhbmdlIG15DQoJdm90ZSB0byAi
c3ByaW5nIyIgSUYgd2UgY2FuIHJlbmFtZS9kZWxldGUgdGhlIGN1cnJlbnQgbWFpbiwgYnV0IGFz
IEp1ZXJnZW4NCglzYXlzLCBoYXZpbmcgbXVsdGlwbGUgbmFtZXMgaXMgcmVhbGx5IGNvbmZ1c2lu
ZyAoSSd2ZSBiZWVuIGJpdHRlbiBieSB0aGlzDQoJbXlzZWxmKS4NCgkNCglOb3cgdGhhdCBJJ3Zl
IGNvbmNlZGVkIHZpY3RvcnkgZm9yIHRoZSBtb2R1bGUgbmFtZSB0byBteSBvcHBvbmVudHMsIEkg
d291bGQNCglsaWtlIHRvIGNvbnRpbnVlIGNhbXBhaWduaW5nIGZvciAxLjAteCAuIDopDQoJDQoJ
Rm9yIHRoZSAiMS4wIGJldGEiIHZzICIwLjkuMSIgdGhlIG1ham9yIHN0aWNraW5nIHBvaW50IGFw
cGVhcnMgdG8gYmUNCgkiZmVhdHVyZSBmcmVlemUiLiAgTWF5YmUgYmV0YSBpcyB0aGUgd3Jvbmcg
dGVybSwgYW5kIHdlIHNob3VsZCBjb25zaWRlcg0KCSJzdGFibGUgYnVpbGQiLiAgVG8gbWUgdGhp
cyBtYWtlcyBtb3JlIHNlbnNlIChldmVuIG1vcmUgc2Vuc2UgdGhhbiAiYmV0YSINCglub3cgc2lu
Y2UgdGhhdCB0ZXJtIHNlZW1zIHRvIGJlIHZhc3RseSBhYnVzZWQgSU1PKS4NCgkNCglJIHRlbmQg
dG8gZm9sbG93IHRoZSByZWxlYXNlIHN0eWxlIGZvbGxvd2VkIGJ5IGVjbGlwc2UgKHNlZQ0KCWh0
dHA6Ly93d3cuZWNsaXBzZS5vcmcvZG93bmxvYWRzL2luZGV4LnBocCkuICBCYXNpY2FsbHkgdGhl
IHZlcnNpb24gaXMgdGhlDQoJY3VycmVudCB2ZXJzaW9uIGJlaW5nIHdvcmtlZCB0b3dhcmRzLCBh
bmQgdGhlIG51bWJlciBpcyBpbmRpY2l0aXZlIG9mIHRoZQ0KCWN1cnJlbnQgc3RhdHVzLiAgVGhl
eSBiYXNpY2FsbHkgcHJvZ3Jlc3MgZnJvbSAic3RhYmxlIGJ1aWxkcyIgdG8gInJlbGVhc2UNCglj
YW50aWRhdGVzIiB0byAicmVsZWFzZSIuICBUaGVpciBuYW1pbmcgZm9yIHRoZSBzdGFibGUgYnVp
bGRzIGlzIHVzdWFsbHkNCgkiMy4wTTIiIG9yIDIuME01IiB3aXRoIHRoZSBwcmVmaXggKDMuMCAv
IDIuMCkgYXMgdGhlIHZlcnNpb24gd29ya2VkIHRvd2FyZHMsDQoJTSBzaWduaWZ5aW5nIGl0cyBu
b3QgYSByZWxlYXNlLCBhbmQgdGhlIHN1ZmZpeCAoMiAvIDUpIGluZGljYXRpbmcgd2hpY2gNCglz
dGFibGUgYnVpbGQuICBGZWF0dXJlcyBhbmQgYnVnLWZpeGVzIGFyZSBjb250aW51YWxseSBhZGRl
ZCBkdXJpbmcgc3RhYmxlDQoJYnVpbGRzLCBmZWF0dXJlIGZyZWV6ZSBpc24ndCBpbXBsZW1lbnRl
ZCB1bnRpbCB0aGUgZmlyc3QgUkMuICBUaGUNCglwcm9ncmVzc2lvbiBpcyBnZW5lcmFsbHk6DQoJ
DQoJMS4wTTENCgkxLjBNMg0KCTEuME0zDQoJMS4wUkMxDQoJMS4wUkMyDQoJMS4wUiAyLjBNMQ0K
CTEuMSAyLjBNMg0KCTEuMiAuLi4NCgkuLi4NCgkNCglBbm90aGVyIHBvaW50IGlzIGhvdyB3ZSB3
aWxsIGhhbmRsZSBmdXR1cmUgcmVsZWFzZXMuIEkga25vdyBJJ20gZ2V0dGluZyB3YXkNCglhaGVh
ZCBvZiB0aGUgcHJvamVjdCwgYnV0IG91ciBjdXJyZW50IG5hbWluZyBzdHJ1Y3R1cmUgd2lsbCBk
aWN0YXRlIHRoZQ0KCWZ1dHVyZSBuYW1pbmcgKG9yIHdlJ2xsIGhhdmUgbWFzcyBjb25mdXNpb24p
LiAgV2hlbiB3ZSBhcmUgd29ya2luZyBvbiBTcHJpbmcNCgkyLjAsIGhvdyB3aWxsIHdlIG5hbWUg
cmVsZWFzZXM/ICBJcyAxLjYgYSBidWcgZml4IHRvIDEuNSwgb3IgYSBwcmVyZWxlYXNlIG9mDQoJ
ZmVhdHVyZXMgZm9yIDIuMD8gIEkgdGhpbmsgdGhhdCBpZiB0aGUgdmVyc2lvbiBpcyBhbHdheXMg
dGhlICJyZWxlYXNlDQoJdmVyc2lvbiBiZWluZyB3b3JrZWQgdG93YXJkcyIgd2UnbGwgaGF2ZSBs
ZXNzIGNvbmZ1c2lvbi4gIEkgdGhpbmsgdGhpcw0KCWV4dGVuZHMgZXZlbiB0byB0aGUgMS4xIG5h
bWUgUm9kIHdhcyBtZW50aW9uaW5nIChmb3IgSk1TLCBldGMuKSBzaW5jZSB0aGF0DQoJYnJpbmdz
IHVwIHF1ZXN0aW9ucyBvbiB3aGV0aGVyIGl0IGlzIGEgMS4wIGJ1ZyBmaXggb3IgbmV3IGZlYXR1
cmVzLg0KCQ0KCUkgd291bGQgYXBwcmVjaWF0ZSBhbnkgZmVlZGJhY2sgb24gdGhlc2UgY29tbWVu
dHMuICBTcGVjaWZpY2FsbHksIGlmIHlvdQ0KCXByZWZlciB0byBzdGF5IHdpdGggdGhlICIwLjku
MSIgYW5kICIxLjEiIG5hbWluZyBzdHlsZSwgaG93IGRvZXMgYSBuZXdjb21lcg0KCWtub3cgd2hp
Y2ggaXMgdGhlIGxhdGVzdCByZWxlYXNlICh3aXRob3V0IHNjb3VyaW5nIHRoZSBtYWlsaW5nIGxp
c3RzKSwgd2hpY2gNCglpcyBidWctZml4ZWQgcmVsZWFzZSB2ZXJzaW9ucywgYW5kIHdoaWNoIGFy
ZSBkZXZlbG9wbWVudCByZWxlYXNlcz8gIEknbSBzdXJlDQoJdGhlcmUgYXJlIG90aGVyIHdheXMg
dGhhbiB3aGF0IEknbSBwcm9wb3NpbmcsIGl0IGp1c3QgYXBwZWFycyB0byBtYWtlIHRoZQ0KCW1v
c3Qgc2Vuc2Ugb2YgdGhlIG1ldGhvZHMgSSd2ZSBlbmNvdW50ZXJlZC4NCgkNCglUcmV2b3IgRC4g
Q29vaw0KCQ0KCQ0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJRnJvbTogc3ByaW5nZnJh
bWV3b3JrLWRldmVsb3Blci1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglbbWFpbHRvOnNw
cmluZ2ZyYW1ld29yay1kZXZlbG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0XU9uIEJl
aGFsZg0KCU9mIGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF0NCglTZW50OiBBdWd1c3QgMiwgMjAw
MyAxMToyMyBBTQ0KCVRvOiBSb2QgSm9obnNvbjsgVHJldm9yIENvb2s7DQoJc3ByaW5nZnJhbWV3
b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglTdWJqZWN0OiBSZTogW1Nwcmlu
Z2ZyYW1ld29yay1kZXZlbG9wZXJdIEN1cnJlbnQgcmVsZWFzZSBwbGFuIC0gd2h5DQoJZGVsYXkg
cGFja2FnZSByZW5hbWluZz8NCgkNCgkNCglTbyBpdCdzIGN1cnJlbnRseSAyOjEgaW4gdGVybXMg
b2YgIjEuMCBiZXRhIiB2cyAiMC45LjEiLiBMaWtlIFRyZXZvciwgSSBhbHNvDQoJdGhvdWdodCBv
ZiB0aGUgbWFya2V0aW5nIGVmZmVjdC4gT24gdGhlIG90aGVyIGhhbmQgdGhlcmUgYXJlIHJlYWxs
eSBzb21lDQoJZmVhdHVyZXMgbGVmdCB0byBhZGQgZm9yIDEuMCwgYW5kIEkgY2FuIHVuZGVyc3Rh
bmQgdGhlIGFyZ3VtZW50IHRoYXQgd2UNCglzaG91bGQgYXZvaWQgdGhlIGltcHJlc3Npb24gb2Yg
YSBmZWF0dXJlIGZyZWV6ZS4gUmVjb25zaWRlcmluZyB0aGlzLCBpdCdzDQoJcHJvYmFibHkgYmV0
dGVyIHRvIHN0YXkgd2l0aCAwLjkueCBmb3IgdGhlIHRpbWUgYmVpbmcuDQoJDQoJVGhlcmUgaXMg
YSBjb25zaXN0ZW5jeSBpc3N1ZSB3aXRoIHRoZSBuYW1lIG9mIHRoZSBuZXcgbW9kdWxlIGZvciB0
aGUNCglvcmcuc3ByaW5nZnJhbWV3b3JrIHZlcnNpb246IGJlIGl0ICJzcHJpbmcxIiBvciAic3By
aW5nMTAiIC0gYm90aCBzdWdnZXN0DQoJdGhhdCB0aGV5IGNvbnRhaW4gdGhlIDEuMCBzb3VyY2Vz
LiAgUmVsZWFzaW5nIGEgMC45LjEgYmFzZWQgb24gc3VjaCBhIG1vZHVsZQ0KCWNvdWxkIGxlYWQg
dG8gY29uZnVzaW9uLiBJIGRvbid0IGhhdmUgYSBwZXJmZWN0IGFsdGVybmF0aXZlIHRob3VnaDog
TWF5YmUNCgkic3ByaW5nIiAoYW5hbG9nb3VzIHRvICJoaWJlcm5hdGUiKSB3aXRob3V0IGV4cGxp
Y2l0IHZlcnNpb24gbnVtYmVyLCB3aXRoDQoJdGhlIG9wdGlvbiB0byB1c2UgInNwcmluZzIiIGZv
ciBhIDIuMCBzb3VyY2UgdHJlZS4gQWZ0ZXIgYWxsLCB0aGUgcm9vdCBvZg0KCXRoZSBwcm9ibGVt
IGlzIHByb2JhYmx5IHRoZSBuYW1lICJtYWluIiBmb3Igb3VyIGN1cnJlbnQgc291cmNlcy4gTm8g
bWF0dGVyDQoJaWYgd2UgY2hvb3NlICJzcHJpbmciLCAic3ByaW5nMSIsIG9yICJzcHJpbmcxMCIg
LSBoYXZpbmcgYSAibWFpbiIgYWxvbmdzaWRlDQoJY2FuIGNhdXNlIGNvbmZ1c2lvbi4NCgkNCglS
ZWdhcmRpbmcgdGhlIHZlcnNpb24gbnVtYmVyIGluIHRoZSBtb2R1bGUgbmFtZTogV2Ugc2hvdWxk
IHRyeSB0byBkZWNpZGUNCgl3aGVuIHRvIGNyZWF0ZSBhIG5ldyBtb2R1bGUgdXBmcm9udC4gSGli
ZXJuYXRlIGhhcyAiaGliZXJuYXRlIiBmb3IgMS54ICgxLjAsDQoJMS4xLCAxLjIpLCBhbmQgYSBu
ZXcgImhpYmVybmF0ZTIiIG1vZHVsZSBmb3IgMi54ICgyLjAgYW5kIHRoZSB1cGNvbWluZyAyLjEp
Lg0KCVNvIGlmIG91ciAxLjEgcmVsZWFzZSB3aWxsIGJhc2ljYWxseSBiZSBhIDEuMCBmb2xsb3ct
dXAgc25hcHNob3Qgd2l0aCBhDQoJbGFyZ2VyIG51bWJlciBvZiBuZXcgZmVhdHVyZXMgdGhhbiB0
aGUgbGFzdCAxLjAueCwgaXQgd291bGQgbWFrZSBzZW5zZSB0bw0KCWtlZXAgMS54IGluIHRoZSBz
YW1lIG1vZHVsZS4gQXMgdGhpcyBpcyB2ZXJ5IGxpa2VseSwgSSBjb25zaWRlciBpdCBzYWZlIHRv
DQoJYXNzdW1lIHRoYXQgd2Ugd2lsbCBjcmVhdGUgYSBuZXcgbW9kdWxlIGZvciAyLjAgYnV0IG5v
dCBlYXJsaWVyLiBUaGVyZWZvcmUsDQoJYSAic3ByaW5nIiBvciAic3ByaW5nMSIgbW9kdWxlIG5h
bWUgaXMgYXBwb3ByaWF0ZSAtIEkgc3VnZ2VzdCBhICJzcHJpbmciDQoJbW9kdWxlLCBhcyBhcmd1
bWVudGVkIGluIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGguDQoJDQoJSnVlcmdlbg0KCQ0KCQ0KCS0t
LS0tVXJzcHJuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQoJVm9uOiBSb2QgSm9obnNvbiBbbWFpbHRv
OnJvZC5qb2huc29uQGludGVyZmFjZTIxLmNvbV0NCglHZXNlbmRldDogU2EgMDIuMDguMjAwMyAx
MDowMA0KCUFuOiBqIHJnZW4gaGxsZXIgW3dlcmszQVRdOyBUcmV2b3IgQ29vazsNCglzcHJpbmdm
cmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCUNjOg0KCUJldHJlZmY6
IFJlOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gQ3VycmVudCByZWxlYXNlIHBsYW4gLSB3
aHkgZGVsYXkNCglwYWNrYWdlIHJlbmFtaW5nPw0KCQ0KCQ0KCQ0KCT4gV293LCB0aGVyZSBzZWVt
cyB0byBiZSBhbiBvdmVyd2hlbG1pbmcgY29uc2Vuc3VzIHRvIGNoYW5nZSB0aGUgcGFja2FnZQ0K
CW5hbWVzIG5vdy4gV2VsbCwgdGhlbiBsZXQgdGhlcmUgYmUgb3JnLnNwcmluZ2ZyYW1ld29yayA6
LSkgVGhlIHJlYXNvbmluZw0KCWJlaGluZCBkZWxheWluZyB0aGlzIHRvIDEuMCBSQyBpbml0aWFs
bHkgd2FzIHRvIGtlZXAgY29uc2lzdGVuY3kgZm9yIGN1cnJlbnQNCgl1c2Vycy4gT24gdGhlIG90
aGVyIGhhbmQsIHRoZXJlJ3MgdGhlIHN0cm9uZyBhcmd1bWVudCBvZiBhIGdyb3dpbmcgdXNlcg0K
CWJhc2U6IEFuIGVhcmx5IGNoYW5nZSB3aWxsIGFmZmVjdCBsZXNzIHBlb3BsZS4NCgkNCglXZSBh
bGwgc2VlbSBhZ3JlZWQuDQoJDQoJPiBPZiBjb3Vyc2Ugd2UgY2FuIHN0aWxsIGtlZXAgMC45LjEg
YXMgbmV4dCB2ZXJzaW9uIG51bWJlci4gQ2FsbGluZyBvdXINCgljdXJyZW50IHN0YXR1cyAxLjAg
YmV0YTEgd291bGRuJ3QgYmUgYWJzdXJkIHRob3VnaCwganVzdCBsb29rIGF0IGF0IHRoZQ0KCWVh
Z2VyIHJlbGVhc2UgcG9saWNpZXMgb2YgSmFrYXJ0YSBvciBIaWJlcm5hdGUuIE5vdGUgdGhhdCBm
b3IgYW55IHN1YnNlcXVlbnQNCgl2ZXJzaW9uIGxpa2UgMi4wIHRoZXJlIHdpbGwgb25seSBiZSB0
aGUgYmV0YS9SQy1vcHRpb24uIFNvLCBvcGluaW9uIHBvbGw6DQoJc3RheSB3aXRoIDAuOS4xIG9y
IGVhZ2VybHkgbW92ZSB0byAxLjAgYmV0YTEgbm93PyBJJ20gaW5jbGluZWQgdG8gZ28gZm9yIHRo
ZQ0KCWxhdHRlci4NCgkNCglJIGFncmVlIHdpdGggVGhvbWFzLiAxLjAgYmV0YSAxIGltcGxpZXMg
YSBmZWF0dXJlIGZyZWV6ZSB0byBtZSwgYW5kIEkgZG9uJ3QNCgl0aGluayB3ZSdyZSB0aGVyZSB5
ZXQuIFRoZSBwYWNlIG9mIGNoYW5nZSBpcyBjZXJ0YWlubHkgc2xvd2luZyBhbmQgaG9wZWZ1bGx5
DQoJZnV0dXJlIGNoYW5nZXMgd2lsbCBiZSBiYWNrd2FyZC1jb21wYXRpYmxlLCBidXQgSSB0aGlu
ayB3ZSBuZWVkIDAuOS4xIGJlZm9yZQ0KCTEuMCBiZXRhIDEuDQoJPg0KCT4gQlRXLCB3aGF0IGRv
ZXMgZXZlcnlib2R5IHRoaW5rIHJlZ2FyZGluZyBhIG5ldyBDVlMgbW9kdWxlDQoJIm1haW4xIi8i
bWFpbjEwIiwgb3IgInNwcmluZzEiLyJzcHJpbmcxMCIsIG9yIHRoZSBsaWtlPyBUaGUgSGliZXJu
YXRlIHRlYW0NCgl3b3JrcyB3aXRoIGEgImhpYmVybmF0ZTIiIG1vZHVsZSBjdXJyZW50bHksIGhh
dmluZyB0aGUgMS4wIHRyZWUgaW4NCgkiaGliZXJuYXRlIiwgc28gY3JlYXRpbmcgYSBuZXcgbW9k
dWxlIHNlZW1zIGFwcHJvcHJpYXRlIHRvIG1lLg0KCQ0KCXNwcmluZzEwLg0KCQ0KCT4gVG8gYXZv
aWQgdW5uZWNlc3NhcnkgZnVydGhlciBkZWxheXMsIEkgdXJnZSBldmVyeWJvZHkgdG8gY29tbWl0
IGFsbA0KCWRhbmdsaW5nIGNoYW5nZXMuIElmIHdlIGFncmVlIG9uIHRoZSBtb2R1bGUgYW5kIGl0
cyBuYW1lLCBJJ2QgbGlrZSB0byBjcmVhdGUNCglpdCBvbiBNb25kYXkgYW5kIGltcG9ydCBhIGNs
ZWFuIG9yZy5zcHJpbmdmcmFtZXdvcmsgdmVyc2lvbi4gVGhlbiB3ZSBzaG91bGQNCgl0ZXN0IHRo
YXQgd2l0aCBjdXJyZW50IGFwcHMsIGFuZCBpZiBldmVyeXRoaW5nIHN1Y2NlZWRzLCB3ZSBzaG91
bGQgYmUgYWJsZQ0KCXRvIHB1Ymxpc2ggdGhlIHJlbGVhc2UgYXQgdGhlIGVuZCBvZiB0aGUgd2Vl
ay4NCgkNCglJJ20gZG9uZSB1bnRpbCB3ZSByZWxlYXNlLCBhbHRob3VnaCBJIHdvdWxkIGxpa2Ug
dG8gYmUgYWJsZSB0byBnZXQgYmFjayBpbnRvDQoJdGhlIGNvZGViYXNlIG5vIGxhdGVyIHRoYW4g
dGhlIGVuZCBvZiB0aGUgd2Vlay4NCgkNCglSZWdhcmRzLA0KCVJvZA0KCQ0KCQ0KCQ0KCQ0KCSAg
ICAgICAgICAgICAgICAgICAgICsSF14gWyl7KFsga3kga3sgW0BIIBE7IiIgbnYpDQoJWkUgaCAT
KGdxID8/WiBoP2o/aV4OJ1ogentePzA/dlwTYkogET8gICB3IGJyT18gbyBsa001TTQgID95IGog
PzsgfTdNfyBfDQoJKmt4HyAgP3paKXpYWCpreB8/ID96Wil6IGwgLmEedyBpICstKB5+IHsgYiA/
Ky13IGs/eB8/ID96WikNCgkNCgktLS0NCglJbmNvbWluZyBtYWlsIGlzIGNlcnRpZmllZCBWaXJ1
cyBGcmVlLg0KCUNoZWNrZWQgYnkgQVZHIGFudGktdmlydXMgc3lzdGVtIChodHRwOi8vd3d3Lmdy
aXNvZnQuY29tKS4NCglWZXJzaW9uOiA2LjAuNTAyIC8gVmlydXMgRGF0YWJhc2U6IDMwMCAtIFJl
bGVhc2UgRGF0ZTogMTgvMDcvMjAwMw0KCQ0KCQ0KCQ0KCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCglUaGlzIFNGLk5ldCBlbWFpbCBzcG9u
c29yZWQgYnk6IEZyZWUgcHJlLWJ1aWx0IEFTUC5ORVQgc2l0ZXMgaW5jbHVkaW5nDQoJRGF0YSBS
ZXBvcnRzLCBFLWNvbW1lcmNlLCBQb3J0YWxzLCBhbmQgRm9ydW1zIGFyZSBhdmFpbGFibGUgbm93
Lg0KCURvd25sb2FkIHRvZGF5IGFuZCBlbnRlciB0byB3aW4gYW4gWEJPWCBvciBWaXN1YWwgU3R1
ZGlvIC5ORVQuDQoJaHR0cDovL2FzcG5ldC5jbGljay11cmwuY29tL2dvL3BzYTAwMTAwMDAzYXZl
L2RpcmVjdDthdC5hc3BuZXRfMDcyMzAzXzAxLzAxDQoJX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxp
bmcgbGlzdA0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0
DQoJaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJh
bWV3b3JrLWRldmVsb3Blcg0KCQ0KCQ0KCQ0KCQ0KCQ0KCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCglUaGlzIFNGLk5ldCBlbWFpbCBzcG9u
c29yZWQgYnk6IEZyZWUgcHJlLWJ1aWx0IEFTUC5ORVQgc2l0ZXMgaW5jbHVkaW5nDQoJRGF0YSBS
ZXBvcnRzLCBFLWNvbW1lcmNlLCBQb3J0YWxzLCBhbmQgRm9ydW1zIGFyZSBhdmFpbGFibGUgbm93
Lg0KCURvd25sb2FkIHRvZGF5IGFuZCBlbnRlciB0byB3aW4gYW4gWEJPWCBvciBWaXN1YWwgU3R1
ZGlvIC5ORVQuDQoJaHR0cDovL2FzcG5ldC5jbGljay11cmwuY29tL2dvL3BzYTAwMTAwMDAzYXZl
L2RpcmVjdDthdC5hc3BuZXRfMDcyMzAzXzAxLzAxDQoJX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxp
bmcgbGlzdA0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0
DQoJaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJh
bWV3b3JrLWRldmVsb3Blcg0KCQ0KDQo=

Re: [Springframework-developer] Current release plan - why delay package renaming?

[<tri...@tr...>]

Rod & all,

> I've been thinking it over last night and I can see major marketing
> advantages in a 1.0 name. (For TSS article etc.)
> 
> So I'm inclined to agree with Trevors suggestion as to Eclipse-stype
> "milestones".
> 
> 1.0M1 sounds good.
> 

I like Trevor's suggestion as well.  Also makes sense since we are changing the
package names.  1.0M1 is more of a distinction from 0.9 than 0.9.1 would be.

I can see the following:

1.0M1 is what we have today plus package name changes
1.0M2/1.0M3/... would include some new features as we see fit
After a feature freeze is agreed upon, we can quickly release 1.0RC1 to be
followed by 1.0RC2 with only bug fixes. 
Then we can release 1.0

1.0.1 would be bug fixes for 1.0

1.1M1... 1.1RC1 ... 1.1 would be the next version to include new features
1.2M1 ...  the next one and so on until we introduce some major changes that
might not be completely backwards compatible.  At that point we move to 2.0M1
with a new source module "spring2".  We can still maintain "spring1" and create
bug fix releases if necessary.

Once we introduce the new source module, is it feasible to rename the "main" CVS
module to maybe "i21beta" or something like it, to make it clear that it is not
the main source tree.

Thomas

Re: [Springframework-developer] Step-by-step tutorial error

[<tri...@tr...>]

Lars,

Looks like something is missing for the i21:bind tag.  If you send me your jsp,
then I can compare it to the one I am running with.

Thomas


> Just tested the step-by-step tutorial from scratch today.
> 
> When calling the priceincrease.jsp from the main menu the error shown below 
> is raised.
> 
> Any suggestions ?
> 
> Thanks.
> Lars
> 
> org.apache.jasper.JasperException: /WEB-INF/jsp/priceincrease.jsp(11,6)
> Unable to load class bind
> 	at
>
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:94)
> 	at
> org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:428)
> 	at
> org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:219)
> 	at org.apache.jasper.compiler.Parser.parseCustomTag(Parser.java:712)
> 	at org.apache.jasper.compiler.Parser.parseElements(Parser.java:804)
> 	at org.apache.jasper.compiler.Parser.parse(Parser.java:122)
> 	at
> org.apache.jasper.compiler.ParserController.parse(ParserController.java:199)
> 	at
> org.apache.jasper.compiler.ParserController.parse(ParserController.java:153)
> 	at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:227)
> 	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:369)
> 	at
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:473)
> 	at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:190)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> 	at
>
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
> 	at
>
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:432)
> 	at
>
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:356)
> 	at
>
com.interface21.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:86)
> 	at
> com.interface21.web.servlet.view.AbstractView.render(AbstractView.java:194)
> 	at
> com.interface21.web.servlet.DispatcherServlet.render(DispatcherServlet.java:505)
> 	at
>
com.interface21.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:387)
> 	at
>
com.interface21.web.servlet.FrameworkServlet.serviceWrapper(FrameworkServlet.java:228)
> 	at
> com.interface21.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:207)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> 	at
>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
> 	at
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
> 	at
>
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> 	at
>
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
> 	at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> 	at
>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at
>
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
> 	at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> 	at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
> 	at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
> 	at
>
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
> 	at
>
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
> 	at
>
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
> 	at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
> 	at
>
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
> 	at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> 	at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
> 	at
>
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
> 	at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> 	at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
> 	at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
> 	at
>
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
> 	at
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
> 	at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
> 	at java.lang.Thread.run(Thread.java:534)
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] Step-by-step tutorial error

[Lars F. <lar...@gm...>]

Just tested the step-by-step tutorial from scratch today.

When calling the priceincrease.jsp from the main menu the error shown below 
is raised.

Any suggestions ?

Thanks.
Lars

org.apache.jasper.JasperException: /WEB-INF/jsp/priceincrease.jsp(11,6)
Unable to load class bind
	at
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:94)
	at
org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:428)
	at
org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:219)
	at org.apache.jasper.compiler.Parser.parseCustomTag(Parser.java:712)
	at org.apache.jasper.compiler.Parser.parseElements(Parser.java:804)
	at org.apache.jasper.compiler.Parser.parse(Parser.java:122)
	at
org.apache.jasper.compiler.ParserController.parse(ParserController.java:199)
	at
org.apache.jasper.compiler.ParserController.parse(ParserController.java:153)
	at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:227)
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:369)
	at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:473)
	at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:190)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
	at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:432)
	at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:356)
	at
com.interface21.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:86)
	at
com.interface21.web.servlet.view.AbstractView.render(AbstractView.java:194)
	at
com.interface21.web.servlet.DispatcherServlet.render(DispatcherServlet.java:505)
	at
com.interface21.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:387)
	at
com.interface21.web.servlet.FrameworkServlet.serviceWrapper(FrameworkServlet.java:228)
	at
com.interface21.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:207)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
	at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
	at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
	at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
	at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
	at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
	at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
	at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
	at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
	at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
	at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
	at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
	at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
	at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
	at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
	at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
	at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
	at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
	at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
	at java.lang.Thread.run(Thread.java:534)

Re: [Springframework-developer] Current release plan - why delay package renaming?

[Rod J. <rod...@in...>]

I've been thinking it over last night and I can see major marketing
advantages in a 1.0 name. (For TSS article etc.)

So I'm inclined to agree with Trevors suggestion as to Eclipse-stype
"milestones".

1.0M1 sounds good.

I agree that "beta" is almost meaningless.

We should decide on how many milestones before RC1. I think only 2.

Regards,
Rod

----- Original Message -----
From: "Trevor Cook" <pr...@se...>
To: <spr...@li...>
Sent: Saturday, August 02, 2003 5:05 PM
Subject: RE: [Springframework-developer] Current release plan - why delay
package renaming?


As far as "main" vs "spring", my main concern is consistency.  I'd change my
vote to "spring#" IF we can rename/delete the current main, but as Juergen
says, having multiple names is really confusing (I've been bitten by this
myself).

Now that I've conceded victory for the module name to my opponents, I would
like to continue campaigning for 1.0-x . :)

For the "1.0 beta" vs "0.9.1" the major sticking point appears to be
"feature freeze".  Maybe beta is the wrong term, and we should consider
"stable build".  To me this makes more sense (even more sense than "beta"
now since that term seems to be vastly abused IMO).

I tend to follow the release style followed by eclipse (see
http://www.eclipse.org/downloads/index.php).  Basically the version is the
current version being worked towards, and the number is indicitive of the
current status.  They basically progress from "stable builds" to "release
cantidates" to "release".  Their naming for the stable builds is usually
"3.0M2" or 2.0M5" with the prefix (3.0 / 2.0) as the version worked towards,
M signifying its not a release, and the suffix (2 / 5) indicating which
stable build.  Features and bug-fixes are continually added during stable
builds, feature freeze isn't implemented until the first RC.  The
progression is generally:

1.0M1
1.0M2
1.0M3
1.0RC1
1.0RC2
1.0R 2.0M1
1.1 2.0M2
1.2 ...
...

Another point is how we will handle future releases. I know I'm getting way
ahead of the project, but our current naming structure will dictate the
future naming (or we'll have mass confusion).  When we are working on Spring
2.0, how will we name releases?  Is 1.6 a bug fix to 1.5, or a prerelease of
features for 2.0?  I think that if the version is always the "release
version being worked towards" we'll have less confusion.  I think this
extends even to the 1.1 name Rod was mentioning (for JMS, etc.) since that
brings up questions on whether it is a 1.0 bug fix or new features.

I would appreciate any feedback on these comments.  Specifically, if you
prefer to stay with the "0.9.1" and "1.1" naming style, how does a newcomer
know which is the latest release (without scouring the mailing lists), which
is bug-fixed release versions, and which are development releases?  I'm sure
there are other ways than what I'm proposing, it just appears to make the
most sense of the methods I've encountered.

Trevor D. Cook


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of jürgen höller [werk3AT]
Sent: August 2, 2003 11:23 AM
To: Rod Johnson; Trevor Cook;
spr...@li...
Subject: Re: [Springframework-developer] Current release plan - why
delay package renaming?


So it's currently 2:1 in terms of "1.0 beta" vs "0.9.1". Like Trevor, I also
thought of the marketing effect. On the other hand there are really some
features left to add for 1.0, and I can understand the argument that we
should avoid the impression of a feature freeze. Reconsidering this, it's
probably better to stay with 0.9.x for the time being.

There is a consistency issue with the name of the new module for the
org.springframework version: be it "spring1" or "spring10" - both suggest
that they contain the 1.0 sources.  Releasing a 0.9.1 based on such a module
could lead to confusion. I don't have a perfect alternative though: Maybe
"spring" (analogous to "hibernate") without explicit version number, with
the option to use "spring2" for a 2.0 source tree. After all, the root of
the problem is probably the name "main" for our current sources. No matter
if we choose "spring", "spring1", or "spring10" - having a "main" alongside
can cause confusion.

Regarding the version number in the module name: We should try to decide
when to create a new module upfront. Hibernate has "hibernate" for 1.x (1.0,
1.1, 1.2), and a new "hibernate2" module for 2.x (2.0 and the upcoming 2.1).
So if our 1.1 release will basically be a 1.0 follow-up snapshot with a
larger number of new features than the last 1.0.x, it would make sense to
keep 1.x in the same module. As this is very likely, I consider it safe to
assume that we will create a new module for 2.0 but not earlier. Therefore,
a "spring" or "spring1" module name is appopriate - I suggest a "spring"
module, as argumented in the previous paragraph.

Juergen


-----Ursprngliche Nachricht-----
Von: Rod Johnson [mailto:rod...@in...]
Gesendet: Sa 02.08.2003 10:00
An: j rgen hller [werk3AT]; Trevor Cook;
spr...@li...
Cc:
Betreff: Re: [Springframework-developer] Current release plan - why delay
package renaming?



> Wow, there seems to be an overwhelming consensus to change the package
names now. Well, then let there be org.springframework :-) The reasoning
behind delaying this to 1.0 RC initially was to keep consistency for current
users. On the other hand, there's the strong argument of a growing user
base: An early change will affect less people.

We all seem agreed.

> Of course we can still keep 0.9.1 as next version number. Calling our
current status 1.0 beta1 wouldn't be absurd though, just look at at the
eager release policies of Jakarta or Hibernate. Note that for any subsequent
version like 2.0 there will only be the beta/RC-option. So, opinion poll:
stay with 0.9.1 or eagerly move to 1.0 beta1 now? I'm inclined to go for the
latter.

I agree with Thomas. 1.0 beta 1 implies a feature freeze to me, and I don't
think we're there yet. The pace of change is certainly slowing and hopefully
future changes will be backward-compatible, but I think we need 0.9.1 before
1.0 beta 1.
>
> BTW, what does everybody think regarding a new CVS module
"main1"/"main10", or "spring1"/"spring10", or the like? The Hibernate team
works with a "hibernate2" module currently, having the 1.0 tree in
"hibernate", so creating a new module seems appropriate to me.

spring10.

> To avoid unnecessary further delays, I urge everybody to commit all
dangling changes. If we agree on the module and its name, I'd like to create
it on Monday and import a clean org.springframework version. Then we should
test that with current apps, and if everything succeeds, we should be able
to publish the release at the end of the week.

I'm done until we release, although I would like to be able to get back into
the codebase no later than the end of the week.

Regards,
Rod




                     +^ [){([ ky k{ [@H ;"" nv)
ZE h (gq ??Z h?j?i^'Z z{^?0?v\bJ ?   w brO_ o lkM5M4  ?y j ?; }7M _
*kx  ?zZ)zXX*kx? ?zZ)z l .aw i +-(~ { b ?+-w k?x? ?zZ)

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 18/07/2003



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Current release plan - why delay package renaming?

[Trevor C. <pr...@se...>]

As far as "main" vs "spring", my main concern is consistency.  I'd =
change my vote to "spring#" IF we can rename/delete the current main, =
but as Juergen says, having multiple names is really confusing (I've =
been bitten by this myself).

Now that I've conceded victory for the module name to my opponents, I =
would like to continue campaigning for 1.0-x . :)

For the "1.0 beta" vs "0.9.1" the major sticking point appears to be =
"feature freeze".  Maybe beta is the wrong term, and we should consider =
"stable build".  To me this makes more sense (even more sense than =
"beta" now since that term seems to be vastly abused IMO). =20

I tend to follow the release style followed by eclipse (see =
http://www.eclipse.org/downloads/index.php).  Basically the version is =
the current version being worked towards, and the number is indicitive =
of the current status.  They basically progress from "stable builds" to =
"release cantidates" to "release".  Their naming for the stable builds =
is usually "3.0M2" or 2.0M5" with the prefix (3.0 / 2.0) as the version =
worked towards, M signifying its not a release, and the suffix (2 / 5) =
indicating which stable build.  Features and bug-fixes are continually =
added during stable builds, feature freeze isn't implemented until the =
first RC.  The progression is generally:

1.0M1
1.0M2
1.0M3
1.0RC1
1.0RC2
1.0R	2.0M1
1.1	2.0M2
1.2	...
...

Another point is how we will handle future releases. I know I'm getting =
way ahead of the project, but our current naming structure will dictate =
the future naming (or we'll have mass confusion).  When we are working =
on Spring 2.0, how will we name releases?  Is 1.6 a bug fix to 1.5, or a =
prerelease of features for 2.0?  I think that if the version is always =
the "release version being worked towards" we'll have less confusion.  I =
think this extends even to the 1.1 name Rod was mentioning (for JMS, =
etc.) since that brings up questions on whether it is a 1.0 bug fix or =
new features.

I would appreciate any feedback on these comments.  Specifically, if you =
prefer to stay with the "0.9.1" and "1.1" naming style, how does a =
newcomer know which is the latest release (without scouring the mailing =
lists), which is bug-fixed release versions, and which are development =
releases?  I'm sure there are other ways than what I'm proposing, it =
just appears to make the most sense of the methods I've encountered.

Trevor D. Cook


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=C3=BCrgen h=C3=B6ller [werk3AT]
Sent: August 2, 2003 11:23 AM
To: Rod Johnson; Trevor Cook;
spr...@li...
Subject: Re: [Springframework-developer] Current release plan - why
delay package renaming?


So it's currently 2:1 in terms of "1.0 beta" vs "0.9.1". Like Trevor, I =
also thought of the marketing effect. On the other hand there are really =
some features left to add for 1.0, and I can understand the argument =
that we should avoid the impression of a feature freeze. Reconsidering =
this, it's probably better to stay with 0.9.x for the time being.
=20
There is a consistency issue with the name of the new module for the =
org.springframework version: be it "spring1" or "spring10" - both =
suggest that they contain the 1.0 sources.  Releasing a 0.9.1 based on =
such a module could lead to confusion. I don't have a perfect =
alternative though: Maybe "spring" (analogous to "hibernate") without =
explicit version number, with the option to use "spring2" for a 2.0 =
source tree. After all, the root of the problem is probably the name =
"main" for our current sources. No matter if we choose "spring", =
"spring1", or "spring10" - having a "main" alongside can cause =
confusion.
=20
Regarding the version number in the module name: We should try to decide =
when to create a new module upfront. Hibernate has "hibernate" for 1.x =
(1.0, 1.1, 1.2), and a new "hibernate2" module for 2.x (2.0 and the =
upcoming 2.1). So if our 1.1 release will basically be a 1.0 follow-up =
snapshot with a larger number of new features than the last 1.0.x, it =
would make sense to keep 1.x in the same module. As this is very likely, =
I consider it safe to assume that we will create a new module for 2.0 =
but not earlier. Therefore, a "spring" or "spring1" module name is =
appopriate - I suggest a "spring" module, as argumented in the previous =
paragraph.
=20
Juergen
=20

	-----Ursprngliche Nachricht-----=20
	Von: Rod Johnson [mailto:rod...@in...]=20
	Gesendet: Sa 02.08.2003 10:00=20
	An: j rgen hller [werk3AT]; Trevor Cook; =
spr...@li...=20
	Cc:=20
	Betreff: Re: [Springframework-developer] Current release plan - why =
delay package renaming?
=09
=09

	> Wow, there seems to be an overwhelming consensus to change the =
package
	names now. Well, then let there be org.springframework :-) The =
reasoning
	behind delaying this to 1.0 RC initially was to keep consistency for =
current
	users. On the other hand, there's the strong argument of a growing user
	base: An early change will affect less people.
=09
	We all seem agreed.
=09
	> Of course we can still keep 0.9.1 as next version number. Calling our
	current status 1.0 beta1 wouldn't be absurd though, just look at at the
	eager release policies of Jakarta or Hibernate. Note that for any =
subsequent
	version like 2.0 there will only be the beta/RC-option. So, opinion =
poll:
	stay with 0.9.1 or eagerly move to 1.0 beta1 now? I'm inclined to go =
for the
	latter.
=09
	I agree with Thomas. 1.0 beta 1 implies a feature freeze to me, and I =
don't
	think we're there yet. The pace of change is certainly slowing and =
hopefully
	future changes will be backward-compatible, but I think we need 0.9.1 =
before
	1.0 beta 1.
	>
	> BTW, what does everybody think regarding a new CVS module
	"main1"/"main10", or "spring1"/"spring10", or the like? The Hibernate =
team
	works with a "hibernate2" module currently, having the 1.0 tree in
	"hibernate", so creating a new module seems appropriate to me.
=09
	spring10.
=09
	> To avoid unnecessary further delays, I urge everybody to commit all
	dangling changes. If we agree on the module and its name, I'd like to =
create
	it on Monday and import a clean org.springframework version. Then we =
should
	test that with current apps, and if everything succeeds, we should be =
able
	to publish the release at the end of the week.
=09
	I'm done until we release, although I would like to be able to get back =
into
	the codebase no later than the end of the week.
=09
	Regards,
	Rod
=09
=09
=09

                     +=12=17^ [){([ ky k{ [@H =11;"" nv)
ZE h =13(gq ??Z h?j?i^=0E'Z z{^?0?v\=13bJ =11?   w brO_ o lkM5M4  ?y j =
?; }7M=7F _                 *kx=1F  ?zZ)zXX*kx=1F? ?zZ)z l .a=1Ew i =
+-(=1E~ { b ?+-w k?x=1F? ?zZ)

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 18/07/2003

Re: [Springframework-developer] Current release plan - why delay package renaming?

[<jue...@we...>]

U28gaXQncyBjdXJyZW50bHkgMjoxIGluIHRlcm1zIG9mICIxLjAgYmV0YSIgdnMgIjAuOS4xIi4g
TGlrZSBUcmV2b3IsIEkgYWxzbyB0aG91Z2h0IG9mIHRoZSBtYXJrZXRpbmcgZWZmZWN0LiBPbiB0
aGUgb3RoZXIgaGFuZCB0aGVyZSBhcmUgcmVhbGx5IHNvbWUgZmVhdHVyZXMgbGVmdCB0byBhZGQg
Zm9yIDEuMCwgYW5kIEkgY2FuIHVuZGVyc3RhbmQgdGhlIGFyZ3VtZW50IHRoYXQgd2Ugc2hvdWxk
IGF2b2lkIHRoZSBpbXByZXNzaW9uIG9mIGEgZmVhdHVyZSBmcmVlemUuIFJlY29uc2lkZXJpbmcg
dGhpcywgaXQncyBwcm9iYWJseSBiZXR0ZXIgdG8gc3RheSB3aXRoIDAuOS54IGZvciB0aGUgdGlt
ZSBiZWluZy4NCiANClRoZXJlIGlzIGEgY29uc2lzdGVuY3kgaXNzdWUgd2l0aCB0aGUgbmFtZSBv
ZiB0aGUgbmV3IG1vZHVsZSBmb3IgdGhlIG9yZy5zcHJpbmdmcmFtZXdvcmsgdmVyc2lvbjogYmUg
aXQgInNwcmluZzEiIG9yICJzcHJpbmcxMCIgLSBib3RoIHN1Z2dlc3QgdGhhdCB0aGV5IGNvbnRh
aW4gdGhlIDEuMCBzb3VyY2VzLiAgUmVsZWFzaW5nIGEgMC45LjEgYmFzZWQgb24gc3VjaCBhIG1v
ZHVsZSBjb3VsZCBsZWFkIHRvIGNvbmZ1c2lvbi4gSSBkb24ndCBoYXZlIGEgcGVyZmVjdCBhbHRl
cm5hdGl2ZSB0aG91Z2g6IE1heWJlICJzcHJpbmciIChhbmFsb2dvdXMgdG8gImhpYmVybmF0ZSIp
IHdpdGhvdXQgZXhwbGljaXQgdmVyc2lvbiBudW1iZXIsIHdpdGggdGhlIG9wdGlvbiB0byB1c2Ug
InNwcmluZzIiIGZvciBhIDIuMCBzb3VyY2UgdHJlZS4gQWZ0ZXIgYWxsLCB0aGUgcm9vdCBvZiB0
aGUgcHJvYmxlbSBpcyBwcm9iYWJseSB0aGUgbmFtZSAibWFpbiIgZm9yIG91ciBjdXJyZW50IHNv
dXJjZXMuIE5vIG1hdHRlciBpZiB3ZSBjaG9vc2UgInNwcmluZyIsICJzcHJpbmcxIiwgb3IgInNw
cmluZzEwIiAtIGhhdmluZyBhICJtYWluIiBhbG9uZ3NpZGUgY2FuIGNhdXNlIGNvbmZ1c2lvbi4N
CiANClJlZ2FyZGluZyB0aGUgdmVyc2lvbiBudW1iZXIgaW4gdGhlIG1vZHVsZSBuYW1lOiBXZSBz
aG91bGQgdHJ5IHRvIGRlY2lkZSB3aGVuIHRvIGNyZWF0ZSBhIG5ldyBtb2R1bGUgdXBmcm9udC4g
SGliZXJuYXRlIGhhcyAiaGliZXJuYXRlIiBmb3IgMS54ICgxLjAsIDEuMSwgMS4yKSwgYW5kIGEg
bmV3ICJoaWJlcm5hdGUyIiBtb2R1bGUgZm9yIDIueCAoMi4wIGFuZCB0aGUgdXBjb21pbmcgMi4x
KS4gU28gaWYgb3VyIDEuMSByZWxlYXNlIHdpbGwgYmFzaWNhbGx5IGJlIGEgMS4wIGZvbGxvdy11
cCBzbmFwc2hvdCB3aXRoIGEgbGFyZ2VyIG51bWJlciBvZiBuZXcgZmVhdHVyZXMgdGhhbiB0aGUg
bGFzdCAxLjAueCwgaXQgd291bGQgbWFrZSBzZW5zZSB0byBrZWVwIDEueCBpbiB0aGUgc2FtZSBt
b2R1bGUuIEFzIHRoaXMgaXMgdmVyeSBsaWtlbHksIEkgY29uc2lkZXIgaXQgc2FmZSB0byBhc3N1
bWUgdGhhdCB3ZSB3aWxsIGNyZWF0ZSBhIG5ldyBtb2R1bGUgZm9yIDIuMCBidXQgbm90IGVhcmxp
ZXIuIFRoZXJlZm9yZSwgYSAic3ByaW5nIiBvciAic3ByaW5nMSIgbW9kdWxlIG5hbWUgaXMgYXBw
b3ByaWF0ZSAtIEkgc3VnZ2VzdCBhICJzcHJpbmciIG1vZHVsZSwgYXMgYXJndW1lbnRlZCBpbiB0
aGUgcHJldmlvdXMgcGFyYWdyYXBoLg0KIA0KSnVlcmdlbg0KIA0KDQoJLS0tLS1VcnNwcsO8bmds
aWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IFJvZCBKb2huc29uIFttYWlsdG86cm9kLmpvaG5z
b25AaW50ZXJmYWNlMjEuY29tXSANCglHZXNlbmRldDogU2EgMDIuMDguMjAwMyAxMDowMCANCglB
bjogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXTsgVHJldm9yIENvb2s7IHNwcmluZ2ZyYW1ld29y
ay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglCZXRyZWZmOiBSZTog
W1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIEN1cnJlbnQgcmVsZWFzZSBwbGFuIC0gd2h5IGRl
bGF5IHBhY2thZ2UgcmVuYW1pbmc/DQoJDQoJDQoNCgk+IFdvdywgdGhlcmUgc2VlbXMgdG8gYmUg
YW4gb3ZlcndoZWxtaW5nIGNvbnNlbnN1cyB0byBjaGFuZ2UgdGhlIHBhY2thZ2UNCgluYW1lcyBu
b3cuIFdlbGwsIHRoZW4gbGV0IHRoZXJlIGJlIG9yZy5zcHJpbmdmcmFtZXdvcmsgOi0pIFRoZSBy
ZWFzb25pbmcNCgliZWhpbmQgZGVsYXlpbmcgdGhpcyB0byAxLjAgUkMgaW5pdGlhbGx5IHdhcyB0
byBrZWVwIGNvbnNpc3RlbmN5IGZvciBjdXJyZW50DQoJdXNlcnMuIE9uIHRoZSBvdGhlciBoYW5k
LCB0aGVyZSdzIHRoZSBzdHJvbmcgYXJndW1lbnQgb2YgYSBncm93aW5nIHVzZXINCgliYXNlOiBB
biBlYXJseSBjaGFuZ2Ugd2lsbCBhZmZlY3QgbGVzcyBwZW9wbGUuDQoJDQoJV2UgYWxsIHNlZW0g
YWdyZWVkLg0KCQ0KCT4gT2YgY291cnNlIHdlIGNhbiBzdGlsbCBrZWVwIDAuOS4xIGFzIG5leHQg
dmVyc2lvbiBudW1iZXIuIENhbGxpbmcgb3VyDQoJY3VycmVudCBzdGF0dXMgMS4wIGJldGExIHdv
dWxkbid0IGJlIGFic3VyZCB0aG91Z2gsIGp1c3QgbG9vayBhdCBhdCB0aGUNCgllYWdlciByZWxl
YXNlIHBvbGljaWVzIG9mIEpha2FydGEgb3IgSGliZXJuYXRlLiBOb3RlIHRoYXQgZm9yIGFueSBz
dWJzZXF1ZW50DQoJdmVyc2lvbiBsaWtlIDIuMCB0aGVyZSB3aWxsIG9ubHkgYmUgdGhlIGJldGEv
UkMtb3B0aW9uLiBTbywgb3BpbmlvbiBwb2xsOg0KCXN0YXkgd2l0aCAwLjkuMSBvciBlYWdlcmx5
IG1vdmUgdG8gMS4wIGJldGExIG5vdz8gSSdtIGluY2xpbmVkIHRvIGdvIGZvciB0aGUNCglsYXR0
ZXIuDQoJDQoJSSBhZ3JlZSB3aXRoIFRob21hcy4gMS4wIGJldGEgMSBpbXBsaWVzIGEgZmVhdHVy
ZSBmcmVlemUgdG8gbWUsIGFuZCBJIGRvbid0DQoJdGhpbmsgd2UncmUgdGhlcmUgeWV0LiBUaGUg
cGFjZSBvZiBjaGFuZ2UgaXMgY2VydGFpbmx5IHNsb3dpbmcgYW5kIGhvcGVmdWxseQ0KCWZ1dHVy
ZSBjaGFuZ2VzIHdpbGwgYmUgYmFja3dhcmQtY29tcGF0aWJsZSwgYnV0IEkgdGhpbmsgd2UgbmVl
ZCAwLjkuMSBiZWZvcmUNCgkxLjAgYmV0YSAxLg0KCT4NCgk+IEJUVywgd2hhdCBkb2VzIGV2ZXJ5
Ym9keSB0aGluayByZWdhcmRpbmcgYSBuZXcgQ1ZTIG1vZHVsZQ0KCSJtYWluMSIvIm1haW4xMCIs
IG9yICJzcHJpbmcxIi8ic3ByaW5nMTAiLCBvciB0aGUgbGlrZT8gVGhlIEhpYmVybmF0ZSB0ZWFt
DQoJd29ya3Mgd2l0aCBhICJoaWJlcm5hdGUyIiBtb2R1bGUgY3VycmVudGx5LCBoYXZpbmcgdGhl
IDEuMCB0cmVlIGluDQoJImhpYmVybmF0ZSIsIHNvIGNyZWF0aW5nIGEgbmV3IG1vZHVsZSBzZWVt
cyBhcHByb3ByaWF0ZSB0byBtZS4NCgkNCglzcHJpbmcxMC4NCgkNCgk+IFRvIGF2b2lkIHVubmVj
ZXNzYXJ5IGZ1cnRoZXIgZGVsYXlzLCBJIHVyZ2UgZXZlcnlib2R5IHRvIGNvbW1pdCBhbGwNCglk
YW5nbGluZyBjaGFuZ2VzLiBJZiB3ZSBhZ3JlZSBvbiB0aGUgbW9kdWxlIGFuZCBpdHMgbmFtZSwg
SSdkIGxpa2UgdG8gY3JlYXRlDQoJaXQgb24gTW9uZGF5IGFuZCBpbXBvcnQgYSBjbGVhbiBvcmcu
c3ByaW5nZnJhbWV3b3JrIHZlcnNpb24uIFRoZW4gd2Ugc2hvdWxkDQoJdGVzdCB0aGF0IHdpdGgg
Y3VycmVudCBhcHBzLCBhbmQgaWYgZXZlcnl0aGluZyBzdWNjZWVkcywgd2Ugc2hvdWxkIGJlIGFi
bGUNCgl0byBwdWJsaXNoIHRoZSByZWxlYXNlIGF0IHRoZSBlbmQgb2YgdGhlIHdlZWsuDQoJDQoJ
SSdtIGRvbmUgdW50aWwgd2UgcmVsZWFzZSwgYWx0aG91Z2ggSSB3b3VsZCBsaWtlIHRvIGJlIGFi
bGUgdG8gZ2V0IGJhY2sgaW50bw0KCXRoZSBjb2RlYmFzZSBubyBsYXRlciB0aGFuIHRoZSBlbmQg
b2YgdGhlIHdlZWsuDQoJDQoJUmVnYXJkcywNCglSb2QNCgkNCgkNCgkNCg0K

Re: [Springframework-developer] Current release plan - why delay package renaming?

[Rod J. <rod...@in...>]

> I'd also like to make up a concrete release plan for the follow-up, be it
0.9.2 or 1.0 beta2, with an approximate timeframe - probably beginning of
September. Obvious candidates are:
>
> - ResultSets from stored procedures;
> - Tiles integration;
> - advanced PropertyEditor support for JSPs;
> - compatibility testing;
> - polished sample apps;
> - very important: documentation and tutorials.

I'd call this 1.0 beta 1.

> I guess that stuff like metadata attributes driving AOP interceptors will
be beyond that timeframe. But we don't need to cram everything into this
follow-up: 1.0 RC1 in early October will be a fine milestone too. It would
generally be good to publish one release per month towards 1.0.

This is still my main priority; it's just that I've been distracted into
various other areas, largely to support actual projects. Anyone who'd like
to help on the metadata side, please let me know. I think this is very
important to the ease of use of our AOP APIs. We need a consistent metadata
solution in which source-level attributes are only one way (although often
the best) of providing metadata. .NET is of course a good example of
source-level metadata. JBoss 4 is also doing some pretty sophisticated
things with metadata hierarchies, although as I understand it it looks more
like text metadata than the object metadata that .NET offers and I think is
important.

I think Attrib4j, Mark Pollack's project, has a part to play here, and am
working with him to try to make Attrib4j easier to use.

> Finally, regarding the scope of 1.0 final: I still vote for delaying JMS
and Web Services support until 1.1, to be able to stabilize and polish the
current features as much as possible for 1.0. The same applies to stuff like
TopLink support or JSR-168 Portlets. We can still decide to focus on certain
features earlier if current needs arise, of course.

Agreed. No one could say that Spring doesn't have enough in it! I think the
timing of getting these things in will depend on how many of us have an
urgent need for them. For example, I may well become far more interested in
TopLink integration and JMS because of work commitments, in which case I'd
definitely be prioritising them, whether or not they'd be identified as a
Spring priority.

Unless for some such reason we end up with the support earlier, I think
Spring 1.1 should have Web Services and JMS as the major new features.
Because these are essentially "bolt-ons" that don't require extensive
changes, we could probably get to 1.1 reasonably quickly from 1.0.

The next major feature on the horizon after that (1.2?) might be dynamic
reconfiguration of bean factories, as we discussed in the list a while back,
although I'm sure our growing user community will generate a lot of our
direction.

TopLink integration is a nice-to-have given our support for Hibernate and
JDO, but I suspect that not that many users are likely to be crying out for
it.

Regards,
Rod

Re: [Springframework-developer] Current release plan - why delay package renaming?

[Rod J. <rod...@in...>]

> Wow, there seems to be an overwhelming consensus to change the package
names now. Well, then let there be org.springframework :-) The reasoning
behind delaying this to 1.0 RC initially was to keep consistency for current
users. On the other hand, there's the strong argument of a growing user
base: An early change will affect less people.

We all seem agreed.

> Of course we can still keep 0.9.1 as next version number. Calling our
current status 1.0 beta1 wouldn't be absurd though, just look at at the
eager release policies of Jakarta or Hibernate. Note that for any subsequent
version like 2.0 there will only be the beta/RC-option. So, opinion poll:
stay with 0.9.1 or eagerly move to 1.0 beta1 now? I'm inclined to go for the
latter.

I agree with Thomas. 1.0 beta 1 implies a feature freeze to me, and I don't
think we're there yet. The pace of change is certainly slowing and hopefully
future changes will be backward-compatible, but I think we need 0.9.1 before
1.0 beta 1.
>
> BTW, what does everybody think regarding a new CVS module
"main1"/"main10", or "spring1"/"spring10", or the like? The Hibernate team
works with a "hibernate2" module currently, having the 1.0 tree in
"hibernate", so creating a new module seems appropriate to me.

spring10.

> To avoid unnecessary further delays, I urge everybody to commit all
dangling changes. If we agree on the module and its name, I'd like to create
it on Monday and import a clean org.springframework version. Then we should
test that with current apps, and if everything succeeds, we should be able
to publish the release at the end of the week.

I'm done until we release, although I would like to be able to get back into
the codebase no later than the end of the week.

Regards,
Rod

RE: [Springframework-developer] Current release plan - why delay package renaming?

[Trevor C. <pr...@se...>]

+1 for 1.0 beta1 - This is all just "marketing stuff" (we could as =
easily jump to v7 like slackware did - =
http://www.slackware.com/faq/do_faq.php?faq=3Dgeneral#0 - :) ).  Those =
"in the know" follow the actual progress of the features and code, those =
outside use the version number to determine whether to use the project.  =
While the code is "not perfect", I feel it's good enough to start =
projects on which will be deployed around the end of the year (4-6 =
months) considering the current state of the code, the rapid development =
by active contributors, and the current plans for a release version.  I =
think the "beta" tag presents a more accurate image to those less =
familiar with Spring that it isn't done, but it's good enough to start =
using in the "real world".

+1 to new module (I'd lean to sticking with a "main#" rather than =
"spring#") - After hearing recent comments about the ease with which we =
can do it ourselves (no help required from Sourceforge) and the extra =
history it will provide, it seems like the simpler and smarter path.

+1 to delaying JMS / Web Services - Most of the features slated for 1.0 =
appear to be enhancements to things Spring already does well (like Tiles =
being added to our solid MVC core).  We should focus on polishing, =
fixing, and enhancing our current features, rather than just adding =
more.  This has the added benefit that by the time we hit 1.0 some good =
projects may already have been created to address these, and we can =
"stay with our strength" and simply write Spring wrappers around those =
projects (similiar to our "adoption" of Hibernate).

That's a lot of +1's.  Is this an election year?  :)

Trevor D. Cook



-----Original Message-----
From: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]
Sent: August 1, 2003 6:33 PM
To: Trevor Cook; spr...@li...
Subject: Re: [Springframework-developer] Current release plan - why
delay package renaming?


Hi everybody,
=20
Wow, there seems to be an overwhelming consensus to change the package =
names now. Well, then let there be org.springframework :-) The reasoning =
behind delaying this to 1.0 RC initially was to keep consistency for =
current users. On the other hand, there's the strong argument of a =
growing user base: An early change will affect less people.
=20
Of course we can still keep 0.9.1 as next version number. Calling our =
current status 1.0 beta1 wouldn't be absurd though, just look at at the =
eager release policies of Jakarta or Hibernate. Note that for any =
subsequent version like 2.0 there will only be the beta/RC-option. So, =
opinion poll: stay with 0.9.1 or eagerly move to 1.0 beta1 now? I'm =
inclined to go for the latter.
=20
BTW, what does everybody think regarding a new CVS module =
"main1"/"main10", or "spring1"/"spring10", or the like? The Hibernate =
team works with a "hibernate2" module currently, having the 1.0 tree in =
"hibernate", so creating a new module seems appropriate to me.
=20
To avoid unnecessary further delays, I urge everybody to commit all =
dangling changes. If we agree on the module and its name, I'd like to =
create it on Monday and import a clean org.springframework version. Then =
we should test that with current apps, and if everything succeeds, we =
should be able to publish the release at the end of the week.
=20
Regarding release notes for changes since 0.9: I'll try to collect them =
from the mailing list, there is quite a number of them actually.
=20
I'd also like to make up a concrete release plan for the follow-up, be =
it 0.9.2 or 1.0 beta2, with an approximate timeframe - probably =
beginning of September. Obvious candidates are:
=20
- ResultSets from stored procedures;
- Tiles integration;
- advanced PropertyEditor support for JSPs;
- compatibility testing;
- polished sample apps;
- very important: documentation and tutorials.
=20
I guess that stuff like metadata attributes driving AOP interceptors =
will be beyond that timeframe. But we don't need to cram everything into =
this follow-up: 1.0 RC1 in early October will be a fine milestone too. =
It would generally be good to publish one release per month towards 1.0.
=20
Finally, regarding the scope of 1.0 final: I still vote for delaying JMS =
and Web Services support until 1.1, to be able to stabilize and polish =
the current features as much as possible for 1.0. The same applies to =
stuff like TopLink support or JSR-168 Portlets. We can still decide to =
focus on certain features earlier if current needs arise, of course.
=20
Regards,
Juergen
=20
=20

	-----Ursprngliche Nachricht-----=20
	Von: Trevor Cook [mailto:pr...@se...]=20
	Gesendet: Fr 01.08.2003 18:09=20
	An: spr...@li...=20
	Cc:=20
	Betreff: RE: [Springframework-developer] Current release plan - why =
delay package renaming?
=09
=09

	Changing it now would be better for me, but I can work with either name =
(my main problem was the public api which a search/replace won't solve =
:) ).  I would vote +1 to do it now, but I don't know the reasons for =
the delay to RC1.  To those who know (Juergen/Rod?), is there a =
technical reason for the delay, or just the release plan?
=09
	Trevor D. Cook

Re: [Springframework-developer] Current release plan - why delay package renaming?

[<tri...@tr...>]

Juergen & Everybody,

> So, opinion poll: stay with 0.9.1
> or eagerly move to 1.0 beta1 now? I'm inclined to go for the latter.
> 

I could go either way - beta1 kind of implies a feature freeze, but we are 
still adding a few features, so I would probably go 0.9.1.
 
> BTW, what does everybody think regarding a new CVS module "main1"/"main10",
> or "spring1"/"spring10", or the like? The Hibernate team works with a
> "hibernate2" module currently, having the 1.0 tree in "hibernate", so
> creating a new module seems appropriate to me.

I'd say "spring1"

>  
> To avoid unnecessary further delays, I urge everybody to commit all dangling
> changes. If we agree on the module and its name, I'd like to create it on
> Monday and import a clean org.springframework version. Then we should test
> that with current apps, and if everything succeeds, we should be able to
> publish the release at the end of the week.
>

Once you change the package name, I'll make sure the 'Step-by-step-MVC' guide 
is up to date.

  
Thomas

Re: [Springframework-developer] Current release plan - why delay package renaming?

[<jue...@we...>]

SGkgZXZlcnlib2R5LA0KIA0KV293LCB0aGVyZSBzZWVtcyB0byBiZSBhbiBvdmVyd2hlbG1pbmcg
Y29uc2Vuc3VzIHRvIGNoYW5nZSB0aGUgcGFja2FnZSBuYW1lcyBub3cuIFdlbGwsIHRoZW4gbGV0
IHRoZXJlIGJlIG9yZy5zcHJpbmdmcmFtZXdvcmsgOi0pIFRoZSByZWFzb25pbmcgYmVoaW5kIGRl
bGF5aW5nIHRoaXMgdG8gMS4wIFJDIGluaXRpYWxseSB3YXMgdG8ga2VlcCBjb25zaXN0ZW5jeSBm
b3IgY3VycmVudCB1c2Vycy4gT24gdGhlIG90aGVyIGhhbmQsIHRoZXJlJ3MgdGhlIHN0cm9uZyBh
cmd1bWVudCBvZiBhIGdyb3dpbmcgdXNlciBiYXNlOiBBbiBlYXJseSBjaGFuZ2Ugd2lsbCBhZmZl
Y3QgbGVzcyBwZW9wbGUuDQogDQpPZiBjb3Vyc2Ugd2UgY2FuIHN0aWxsIGtlZXAgMC45LjEgYXMg
bmV4dCB2ZXJzaW9uIG51bWJlci4gQ2FsbGluZyBvdXIgY3VycmVudCBzdGF0dXMgMS4wIGJldGEx
IHdvdWxkbid0IGJlIGFic3VyZCB0aG91Z2gsIGp1c3QgbG9vayBhdCBhdCB0aGUgZWFnZXIgcmVs
ZWFzZSBwb2xpY2llcyBvZiBKYWthcnRhIG9yIEhpYmVybmF0ZS4gTm90ZSB0aGF0IGZvciBhbnkg
c3Vic2VxdWVudCB2ZXJzaW9uIGxpa2UgMi4wIHRoZXJlIHdpbGwgb25seSBiZSB0aGUgYmV0YS9S
Qy1vcHRpb24uIFNvLCBvcGluaW9uIHBvbGw6IHN0YXkgd2l0aCAwLjkuMSBvciBlYWdlcmx5IG1v
dmUgdG8gMS4wIGJldGExIG5vdz8gSSdtIGluY2xpbmVkIHRvIGdvIGZvciB0aGUgbGF0dGVyLg0K
IA0KQlRXLCB3aGF0IGRvZXMgZXZlcnlib2R5IHRoaW5rIHJlZ2FyZGluZyBhIG5ldyBDVlMgbW9k
dWxlICJtYWluMSIvIm1haW4xMCIsIG9yICJzcHJpbmcxIi8ic3ByaW5nMTAiLCBvciB0aGUgbGlr
ZT8gVGhlIEhpYmVybmF0ZSB0ZWFtIHdvcmtzIHdpdGggYSAiaGliZXJuYXRlMiIgbW9kdWxlIGN1
cnJlbnRseSwgaGF2aW5nIHRoZSAxLjAgdHJlZSBpbiAiaGliZXJuYXRlIiwgc28gY3JlYXRpbmcg
YSBuZXcgbW9kdWxlIHNlZW1zIGFwcHJvcHJpYXRlIHRvIG1lLg0KIA0KVG8gYXZvaWQgdW5uZWNl
c3NhcnkgZnVydGhlciBkZWxheXMsIEkgdXJnZSBldmVyeWJvZHkgdG8gY29tbWl0IGFsbCBkYW5n
bGluZyBjaGFuZ2VzLiBJZiB3ZSBhZ3JlZSBvbiB0aGUgbW9kdWxlIGFuZCBpdHMgbmFtZSwgSSdk
IGxpa2UgdG8gY3JlYXRlIGl0IG9uIE1vbmRheSBhbmQgaW1wb3J0IGEgY2xlYW4gb3JnLnNwcmlu
Z2ZyYW1ld29yayB2ZXJzaW9uLiBUaGVuIHdlIHNob3VsZCB0ZXN0IHRoYXQgd2l0aCBjdXJyZW50
IGFwcHMsIGFuZCBpZiBldmVyeXRoaW5nIHN1Y2NlZWRzLCB3ZSBzaG91bGQgYmUgYWJsZSB0byBw
dWJsaXNoIHRoZSByZWxlYXNlIGF0IHRoZSBlbmQgb2YgdGhlIHdlZWsuDQogDQpSZWdhcmRpbmcg
cmVsZWFzZSBub3RlcyBmb3IgY2hhbmdlcyBzaW5jZSAwLjk6IEknbGwgdHJ5IHRvIGNvbGxlY3Qg
dGhlbSBmcm9tIHRoZSBtYWlsaW5nIGxpc3QsIHRoZXJlIGlzIHF1aXRlIGEgbnVtYmVyIG9mIHRo
ZW0gYWN0dWFsbHkuDQogDQpJJ2QgYWxzbyBsaWtlIHRvIG1ha2UgdXAgYSBjb25jcmV0ZSByZWxl
YXNlIHBsYW4gZm9yIHRoZSBmb2xsb3ctdXAsIGJlIGl0IDAuOS4yIG9yIDEuMCBiZXRhMiwgd2l0
aCBhbiBhcHByb3hpbWF0ZSB0aW1lZnJhbWUgLSBwcm9iYWJseSBiZWdpbm5pbmcgb2YgU2VwdGVt
YmVyLiBPYnZpb3VzIGNhbmRpZGF0ZXMgYXJlOg0KIA0KLSBSZXN1bHRTZXRzIGZyb20gc3RvcmVk
IHByb2NlZHVyZXM7DQotIFRpbGVzIGludGVncmF0aW9uOw0KLSBhZHZhbmNlZCBQcm9wZXJ0eUVk
aXRvciBzdXBwb3J0IGZvciBKU1BzOw0KLSBjb21wYXRpYmlsaXR5IHRlc3Rpbmc7DQotIHBvbGlz
aGVkIHNhbXBsZSBhcHBzOw0KLSB2ZXJ5IGltcG9ydGFudDogZG9jdW1lbnRhdGlvbiBhbmQgdHV0
b3JpYWxzLg0KIA0KSSBndWVzcyB0aGF0IHN0dWZmIGxpa2UgbWV0YWRhdGEgYXR0cmlidXRlcyBk
cml2aW5nIEFPUCBpbnRlcmNlcHRvcnMgd2lsbCBiZSBiZXlvbmQgdGhhdCB0aW1lZnJhbWUuIEJ1
dCB3ZSBkb24ndCBuZWVkIHRvIGNyYW0gZXZlcnl0aGluZyBpbnRvIHRoaXMgZm9sbG93LXVwOiAx
LjAgUkMxIGluIGVhcmx5IE9jdG9iZXIgd2lsbCBiZSBhIGZpbmUgbWlsZXN0b25lIHRvby4gSXQg
d291bGQgZ2VuZXJhbGx5IGJlIGdvb2QgdG8gcHVibGlzaCBvbmUgcmVsZWFzZSBwZXIgbW9udGgg
dG93YXJkcyAxLjAuDQogDQpGaW5hbGx5LCByZWdhcmRpbmcgdGhlIHNjb3BlIG9mIDEuMCBmaW5h
bDogSSBzdGlsbCB2b3RlIGZvciBkZWxheWluZyBKTVMgYW5kIFdlYiBTZXJ2aWNlcyBzdXBwb3J0
IHVudGlsIDEuMSwgdG8gYmUgYWJsZSB0byBzdGFiaWxpemUgYW5kIHBvbGlzaCB0aGUgY3VycmVu
dCBmZWF0dXJlcyBhcyBtdWNoIGFzIHBvc3NpYmxlIGZvciAxLjAuIFRoZSBzYW1lIGFwcGxpZXMg
dG8gc3R1ZmYgbGlrZSBUb3BMaW5rIHN1cHBvcnQgb3IgSlNSLTE2OCBQb3J0bGV0cy4gV2UgY2Fu
IHN0aWxsIGRlY2lkZSB0byBmb2N1cyBvbiBjZXJ0YWluIGZlYXR1cmVzIGVhcmxpZXIgaWYgY3Vy
cmVudCBuZWVkcyBhcmlzZSwgb2YgY291cnNlLg0KIA0KUmVnYXJkcywNCkp1ZXJnZW4NCiANCiAN
Cg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBUcmV2b3IgQ29v
ayBbbWFpbHRvOnByaXNlMDNAc2VudGV4Lm5ldF0gDQoJR2VzZW5kZXQ6IEZyIDAxLjA4LjIwMDMg
MTg6MDkgDQoJQW46IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2Uu
bmV0IA0KCUNjOiANCglCZXRyZWZmOiBSRTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIEN1
cnJlbnQgcmVsZWFzZSBwbGFuIC0gd2h5IGRlbGF5IHBhY2thZ2UgcmVuYW1pbmc/DQoJDQoJDQoN
CglDaGFuZ2luZyBpdCBub3cgd291bGQgYmUgYmV0dGVyIGZvciBtZSwgYnV0IEkgY2FuIHdvcmsg
d2l0aCBlaXRoZXIgbmFtZSAobXkgbWFpbiBwcm9ibGVtIHdhcyB0aGUgcHVibGljIGFwaSB3aGlj
aCBhIHNlYXJjaC9yZXBsYWNlIHdvbid0IHNvbHZlIDopICkuICBJIHdvdWxkIHZvdGUgKzEgdG8g
ZG8gaXQgbm93LCBidXQgSSBkb24ndCBrbm93IHRoZSByZWFzb25zIGZvciB0aGUgZGVsYXkgdG8g
UkMxLiAgVG8gdGhvc2Ugd2hvIGtub3cgKEp1ZXJnZW4vUm9kPyksIGlzIHRoZXJlIGEgdGVjaG5p
Y2FsIHJlYXNvbiBmb3IgdGhlIGRlbGF5LCBvciBqdXN0IHRoZSByZWxlYXNlIHBsYW4/DQoJDQoJ
VHJldm9yIEQuIENvb2sNCg0K

Re: [Springframework-developer] equals/hashCode for entities

[Colin S. <col...@ex...>]

I was discussing this option with somebody the other day. You actually 
don't necessarilly need to hit the db for each new object id. You could 
use the standard hi-lo or variation of technique, where a sequence 
provides the low word and then the high word comes from  in memory, from 
some sort of singleton. So you end up hitting the db on only every 100 
ids, etc.  Of course, this does mean that there are all sorts of holes 
in your ids, and large values. As you say, there is the disadvantage 
that a tier that is disconnected from the db can no longer use this 
technique (although potentially that tier could ask for a bunch of ids 
from the remote tier).

The other disadvantage for Hibernate use would be that you would no 
longer have a distinguising unsaved entity id value, since there would 
be a valid id in the entity. The only way I can think to get around this 
and still use saveOrUpdate, is to use a Hibernate Interceptor, and use 
another property in the entity which says whether it is saved or not. I 
already use this for an entity with a composite id key, so it's a 
workable solution.


Timo Verhoeven wrote:

>Hi!
>
>I think I know another safe solution... which has its own drawbacks, of 
>course:
>
>Given I want to use native db sequences and I use DAOs in my app-design, 
>I could disallow access to all domain objects' (objects to be 
>persisted) constructors and insert a 'newInstance' method for each 
>domain object in a/the DAO. This 'newInstance' method would call the 
>constructor, then access the native db sequence for the next value, 
>change the id in the newly created instance, and return that instance. 
>As far as I see it, this should "do it".
>
>Drawbacks: 
>- You can no longer create new domain object instances easily outside 
>your app (/appserver), say in a remote Client accessing your EJB-app.
>- Each and every domain object instance now needs one additional db 
>access at instantiation time.
>- There will be "holes" in your database tables when you look at the id 
>sequences when you create a domain object instance that will be dropped 
>without persisting it.
>- I'm not sure if the special m:n is handled correctly....
>- Using autoincrement columns with this approach might not be as easy as 
>using sequences.
>
>Have I missed something? Opinions?
>
>
>Regards,
>
>Timo
>
>Am Freitag, 1. August 2003 19:51 schrieb Colin Sampaleanu:
>  
>
>>I started a thread on there actually, but unfortunately I couldn't
>>get Gavin to agree that it is worth enhancing Hibernate to support
>>dynamic rehashing of the changed element in the Set on the id change,
>>which I think is what is really needed...
>>
>>http://sourceforge.net/forum/forum.php?thread_id=909482&forum_id=1286
>>38
>>
>>Timo Verhoeven wrote:
>>    
>>
>>>Hi!
>>>
>>>It might be a good idea to discuss these issues on the hibernate
>>>forums/mailing lists. I could imagine, there are others who had
>>>these problems before.
>>>
>>>
>>>Regards,
>>>
>>>Timo
>>>
>>>Am Dienstag, 29. Juli 2003 17:18 schrieb Colin Sampaleanu:
>>>      
>>>
>>>>jürgen höller [werk3AT] wrote:
>>>>        
>>>>
>>>>><quote>
>>>>>So, we make a hashCode with some smarts. First time hashcode is
>>>>>called, - if id is null/zero, then hashCode will forever return
>>>>>the same value, which is the same for all class instances.
>>>>>Inefficient, but doesn't cause Sets to barf.
>>>>>- but if is not-null/zero and hashCode has never been called while
>>>>>id was null/zero, then hashCode will retun a value based on the
>>>>>id. This means that loaded entities loaded form the db are
>>>>>treated efficiently.
>>>>>
>>>>>Still not that great in terms of efficiency for new entities, but
>>>>>efficient for old entities.
>>>>></quote>
>>>>>
>>>>>Interesting idea - a hashCode implementation that tracks if it has
>>>>>already been called with an empty ID... So "contains" and "remove"
>>>>>will work even after saving, but unfortunately only for this very
>>>>>instance. Calling "contains" with a freshly loaded instance (and
>>>>>the previously saved one in the collection) will still fail, as
>>>>>the freshly loaded instance will return an ID-based hash code
>>>>>that will not match the one in the collection.
>>>>>          
>>>>>
>>>>Hmm, I think your point shows that this technique is somewhat
>>>>dangerous. I think it might break Hibernate's saveOrUpdate
>>>>functionality in some cases. You can not have a new object which is
>>>>added to a session (therefore it had an empty id and was added as
>>>>such to the collection, and then come along with a transient
>>>>version of the same object (which was built up in a different
>>>>order (ie not added to a collection before the id was set), coming
>>>>in as a child in a collection inside a parent object, and call
>>>>saveOrUpdate reliably. That is, Hibernate would know if the object
>>>>needs to be saved or updated ok, but on an update would not be
>>>>able to get the same initial instance to update.
>>>>
>>>>bummer...
>>>>
>>>>        
>>>>
>>>>><quote>
>>>>>Also, there is still an issue with any collection (ie not HashSet)
>>>>>that uses 'equals', since that is going to change when the id
>>>>>changes. </quote>
>>>>>
>>>>>But that doesn't matter as such a collection will just call
>>>>>"equals" on *lookup*, not on *addition*. It will always find an
>>>>>entity, as long as "equals" can deal with the current state.
>>>>>That's not the case with HashSet: The hash code of an object is
>>>>>determined within the "add" method, and fixed from there on.
>>>>>
>>>>>Juergen
>>>>>          
>>>>>
>>-------------------------------------------------------
>>This SF.Net email sponsored by: Free pre-built ASP.NET sites
>>including Data Reports, E-commerce, Portals, and Forums are available
>>now. Download today and enter to win an XBOX or Visual Studio .NET.
>>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303
>>_01/01 _______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-develope
>>r
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] equals/hashCode for entities

[Timo V. <sic...@gm...>]

Hi!

I think I know another safe solution... which has its own drawbacks, of=20
course:

Given I want to use native db sequences and I use DAOs in my app-design,=20
I could disallow access to all domain objects' (objects to be=20
persisted) constructors and insert a 'newInstance' method for each=20
domain object in a/the DAO. This 'newInstance' method would call the=20
constructor, then access the native db sequence for the next value,=20
change the id in the newly created instance, and return that instance.=20
As far as I see it, this should "do it".

Drawbacks:=20
=2D You can no longer create new domain object instances easily outside=20
your app (/appserver), say in a remote Client accessing your EJB-app.
=2D Each and every domain object instance now needs one additional db=20
access at instantiation time.
=2D There will be "holes" in your database tables when you look at the id=20
sequences when you create a domain object instance that will be dropped=20
without persisting it.
=2D I'm not sure if the special m:n is handled correctly....
=2D Using autoincrement columns with this approach might not be as easy as=
=20
using sequences.

Have I missed something? Opinions?


Regards,

Timo

Am Freitag, 1. August 2003 19:51 schrieb Colin Sampaleanu:
> I started a thread on there actually, but unfortunately I couldn't
> get Gavin to agree that it is worth enhancing Hibernate to support
> dynamic rehashing of the changed element in the Set on the id change,
> which I think is what is really needed...
>
> http://sourceforge.net/forum/forum.php?thread_id=3D909482&forum_id=3D1286
>38
>
> Timo Verhoeven wrote:
> >Hi!
> >
> >It might be a good idea to discuss these issues on the hibernate
> >forums/mailing lists. I could imagine, there are others who had
> > these problems before.
> >
> >
> >Regards,
> >
> >Timo
> >
> >Am Dienstag, 29. Juli 2003 17:18 schrieb Colin Sampaleanu:
> >>j=FCrgen h=F6ller [werk3AT] wrote:
> >>><quote>
> >>>So, we make a hashCode with some smarts. First time hashcode is
> >>>called, - if id is null/zero, then hashCode will forever return
> >>> the same value, which is the same for all class instances.
> >>> Inefficient, but doesn't cause Sets to barf.
> >>>- but if is not-null/zero and hashCode has never been called while
> >>>id was null/zero, then hashCode will retun a value based on the
> >>> id. This means that loaded entities loaded form the db are
> >>> treated efficiently.
> >>>
> >>>Still not that great in terms of efficiency for new entities, but
> >>>efficient for old entities.
> >>></quote>
> >>>
> >>>Interesting idea - a hashCode implementation that tracks if it has
> >>>already been called with an empty ID... So "contains" and "remove"
> >>>will work even after saving, but unfortunately only for this very
> >>>instance. Calling "contains" with a freshly loaded instance (and
> >>>the previously saved one in the collection) will still fail, as
> >>> the freshly loaded instance will return an ID-based hash code
> >>> that will not match the one in the collection.
> >>
> >>Hmm, I think your point shows that this technique is somewhat
> >>dangerous. I think it might break Hibernate's saveOrUpdate
> >>functionality in some cases. You can not have a new object which is
> >>added to a session (therefore it had an empty id and was added as
> >>such to the collection, and then come along with a transient
> >> version of the same object (which was built up in a different
> >> order (ie not added to a collection before the id was set), coming
> >> in as a child in a collection inside a parent object, and call
> >> saveOrUpdate reliably. That is, Hibernate would know if the object
> >> needs to be saved or updated ok, but on an update would not be
> >> able to get the same initial instance to update.
> >>
> >>bummer...
> >>
> >>><quote>
> >>>Also, there is still an issue with any collection (ie not HashSet)
> >>>that uses 'equals', since that is going to change when the id
> >>>changes. </quote>
> >>>
> >>>But that doesn't matter as such a collection will just call
> >>> "equals" on *lookup*, not on *addition*. It will always find an
> >>> entity, as long as "equals" can deal with the current state.
> >>> That's not the case with HashSet: The hash code of an object is
> >>> determined within the "add" method, and fixed from there on.
> >>>
> >>>Juergen
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites
> including Data Reports, E-commerce, Portals, and Forums are available
> now. Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303
>_01/01 _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-develope
>r

Re: [Springframework-developer] petclinic, hsqldb, & jboss

[Rajeev K. <Ra...@cu...>]

Jean-Pierre,

I found out that "MessageCache" error turned out to be a JBOSS =
configuration issue.  The JBOSS 3.2.1 ships out with recursivesearch =
attribute (in jboss-service.xml) set to false as shown below:

<attribute name=3D"RecursiveSearch">False</attribute>

This should be changed to true as show below:

<attribute name=3D"RecursiveSearch">True</attribute>

Now the petclinic sample works fine under JBOSS. =20

It may be obvious that when running under a managed environment like =
JBOSS, the application-context.xml should be modified to comment the =
datasource for non-J2ee environment, and uncomment the datasource for =
J2EE environment.  But I think it should be clearly mentioned as one of =
the steps required to make the sample app to work under JBOSS.

Rajeev Kaul
  ----- Original Message -----=20
  From: Jean-Pierre=20
  To: 'Rajeev Kaul' ; spr...@li...=20
  Sent: Tuesday, July 29, 2003 1:20 PM
  Subject: RE : [Springframework-developer] petclinic, hsqldb, & jboss


  Rajeev,



  >>> One more thing.  There is no need to comment out the log4j =
configuration listener for spring samples running under JBOSS.  Just use =
the attached log4j.properties file.



  I tested your log4j file, but it's no miracle. It is carefully written =
to well start. Unfortunately, the issue rests when undeploying the =
application: all JBoss logging are definitively stopped. The server =
itself can go wrong in this case, but it's not the case with your log4j =
file. It seems it's the best possible, but I believe like others that =
with JBoss the logging is better set in JBoss configuration files. =20

  So I will provide your file but let the note for commenting out the =
listener.



  >>> I actually used the jboss supplied hsqldb-ds.xml file instead of =
hsql-petclinic-ds.xml.  I modified the petclinic build.properties to use =
the port 1701 for hsql, and the jboss-web.xml to use the =
"java:/DefaultDS" as the jndi name.  This eliminates the step of having =
to copy a separate hsql-petclinic-ds.xml file in the Jboss deploy dir. =
The petclinic application works fine with this setting.  However, I am =
still getting the JBOSS "MessageCache" error.



  Yes, your proposal simplifies the installation by the use of =
DefaultDS. Just as you made, the port must be set to 1701 in =
build.properties. I will make changes.



  For the "MessageCache" error, we will certainly have to live with for =
the 0.9.1. I have no more time to fix in time.



  Regards,

  Jean-Pierre

Re: [Springframework-developer] Current release plan - why delay package renaming?

[Ken K. <kk...@kk...>]

+1 for doing it now.

Ken

>----- Original Message -----
>From: <rod...@in...>
>To: "Colin Sampaleanu" <col...@ex...>
>Cc: "jürgen höller [werk3AT]" <jue...@we...>;
><spr...@li...>;
><rod...@in...>
>Sent: Friday, August 01, 2003 8:55 AM
>Subject: Re: [Springframework-developer] Current release plan - why delay
>package renaming?
>
>
>  
>
>>>I wanted to play the devil's advocate and suggest that the
>>>      
>>>
>>package
>>renaming be done now instead of later.  I understand that the
>>main issue
>>is that it takes a while to do it through SourceForge in
>>terms of
>>hanlding the CVS dirs on the server itself. However, the
>>possibility of
>>just doing a checkin to the new location has already been
>>mentioned and
>>would be very easy. Of course the history for files would
>>still be
>>available at the old location.
>>
>>I think this deserves serious consideration, although we
>>previously agreed the RC1 timeframe. Let's vote on it. I vote
>>for switching now, although I'm open to good counter-
>>arguments.
>>
>>Another advantage of the new location approach is that we
>>don't need to delay things by waiting for SourceForge to do
>>anything.
>>
>>Regards,
>>Rod
>>
>>
>>    
>>

Re: [Springframework-developer] equals/hashCode for entities

[Colin S. <col...@ex...>]

I started a thread on there actually, but unfortunately I couldn't get 
Gavin to agree that it is worth enhancing Hibernate to support dynamic 
rehashing of the changed element in the Set on the id change, which I 
think is what is really needed...

http://sourceforge.net/forum/forum.php?thread_id=909482&forum_id=128638


Timo Verhoeven wrote:

>Hi!
>
>It might be a good idea to discuss these issues on the hibernate 
>forums/mailing lists. I could imagine, there are others who had these 
>problems before.
>
>
>Regards,
>
>Timo
>
>Am Dienstag, 29. Juli 2003 17:18 schrieb Colin Sampaleanu:
>  
>
>>jürgen höller [werk3AT] wrote:
>>    
>>
>>><quote>
>>>So, we make a hashCode with some smarts. First time hashcode is
>>>called, - if id is null/zero, then hashCode will forever return the
>>>same value, which is the same for all class instances. Inefficient,
>>>but doesn't cause Sets to barf.
>>>- but if is not-null/zero and hashCode has never been called while
>>>id was null/zero, then hashCode will retun a value based on the id.
>>>This means that loaded entities loaded form the db are treated
>>>efficiently.
>>>
>>>Still not that great in terms of efficiency for new entities, but
>>>efficient for old entities.
>>></quote>
>>>
>>>Interesting idea - a hashCode implementation that tracks if it has
>>>already been called with an empty ID... So "contains" and "remove"
>>>will work even after saving, but unfortunately only for this very
>>>instance. Calling "contains" with a freshly loaded instance (and
>>>the previously saved one in the collection) will still fail, as the
>>>freshly loaded instance will return an ID-based hash code that will
>>>not match the one in the collection.
>>>      
>>>
>>Hmm, I think your point shows that this technique is somewhat
>>dangerous. I think it might break Hibernate's saveOrUpdate
>>functionality in some cases. You can not have a new object which is
>>added to a session (therefore it had an empty id and was added as
>>such to the collection, and then come along with a transient version
>>of the same object (which was built up in a different order (ie not
>>added to a collection before the id was set), coming in as a child 
>>in a collection inside a parent object, and call saveOrUpdate
>>reliably. That is, Hibernate would know if the object needs to be
>>saved or updated ok, but on an update would not be able to get the
>>same initial instance to update.
>>
>>bummer...
>>
>>    
>>
>>><quote>
>>>Also, there is still an issue with any collection (ie not HashSet)
>>>that uses 'equals', since that is going to change when the id
>>>changes. </quote>
>>>
>>>But that doesn't matter as such a collection will just call "equals"
>>>on *lookup*, not on *addition*. It will always find an entity, as
>>>long as "equals" can deal with the current state. That's not the
>>>case with HashSet: The hash code of an object is determined within
>>>the "add" method, and fixed from there on.
>>>
>>>Juergen
>>>      
>>>