springframework-developer — Spring Framework developers list

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

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

Rod & All,

> 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.
> 

+1 for doing it now.

Thomas

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

[Kopylenko, D. <dko...@ac...>]

+1 for switching now

-----Original Message-----
From: rod...@in... [mailto:rod...@in...]=20
Sent: Friday, August 01, 2003 11:55 AM
To: Colin Sampaleanu
Cc: j=FCrgen h=F6ller [werk3AT];
spr...@li...; =
rod...@in...
Subject: Re: [Springframework-developer] Current release plan - why =
delay
package renaming?


>I wanted to play the devil's advocate and suggest that the
package=20
renaming be done now instead of later.  I understand that the=20
main issue=20
is that it takes a while to do it through SourceForge in=20
terms of=20
hanlding the CVS dirs on the server itself. However, the=20
possibility of=20
just doing a checkin to the new location has already been=20
mentioned and=20
would be very easy. Of course the history for files would=20
still be=20
available at the old location.=20

I think this deserves serious consideration, although we=20
previously agreed the RC1 timeframe. Let's vote on it. I vote=20
for switching now, although I'm open to good counter- arguments.

Another advantage of the new location approach is that we=20
don't need to delay things by waiting for SourceForge to do=20
anything.

Regards,
Rod


-------------------------------------------------------
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!

It might be a good idea to discuss these issues on the hibernate=20
forums/mailing lists. I could imagine, there are others who had these=20
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=20
> 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_0723
> >03_01/01 _______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-develop
> >er
>
> -------------------------------------------------------
> 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] Current release plan

[Tarjei S. <lo...@on...>]

On Wed, Jul 30, 2003 at 10:41:04PM +0200, Alef Arendsen (JTeam) wrote:
[..]
> As far as additions to the MVC are concerned, I don't think much is
> needed to be able to build a decent webapp. Anybody interested in
> getting the TilesView(Resolver) in before the 1.0 release (might be a
> nice feature to show the pluggability and stuff)??

I'm very interested in getting at least TilesView in before 1.0. I'm
using Tiles myself for most of my own personal projects and I find it
highly useful. I've spent some time lately looking at the TilesView and
TilesViewResolver you posted a couple of weeks ago. TilesView seemed to
work quite ok, definitely something that could be included in Spring
imho :)

When it comes to the TilesViewResolver I'm not quite so sure, it doesn't
seem quite right in my opinion. I would much rather see an aproach like
the one we currently have for Velocity. The TilesViewResolver you posted
didn't really do anything specifically related to resolving the view, 
it more or less just took care of initializing the DefinitionsFactory for 
Tiles. 

I'd like to propose that TilesViewResolver should be renamed to
something like TilesConfigurer. TilesConfigurer would just be a simple
javabean that takes care of initializing Tiles, just like
VelocityConfigurer currently does for Velocity. TilesView would be
pretty much the same as before, maybe we could add a definitionName
property that gives the user a possibility to not use the view name as
the definition name all of the time. We could default to using the
viewname as the definitionname to minimize the need for aditional 
configration for each TilesView but allow the developers out there to 
override it if needed.

--
Tarjei Skorgenes
lo...@on...

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

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

+1
----- Original Message -----
From: <rod...@in...>
To: "Colin Sampaleanu" <col...@ex...>
Cc: "j=C3=BCrgen h=C3=B6ller [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
>
>
> -------------------------------------------------------
> 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...>]

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?

Trevor D. Cook


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: August 1, 2003 11:47 AM
To: j=C3=BCrgen h=C3=B6ller [werk3AT];
spr...@li...;
rod...@in...
Subject: Re: [Springframework-developer] Current release plan - why
delay package renaming?


I wanted to play the devil's advocate and suggest that the package=20
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=20
hanlding the CVS dirs on the server itself. However, the possibility of=20
just doing a checkin to the new location has already been mentioned and=20
would be very easy. Of course the history for files would still be=20
available at the old location.

Spring really seems to be getting a lot of momentum lately. I think it's =

really good stuff and most people who look at it seem to agree :-)   So=20
I think a package name now will potentially affect a _lot_ less people=20
than one later.  I know in our case, we have a pretty big project which=20
has started using Spring. In about a week, we need to do a big branch.=20
If both branches need to have Spring packages updated it will complicate =

the merge later. I think other people will have this sort of issue.

Another consideration is that 0.9.1 (as I understand it) introduces at=20
least a few non-backwards compatible changes. Doing the package rename=20
now would maybe make it possible for subsequent releases to remain=20
backwards compatible.

Regards,
Colin

j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:

>Everybody,
>
>As I just wrote in the reply to Alef's "PropertyEditors in JSPs" =
suggestion, we will very likely release a 0.9.2 at the end of August, =
with further polishing and enhancements.
>
>FYI, I'll be travelling to Australia for the whole of September, so I'd =
prefer to get 0.9.2 out before that, and our first org.springframework =
1.0 RC right after my return. Is a 1.0 RC1 target at the beginning of =
October fine for everybody? I hope it's not too late, but we will need =
the time anyway for documentation and all that stuff. 1.0 final could be =
possible in November then.
>
>BTW, we don't *need* to make SourceForge change our CVS directories to =
apply the package name change. We could also keep the current "main" =
module as it is, including all its version history, and introduce a new =
"main10" module with a fresh import of an org.springframework version. =
This would also make sense in terms of dead directories that a CVS =
update always traverses: There wouldn't be any then.
>
>Juergen
>
>
>-----Original Message-----
>From: j=C3=BCrgen h=C3=B6ller [werk3AT]=20
>Sent: Wednesday, July 30, 2003 11:34 PM
>To: pr...@se...; Spring Developers
>Subject: Re: [Springframework-developer] Current release plan
>
>
>Hi Trevor,
>=20
>First of all, good questions resp. important ones indeed!
>=20
><quote>
>1. What still needs to be done for 0.9.1.  From that list, what is =
currently
>"assigned" to someone and what still needs help?
></quote>
>=20
>Not a lot, actually. It's mainly about polishing the Petclinic and =
Countries sample apps, and testing the current codebase in everyone's =
own projects. Everything should be assigned so far, except the latter of =
course :-)
>=20
>I'm currently polishing a lot of the source code. I've also added 2 new =
features that aren't committed yet but will be by the end of this week, =
namely Hibernate flush mode support on HibernateTemplate and =
HibernateInterceptor, and read-only transactions (suppressing Hibernate =
flush on the transaction level). Furthermore, I've refined =
TransactionInterceptor and MapTransactionAttributeSource a bit, =
supporting more configuration options then before.
>=20
><quote>
>2. Same as #1 but for the 1.0 release.
></quote>
>
>The first 1.0 RC will involve a package name change from =
com.interface21 to org.springframework. Besides that, there won't be a =
lot in terms of new features -maybe even less than from 0.9 to 0.9.1. =
Rod might already introduce some source-level attribute stuff to the AOP =
framework, but that isn't a requirement at all. Proper JMS and Web =
Service support are candidates too but can easily wait until 1.1.
>=20
><quote>
>3. What is the target time-frame for the 0.9.1 and 1.0 releases =
(obviously
>this is sketchy since it's "volunteer" work, but "gut guesses" - =
probably
>from Juergen :) - based on work left is what I'm hoping for.  The =
previous
>estimate was the 1.0RC1 by now.
></quote>
>=20
>0.9.1 should be out any day now. I encourage everyone to try it the =
current CVS version before the weekend. A release some time next week =
should really be achievable. We *need* to get out a follow-up release =
quickly, if just because of all the enhancements to the Hibernate =
support that have a good chance of getting adopted promptly. My =
Hibernate article in the community area and my postings to the Hibernate =
forum have already been discussing some of them for a while.
>
><quote>
>4. From Juergen's email which I referenced, it states "As far as I see, =
we
>don't need additional functionality for 1.0".  The main thing holding =
me
>back from adopting the current code base (I'm currently using a
>personally-modified version of 0.8) is the amount and frequency of =
changes
>to core functionality and the public api.  Some new features or minor =
bug
>fixes are ok/normal, but these sweeping changes are destructive to
>production code.  How close are we to finalizing the public api and the =
core
>code?  Is it likely that these major changes should be done for 0.9.1?
></quote>
>=20
>Maybe I'm promising too much, but I don't see any major changes on the =
horizon. The introduction of the new DTD was probably the biggest change =
in the last few months, everything else was just about slight changes to =
the public API. I agree that we need stable APIs though to allow =
production apps to rely on them without *any* hassle. 0.9.1 should be as =
stable as can be in that respect, besides the package name change for =
1.0 RC which should just involve a search-and-replace.
>
><quote>
>To expand on my fourth question with a recommendation (hopefully it =
makes
>sense to everyone).  If possible we should finalize the public api for
>version 0.9.1 rather than at the 1.0RC1.  This will allow usage in new
>development without fear of incompatibilities in the next couple =
months. (...)
></quote>
>=20
>As I indicated above, I fully agree. We've been changing our apps at =
werk3AT quite often too, it would be fine it that wouldn't be necessary =
anymore as soon as possible. And I'd really like to get you on board =
again, in terms of working with a current Spring version :-)
>=20
>Regards,
>Juergen
>N=18HS^=E9=9A=8A[){([Zzn=E8=A5=B4=044D=D7=ACw%=D8=A76i=17l=11&x+ljwEjzz0=
=0E'Z=C9=A9z{^0v\=13bJ=DB=9DDN=1Bm=DA=B2=DE=B5brK&
>?=C6=B4]4M=DA=BD=DD=8AZ=DE=B7NM5J=07jg=1Dzx%R=DA=99(G^hlq=07zm?X(=1E~zwX=
b?=07jg=1Dz
>N=18?HS^?=E9=9A=8A[)?{(??[?Z?z??n=E8=A5=B4=04?4D?=D7=AC?w%?=D8=A7?6?i=17=
???l=11?&???x?+??ljwE??????j??zz0=0E?'?????Z=C9=A9?z{^??0?v?\=13???b??J=DB=
=9D??DN=1Bm??=DA=B2?=DE=B5?brK???&?
>??=C6=B4?]4?M=DA=BD?=DD=8A????Z??=DE=B7N??M???5J??=07?jg???=1Dz??????x%?=
?R?????=DA=99?(?G^??h????l???q??=07?z?m????X???(??=1E~??zw??X?????b??????=
=07?jg???=1Dz??
>




-------------------------------------------------------
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?

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

>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] Current release plan - why delay package renaming?

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

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.

Spring really seems to be getting a lot of momentum lately. I think it's 
really good stuff and most people who look at it seem to agree :-)   So 
I think a package name now will potentially affect a _lot_ less people 
than one later.  I know in our case, we have a pretty big project which 
has started using Spring. In about a week, we need to do a big branch. 
If both branches need to have Spring packages updated it will complicate 
the merge later. I think other people will have this sort of issue.

Another consideration is that 0.9.1 (as I understand it) introduces at 
least a few non-backwards compatible changes. Doing the package rename 
now would maybe make it possible for subsequent releases to remain 
backwards compatible.

Regards,
Colin

jürgen höller [werk3AT] wrote:

>Everybody,
>
>As I just wrote in the reply to Alef's "PropertyEditors in JSPs" suggestion, we will very likely release a 0.9.2 at the end of August, with further polishing and enhancements.
>
>FYI, I'll be travelling to Australia for the whole of September, so I'd prefer to get 0.9.2 out before that, and our first org.springframework 1.0 RC right after my return. Is a 1.0 RC1 target at the beginning of October fine for everybody? I hope it's not too late, but we will need the time anyway for documentation and all that stuff. 1.0 final could be possible in November then.
>
>BTW, we don't *need* to make SourceForge change our CVS directories to apply the package name change. We could also keep the current "main" module as it is, including all its version history, and introduce a new "main10" module with a fresh import of an org.springframework version. This would also make sense in terms of dead directories that a CVS update always traverses: There wouldn't be any then.
>
>Juergen
>
>
>-----Original Message-----
>From: jürgen höller [werk3AT] 
>Sent: Wednesday, July 30, 2003 11:34 PM
>To: pr...@se...; Spring Developers
>Subject: Re: [Springframework-developer] Current release plan
>
>
>Hi Trevor,
> 
>First of all, good questions resp. important ones indeed!
> 
><quote>
>1. What still needs to be done for 0.9.1.  From that list, what is currently
>"assigned" to someone and what still needs help?
></quote>
> 
>Not a lot, actually. It's mainly about polishing the Petclinic and Countries sample apps, and testing the current codebase in everyone's own projects. Everything should be assigned so far, except the latter of course :-)
> 
>I'm currently polishing a lot of the source code. I've also added 2 new features that aren't committed yet but will be by the end of this week, namely Hibernate flush mode support on HibernateTemplate and HibernateInterceptor, and read-only transactions (suppressing Hibernate flush on the transaction level). Furthermore, I've refined TransactionInterceptor and MapTransactionAttributeSource a bit, supporting more configuration options then before.
> 
><quote>
>2. Same as #1 but for the 1.0 release.
></quote>
>
>The first 1.0 RC will involve a package name change from com.interface21 to org.springframework. Besides that, there won't be a lot in terms of new features -maybe even less than from 0.9 to 0.9.1. Rod might already introduce some source-level attribute stuff to the AOP framework, but that isn't a requirement at all. Proper JMS and Web Service support are candidates too but can easily wait until 1.1.
> 
><quote>
>3. What is the target time-frame for the 0.9.1 and 1.0 releases (obviously
>this is sketchy since it's "volunteer" work, but "gut guesses" - probably
>from Juergen :) - based on work left is what I'm hoping for.  The previous
>estimate was the 1.0RC1 by now.
></quote>
> 
>0.9.1 should be out any day now. I encourage everyone to try it the current CVS version before the weekend. A release some time next week should really be achievable. We *need* to get out a follow-up release quickly, if just because of all the enhancements to the Hibernate support that have a good chance of getting adopted promptly. My Hibernate article in the community area and my postings to the Hibernate forum have already been discussing some of them for a while.
>
><quote>
>4. From Juergen's email which I referenced, it states "As far as I see, we
>don't need additional functionality for 1.0".  The main thing holding me
>back from adopting the current code base (I'm currently using a
>personally-modified version of 0.8) is the amount and frequency of changes
>to core functionality and the public api.  Some new features or minor bug
>fixes are ok/normal, but these sweeping changes are destructive to
>production code.  How close are we to finalizing the public api and the core
>code?  Is it likely that these major changes should be done for 0.9.1?
></quote>
> 
>Maybe I'm promising too much, but I don't see any major changes on the horizon. The introduction of the new DTD was probably the biggest change in the last few months, everything else was just about slight changes to the public API. I agree that we need stable APIs though to allow production apps to rely on them without *any* hassle. 0.9.1 should be as stable as can be in that respect, besides the package name change for 1.0 RC which should just involve a search-and-replace.
>
><quote>
>To expand on my fourth question with a recommendation (hopefully it makes
>sense to everyone).  If possible we should finalize the public api for
>version 0.9.1 rather than at the 1.0RC1.  This will allow usage in new
>development without fear of incompatibilities in the next couple months. (...)
></quote>
> 
>As I indicated above, I fully agree. We've been changing our apps at werk3AT quite often too, it would be fine it that wouldn't be necessary anymore as soon as possible. And I'd really like to get you on board again, in terms of working with a current Spring version :-)
> 
>Regards,
>Juergen
>NHS^隊[){([Zzn襴4D׬w%ا6il&x+ljwEjzz0'Zɩz{^0v\bJ۝DNmڲ޵brK&
>?ƴ]4Mڽ݊Z޷NM5Jjgzx%Rڙ(G^hlqzm?X(~zwXb?jgz
>N?HS^?隊[)?{(??[?Z?z??n襴?4D?׬?w%?ا?6?i???l?&???x?+??ljwE??????j??zz0?'?????Zɩ?z{^??0?v?\???b??J۝??DNm??ڲ?޵?brK???&?
>??ƴ?]4?Mڽ?݊????Z??޷N??M???5J???jg???z??????x%??R?????ڙ?(?G^??h????l???q???z?m????X???(??~??zw??X?????b???????jg???z??
>

RE: [Springframework-developer] polishing and new features - security model??????

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

I think Security might be too large an issue to be addressed in Spring, at
least without complicating it even further.  While you're idea has promise,
there are so many other ways of handling it (such as with db permissions,
handling only in certain layers, creating object hierarchies with different
methods) that my opinion is we should leave it.  Spring's philosophy (IMO)
has been about providing a generic core infrastructure that does NOT intrude
on the business layer, and does not enforce a specific way of coding (for
example the whole JDBC vs EJB vs Hibernate vs JDO is handled seamlessly from
the perspective of the business layer).  I would vote against adding the
sort of handling you're describing.

That being said, we have run into some of the issues you're discussing in
our programming over the last few months on a Spring-based web-app.  We
solved our problem through custom taglibs in the (jsp) web layer (this
handles accessors), and you can use a custom binder (instead of the default
from BindUtils) which receives the request object (so has access to security
info) before processing each object.  I'm not quite up-to-speed on the
current codebase, so Juergen may have a "quick-tip" on how best to override
the binder used.  AOP also looks very promising, although I have yet to get
into it.

Basically, Spring provides many ways for you to handle your problem
according to your needs, but I don't think we can generalize the (security)
solution, only the tools (Spring) to deal with it as needed.

My 2 cents.

Trevor D. Cook


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Alef Arendsen (JTeam)
Sent: August 1, 2003 4:24 AM
To: 'Timo Verhoeven'; spr...@li...
Subject: RE: [Springframework-developer] polishing and new features -
security model??????


<quote>
 C - [ depends on project ]
 B - POJO Business Objects
 A - POJO DAO Objects (Hibernate in my case)

 Objects in each layer may only call other Object in the same layer or
 Objects in the NEXT lower layer.

 Given I was to build an EJB solution, layer C would be a SINGLE session

 facade SLSB (single because I want to avoid COSTLY inter EJB calls).
 For testing/QA, I would write unittests at layer C to test B and A, and

 maybe unittests at layer D to test the SLSB. For maintenance
 (developers only) I could write another POJO java-app running at C. If
 I wanted to CHANGE the solution-type from EJB to webinterface I could
 either replace the SLSB at C with servlets/jsps/etc. or write a
 servlet/jsp/etc. layer at D using EJB layer C.
</quote>
Well, this isn't very odd! It resembles the way we (and probably a lot
Of other people) do things...

<quote>
 The above appears VERY FLEXBILE to me. If I got you right, you would
 like to add security at layer A. This would screw up the model at
 various points (my problem - I do not have to use those security
 features). Furthermore, it might not be a good idea to have a depency
 in a Spring security API on SPECIFIC other security providing
 frameworks such as EJB and Servlets - relying on the Principal
 interface sort of introduces such a dependency, though.

 Please don't get me wrong: These are mainly my thoughts on how your
 proposal would affect my current model...
</quote>
I totally get your point. The way you're working is exactly the same as
We do. We call layers A & B (they don't differ much here) the module
layer here, the layer above is the component layer containing business
logic... Modules can't have security, can't have io, can't have
networking etctera (basically all EJB forbids)... The component layer
contains transactions/security, etctera.

The thing is, that the security model J2EE provides does not meet our
demands when it comes to security for __parts of objects__. I'm trying
to figure out something to add this. This does not mean I'm intruding on
the module level (A+B). You can compare it a lot with the validation
framework. We're having the commons validator included as validator for
the Spring framework (just extend the validator interface and use the
commons validator there). Each data object in our system has a
validation.xml file (located right beside the class file, called
[class].validation.xml). This means I haven't intruded on the data
level, just added a descirptorfile, describing validation rules... No
extra interface (I hate that ;-). Same thing holds for the Hibernate
stuff... We're using a proprietary little farmework for integration of
Hibernate into Spring (would rather have used Spring here, but the
framework is already in place for a long time). The Hibernate files are
placed right besides the data files and are called [class].hbm.xml.

Right now I want to add security. HOW the security is done, is actually
determine by the security-implementation (in this cause a
RoleObjectPermissionsWhatever, __located at the component level (Spring
+ C)__, however using the descriptor files from the module level
(A+B)... No extra interface or classes to extend, just an extra
description.

What the criteria for the permissions would be, is totally up to the
implementation. In this case I need Role/Principal information, which
means I either need the SessionContext/EntityContext or a ServletRequest
(whatever, something using JAAS/javax.security). This means the
implementation can __never__ be located at the modulelayer (A+B). Other
implementations would provide time based permissions (between 2am-3am
not possible to edit backup schedule, because backup is actually done
then)...

Anyway, I hope this clarifies things a little bit and I hope to get some
more feedback and stuff (people just shouting __arghh this is ugly__
would do as well!!!)...

Thanx,

Alef



-------------------------------------------------------
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

---
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] New Spring production deployment

[Kopylenko, D. <dko...@ac...>]

Thomas, all,

This is phase 1 of the project (public site). Now we're planning to begin
phase 2 (administrative site).
Phase 1 is the simple and consistent Spring architecture - JavaBean based
objects wired through a bean factory and deployed in the Web container (no
remote access). There is a layer of Business Interfaces and a distinct layer
of DAO interfaces for the "middle tier". Business Interfaces are implemented
by POJO and DAO interfaces are also implemented by POJO utilizing plain old
SQL and Spring's JDBC abstraction layer. As for the tx management we're
using Spring's declarative AOP CMT with JtaTransactionManager strategy. Also
we've implemented few of our own aopalliance AOP interceptors such as
"DebugInterceptor", "AuditTrailHandlerInterceptor",
"MailConfirmationInterceptor" - works like a charm :-) In the web tier we're
using Spring's MVC framework (we chose to use MultiActionControllers
exclusively for this phase).

The deployment platform is Sun Solaris 8, app server is Jboss 3.2.0/Tomcat
4.1, the RDBMS is Oracle 9i.

So there it is. For phase 2 we would probably look into Hibernate (we're
pretty new to it though). Once again, the architecture is "clean" and the
performance is also VERY GOOD. Just wanted to mention - it all started by me
picking the copy of Rod's book about 8 months ago :-))

Regards,
Dmitriy.

-----Original Message-----
From: tri...@tr... [mailto:tri...@tr...] 
Sent: Friday, August 01, 2003 9:39 AM
To: Kopylenko, Dmitry
Cc: 'springframework-developer'
Subject: Re: [Springframework-developer] New Spring production deployment


Dmitriy

> I guess it could be considered a Spring success
> story :-)
> 

I would say so.  It looks great, congratulations on a successful poject.
I'm sure there is interest in getting your views on using Spring for
developing this application.  To start - what does your database layer look
like?  Are you using Spring JDBC or are you using Hibernate?

Thomas

FW: [Springframework-developer] New Spring production deployment

[Kopylenko, D. <dko...@ac...>]

-----Original Message-----
From: Kopylenko, Dmitry 
Sent: Friday, August 01, 2003 10:00 AM
To: 'tri...@tr...'; Kopylenko, Dmitry
Cc: 'springframework-developer'
Subject: RE: [Springframework-developer] New Spring production deployment


Thomas, all,

This is phase 1 of the project (public site). Now we're planning to begin
phase 2 (administrative site). Phase 1 is the simple and consistent Spring
architecture - JavaBean based objects wired through a bean factory and
deployed in the Web container (no remote access). There is a layer of
Business Interfaces and a distinct layer of DAO interfaces for the "middle
tier". Business Interfaces are implemented by POJO and DAO interfaces are
also implemented by POJO utilizing plain old SQL and Spring's JDBC
abstraction layer. As for the tx management we're using Spring's declarative
AOP CMT with JtaTransactionManager strategy. Also we've implemented few of
our own aopalliance AOP interceptors such as "DebugInterceptor",
"AuditTrailHandlerInterceptor", "MailConfirmationInterceptor" - works like a
charm :-) In the web tier we're using Spring's MVC framework (we chose to
use MultiActionControllers exclusively for this phase).

The deployment platform is Sun Solaris 8, app server is Jboss 3.2.0/Tomcat
4.1, the RDBMS is Oracle 9i.

So there it is. For phase 2 we would probably look into Hibernate (we're
pretty new to it though). Once again, the architecture is "clean" and the
performance is also VERY GOOD. Just wanted to mention - it all started by me
picking the copy of Rod's book about 8 months ago :-))

Regards,
Dmitriy.

-----Original Message-----
From: tri...@tr... [mailto:tri...@tr...] 
Sent: Friday, August 01, 2003 9:39 AM
To: Kopylenko, Dmitry
Cc: 'springframework-developer'
Subject: Re: [Springframework-developer] New Spring production deployment


Dmitriy

> I guess it could be considered a Spring success
> story :-)
> 

I would say so.  It looks great, congratulations on a successful poject.
I'm sure there is interest in getting your views on using Spring for
developing this application.  To start - what does your database layer look
like?  Are you using Spring JDBC or are you using Hibernate?

Thomas

RE: [Springframework-developer] New Spring production deployment

[Kopylenko, D. <dko...@ac...>]

No problem at all with the deployment. Just ran ant "production.dist" target
- it would build the .war file and drop it into the Jboss' deploy directory
(hot deploy) THAT IS IT :-))

D.

-----Original Message-----
From: Trevor Cook [mailto:pr...@se...] 
Sent: Friday, August 01, 2003 10:23 AM
To: 'springframework-developer'
Subject: RE: [Springframework-developer] New Spring production deployment


Definately a success.  Congratulations Dmitriy, it looks great!

Another question for you is ease of deployment.  Were there any "hurdles"
you had to jump as far as getting Spring working live, or did it deploy
pretty smoothly?

I think this also might be a good time to go back to the "who's using
Spring" question from:
http://sourceforge.net/mailarchive/forum.php?thread_id=2742971&forum_id=2840
1
http://sourceforge.net/mailarchive/forum.php?thread_id=2747599&forum_id=2840
1
http://sourceforge.net/mailarchive/forum.php?thread_id=2748062&forum_id=2840
1

Trevor


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf Of
tri...@tr...
Sent: August 1, 2003 9:39 AM
To: Kopylenko, Dmitry
Cc: 'springframework-developer'
Subject: Re: [Springframework-developer] New Spring production deployment


Dmitriy

> I guess it could be considered a Spring success
> story :-)
>

I would say so.  It looks great, congratulations on a successful poject. I'm
sure there is interest in getting your views on using Spring for developing
this application.  To start - what does your database layer look like?  Are
you using Spring JDBC or are you using Hibernate?

Thomas



-------------------------------------------------------
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] New Spring production deployment

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

Definately a success.  Congratulations Dmitriy, it looks great!

Another question for you is ease of deployment.  Were there any "hurdles"
you had to jump as far as getting Spring working live, or did it deploy
pretty smoothly?

I think this also might be a good time to go back to the "who's using
Spring" question from:
http://sourceforge.net/mailarchive/forum.php?thread_id=2742971&forum_id=2840
1
http://sourceforge.net/mailarchive/forum.php?thread_id=2747599&forum_id=2840
1
http://sourceforge.net/mailarchive/forum.php?thread_id=2748062&forum_id=2840
1

Trevor


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of tri...@tr...
Sent: August 1, 2003 9:39 AM
To: Kopylenko, Dmitry
Cc: 'springframework-developer'
Subject: Re: [Springframework-developer] New Spring production
deployment


Dmitriy

> I guess it could be considered a Spring success
> story :-)
>

I would say so.  It looks great, congratulations on a successful poject.
I'm
sure there is interest in getting your views on using Spring for developing
this
application.  To start - what does your database layer look like?  Are you
using
Spring JDBC or are you using Hibernate?

Thomas



-------------------------------------------------------
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

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

>>FYI, I'll be travelling to Australia for the whole of September,
>>so I'd prefer to get 0.9.2 out before that, and our first =
org.springframework
>>1.0 RC right after my return. Is a 1.0 RC1 target at the beginning of=20
>>October fine for everybody? I hope it's not too late, but we will need =

>>the time anyway for documentation and all that stuff. 1.0 final could
>>be possible in November then.
Timing sounds good.  I'm in the same boat right now with summer vacation =
- work 1 day, take 3 off  :) (that's why you'll notice so many emails =
from me today, and nothing till next week :) ). I won't be back to =
regular hours (work and presonally) until mid-September.  It would be =
nice to get stuff out quicker, but I think your estimates/targets are =
bang on considering "reality".

>>BTW, we don't *need* to make SourceForge change our CVS directories=20
>>to apply the package name change. We could also keep the current=20
>>"main" module as it is, including all its version history, and=20
>>introduce a new "main10" module with a fresh import of an =
org.springframework=20
>>version. This would also make sense in terms of dead directories that=20
>>a CVS update always traverses: There wouldn't be any then.
I'm not that familiar with modules, but I think the main thing is making =
sure it's easy to fetch the single current version.  If your method will =
do that, no problem here.

Trevor D. Cook

RE: [Springframework-developer] Current release plan

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

Great news!  I can now get back into the main branch ;)  Our new =
projects (which I'm starting ... now) will be based on the current =
Spring (0.9.1) and our 2 existing apps will be migrated over the next =
couple months as time permits.

Trevor D. Cook


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=C3=BCrgen h=C3=B6ller [werk3AT]
Sent: July 30, 2003 5:34 PM
To: pr...@se...; Spring Developers
Subject: Re: [Springframework-developer] Current release plan


Hi Trevor,
=20
First of all, good questions resp. important ones indeed!
=20
<quote>
1. What still needs to be done for 0.9.1.  From that list, what is =
currently
"assigned" to someone and what still needs help?
</quote>
=20
Not a lot, actually. It's mainly about polishing the Petclinic and =
Countries sample apps, and testing the current codebase in everyone's =
own projects. Everything should be assigned so far, except the latter of =
course :-)
=20
I'm currently polishing a lot of the source code. I've also added 2 new =
features that aren't committed yet but will be by the end of this week, =
namely Hibernate flush mode support on HibernateTemplate and =
HibernateInterceptor, and read-only transactions (suppressing Hibernate =
flush on the transaction level). Furthermore, I've refined =
TransactionInterceptor and MapTransactionAttributeSource a bit, =
supporting more configuration options then before.
=20
<quote>
2. Same as #1 but for the 1.0 release.
</quote>

The first 1.0 RC will involve a package name change from com.interface21 =
to org.springframework. Besides that, there won't be a lot in terms of =
new features -maybe even less than from 0.9 to 0.9.1. Rod might already =
introduce some source-level attribute stuff to the AOP framework, but =
that isn't a requirement at all. Proper JMS and Web Service support are =
candidates too but can easily wait until 1.1.
=20
<quote>
3. What is the target time-frame for the 0.9.1 and 1.0 releases =
(obviously
this is sketchy since it's "volunteer" work, but "gut guesses" - =
probably
from Juergen :) - based on work left is what I'm hoping for.  The =
previous
estimate was the 1.0RC1 by now.
</quote>
=20
0.9.1 should be out any day now. I encourage everyone to try it the =
current CVS version before the weekend. A release some time next week =
should really be achievable. We *need* to get out a follow-up release =
quickly, if just because of all the enhancements to the Hibernate =
support that have a good chance of getting adopted promptly. My =
Hibernate article in the community area and my postings to the Hibernate =
forum have already been discussing some of them for a while.

<quote>
4. From Juergen's email which I referenced, it states "As far as I see, =
we
don't need additional functionality for 1.0".  The main thing holding me
back from adopting the current code base (I'm currently using a
personally-modified version of 0.8) is the amount and frequency of =
changes
to core functionality and the public api.  Some new features or minor =
bug
fixes are ok/normal, but these sweeping changes are destructive to
production code.  How close are we to finalizing the public api and the =
core
code?  Is it likely that these major changes should be done for 0.9.1?
</quote>
=20
Maybe I'm promising too much, but I don't see any major changes on the =
horizon. The introduction of the new DTD was probably the biggest change =
in the last few months, everything else was just about slight changes to =
the public API. I agree that we need stable APIs though to allow =
production apps to rely on them without *any* hassle. 0.9.1 should be as =
stable as can be in that respect, besides the package name change for =
1.0 RC which should just involve a search-and-replace.

<quote>
To expand on my fourth question with a recommendation (hopefully it =
makes
sense to everyone).  If possible we should finalize the public api for
version 0.9.1 rather than at the 1.0RC1.  This will allow usage in new
development without fear of incompatibilities in the next couple months. =
(...)
</quote>
=20
As I indicated above, I fully agree. We've been changing our apps at =
werk3AT quite often too, it would be fine it that wouldn't be necessary =
anymore as soon as possible. And I'd really like to get you on board =
again, in terms of working with a current Spring version :-)
=20
Regards,
Juergen
                     +=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)

[Springframework-developer] petclinic testing

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

I tested the new petclinic with no problems.  I ran it on:

Tomcat 4.1.24 
Windows XP
Sun JDK 1.4.1

Good job Ken!

Trevor

Re: [Springframework-developer] New Spring production deployment

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

Dmitriy

> I guess it could be considered a Spring success
> story :-)
> 

I would say so.  It looks great, congratulations on a successful poject.  I'm
sure there is interest in getting your views on using Spring for developing this
application.  To start - what does your database layer look like?  Are you using
Spring JDBC or are you using Hibernate?

Thomas

[Springframework-developer] New Spring production deployment

[Kopylenko, D. <dko...@ac...>]

Hello everyone. Just F.Y.I., today we successfully deployed to production a
web based application (GAS - Graduate Admission System) powered by Spring
framework (all layers). I guess it could be considered a Spring success
story :-)

https://www.acs.rutgers.edu/gradadmission/overview.html
<https://www.acs.rutgers.edu/gradadmission/overview.html> 

Dmitriy.

RE: [Springframework-developer] Using PropertyEditors in JSPs

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

<quote>That sounds interesting, and it should be pretty easy to
integrate. But for the sake of getting 0.9.1 out ASAP, I suggest to hold
it back for after the release, just like the Tiles integration. I guess
we will release a 0.9.2 follow-up at end of August anyway, all that
stuff should fit in there in polished and tested versions.</quote>

Totally agree, I'll maintain in my local tree and test it a bit
further...

<quote>BTW, I really like the extensive Javadoc that you added to some
of the web controller classes, especially the explanations of the
workflows! Very, very welcome :-)</quote>

No problem, probably I'll have a chance to do some more tomorrow. After
tomorrow I'm on a holiday until the 13th by the way...

Alef

-----Original Message-----
From: Alef Arendsen (JTeam) [mailto:al...@jt...]
Sent: Wednesday, July 30, 2003 1:55 PM
To: spr...@li...
Subject: [Springframework-developer] Using PropertyEditors in JSPs


Everyone,=20
I've made an addition to the BindStatus and BindTag and added a
TransformTag (the name is still open for discussion) I wanted to discuss
with you before adding it.
When using <spring:bind>, a BindStatus object is instantiated for the
path (on the command class) I'm setting in the tag. Also, any
PropertyEditors that are associated to that field or type of property
are consulted to get the appropriate String representation for the
property. However, right now it's not possible to also retrieve String
representations for any referenceData I've bound in the requestContext.
Consider the following:=20
I want to add a user and the user has a property called language
(preferred language, with associated getLocale() and setLocale()
methods)=20
Using a formcontroller I've returned the formBackingObject as well as
some referenceData (in this case, a list of Locale objects from which
the user wants to choose)=20
To be able to let the user choose one of the locale objects and let the
framework set the right locale using the associated LocaleEditor, I need
to be able to make consult the LocaleEditor for the locales in the list
as well=20

I thought of the following to make this work. Everything enclosed by
<spring:bind>-tags applies to a certain path of the command object and
therefore (if applicable) an associated PropertyEditor. So anything
enclosed by those tags could be rendered using that specific
PropertyEditor as well.
The attached example shows the final JSP used to implement the above
usecase.=20
Modification that need to be made to add this functionality are the
following:=20
getCustomerEditor()-method to BindTag and Errors interface (and
corresponding implementations in BindException and EscapedErrors
(returning the appropriate editor or null if not applicable or not
found)=20
Addition of transform-tag to be used inside bindtag=20

The only thing I'm not sure about is the first modification=85=20
Any comments, objections or remarks about the implementation?=20
Alef=20
<<...>>=20
=3D=3D=20
JTeam B.V.=20
Donker Curtiusstraat 7-412=20
1051 JL  Amsterdam=20
T: +31 20 486 20 36=20
M: +31 6 24 11 1996=20
F: +31 84 837 00 00=20
E: al...@jt...=20
W: www.jteam.nl=20

Re: [Springframework-developer] Changes for 0.9.1

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

Here's a list of the changes I've made between 0.9 and 0.9.1. 
I hope I've remembered everything. I think it would be good 
if we all add to this to form a release note.

Juergen, could you summarize the significant changes you've 
made (I know you've posted many of them to the list, so 
compiling those into a single doc would be a good start).

I've distinguished between backward-compatible changes and 
changes that will break user code (marked with *).


CHANGES

* indicates not backward compatible

--------------------------
* Updated to current AOP Alliance interfaces. 
org.aopalliance -> org.aopalliance.intercept. 
MethodInvocation.invokeNext() -> proceed(). 

--------------------------
- Created distinction between static and dynamic method 
pointcuts. Static pointcuts depend only on invoked method, 
and possibly attributes; dynamic pointcuts are also aware of 
arguments. This will permit performance optimizations in AOP 
framework if required in the future.

--------------------------
- Added regular expression method pointcut. This matches 
method FQNs, such as .*get.*, which will match
com.mycom.Foo.getValue()
org.somewhere.Someclass.getSomething()

OR

com.mycom.*get*, which will match only the first example. 
(OK, I'm being lazy, the . is a wildchar not a literal ., but 
it looks good.) Syntax is Perl 5 regular expressions. If you 
want to use this, remember to include Jakarta ORO in your 
classpath.

--------------------------
* com.interface21.ejb.support package once again provides a 
BeanFactory to subclasses. It differs from the original 
version in that the default BeanFactory is now an XML bean 
factory, loaded from the classpath with the environment 
variable ejb/BeanFactoryPath specifying the location.

You'll need an environment variable like this in ejb-jar.xml:

 <env-entry>
	<description>
		Path to the bean factory. Note that this is 
on the classpath
		and the XML file should be included in the 
EJB Jar file.
	</description>
	<env-entry-name>ejb/BeanFactoryPath</env-entry-name>
	<env-entry-type>java.lang.String</env-entry-type>
	<env-entry-
value>/com/mycompany/myapplication/myName.xml</env-entry-
value>
</env-entry>

You'll also need to implement a protected abstract onEjbCreate
() method, rather than implement ejbCreate(). This is 
consistent across SLSBs and MDBs.

Stateful session beans should extend the new 
AbstractStatefulSessionBean class. AbstractEnterpriseBean and 
AbstractSessionBean are now package-visible, as they 
shouldn't be subclassed directly.

--------------------------
- Spring bean factory DTD has been extended to allow map 
entries to be lists, as well as values or references

--------------------------
- Added an optional "init-method" attribute to XML bean 
definitions. This specifies the name of a no-arg method that 
should be invoked after all property values have been set. 
This method provides an alternative to implementing the 
InitializingBean, so that application classes aren't forced 
into dependency on Spring APIs. The init method may throw any 
exception: if it does the framework will catch it, treat it 
as fatal, and log it.

--------------------------
- Fixed bug where NoSuchMethodError could be thrown if a 
Spring XML beans definition file was invalid.

--------------------------
- Improved support for bean factory inheritance. Added 
methods in BeanFactoryUtils to look at _all_ beans (or beans 
of a particular type) including ancestor definitions, rather 
than just definitions in the leaf factory. Updated framework 
classes such as ProxyFactoryBean to pick up beans of the 
relevant type from ancestor factories.

--------------------------
- Added getUnderlyingResultSet() method to ReadOnlyResultSet. 
Allows use of proprietary methods on ResultSets if necessary, 
while preserving the default prohibition of navigation 
methods.

--------------------------
- Further improvement to test suite. Unit test coverage now 
74%. 

RE: [Springframework-developer] polishing and new features - security model??????

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

<quote>
 C - [ depends on project ]
 B - POJO Business Objects
 A - POJO DAO Objects (Hibernate in my case)
 
 Objects in each layer may only call other Object in the same layer or 
 Objects in the NEXT lower layer. 
 
 Given I was to build an EJB solution, layer C would be a SINGLE session

 facade SLSB (single because I want to avoid COSTLY inter EJB calls). 
 For testing/QA, I would write unittests at layer C to test B and A, and

 maybe unittests at layer D to test the SLSB. For maintenance 
 (developers only) I could write another POJO java-app running at C. If 
 I wanted to CHANGE the solution-type from EJB to webinterface I could 
 either replace the SLSB at C with servlets/jsps/etc. or write a 
 servlet/jsp/etc. layer at D using EJB layer C.
</quote>
Well, this isn't very odd! It resembles the way we (and probably a lot
Of other people) do things...

<quote>
 The above appears VERY FLEXBILE to me. If I got you right, you would 
 like to add security at layer A. This would screw up the model at 
 various points (my problem - I do not have to use those security 
 features). Furthermore, it might not be a good idea to have a depency 
 in a Spring security API on SPECIFIC other security providing 
 frameworks such as EJB and Servlets - relying on the Principal 
 interface sort of introduces such a dependency, though.
 
 Please don't get me wrong: These are mainly my thoughts on how your 
 proposal would affect my current model... 
</quote>
I totally get your point. The way you're working is exactly the same as
We do. We call layers A & B (they don't differ much here) the module
layer here, the layer above is the component layer containing business
logic... Modules can't have security, can't have io, can't have
networking etctera (basically all EJB forbids)... The component layer
contains transactions/security, etctera.

The thing is, that the security model J2EE provides does not meet our
demands when it comes to security for __parts of objects__. I'm trying
to figure out something to add this. This does not mean I'm intruding on
the module level (A+B). You can compare it a lot with the validation
framework. We're having the commons validator included as validator for
the Spring framework (just extend the validator interface and use the
commons validator there). Each data object in our system has a
validation.xml file (located right beside the class file, called
[class].validation.xml). This means I haven't intruded on the data
level, just added a descirptorfile, describing validation rules... No
extra interface (I hate that ;-). Same thing holds for the Hibernate
stuff... We're using a proprietary little farmework for integration of
Hibernate into Spring (would rather have used Spring here, but the
framework is already in place for a long time). The Hibernate files are
placed right besides the data files and are called [class].hbm.xml.

Right now I want to add security. HOW the security is done, is actually
determine by the security-implementation (in this cause a
RoleObjectPermissionsWhatever, __located at the component level (Spring
+ C)__, however using the descriptor files from the module level
(A+B)... No extra interface or classes to extend, just an extra
description.

What the criteria for the permissions would be, is totally up to the
implementation. In this case I need Role/Principal information, which
means I either need the SessionContext/EntityContext or a ServletRequest
(whatever, something using JAAS/javax.security). This means the
implementation can __never__ be located at the modulelayer (A+B). Other
implementations would provide time based permissions (between 2am-3am
not possible to edit backup schedule, because backup is actually done
then)...

Anyway, I hope this clarifies things a little bit and I hope to get some
more feedback and stuff (people just shouting __arghh this is ugly__
would do as well!!!)...

Thanx,

Alef

Re: [Springframework-developer] polishing and new features - security model??????

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

Hi all!

I'm quite new to the spring framework. I started evaluating it about a=20
month ago. So if the following appears odd it might be due to my lack=20
of experience.

Currently, if I were to build a project with the Spring framework, I=20
would build my layers as follows:

C - [ depends on project ]
B - POJO Business Objects
A - POJO DAO Objects (Hibernate in my case)

Objects in each layer may only call other Object in the same layer or=20
Objects in the NEXT lower layer.=20

Given I was to build an EJB solution, layer C would be a SINGLE session=20
facade SLSB (single because I want to avoid COSTLY inter EJB calls).=20
=46or testing/QA, I would write unittests at layer C to test B and A, and=20
maybe unittests at layer D to test the SLSB. For maintenance=20
(developers only) I could write another POJO java-app running at C. If=20
I wanted to CHANGE the solution-type from EJB to webinterface I could=20
either replace the SLSB at C with servlets/jsps/etc. or write a=20
servlet/jsp/etc. layer at D using EJB layer C.

Layers A and B do NOT contain ANY features the EJB container can provide=20
at C, i.e. no TX demarcation, no security, etc.. So if I have a layer=20
at C that is not EJB I CAN (but do not HAVE TO) implement these=20
features myself. In case of testing/QA layers A + B I'm HAPPY that I'm=20
not EJB dependent and that I do not have to "code around" security=20
measures! For developer controlled maintenance code at layer C I'm=20
HAPPY that I do have to care about security and TX (in maintenance mode=20
its only me connected to the system). And in case I change from EJB to=20
web-solution I have the CHOICE whether I want the benefits (and=20
overhead) of using EJB at C with web at D or wheter I want web at C,=20
where I would have to manually care about security and TX demarcation.

The above appears VERY FLEXBILE to me. If I got you right, you would=20
like to add security at layer A. This would screw up the model at=20
various points (my problem - I do not have to use those security=20
features). Furthermore, it might not be a good idea to have a depency=20
in a Spring security API on SPECIFIC other security providing=20
frameworks such as EJB and Servlets - relying on the Principal=20
interface sort of introduces such a dependency, though.

Please don't get me wrong: These are mainly my thoughts on how your=20
proposal would affect my current model...=20


Just my 2c,

Timo

Am Donnerstag, 31. Juli 2003 23:26 schrieb Alef Arendsen \(JTeam\):
> > interceptor framework supports postHandle
> > now in addition to preHandle, allowing e.g.
> > for binding user contexts from a session
> > attribute to a ThreadLocal in preHandle
> > and removing it again in postHandle.
>
> Argggh.... I just spent my time breaking my mind over the issue how
> to do this (and shouting at the framework for not having
> postHandlerInterceptors ;-). Then I get this email ;-). So to
> implement the latest and greatest of my features, I will probably
> have a chance to test this quite thoroughly tomorrow. Some of those
> features might - btw - be very interesting for addition to Spring,
> but definitely not for 0.9.1 release!!!
>
> Ahh, what the heck, why don't I just already put up the ideas, maybe
> people have some interesting thoughts... What I'll describe below is
> already implemented in a working prototype.
>
> --- WARNING - NOT FOR THE 0.9.1 RELEASE, JUST A TWIST OF THE MIND ---
>
> I've been struggling for ever with the question how to prevent
> certain users from seeing or being able to edit certain data. And
> then I don't mean complete objects, just bits of objects. For
> instance:
> administrators can create and edit Account-objects, users in their
> turn can only update their firstName-property and lastName-property
> (contained by those accounts). I really don't want to - every time I
> save the Account object - check if the user
> isInRole(user/administrator) and check if the firstName-property and
> lastName-property has been set, etcetera. I also don't want to have
> those checks in my
> datamodel/objects. It would be perfect if this could done outside the
> datamodel and also outside the businesslogic. Just like validation.
> Oh yeah, I don't want to do it with database-views...
>
> So today I had a huge fight (design sessions are always fights here,
> but it's very constructive) with my colleague about this issue. We
> finally came up with the idea to think up a generic
> Object/PropertyPermissions framework, of which he would make the
> implementation that would set permissions based on the combination of
> Object type and Role (contained by the Principal).
>
> To be able to use this in MVC (and more specifically: Spring), I have
> devised something like the Validator (contained in a new package
> com.interface21.security), called PropertyPermissionsResolver. This
> works together with the PropertyPermissions interface and the
> PropertyPermissions interface. All very abstract and to be
> implemented just as the validator.
>
> PropertyPermissions would apply to the complete Model (in the
> ModelAndView) and objects in the model will dynamically be passed to
> the PropertyPermissionInspector (having the same boolean
> supports()-method as the Validator). So if no Inspector is defined
> for a certain Object, no permission will be added (or nothing is
> accessible at all, this would be configurable).
>
> Views can use the information of the PropertyPermissions and stuff in
> their logic to render things accordingly. To facilitate JSP Views I
> want to a couple of method to the BindStatus object - or extending it
> for this purpose - (specifically isVisible() and isEditable()) to be
> able to use the BindStatus for this purpose as well=85 JSP code
> utilizing this would somewhat look like this:
>
> <spring:bind path=3D"Account.active">
> 	<c:if test=3D"${status.editable}">
> 		<intput type=3D"text" name=3D"<c:out
> value=3D"${status.epxression}"/>" value=3D"<c:out
> value=3D"${status.value}"/>">
> 	</c:if>
> </spring:bind>
> <spring:bind path=3D"Account.fistName">
> 	<c:if test=3D"${status.editable}">
> 		<input type=3D"text" name=3D"<c:out
> value=3D"${status.epxression}"/> value=3D"<c:out
> value=3D"${status.value}"/>"> </c:if>
> </spring:bind>
>
> The above code would result in two textfields for the administrator
> (both active and firstName) and one textfield for anybody with role
> 'user' when applying the usecase mentioned above (if of course you
> would be using the Role/ObjectType based security model!). So only
> one view, one controller, one model but still hiding certain property
> from certain users that are not allowed to see them (and a lot more
> possible functionalities ;-).
>
> Right now I've got things implemented for Roles/ObjectTypes and this
> looks like the following. As you might see, nested property
> permission are possible using this thing as well=85 This is all pretty
> specific for our application and way of working, but the interfaces
> (PropertyPermissions, Inspector, Resolver and stuff) and the complete
> idea is especially suitable for addition in my opinion, even more
> since Juergen just added the postHandle things, where this can take
> place...
>
> <object-permission name=3D"jteam.site.data.Account">
>         <!-- everybody is allowed to see everything -->
>         <property-permission>
>             <role-name>administrator</role-name>
>             <role-name>employee</role-name>
>             <property-name>*</property-name>
>             <editable>true</editable>
>             <visible>true</visible>
>         </property-permission>
>         <!-- the customer cannot edit an account -->
>         <property-permission>
>             <role-name>customer</role-name>
>             <property-name>*</property-name>
>             <editable>false</editable>
>         </property-permission>
>         <!-- define the properties that are nested -->
>         <object-permission-ref property=3D"account"
> ref=3D"jteam.site.data.Account"/>
> </object-permission>
>
> However, I've got a couple of issues hanging around=85
> *	The BindStatus things are pretty JSP-specific of course. How to
> use PropertyPermissions when one's View technology is Velocity? I
> don't want to (before the view gets rendered) generate all
> PermissionsObjects up front, because this is all nested and it could
> well be 100's of objects each request (of which probably only 10% is
> actually used, considering a form of 10 fields)
> *	What to do with the PropertyPermissionsInspector. There's no
> place - so far I can see - to put the PropertyPermissions in. I kind
> of sense they should be part of the model (in the ModelAndView
> object), but this of course is a major api-change.
> PropertyPermissions should be usable in any view, not just for
> instance the JSP view. So somehow the Inspector needs to be available
> at all times...
> *	How to actually get in the functionality that it=92s not only
> possible to see if a property is editable, but also to prevent the
> setter from being called. I smell a bit of AOP here (and I'm not too
> familiar with it yet), but is it possible to create advises and
> interceptor dynamically using a security configuration file or
> something?
> *	How to get extra information in for use when developing custom
> propertypermissioninspectors. Right now I need to have the principal
> to determine the role of the user and I'm passing on the
> HttpServletRequest to achieve this=85 But this does not feel right (see
> the methods below)
>
> Phew=85 that's all basically. Below I'll insert the public API for the
> object I've mentioned, just so you can take a look=85
>
> /* this one is resembling Errors a lot */
> Interface PropertyPermissions
> ---- // final static permission integer
> ---- boolean isVisible(String path)
> ---- boolean isEditable(String path)
> ---- boolean setNestedPath(Sring nested)
> ---- void permit(String field, int permissions)
>
> /* this is the interface actually determining the permissions */
> Interface PropertyPermissionInspector
> ---- boolean support(Class clzz)
> ---- /* passing on the servletrequest does not feel right, but see
> the remark above */
> ---- PropertyPermissions determinePropertyPermissions(Object o,
> HttpServletRequest req)
>
> /* this is the to-be-configured collection of Inspector that will be
> used
>    to apply a security model to the complete Model(AndView), names
> are crap by the way */
> Class PropertyPermissionsResolver
> ---- /* setter for the propertypermission objects in the
> xxx-servlet.xml */
> ---- void setPropertyPermissionsInspector(List l)
> ---- /* finds inspector supporting given class and returns
> PropertyPermissions */
> ---- PropertyPermissions getPropertyPermissions(request, response,
> object)
>
> This all would be used from a PostSecurityHandlerInterceptor which I
> haven't created yet=85.
>
> Opinions???
>
> Alef

Re: [Springframework-developer] polishing and new features

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

> application context includes via XML entities: the new
ResourceBaseEntityResolver resolves such entities relative to the resource
base of the application context now, allowing for splitting context
definitions into multiple files;

Excellent.

> DAO base classes: the new JdbcDaoSupport, HibernateDaoSupport, and
JdoDaoSupport classes in respective support packages can serve as convenient
base classes for DAOs that use the templates;

Also excellent. This is an important selling point for Spring, as the
Hibernate forum shows.

Regards,
Rod

RE: [Springframework-developer] polishing and new features - security model??????

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

> interceptor framework supports postHandle=20
> now in addition to preHandle, allowing e.g.=20
> for binding user contexts from a session=20
> attribute to a ThreadLocal in preHandle=20
> and removing it again in postHandle.

Argggh.... I just spent my time breaking my mind over the issue how to
do this (and shouting at the framework for not having
postHandlerInterceptors ;-). Then I get this email ;-). So to implement
the latest and greatest of my features, I will probably have a chance to
test this quite thoroughly tomorrow. Some of those features might - btw
- be very interesting for addition to Spring, but definitely not for
0.9.1 release!!!

Ahh, what the heck, why don't I just already put up the ideas, maybe
people have some interesting thoughts... What I'll describe below is
already implemented in a working prototype.

--- WARNING - NOT FOR THE 0.9.1 RELEASE, JUST A TWIST OF THE MIND ---

I've been struggling for ever with the question how to prevent certain
users from seeing or being able to edit certain data. And then I don't
mean complete objects, just bits of objects. For instance:
administrators can create and edit Account-objects, users in their turn
can only update their firstName-property and lastName-property
(contained by those accounts). I really don't want to - every time I
save the Account object - check if the user isInRole(user/administrator)
and check if the firstName-property and lastName-property has been set,
etcetera. I also don't want to have those checks in my
datamodel/objects. It would be perfect if this could done outside the
datamodel and also outside the businesslogic. Just like validation. Oh
yeah, I don't want to do it with database-views...

So today I had a huge fight (design sessions are always fights here, but
it's very constructive) with my colleague about this issue. We finally
came up with the idea to think up a generic Object/PropertyPermissions
framework, of which he would make the implementation that would set
permissions based on the combination of Object type and Role (contained
by the Principal).

To be able to use this in MVC (and more specifically: Spring), I have
devised something like the Validator (contained in a new package
com.interface21.security), called PropertyPermissionsResolver. This
works together with the PropertyPermissions interface and the
PropertyPermissions interface. All very abstract and to be implemented
just as the validator.

PropertyPermissions would apply to the complete Model (in the
ModelAndView) and objects in the model will dynamically be passed to the
PropertyPermissionInspector (having the same boolean supports()-method
as the Validator). So if no Inspector is defined for a certain Object,
no permission will be added (or nothing is accessible at all, this would
be configurable).

Views can use the information of the PropertyPermissions and stuff in
their logic to render things accordingly. To facilitate JSP Views I want
to a couple of method to the BindStatus object - or extending it for
this purpose - (specifically isVisible() and isEditable()) to be able to
use the BindStatus for this purpose as well=85 JSP code utilizing this
would somewhat look like this:

<spring:bind path=3D"Account.active">
	<c:if test=3D"${status.editable}">
		<intput type=3D"text" name=3D"<c:out
value=3D"${status.epxression}"/>" value=3D"<c:out
value=3D"${status.value}"/>">
	</c:if>
</spring:bind>
<spring:bind path=3D"Account.fistName">
	<c:if test=3D"${status.editable}">
		<input type=3D"text" name=3D"<c:out
value=3D"${status.epxression}"/> value=3D"<c:out =
value=3D"${status.value}"/>">
	</c:if>
</spring:bind>

The above code would result in two textfields for the administrator
(both active and firstName) and one textfield for anybody with role
'user' when applying the usecase mentioned above (if of course you would
be using the Role/ObjectType based security model!). So only one view,
one controller, one model but still hiding certain property from certain
users that are not allowed to see them (and a lot more possible
functionalities ;-).

Right now I've got things implemented for Roles/ObjectTypes and this
looks like the following. As you might see, nested property permission
are possible using this thing as well=85 This is all pretty specific for
our application and way of working, but the interfaces
(PropertyPermissions, Inspector, Resolver and stuff) and the complete
idea is especially suitable for addition in my opinion, even more since
Juergen just added the postHandle things, where this can take place...

<object-permission name=3D"jteam.site.data.Account">
        <!-- everybody is allowed to see everything -->
        <property-permission>
            <role-name>administrator</role-name>
            <role-name>employee</role-name>
            <property-name>*</property-name>
            <editable>true</editable>
            <visible>true</visible>
        </property-permission>
        <!-- the customer cannot edit an account -->
        <property-permission>
            <role-name>customer</role-name>
            <property-name>*</property-name>
            <editable>false</editable>
        </property-permission>
        <!-- define the properties that are nested -->
        <object-permission-ref property=3D"account"
ref=3D"jteam.site.data.Account"/>
</object-permission>

However, I've got a couple of issues hanging around=85
*	The BindStatus things are pretty JSP-specific of course. How to
use PropertyPermissions when one's View technology is Velocity? I don't
want to (before the view gets rendered) generate all PermissionsObjects
up front, because this is all nested and it could well be 100's of
objects each request (of which probably only 10% is actually used,
considering a form of 10 fields)
*	What to do with the PropertyPermissionsInspector. There's no
place - so far I can see - to put the PropertyPermissions in. I kind of
sense they should be part of the model (in the ModelAndView object), but
this of course is a major api-change. PropertyPermissions should be
usable in any view, not just for instance the JSP view. So somehow the
Inspector needs to be available at all times...
*	How to actually get in the functionality that it=92s not only
possible to see if a property is editable, but also to prevent the
setter from being called. I smell a bit of AOP here (and I'm not too
familiar with it yet), but is it possible to create advises and
interceptor dynamically using a security configuration file or
something?
*	How to get extra information in for use when developing custom
propertypermissioninspectors. Right now I need to have the principal to
determine the role of the user and I'm passing on the HttpServletRequest
to achieve this=85 But this does not feel right (see the methods below)

Phew=85 that's all basically. Below I'll insert the public API for the
object I've mentioned, just so you can take a look=85

/* this one is resembling Errors a lot */
Interface PropertyPermissions
---- // final static permission integer
---- boolean isVisible(String path)
---- boolean isEditable(String path)
---- boolean setNestedPath(Sring nested)
---- void permit(String field, int permissions)

/* this is the interface actually determining the permissions */
Interface PropertyPermissionInspector
---- boolean support(Class clzz)
---- /* passing on the servletrequest does not feel right, but see the
remark above */
---- PropertyPermissions determinePropertyPermissions(Object o,
HttpServletRequest req)

/* this is the to-be-configured collection of Inspector that will be
used
   to apply a security model to the complete Model(AndView), names are
crap by the way */
Class PropertyPermissionsResolver
---- /* setter for the propertypermission objects in the xxx-servlet.xml
*/
---- void setPropertyPermissionsInspector(List l)
---- /* finds inspector supporting given class and returns
PropertyPermissions */
---- PropertyPermissions getPropertyPermissions(request, response,
object)

This all would be used from a PostSecurityHandlerInterceptor which I
haven't created yet=85.

Opinions???

Alef

RE: [Springframework-developer] Current release plan

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

RXZlcnlib2R5LA0KDQpBcyBJIGp1c3Qgd3JvdGUgaW4gdGhlIHJlcGx5IHRvIEFsZWYncyAiUHJv
cGVydHlFZGl0b3JzIGluIEpTUHMiIHN1Z2dlc3Rpb24sIHdlIHdpbGwgdmVyeSBsaWtlbHkgcmVs
ZWFzZSBhIDAuOS4yIGF0IHRoZSBlbmQgb2YgQXVndXN0LCB3aXRoIGZ1cnRoZXIgcG9saXNoaW5n
IGFuZCBlbmhhbmNlbWVudHMuDQoNCkZZSSwgSSdsbCBiZSB0cmF2ZWxsaW5nIHRvIEF1c3RyYWxp
YSBmb3IgdGhlIHdob2xlIG9mIFNlcHRlbWJlciwgc28gSSdkIHByZWZlciB0byBnZXQgMC45LjIg
b3V0IGJlZm9yZSB0aGF0LCBhbmQgb3VyIGZpcnN0IG9yZy5zcHJpbmdmcmFtZXdvcmsgMS4wIFJD
IHJpZ2h0IGFmdGVyIG15IHJldHVybi4gSXMgYSAxLjAgUkMxIHRhcmdldCBhdCB0aGUgYmVnaW5u
aW5nIG9mIE9jdG9iZXIgZmluZSBmb3IgZXZlcnlib2R5PyBJIGhvcGUgaXQncyBub3QgdG9vIGxh
dGUsIGJ1dCB3ZSB3aWxsIG5lZWQgdGhlIHRpbWUgYW55d2F5IGZvciBkb2N1bWVudGF0aW9uIGFu
ZCBhbGwgdGhhdCBzdHVmZi4gMS4wIGZpbmFsIGNvdWxkIGJlIHBvc3NpYmxlIGluIE5vdmVtYmVy
IHRoZW4uDQoNCkJUVywgd2UgZG9uJ3QgKm5lZWQqIHRvIG1ha2UgU291cmNlRm9yZ2UgY2hhbmdl
IG91ciBDVlMgZGlyZWN0b3JpZXMgdG8gYXBwbHkgdGhlIHBhY2thZ2UgbmFtZSBjaGFuZ2UuIFdl
IGNvdWxkIGFsc28ga2VlcCB0aGUgY3VycmVudCAibWFpbiIgbW9kdWxlIGFzIGl0IGlzLCBpbmNs
dWRpbmcgYWxsIGl0cyB2ZXJzaW9uIGhpc3RvcnksIGFuZCBpbnRyb2R1Y2UgYSBuZXcgIm1haW4x
MCIgbW9kdWxlIHdpdGggYSBmcmVzaCBpbXBvcnQgb2YgYW4gb3JnLnNwcmluZ2ZyYW1ld29yayB2
ZXJzaW9uLiBUaGlzIHdvdWxkIGFsc28gbWFrZSBzZW5zZSBpbiB0ZXJtcyBvZiBkZWFkIGRpcmVj
dG9yaWVzIHRoYXQgYSBDVlMgdXBkYXRlIGFsd2F5cyB0cmF2ZXJzZXM6IFRoZXJlIHdvdWxkbid0
IGJlIGFueSB0aGVuLg0KDQpKdWVyZ2VuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
CkZyb206IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF0gDQpTZW50OiBXZWRuZXNkYXksIEp1bHkg
MzAsIDIwMDMgMTE6MzQgUE0NClRvOiBwcmlzZTAzQHNlbnRleC5uZXQ7IFNwcmluZyBEZXZlbG9w
ZXJzDQpTdWJqZWN0OiBSZTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIEN1cnJlbnQgcmVs
ZWFzZSBwbGFuDQoNCg0KSGkgVHJldm9yLA0KIA0KRmlyc3Qgb2YgYWxsLCBnb29kIHF1ZXN0aW9u
cyByZXNwLiBpbXBvcnRhbnQgb25lcyBpbmRlZWQhDQogDQo8cXVvdGU+DQoxLiBXaGF0IHN0aWxs
IG5lZWRzIHRvIGJlIGRvbmUgZm9yIDAuOS4xLiAgRnJvbSB0aGF0IGxpc3QsIHdoYXQgaXMgY3Vy
cmVudGx5DQoiYXNzaWduZWQiIHRvIHNvbWVvbmUgYW5kIHdoYXQgc3RpbGwgbmVlZHMgaGVscD8N
CjwvcXVvdGU+DQogDQpOb3QgYSBsb3QsIGFjdHVhbGx5LiBJdCdzIG1haW5seSBhYm91dCBwb2xp
c2hpbmcgdGhlIFBldGNsaW5pYyBhbmQgQ291bnRyaWVzIHNhbXBsZSBhcHBzLCBhbmQgdGVzdGlu
ZyB0aGUgY3VycmVudCBjb2RlYmFzZSBpbiBldmVyeW9uZSdzIG93biBwcm9qZWN0cy4gRXZlcnl0
aGluZyBzaG91bGQgYmUgYXNzaWduZWQgc28gZmFyLCBleGNlcHQgdGhlIGxhdHRlciBvZiBjb3Vy
c2UgOi0pDQogDQpJJ20gY3VycmVudGx5IHBvbGlzaGluZyBhIGxvdCBvZiB0aGUgc291cmNlIGNv
ZGUuIEkndmUgYWxzbyBhZGRlZCAyIG5ldyBmZWF0dXJlcyB0aGF0IGFyZW4ndCBjb21taXR0ZWQg
eWV0IGJ1dCB3aWxsIGJlIGJ5IHRoZSBlbmQgb2YgdGhpcyB3ZWVrLCBuYW1lbHkgSGliZXJuYXRl
IGZsdXNoIG1vZGUgc3VwcG9ydCBvbiBIaWJlcm5hdGVUZW1wbGF0ZSBhbmQgSGliZXJuYXRlSW50
ZXJjZXB0b3IsIGFuZCByZWFkLW9ubHkgdHJhbnNhY3Rpb25zIChzdXBwcmVzc2luZyBIaWJlcm5h
dGUgZmx1c2ggb24gdGhlIHRyYW5zYWN0aW9uIGxldmVsKS4gRnVydGhlcm1vcmUsIEkndmUgcmVm
aW5lZCBUcmFuc2FjdGlvbkludGVyY2VwdG9yIGFuZCBNYXBUcmFuc2FjdGlvbkF0dHJpYnV0ZVNv
dXJjZSBhIGJpdCwgc3VwcG9ydGluZyBtb3JlIGNvbmZpZ3VyYXRpb24gb3B0aW9ucyB0aGVuIGJl
Zm9yZS4NCiANCjxxdW90ZT4NCjIuIFNhbWUgYXMgIzEgYnV0IGZvciB0aGUgMS4wIHJlbGVhc2Uu
DQo8L3F1b3RlPg0KDQpUaGUgZmlyc3QgMS4wIFJDIHdpbGwgaW52b2x2ZSBhIHBhY2thZ2UgbmFt
ZSBjaGFuZ2UgZnJvbSBjb20uaW50ZXJmYWNlMjEgdG8gb3JnLnNwcmluZ2ZyYW1ld29yay4gQmVz
aWRlcyB0aGF0LCB0aGVyZSB3b24ndCBiZSBhIGxvdCBpbiB0ZXJtcyBvZiBuZXcgZmVhdHVyZXMg
LW1heWJlIGV2ZW4gbGVzcyB0aGFuIGZyb20gMC45IHRvIDAuOS4xLiBSb2QgbWlnaHQgYWxyZWFk
eSBpbnRyb2R1Y2Ugc29tZSBzb3VyY2UtbGV2ZWwgYXR0cmlidXRlIHN0dWZmIHRvIHRoZSBBT1Ag
ZnJhbWV3b3JrLCBidXQgdGhhdCBpc24ndCBhIHJlcXVpcmVtZW50IGF0IGFsbC4gUHJvcGVyIEpN
UyBhbmQgV2ViIFNlcnZpY2Ugc3VwcG9ydCBhcmUgY2FuZGlkYXRlcyB0b28gYnV0IGNhbiBlYXNp
bHkgd2FpdCB1bnRpbCAxLjEuDQogDQo8cXVvdGU+DQozLiBXaGF0IGlzIHRoZSB0YXJnZXQgdGlt
ZS1mcmFtZSBmb3IgdGhlIDAuOS4xIGFuZCAxLjAgcmVsZWFzZXMgKG9idmlvdXNseQ0KdGhpcyBp
cyBza2V0Y2h5IHNpbmNlIGl0J3MgInZvbHVudGVlciIgd29yaywgYnV0ICJndXQgZ3Vlc3NlcyIg
LSBwcm9iYWJseQ0KZnJvbSBKdWVyZ2VuIDopIC0gYmFzZWQgb24gd29yayBsZWZ0IGlzIHdoYXQg
SSdtIGhvcGluZyBmb3IuICBUaGUgcHJldmlvdXMNCmVzdGltYXRlIHdhcyB0aGUgMS4wUkMxIGJ5
IG5vdy4NCjwvcXVvdGU+DQogDQowLjkuMSBzaG91bGQgYmUgb3V0IGFueSBkYXkgbm93LiBJIGVu
Y291cmFnZSBldmVyeW9uZSB0byB0cnkgaXQgdGhlIGN1cnJlbnQgQ1ZTIHZlcnNpb24gYmVmb3Jl
IHRoZSB3ZWVrZW5kLiBBIHJlbGVhc2Ugc29tZSB0aW1lIG5leHQgd2VlayBzaG91bGQgcmVhbGx5
IGJlIGFjaGlldmFibGUuIFdlICpuZWVkKiB0byBnZXQgb3V0IGEgZm9sbG93LXVwIHJlbGVhc2Ug
cXVpY2tseSwgaWYganVzdCBiZWNhdXNlIG9mIGFsbCB0aGUgZW5oYW5jZW1lbnRzIHRvIHRoZSBI
aWJlcm5hdGUgc3VwcG9ydCB0aGF0IGhhdmUgYSBnb29kIGNoYW5jZSBvZiBnZXR0aW5nIGFkb3B0
ZWQgcHJvbXB0bHkuIE15IEhpYmVybmF0ZSBhcnRpY2xlIGluIHRoZSBjb21tdW5pdHkgYXJlYSBh
bmQgbXkgcG9zdGluZ3MgdG8gdGhlIEhpYmVybmF0ZSBmb3J1bSBoYXZlIGFscmVhZHkgYmVlbiBk
aXNjdXNzaW5nIHNvbWUgb2YgdGhlbSBmb3IgYSB3aGlsZS4NCg0KPHF1b3RlPg0KNC4gRnJvbSBK
dWVyZ2VuJ3MgZW1haWwgd2hpY2ggSSByZWZlcmVuY2VkLCBpdCBzdGF0ZXMgIkFzIGZhciBhcyBJ
IHNlZSwgd2UNCmRvbid0IG5lZWQgYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IGZvciAxLjAiLiAg
VGhlIG1haW4gdGhpbmcgaG9sZGluZyBtZQ0KYmFjayBmcm9tIGFkb3B0aW5nIHRoZSBjdXJyZW50
IGNvZGUgYmFzZSAoSSdtIGN1cnJlbnRseSB1c2luZyBhDQpwZXJzb25hbGx5LW1vZGlmaWVkIHZl
cnNpb24gb2YgMC44KSBpcyB0aGUgYW1vdW50IGFuZCBmcmVxdWVuY3kgb2YgY2hhbmdlcw0KdG8g
Y29yZSBmdW5jdGlvbmFsaXR5IGFuZCB0aGUgcHVibGljIGFwaS4gIFNvbWUgbmV3IGZlYXR1cmVz
IG9yIG1pbm9yIGJ1Zw0KZml4ZXMgYXJlIG9rL25vcm1hbCwgYnV0IHRoZXNlIHN3ZWVwaW5nIGNo
YW5nZXMgYXJlIGRlc3RydWN0aXZlIHRvDQpwcm9kdWN0aW9uIGNvZGUuICBIb3cgY2xvc2UgYXJl
IHdlIHRvIGZpbmFsaXppbmcgdGhlIHB1YmxpYyBhcGkgYW5kIHRoZSBjb3JlDQpjb2RlPyAgSXMg
aXQgbGlrZWx5IHRoYXQgdGhlc2UgbWFqb3IgY2hhbmdlcyBzaG91bGQgYmUgZG9uZSBmb3IgMC45
LjE/DQo8L3F1b3RlPg0KIA0KTWF5YmUgSSdtIHByb21pc2luZyB0b28gbXVjaCwgYnV0IEkgZG9u
J3Qgc2VlIGFueSBtYWpvciBjaGFuZ2VzIG9uIHRoZSBob3Jpem9uLiBUaGUgaW50cm9kdWN0aW9u
IG9mIHRoZSBuZXcgRFREIHdhcyBwcm9iYWJseSB0aGUgYmlnZ2VzdCBjaGFuZ2UgaW4gdGhlIGxh
c3QgZmV3IG1vbnRocywgZXZlcnl0aGluZyBlbHNlIHdhcyBqdXN0IGFib3V0IHNsaWdodCBjaGFu
Z2VzIHRvIHRoZSBwdWJsaWMgQVBJLiBJIGFncmVlIHRoYXQgd2UgbmVlZCBzdGFibGUgQVBJcyB0
aG91Z2ggdG8gYWxsb3cgcHJvZHVjdGlvbiBhcHBzIHRvIHJlbHkgb24gdGhlbSB3aXRob3V0ICph
bnkqIGhhc3NsZS4gMC45LjEgc2hvdWxkIGJlIGFzIHN0YWJsZSBhcyBjYW4gYmUgaW4gdGhhdCBy
ZXNwZWN0LCBiZXNpZGVzIHRoZSBwYWNrYWdlIG5hbWUgY2hhbmdlIGZvciAxLjAgUkMgd2hpY2gg
c2hvdWxkIGp1c3QgaW52b2x2ZSBhIHNlYXJjaC1hbmQtcmVwbGFjZS4NCg0KPHF1b3RlPg0KVG8g
ZXhwYW5kIG9uIG15IGZvdXJ0aCBxdWVzdGlvbiB3aXRoIGEgcmVjb21tZW5kYXRpb24gKGhvcGVm
dWxseSBpdCBtYWtlcw0Kc2Vuc2UgdG8gZXZlcnlvbmUpLiAgSWYgcG9zc2libGUgd2Ugc2hvdWxk
IGZpbmFsaXplIHRoZSBwdWJsaWMgYXBpIGZvcg0KdmVyc2lvbiAwLjkuMSByYXRoZXIgdGhhbiBh
dCB0aGUgMS4wUkMxLiAgVGhpcyB3aWxsIGFsbG93IHVzYWdlIGluIG5ldw0KZGV2ZWxvcG1lbnQg
d2l0aG91dCBmZWFyIG9mIGluY29tcGF0aWJpbGl0aWVzIGluIHRoZSBuZXh0IGNvdXBsZSBtb250
aHMuICguLi4pDQo8L3F1b3RlPg0KIA0KQXMgSSBpbmRpY2F0ZWQgYWJvdmUsIEkgZnVsbHkgYWdy
ZWUuIFdlJ3ZlIGJlZW4gY2hhbmdpbmcgb3VyIGFwcHMgYXQgd2VyazNBVCBxdWl0ZSBvZnRlbiB0
b28sIGl0IHdvdWxkIGJlIGZpbmUgaXQgdGhhdCB3b3VsZG4ndCBiZSBuZWNlc3NhcnkgYW55bW9y
ZSBhcyBzb29uIGFzIHBvc3NpYmxlLiBBbmQgSSdkIHJlYWxseSBsaWtlIHRvIGdldCB5b3Ugb24g
Ym9hcmQgYWdhaW4sIGluIHRlcm1zIG9mIHdvcmtpbmcgd2l0aCBhIGN1cnJlbnQgU3ByaW5nIHZl
cnNpb24gOi0pDQogDQpSZWdhcmRzLA0KSnVlcmdlbg0KThhIU17pmopbKXsoW1p6builtAQ0RNes
dyXYpzZpF2wRJngrbGp3RWp6ejAOJ1rJqXp7XjB2XBNiStudRE4bbdqy3rVicksmDQo/xrRdNE3a
vd2KWt63Tk01SgdqZx16eCVS2pkoR15obHEHem0/WCgefnp3WGI/B2pnHXoNCg==