springframework-developer — Spring Framework developers list

Re: [Springframework-developer] JDBC Insert functionality

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

Ken:

Good points.

> I would like to propose a bit of refactoring to the incrementers class 
> hierarchy to enhance pluggability. As it stands now, there is a lot of 
> common functionality that is redundant in the concrete classes and could 
> be pushed up to the AbstractDataFieldMaxValueIncrementer class:
> 
> 1. cacheSize field and setter
> 2. prefixWithZero field and setter
> 3. dataSource field and setter
> 4. sequenceName (Oracle) or tableName (Mysql and Hsql) field and setter, 
> perhaps renamed to incrementerName
> 

I think it is a good idea to enhance the pluggability for these implementations.
 What we need to be able to set is Data Source, Sequence/Table Name and Column
Name.  When Column Nam is not needed, we could just leave it as null.  If we use
a standard name for the column, then it would be harder to use our framework on
already existing databases that use a sequenece table.  I believe the way we are
doing it for MySQL is a fairly standard approach that is already used by many
developers.

> NOTE: The interface for RdmsMaxValueIncrementer is inconsistent with the 
> others and out-of-date. As it is also unsafe, perhaps it should be 
> removed altogether. It should at least be brought up-to-date.
> 

I would vote for removing it.

--Thomas

[Springframework-developer] JDBC Insert functionality

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

On Friday, I was working on an HSQL version of the incrementer but had 
not completed the work before leaving for an extended holiday. I was 
intending to use it so as to provide support in the Petclinic demo for 
both Mysql and Hsql. I was pleased to find it done when I got back :=). 
I have built the demo using both db's now and the insert use case works 
well on both versions.

I would like to propose a bit of refactoring to the incrementers class 
hierarchy to enhance pluggability. As it stands now, there is a lot of 
common functionality that is redundant in the concrete classes and could 
be pushed up to the AbstractDataFieldMaxValueIncrementer class:

1. cacheSize field and setter
2. prefixWithZero field and setter
3. dataSource field and setter
4. sequenceName (Oracle) or tableName (Mysql and Hsql) field and setter, 
perhaps renamed to incrementerName

NOTE: The interface for RdmsMaxValueIncrementer is inconsistent with the 
others and out-of-date. As it is also unsafe, perhaps it should be 
removed altogether. It should at least be brought up-to-date.


I have provided an example to show how these changes can benefit the 
user (developer):


In Petclinic, I provide beans in applicationContext.xml to configure the 
dataSource and incrementer for my DAO bean. At present, I only have 1 
insert use case, addVisit.

NOTE: I have elected to show the use of pooled datasources in a later 
iteration of the demo.


For mysql:

  <bean name="dataSource" 
class="com.interface21.jdbc.datasource.DriverManagerDataSource" >
    <property name="driverClassName">com.mysql.jdbc.Driver</property>
    <property name="url">jdbc:mysql://localhost:3306/petclinic</property>
    <property name="username">pc</property>
    <property name="password">pc</property>
  </bean>
   
  <bean name="visitIncrementer" 
class="com.interface21.jdbc.core.support.MySQLMaxValueIncrementer" >
    <property name="dataSource" beanRef="true">dataSource</property>
    <property name="tableName">visits_seq</property>
    <property name="columnName">seq</property>
  </bean>

 
For hsql:

  <bean name="dataSource" 
class="com.interface21.jdbc.datasource.DriverManagerDataSource" >
    <property name="driverClassName">org.hsqldb.jdbcDriver</property>
    <property name="url">jdbc:hsqldb:hsql://localhost:9001</property>
    <property name="username">sa</property>
  </bean>
   
  <bean name="visitIncrementer" 
class="com.interface21.jdbc.core.support.HsqlMaxValueIncrementer" >
    <property name="dataSource" beanRef="true">dataSource</property>
    <property name="tableName">visits_seq</property>
  </bean>


My DAO bean:

  <bean name="clinicDAO" class="petclinic.dao.ClinicJdbcDAO" >
    <property name="dataSource" beanRef="true">dataSource</property>
    <property name="visitIncrementer" 
beanRef="true">visitIncrementer</property>
  </bean>
   


As it stands, I need to configure a separate incrementer bean for each 
new insert use case and add a field and setter for each one to the DAO 
or alternatively embed code using the specific concrete class names in 
the DAO which is now generic JDBC.


What I would like to do is something like this:

  <bean name="incrementer"
        singleton="false"
        
class="com.interface21.jdbc.core.support.MySQLMaxValueIncrementer" > 
<!-- or some other concrete incrementer -->
    <property name="dataSource" beanRef="true">dataSource</property>
  </bean>
 
  <bean name="clinicDAO" class="petclinic.dao.ClinicJdbcDAO" >
    <property name="dataSource" beanRef="true">dataSource</property>
    <property name="incrementer" beanRef="true">incrementer</property>
  </bean>
   
 
I could then use this as a prototype bean for each of the insert use 
cases which would then instantiate a prototype object using getBean() on 
an AbstractDataFieldMaxValueIncrementer  reference, subsequently setting 
the incrementerName property for that object for the particular use case 
in code. The code remains completely generic and all the database 
configuration/selection is done in xml. A problem remains with the Mysql 
version in that the columnName property needs to be set. This could be 
accomplished without breaking genericity by conventionally using a 
default columnName, such as "seq".



What do you think ???


Ken

Re: [Springframework-developer] New DTD

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

Advance warning: Unless anyone has a strong objection, I'm 
going to check in the changes to XmlBeanFactory and a revised 
DTD in the next couple of days. 

Following our discussions:
- there will be a new <collection> element. A <property> must 
contain a <collection>,<ref> or <value>.
- This approach will allow <map> elements to be added fairly 
easily. However I don't have time to do this in the first cut.
- This is *not* backward compatible. Name -> id attribute, 
<property> elements can't contain text. I'm dropping 
forgiving parsing.
- Validation will be enforced. This means we need to think 
about where we put the DTD. (Juergen, how's your URIResolver 
coming on?) 

I'm currently changing all the XML files in the test suite to 
the new format. I've already tested the changes to 
XmlBeanFactory itself.

Although the new format is more verbose, I think it is more 
maneagable, and the changes are definitely worthwhile. 
Validation of id refs works nicely, and even in the fairly 
primitive Eclipse XML editor I use, I get prompted for 
completions as I author the XML.

THESE CHANGES WILL BREAK ALL EXISTING XML FILES. However, the 
changes should be fairly straightforward.

Regards,
Rod

[Springframework-developer] =?iso-8859-1?Q?UTF-8?=

[=?iso-8859-1?Q?<jp....@ti...>]

Hello Everybody,=0D=0A=0D=0AThis discussion is clearly not intended for 0=
.8 release.=0D=0A=0D=0AWe have now a pretty localization handling which w=
orks fine ... as long as we have only to manage ISO-LATIN-1 compatible la=
nguages.=0D=0A=0D=0AA few issues have to be solved to propose an UTF-8 ca=
pable framework. =0D=0A- The HttpResponse has to be turnable to UTF-8 usi=
ng the right Writer.=0D=0A- The Binder has to be able to detect the used =
coding from the request and work accordingly or even using a servlet filt=
er.=0D=0A- With Unicode capable databases, the data has to be stored and =
retrieved correctly.=0D=0A=0D=0AWhat I used for now is a crazy workaround=
. If anyone has a practice in this area, any help is welcome. It could be=
 a good job for the framework. I can work on but have some good practice =
lacks on this topic.=0D=0A=0D=0ARegards,=0D=0AJean-Pierre=0D=0A=0D=0A=0A=0A=
********** SPECIAL ADSL **********=0AL'ADSL =E0 partir de 15,95 EUR/mois =
et le modem ADSL offert ?  C'est en exclusivit=E9 chez Tiscali !=0APour p=
rofiter de cette offre, cliquez ici: http://register.tiscali.fr/adsl/=0AO=
ffre soumise =E0 conditions.=0A

RE : [Springframework-developer] Problem with MySqlMaxValueIncrementer

[JP P. <jp....@ti...>]

It was a good idea to use a not transactional table type for the
increment. It's the simplest way.

Jean-Pierre


> -----Message d'origine-----
> De : spr...@li...=20
> [mailto:spr...@li...]
>  De la part de tri...@tr...
> Envoy=E9 : samedi 31 mai 2003 20:12
> =C0 : tri...@tr...
> Cc : Isabelle Muszynski;=20
> spr...@li...
> Objet : Re: [Springframework-developer] Problem with=20
> MySqlMaxValueIncrementer
>=20
>=20
> Isabelle and All,
>=20
> I have commited my changes to the MySQLMaxValueIncrementer. =20
>=20
> You now declare the "sequence" table like this:
> =20
>    create table sequence (id int not null) type=3DMYISAM;
>    insert into sequence values(0);
>=20
> No need for auto-increment for either table.  The=20
> "type=3DMYISAM" is nor=20
> necessary, but it underscores that this table is not part of=20
> any transaction.
>=20
> Everything else works the same.
>=20
> I changed the increment logic to use
>=20
>    update sequence set id=3Dlast_insert_id(id+?);
>=20
> where ? is the batch size.
>=20
> This works fine during my testing.  Let me know if you run in=20
> to any problems.
>=20
> I'll make some changes to the OracleSequenceMaxValueIncrementer next.
>=20
> --Thomas
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!=20
> http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5
>=20
> _______________________________________________
>=20
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

RE : [Springframework-developer] Authentication and authorization

[JP P. <jp....@ti...>]

Hi Juergen,

I used the J2EE authentication with JDBC repository, checking in the
front of ServletController if the user was logged in without having his
data in session to put them.
But I will not continue to use this method. I have also thinked on the
filter method but not on HandlerAdapter. The two methods seem be the
more practical, but regardless of the chosen method, what URL can be
only reached by logged users or having a certain role has to be
extracted from the code and put in a file description (or SGBD?).
Perhaps in the ApplicationContext.xml or a specific file? If we would
use regular expressions, will we have to use external libs like ORO?

Regards,
Jean-Pierre


> -----Message d'origine-----
> De : spr...@li...=20
> [mailto:spr...@li...]
>  De la part de j=FCrgen h=F6ller [werk3AT]
> Envoy=E9 : lundi 2 juin 2003 13:53
> =C0 : spr...@li...
> Objet : RE: [Springframework-developer] Authentication and=20
> authorization
>=20
>=20
> Rod, everyone,
>=20
> I've just analyzed existing Spring mechanisms for=20
> authorization checks.
>=20
> Let's assume a simple login case: An application uses a=20
> LoginController mapped to "/login", displaying a login form,=20
> performing custom authentication in its performSubmit=20
> implementation, and redirecting to some main menu on=20
> successful submit. In the course of the latter, it adds an=20
> attribute representing the current user's settings to the=20
> session, maybe even just a "loggedIn" with value Boolean.TRUE=20
> to mark the session as logged in. A pseudo example using=20
> AbstractFormController (of course, SimpleFormController would=20
> fit too, not leveraging successView though):
> ......

RE : [Springframework-developer] paged lists

[JP P. <jp....@ti...>]

Hi Juergen, everybody,

I have tested and completed the pagedlist.

- Some "oldies" were in the JSP.
- The locale is now active (en, fr, de).
- The detail page can be reached from the list.
- The filter must redefine equals() and hashcode() as in the test. We =
could provide an abstract class for filters using reflection for =
redefining equals and hashcode?
- The refreshableListHolder sets now the page to 0 if the refresh is due =
to the filter to avoid being over the last page.

The online demo and war download can be found at =
http://tech.jppawlak.info/spring/samples.htm
(the site is now reachable, I didn't add the CNAME entry to the DSN last =
week).=20

I didn't change the CookieLocaleResolver, but it seems to me than adding =
setPath and getPath methods will be useful as well as setting by default =
the path to "/". Generally we want to change the locale for the whole =
application and without this, it's only the part in the current url and =
subs which is involved.

Regards,
Jean-Pierre


> -----Message d'origine-----
> De : spr...@li...=20
> [mailto:spr...@li...]
>  De la part de j=C3=BCrgen h=C3=B6ller [werk3AT]
> Envoy=C3=A9 : lundi 2 juin 2003 11:49
> =C3=80 : spr...@li...
> Objet : FW: [Springframework-developer] paged lists
>=20
>=20
> Resending with an even smaller JAR file without class files -=20
> the former didn't get throught to the list because of the=20
> attachment size...
>=20
>=20
> -----Original Message-----
> From: j=C3=BCrgen h=C3=B6ller [werk3AT]=20
> Sent: Tuesday, May 27, 2003 8:05 PM
> To: springframework-developer
> Subject: RE: [Springframework-developer] paged lists
>=20
>=20
> I've attached the reworked version of the paged list example.=20
> I've omitted all the JAR files to keep the JAR small. You'll=20
> still need a current spring-full, log4j, and jstl.jar +=20
> standard.jar for Apache's JSTL implementation.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: j=C3=BCrgen h=C3=B6ller [werk3AT]=20
> Sent: Monday, May 26, 2003 10:07 PM
> To: jp....@ti...
> Cc: springframework-developer
> Subject: Re: [Springframework-developer] paged lists
>=20
>=20
> Jean-Pierre,
> =20
> I've just committed my reworked version.
> =20
> There's now a SortDefinition interface in=20
> com.interface21.beans, with a MutableSortDefinition=20
> implementation. The sort methods have moved from BeanUtils to=20
> PropertyComparator.
> =20
> PagedListHolder is quite similar to before, targetted an=20
> immutable lists, but with binding-friendly sorting support=20
> via SortDefinition. I've turned PageListAutoHolder into=20
> RefreshablePagedListHolder, adding refreshing from a source=20
> provider on changed Locale or filter. Filter is a generic=20
> Object property now, allowing for any filter settings being=20
> passed through to the respective source provider.
> =20
> I'll send the adapted version of your example app to the list=20
> tomorrow. There haven't been many changes to the controller=20
> and view, but why figure out yourself? :-)
> =20
> Regards,
> Juergen
> =20
> =20
>=20
> 	-----Urspr=C3=BCngliche Nachricht-----=20
> 	Von: jp....@ti... [mailto:jp....@ti...]=20
> 	Gesendet: So 25.05.2003 15:08=20
> 	An: j=C3=BCrgen h=C3=B6ller [werk3AT]=20
> 	Cc: springframework-developer=20
> 	Betreff: Re: [Springframework-developer] paged lists
> =09
> =09
>=20
> 	Hi J=C3=BCrgen,
> =09
> 	Your suggests are very welcome. As you have a  better=20
> knowledge ob the whole Spring framework, you seen quickly=20
> better interaction use. I am not at home, It seems you are=20
> already making the change. If you expext anything from me,=20
> talk me just about.=20
> =09
> 	Regards,
> 	Jean-Pierre
> =09
> 	---------- Initial Header -----------
> =09
> 	From      :=20
> spr...@li...
> 	To          : "JP Pawlak"=20
> <jp....@ti...>,"Spring Developers"=20
> <spr...@li...>
> 	Cc          :
> 	Date      : Sun, 25 May 2003 14:48:34 +0200
> 	Subject : Re: [Springframework-developer] paged lists
> =09
> 	Hi Jean-Pierre,
> =09
> 	BTW, the tests have all worked for me on Friday - I'll=20
> recheck tomorrow.
> =09
> 	Regarding PagedListAutoHolder: I appreciate its added=20
> functionality. If I understand correctly, it's targetted at=20
> easy usage in a web controller. My initial PagedListHolder=20
> was just a first take, drawn from an application project. I'm=20
> very much for working all of this into a refined version,=20
> even before 0.8. I'll probably use it in our application project too.
> =09
> 	---
> =09
> 	I've got some concrete issues:
> =09
> 	- Generally, we should try to use data binding wherever=20
> possible, to keep the model and the actions as OO resp.=20
> bean-style as possible. I'm not a great fan of manual=20
> parameter parsing (have used it far too many times myself),=20
> be it from the ServletRequest or from a String-based=20
> parameter map. Spring's ServletRequestDataBinder allows for=20
> very powerful binding of request parameters to bean=20
> instances, even one to request to multiple beans. Manual=20
> String parameter evaluation doesn't belong in a proper model=20
> object, IMO.
> =09
> 	- getMaxDisplayPages, getFirstDisplayPage,=20
> getLastDisplayPage should probably be called=20
> getMaxLinkedPages, getFirstLinkedPage, getLastLinkedPage - as=20
> they aren't really displayed themselves but rather just=20
> linked from the currently displayed page.
> =09
> 	- I'd like to turn your "Sort" inner class into a=20
> generic com.interface21.beans.SortDefinition interface, and=20
> offer an accompanying=20
> BeanUtils.sortByProperty(List,SortDefinition) method. Your=20
> current Sort implementation could serve as=20
> DefaultSortDefinition implementation.
> =09
> 	- As you've addressed with extendedInfo, reloading can=20
> depend on various specific parameters. But filtering could be=20
> based not only on per-field matching values but on regular=20
> expressions etc. A generic "filter" property of type Object=20
> will allow the controller to store a state object=20
> representing the current filter settings, combining your=20
> filterMap and extendedInfo in one generic Object. Note that=20
> PagedListHolder does not and should not need to know about=20
> the semantics of "filter".
> =09
> 	- Some properties represent List meta data: "sort" of=20
> type SortDefinition, "filter" of type Object, "locale" of=20
> type Locale. These can easily be included in PagedListHolder,=20
> just like the linked pages support too (in the end, let's=20
> merge PagedListHolder and PagedListAutoHolder - we probably=20
> don't need both). PagedListSourceProvider would have a=20
> generic loadList(Object Filter, Locale locale) then.
> =09
> 	- PagedListHolder properties like pageSize, pageNr,=20
> maxLinkedPages should be populated via binding (that's how my=20
> initial version was meant to be used). Let's treat=20
> PagedListHolder as a form bean, with request parameters=20
> getting bound to it on every submit - no String parameter=20
> parsing, no Integer.parseInt. The same applies to "sort" and=20
> "filter": A controller can set specific instances to the=20
> PagedListHolder instance on setup. These instances can be=20
> populated via the same binding step, using nested paths like=20
> "sort.ascending" etc.
> =09
> 	- PagedListHolder's refresh method should do equals=20
> checks on "sort" and "filter" (using stored copies from the=20
> last refresh), and perform resorting resp. reloading if=20
> necessary (setting current versions as stored copies). Thus,=20
> a controller should invoke refresh after each bean=20
> population, i.e. on each request. A real refresh can be=20
> enforced by a respective request parameter, but this should=20
> be checked by the specific web controller, triggering a=20
> refresh(boolean enforce) call with true then.
> =09
> 	- All things considered, the unified PagedListHolder=20
> will not need to know anything about request parameters.=20
> PagedListAutoHolder's xxxParam properties and its quite=20
> lengthy execute method aren't necessary then, most stuff can=20
> work via data binding and refresh. If one wants to use=20
> different request parameters, one can always perform manual=20
> post-binding, but the bean property names should be pretty=20
> straightforward as parameter names anyway. The binding paths=20
> match the JSTL EL expressions nicely, like "sort.ascending".
> =09
> 	---
> =09
> 	A controller implementation is as simple as before. It=20
> just needs to trigger the binding and call the refresh method=20
> afterwards, instead of the current execute call. The=20
> respective code in your PagedListController example would=20
> look about as follows:
> =09
> 	public ModelAndView showMain(HttpServletRequest=20
> request, HttpServletResponse response) {
> 	  PagedListAutoHolder listHolder =3D
> 	   =20
> (PagedListAutoHolder)request.getSession(true).getAttribute(COU
> NTRIES_ATTR);
> 	  if (null =3D=3D listHolder) {
> 	    listHolder =3D=20
> (PagedListAutoHolder)this.getApplicationContext().getBean("aut
oListHolder");
> 	    listHolder.setSourceProvider(new CountriesProvider());
> 	    listHolder.setFilter(new CountriesFilter());
> 	    listHolder.setSort(new DefaultSortDefinition());
> 	   =20
> request.getSession(true).setAttribute(COUNTRIES_ATTR, listHolder);=20
> 	  }
> 	  BindException ex =3D BindUtils.bind(request,=20
> listHolder, "countries");
> 	  boolean forceRefresh =3D=20
> request.getParameter("forceRefresh) !=3D null;
> 	  listHolder.refresh(forceRefresh);
> 	  return new ModelAndView("mainView", ex.getModel());
> 	}
> =09
> 	public class CountriesFilter {
> 	  private String name;
> 	  private String code;
> 	  public String getName() {
> 	    return name;
> 	  }
> 	  public vois setName(String name) {
> 	    this.name =3D name;
> 	  }
> 	  public String getCode() {
> 	    return code;
> 	  }
> 	  public vois setCode(String code) {
> 	    this.code =3D code;
> 	  }
> 	}
> =09
> 	Filtering doesn't work via parameter names that serve=20
> as filter names anymore, but with a nested "filter" object of=20
> type CountriesFilter. So your main.jsp would need to use=20
> "countries.filter.code" EL for matching, sending=20
> "filter.code" as request parameter name for changing. The=20
> same applies to sorting, using the nested "sort" object: e.g.=20
> "countries.sort.ascending" EL for evaluation (just like in=20
> your current version), "sort.ascending" as request parameter name.
> =09
> 	---
> =09
> 	What do you think? I'm keen on applying these changes=20
> promptly, if you don't mind, if possible already tomorrow.=20
> BTW, I'm writing this on a non-development PC at home, so I=20
> haven't actually prototyped the design, but I expect it to=20
> work nicely. We should end up with significantly less and=20
> more maintainable code, I hope.
> =09
> 	Regards,
> 	Juergen
> =09
> =09
> =09
> 	        -----Urspr=C3=BCngliche Nachricht-----
> 	        Von: JP Pawlak [mailto:jp....@ti...]
> 	        Gesendet: Fr 23.05.2003 22:20
> 	        An: Spring Developers
> 	        Cc:
> 	        Betreff: [Springframework-developer] paged lists
> 	      =20
> 	      =20
> =09
> =09
> 	        Hi,
> 	      =20
> 	        Excuse me from disturbing from fundamental=20
> issues like the KeyBinder
> 	        posted by Isabelle and the broken tests I've=20
> just posted.
> 	      =20
> 	        As I talked about, I have added three files:
> 	        In src:
> 	           -=20
> com.interface21.util.PagedListAutoHolder.java (Class derived from
> 	        PagedListHolder)
> 	           -=20
> com.interface21.util.PagedListSourceProvider.java (Interface)
> 	        in test:
> 	           -=20
> com.interface21.util.PagedListAutoHolderTests.java (Class)
> 	      =20
> 	        This all for easy use of a more powerfull paged List.
> 	        The javadoc and eventually test source will=20
> normally suffice to
> 	        understand the use.
> 	        Nevertheless, if I will not be impacted by the=20
> current test issues, I
> 	        will try to provide a tiny sample application=20
> for demonstrating.
> 	      =20
> 	        After 0.8 will be released, I could have some=20
> help for rewieving the
> 	        javadoc comments as my English is very far from perfect.
> 	      =20
> 	        Regards,
> 	        ______________________________
> 	        Jean-Pierre Pawlak
> 	        jp....@ti...
> 	       =20
> 	      =20
> 	      =20
> 	      =20
> 	      =20
> 	        -------------------------------------------------------
> 	        This SF.net email is sponsored by: ObjectStore.
> 	        If flattening out C++ or Java code to make your=20
> application fit in a
> 	        relational database is painful, don't do it!=20
> Check out ObjectStore.
> 	        Now part of Progress Software.=20
> http://www.objectstore.net/sourceforge
> 	       =20
> _______________________________________________
> 	        Springframework-developer mailing list
> 	        Spr...@li...
> 	       =20
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 	      =20
> =09
> =09
> =09
> 	********** SPECIAL ADSL **********
> 	L'ADSL =C3=A0 partir de 15,95 EUR/mois et le modem ADSL=20
> offert ?  C'est en exclusivit=C3=A9 chez Tiscali !
> 	Pour profiter de cette offre, cliquez ici:=20
> http://register.tiscali.fr/adsl/
> 	Offre soumise =C3=A0 conditions.
> =09
> =09
> =09
>=20
> N=18HY=DE=B5=E9=9A=8AX'un7+h=1F~V
> ./Z(uh=1E=CA=8Bje=C6=AD=DF=8A=D8=A7jj=D8=A8]j=D6=9Bj=C7=A2vv
> =179r=D4=AD
> Z=1F> ,J=DE=86i0=E2=80=A0yl=DE=9D=7Fq =DA=99(G^hj)b	b=D4=A9)~{
> +=D7=AFzZ)zb,y+=DE=B6=1Bm+-.=C7=9F=1E=7F+-b=D8=A7~=EC=A6=B8=DA=99(G^h
>=20

RE: [Springframework-developer] Authentication and authorization

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

Um9kLCBldmVyeW9uZSwNCg0KSSd2ZSBqdXN0IGFuYWx5emVkIGV4aXN0aW5nIFNwcmluZyBtZWNo
YW5pc21zIGZvciBhdXRob3JpemF0aW9uIGNoZWNrcy4NCg0KTGV0J3MgYXNzdW1lIGEgc2ltcGxl
IGxvZ2luIGNhc2U6IEFuIGFwcGxpY2F0aW9uIHVzZXMgYSBMb2dpbkNvbnRyb2xsZXIgbWFwcGVk
IHRvICIvbG9naW4iLCBkaXNwbGF5aW5nIGEgbG9naW4gZm9ybSwgcGVyZm9ybWluZyBjdXN0b20g
YXV0aGVudGljYXRpb24gaW4gaXRzIHBlcmZvcm1TdWJtaXQgaW1wbGVtZW50YXRpb24sIGFuZCBy
ZWRpcmVjdGluZyB0byBzb21lIG1haW4gbWVudSBvbiBzdWNjZXNzZnVsIHN1Ym1pdC4gSW4gdGhl
IGNvdXJzZSBvZiB0aGUgbGF0dGVyLCBpdCBhZGRzIGFuIGF0dHJpYnV0ZSByZXByZXNlbnRpbmcg
dGhlIGN1cnJlbnQgdXNlcidzIHNldHRpbmdzIHRvIHRoZSBzZXNzaW9uLCBtYXliZSBldmVuIGp1
c3QgYSAibG9nZ2VkSW4iIHdpdGggdmFsdWUgQm9vbGVhbi5UUlVFIHRvIG1hcmsgdGhlIHNlc3Np
b24gYXMgbG9nZ2VkIGluLiBBIHBzZXVkbyBleGFtcGxlIHVzaW5nIEFic3RyYWN0Rm9ybUNvbnRy
b2xsZXIgKG9mIGNvdXJzZSwgU2ltcGxlRm9ybUNvbnRyb2xsZXIgd291bGQgZml0IHRvbywgbm90
IGxldmVyYWdpbmcgc3VjY2Vzc1ZpZXcgdGhvdWdoKToNCg0KcHVibGljIGNsYXNzIExvZ2luQ29u
dHJvbGxlciBleHRlbmRzIEFic3RyYWN0Rm9ybUNvbnRyb2xsZXIgew0KCXB1YmxpYyBMb2dpbkNv
bnRyb2xsZXIoKSB7DQoJCXNldENvbW1hbmRDbGFzcyhMb2dpbkZvcm0uY2xhc3MpOw0KCQlzZXRC
ZWFuTmFtZSgibG9naW5Gb3JtIik7DQoJfQ0KCXByb3RlY3RlZCBNb2RlbEFuZFZpZXcgc2hvd0Zv
cm0oSHR0cFNlcnZsZXRSZXF1ZXN0IHJlcXVlc3QsIEh0dHBTZXJ2bGV0UmVzcG9uc2UgcmVzcG9u
c2UsIEJpbmRFeGNlcHRpb24gZXJyb3JzKSB7DQoJCXJldHVybiBzaG93Rm9ybShyZXF1ZXN0LCBl
cnJvcnMsICJsb2dpbkZvcm1WaWV3Iik7DQoJfQ0KCXByb3RlY3RlZCBNb2RlbEFuZFZpZXcgcHJv
Y2Vzc1N1Ym1pdChIdHRwU2VydmxldFJlcXVlc3QgcmVxdWVzdCwgSHR0cFNlcnZsZXRSZXNwb25z
ZSByZXNwb25zZSwgT2JqZWN0IGNvbW1hbmQsIEJpbmRFeGNlcHRpb24gZXJyb3JzKSB7DQoJCUxv
Z2luRm9ybSBsb2dpbkZvcm0gPSAoTG9naW5Gb3JtKSBjb21tYW5kOw0KCQlpZiAobG9naW5TZXJ2
aWNlLmxvZ2luKGxvZ2luRm9ybS5nZXRVc2VybmFtZSgpLCBsb2dpbkZvcm0uZ2V0UGFzc3dvcmQo
KSkpIHsNCgkJCXJlcXVlc3QuZ2V0U2Vzc2lvbigpLnNldEF0dHJpYnV0ZSgibG9nZ2VkSW4iLCBC
b29sZWFuLlRSVUUpOw0KCQkJcmVzcG9uc2Uuc2VuZFJlZGlyZWN0KCIvbWFpbm1lbnUiKTsNCgkJ
CXJldHVybiBudWxsOw0KCQl9DQoJCWVsc2Ugew0KCQkJcmV0dXJuIHNob3dGb3JtKHJlcXVlc3Qs
IHJlc3BvbnNlLCBlcnJvcnMpOw0KCQl9DQoJfQ0KCXB1YmxpYyBzdGF0aWMgY2xhc3MgTG9naW5G
b3JtIHsNCgkJcHJpdmF0ZSBTdHJpbmcgdXNlcm5hbWU7DQoJCXByaXZhdGUgU3RyaW5nIHBhc3N3
b3JkOw0KCQkvLyBnZXR0ZXJzL3NldHRlcnMgZm9sbG93aW5nDQoJfQ0KfQ0KDQpTbyBob3cgdG8g
cGVyZm9ybSBhdXRoZW50aWNhdGlvbiBjaGVja3MgZm9yIGFsbCBvdGhlciBjb250cm9sbGVycz8g
TGV0J3MgYXNzdW1lIHRoYXQgYWxsIG9mIHRoZW0gcmVxdWlyZSBhIHN1Y2Nlc3NmdWwgbG9naW4s
IGFuZCBzaG91bGQgcmVkaXJlY3QgdG8gdGhlIGxvZ2luIGNvbnRyb2xsZXIgaWYgdGhlIHVzZXIg
aXNuJ3QgbG9nZ2VkIGluLiBBbmQgd2UnZCBsaWtlIHRvIGF2b2lkIGhhdmluZyB0byBjaGVjayB0
aGUgc2Vzc2lvbiBhdHRyaWJ1dGUgaW4gZXZlcnkgY29udHJvbGxlciBpbXBsZW1lbnRhdGlvbi4g
VGhlcmUgYXJlIG51bWVyb3VzIGV4aXN0aW5nIGhvb2tzIGZvciB0aGlzLCBhbGwgb2YgdGhlbSBs
ZXR0aW5nIG9ubHkgTG9naW5Db250cm9sbGVyIHRocm91Z2ggaWYgdGhlICJsb2dnZWRJbiIgc2Vz
c2lvbiBhdHRyaWJ1dGUgaXNuJ3QgYXZhaWxhYmxlOg0KDQoxLiB1c2luZyBhIHN0YW5kYXJkIFNl
cnZsZXQgZmlsdGVyLCByZWRpcmVjdGluZyB0byBsb2dpbiAob3Igc2VuZGluZyBhbiBlcnJvcikg
aWYgbm90IGF1dGhvcml6ZWQ6DQoNCnB1YmxpYyBjbGFzcyBMb2dpbkhhbmRsZXJGaWx0ZXIgaW1w
bGVtZW50cyBGaWx0ZXIgew0KCXB1YmxpYyB2b2lkIGRvRmlsdGVyKFNlcnZsZXRSZXF1ZXN0IHJl
cXVlc3QsIFNlcnZsZXRSZXNwb25zZSByZXNwb25zZSwgRmlsdGVyQ2hhaW4gZmlsdGVyQ2hhaW4p
IHsNCgkJSHR0cFNlcnZsZXRSZXF1ZXN0IGh0dHBSZXF1ZXN0ID0gKEh0dHBTZXJ2bGV0UmVxdWVz
dCkgcmVxdWVzdDsNCgkJSHR0cFNlcnZsZXRSZXNwb25zZSBodHRwUmVzcG9uc2UgPSAoSHR0cFNl
cnZsZXRSZXNwb25zZSkgcmVzcG9uc2U7DQoJCWlmIChodHRwUmVxdWVzdC5nZXRSZXF1ZXN0VVJJ
KCkuZXF1YWxzKCIvbG9naW4iKSB8fCBXZWJVdGlscy5nZXRTZXNzaW9uQXR0cmlidXRlKGh0dHBS
ZXF1ZXN0LCAibG9nZ2VkSW4iKSAhPSBudWxsKSB7DQoJCQlmaWx0ZXJDaGFpbi5kb0ZpbHRlcihy
ZXF1ZXN0LCByZXNwb25zZSk7DQoJCX0NCgkJZWxzZSB7DQoJCQlodHRwUmVzcG9uc2Uuc2VuZFJl
ZGlyZWN0KCIvbG9naW4iKTsNCgkJCS8vIGh0dHBSZXNwb25zZS5zZW5kRXJyb3IoSHR0cFNlcnZs
ZXRSZXNwb25zZS5TQ19GT1JCSURERU4pOw0KCQl9DQoJfQ0KfQ0KDQoyLiB1c2luZyBhIGN1c3Rv
bSBIYW5kbGVyQWRhcHRlciBpbXBsZW1lbnRhdGlvbiwgcmVkaXJlY3RpbmcgdG8gbG9naW4gKG9y
IHNlbmRpbmcgYW4gZXJyb3IpIGlmIG5vdCBhdXRob3JpemVkOg0KDQpwdWJsaWMgY2xhc3MgTG9n
aW5IYW5kbGVyQWRhcHRlciBleHRlbmRzIFNpbXBsZUNvbnRyb2xsZXJIYW5kbGVyQWRhcHRlciB7
DQoJcHVibGljIE1vZGVsQW5kVmlldyBoYW5kbGUoSHR0cFNlcnZsZXRSZXF1ZXN0IHJlcXVlc3Qs
IEh0dHBTZXJ2bGV0UmVzcG9uc2UgcmVzcG9uc2UsIE9iamVjdCBoYW5kbGVyKSB7DQoJCWlmICho
YW5kbGVyIGluc3RhbmNlb2YgTG9naW5Db250cm9sbGVyIHx8IFdlYlV0aWxzLmdldFNlc3Npb25B
dHRyaWJ1dGUocmVxdWVzdCwgImxvZ2dlZEluIikgIT0gbnVsbCkgew0KCQkJcmV0dXJuIHN1cGVy
LmhhbmRsZShyZXF1ZXN0LCByZXNwb25zZSwgaGFuZGxlcik7DQoJCX0NCgkJZWxzZSB7DQoJCQly
ZXNwb25zZS5zZW5kUmVkaXJlY3QoIi9sb2dpbiIpOw0KCQkJLy8gcmVzcG9uc2Uuc2VuZEVycm9y
KEh0dHBTZXJ2bGV0UmVzcG9uc2UuU0NfRk9SQklEREVOKTsNCgkJCXJldHVybiBudWxsOw0KCQl9
DQoJfQ0KfQ0KDQozLiB1c2luZyBhIGN1c3RvbSBIYW5kbGVyTWFwcGluZyBpbXBsZW1lbnRhdGlv
biwgcmV0dXJuaW5nIHRoZSBsb2dpbiBoYW5kbGVyIGlmIG5vdCBhdXRob3JpemVkIChpbnN0ZWFk
IG9mIHVzaW5nIGxvb2t1cEhhbmRsZXIgZWxzZSwgb25lIGNvdWxkIGFsc28gc2V0IGEgZGVmYXVs
dCBoYW5kbGVyIGZvciB0aGUgbWFwcGluZyBhbmQgcmVseSBvbiB0aGUgZmFsbGJhY2sgdG8gaXQp
Og0KDQpwdWJsaWMgY2xhc3MgTG9naW5IYW5kbGVyTWFwcGluZyBleHRlbmRzIFNpbXBsZVVybEhh
bmRsZXJNYXBwaW5nIHsNCglwcm90ZWN0ZWQgT2JqZWN0IGdldEhhbmRsZXJJbnRlcm5hbChIdHRw
U2VydmxldFJlcXVlc3QgcmVxdWVzdCkgew0KCQlPYmplY3QgaGFuZGxlciA9IHN1cGVyLmdldEhh
bmRsZXJJbnRlcm5hbChyZXF1ZXN0KTsNCgkJaWYgKGhhbmRsZXIgaW5zdGFuY2VvZiBMb2dpbkNv
bnRyb2xsZXIgfHwgV2ViVXRpbHMuZ2V0U2Vzc2lvbkF0dHJpYnV0ZShyZXF1ZXN0LCAibG9nZ2Vk
SW4iKSAhPSBudWxsKSB7DQoJCQlyZXR1cm4gaGFuZGxlcjsNCgkJfQ0KCQllbHNlIHsNCgkJCXJl
dHVybiBsb29rdXBIYW5kbGVyKCIvbG9naW4iKTsNCgkJfQ0KCX0NCn0NCg0KVGhlIFNlcnZsZXQg
ZmlsdGVyIGhhcyB0aGUgYWR2YW50YWdlIG9mIHNwYW5uaW5nIGFsbCBDb250cm9sbGVyU2Vydmxl
dHMsIHNvIHRoZSBhdXRob3JpemF0aW9uIGNoZWNrIGRvZXNuJ3QgaGF2ZSB0byBiZSByZWdpc3Rl
cmVkIGluIGFsbCBDb250cm9sbGVyU2VydmxldHMgb2YgYW4gYXBwbGljYXRpb24gdGhhdCBqdXN0
IGhhcyBvbmUgc2luZ2xlIGNlbnRyYWwgbG9naW4uIEl0IGNhbid0IGNoZWNrIGZvciB0aGUgdHlw
ZSBvZiBjb250cm9sbGVyIHRob3VnaCwgdGh1cyBpdCBoYXMgdG8gbWF0Y2ggdGhlIGxvZ2luIFVS
SS4gTG9naW5IYW5kbGVyQWRhcHRlciBjYW4gY2hlY2sgdGhlIGNvbnRyb2xsZXIgdHlwZSwgYnV0
IHdvdWxkIGhhdmUgdG8gYmUgcmVnaXN0ZXJlZCBpbiBlYWNoIENvbnRyb2xsZXJTZXJ2bGV0LCB1
c2luZyBhIHJlZGlyZWN0IGJlY2F1c2Ugb25seSBvbmUgb2YgdGhlIENvbnRyb2xsZXJTZXJ2bGV0
cyBmZWF0dXJlcyBMb2dpbkNvbnRyb2xsZXIgaXRzZWxmLiBMb2dpbkhhbmRsZXJNYXBwaW5nIHdp
bGwgb25seSB3b3JrIHdpdGggYSBzaW5nbGUgQ29udHJvbGxlclNlcnZsZXQsIGJ1dCBpdCBjYW4g
cmV0dXJuIHRoZSBsb2NhbCBMb2dpbkNvbnRyb2xsZXIgaW5zdGFuY2UgaWYgdGhlIHVzZXIgaXNu
J3QgYXV0aG9yaXplZC4NCg0KQSB3ZWIgYXV0aGVudGljYXRpb24gQU9QIGludGVyY2VwdG9yIHdv
dWxkIGJlIGFibGUgdG8gcGVyZm9ybSB0aGUgc2FtZSBzdHJhdGVneSBvbiBDb250cm9sbGVyIGlt
cGxlbWVudGF0aW9ucywgYmVpbmcgdGlnaHRseSBjb3VwbGVkIHRvIHRoZSBwYXJhbWV0ZXIgdHlw
ZXMgb2YgaGFuZGxlUmVxdWVzdCB0aG91Z2guIEEgZ2VuZXJpYyBhdXRoZW50aWNhdGlvbiBpbnRl
cmNlcHRvciBmb3IgYW55IGJlYW5zIHdvdWxkIGhhdmUgdG8gdXNlIHNvbWUgVGhyZWFkTG9jYWwg
Y3JlZGVudGlhbHMsIGJ1dCB3aG8gaXMgcmVzcG9uc2libGUgZm9yIGFkZGluZyB0aGVtIG9uIGV2
ZXJ5IHJlcXVlc3Q/IEFuZCB3aXRoIHRoZSBjdXJyZW50IGludGVyY2VwdG9yIGRlY2xhcmF0aW9u
IGFwcHJvYWNoLCBvbmUgaGFzIHRvIGRlZmluZSBib3RoIGEgcHJveHkgYW5kIGEgdGFyZ2V0IGZv
ciBlYWNoIGFuZCBldmVyeSBjb250cm9sbGVyIGluIHRoZSB3ZWIgYXBwLiBUaGF0IGRvZXNuJ3Qg
c2VlbSB2ZXJ5IGNvbWZvcnRhYmxlIHRvIG1lLCBzbyBJJ2QgcHJlZmVyIG9uZSBvZiB0aGUgYWJv
dmUgc29sdXRpb25zLg0KDQpJJ3ZlIGFsc28gY29uc2lkZXJlZCBtb2RpZnlpbmcgQ29udHJvbGxl
clNlcnZsZXQgdG8gaW50cm9kdWNlIEhhbmRsZXJJbnRlcmNlcHRvcnMgdGhhdCB3b3VsZCBnZXQg
YXBwbGllZCBiZWZvcmUgaW52b2tpbmcgYSBoYW5kbGVyLiBCdXQgZWZmZWN0aXZlbHksIHRoZSBt
ZXRob2Qgc2lnbmF0dXJlIHdvdWxkIGV4YWN0bHkgbG9vayBsaWtlIEhhbmRsZXJBZGFwdGVyLmhh
bmRsZS4gU28gSSd2ZSBkZWNpZGVkIHRvIHNob3cgZXh0ZW5kaW5nIFNpbXBsZUNvbnRyb2xsZXJI
YW5kbGVyQWRhcHRlciBhYm92ZS4gSSdtIGF3YXJlIHRoYXQgdGhpcyB3aWRlbnMgSGFuZGxlckFk
YXB0ZXIncyByb2xlIChjaGVja2luZyBoYW5kbGVyIHR5cGUgKyBhdXRob3JpemF0aW9uKSwgYnV0
IGR1cGxpY2F0aW5nIHRoZSBoYW5kbGUgbWV0aG9kIHNpZ25hdHVyZSB2aWEgYSBIYW5kbGVySW50
ZXJjZXB0b3IgKHRoZW4ganVzdCByZXNwb25zaWJsZSBmb3IgYXV0aG9yaXphdGlvbikgZG9lc24n
dCBzZWVtIGlkZWFsIHRvby4NCg0KT2YgY291cnNlLCBtb3JlIHNvcGhpc3RpY2F0ZWQgYXV0aG9y
aXphdGlvbiBjYW4gYmUgaW1wbGVtZW50ZWQgdmlhIGEgdXNlciBvYmplY3QgYXMgc2Vzc2lvbiBh
dHRyaWJ1dGUuIEEgY3VzdG9tIGF1dGhvcml6YXRpb24gY2hlY2sgY2FuIHRoZW4gY2hlY2sgdGhl
IHVzZXIncyByb2xlLCByaWdodHMsIG9yIHdoYXRldmVyLiBUaGUgcXVlc3Rpb24gaXMsIHdoZXJl
IHRvIGRyYXcgdGhlIGxpbmUgdG8gY2hlY2tpbmcgd2l0aGluIHRoZSBjb250cm9sbGVyIGltcGxl
bWVudGF0aW9uPyBGb3IgZXhhbXBsZSwgYW4gYWN0dWFsIGltcGxlbWVudGF0aW9uIG1pZ2h0IHBy
b3ZpZGUgYW4gYWRhcHRlZCBtb2RlbCBhY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgdXNlcidzIHJp
Z2h0cywgbm90IGJlaW5nIG9ydGhvZ29uYWwgYW55bW9yZS4gQnV0IGluIG1hbnkgY2FzZXMsIG9u
ZSB3aWxsIHNpbXBseSB3YW50IHRvIGZvcmJpZCBhY2Nlc3MgdG8gY2VydGFpbiByZXNvdXJjZXMg
Y29tcGxldGVseSB3aXRob3V0IGxvZ2luLg0KDQpJJ20gZWFnZXIgdG8gaGVhciBvcGluaW9ucyBv
biB0aGlzLiBIb3cgZG9lcyBldmVyeWJvZHkgc29sdmUgbG9naW4gbmVlZHMgY3VycmVudGx5PyBB
bnlvbmUgdXNpbmcgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCB3YXkgdGhhbiB0aGUgb25lcyBhYm92
ZT8gQXQgd2VyazNBVCwgd2UndmUgYWRvcHRlZCB0aGUgZmlsdGVyIGFwcHJvYWNoIGJlY2F1c2Ug
d2UgaGF2ZSBudW1lcm91cyBDb250cm9sbGVyU2VydmxldHMgd2l0aCBvbmUgY2VudHJhbCBsb2dp
bi4NCg0KUmVnYXJkcywNCkp1ZXJnZW4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogUm9kIEpvaG5zb24gW21haWx0bzpyb2Quam9obnNvbkBpbnRlcmZhY2UyMS5jb21dDQpT
ZW50OiBUdWVzZGF5LCBNYXkgMjcsIDIwMDMgMTA6NDggQU0NClRvOiBqw7xyZ2VuIGjDtmxsZXIg
W3dlcmszQVRdOw0Kc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5u
ZXQNClN1YmplY3Q6IFJlOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gQXV0aGVudGljYXRp
b24gYW5kDQphdXRob3JpemF0aW9uDQoNCg0KSSBhZ3JlZSwgbWF5YmUgU3ByaW5nIHNob3VsZCBv
ZmZlciB0aGlzLg0KDQpTcHJpbmcncyBhbmNlc3RvciwgdGhlIE1WQyBmcmFtZXdvcmsgSSB3cm90
ZSBmb3IgRlQgZ3JvdXAsIGRpZA0KYXV0aGVudGljYXRpb24gYW5kIGl0IHdvcmtlZCB3ZWxsLg0K
DQpXaGF0IGFib3V0IGFkZGluZyBhbiBhdXRoZW50aWNhdGlvbiBpbnRlcmNlcHRvcj8gSSB0aGlu
ayBhdXRoZW50aWNhdGlvbiBpcw0KYXJndWFibGUgb3J0aG9nb25hbCB0byB0aGUgYXBwIHByb3Bl
ciwgaGVuY2UgYSBnb29kIGNhbmRpZGF0ZSBmb3IgQU9QLiBBcw0KYWxsIGNvbnRyb2xsZXJzIGlt
cGxlbWVudCBhbiBpbnRlcmZhY2UsIHdlIGNhbiBlYXNpbHkgcHV0IGEgZ2xvYmFsDQppbnRlcmNl
cHRvciBpbiBmcm9udCBvZiBhbGwgb2YgdGhlbS4NCg0KSSBhZ3JlZTogc3RhbmRhcmQgSjJFRSBh
dXRoZW50aWNhdGlvbiBpcyBub3QgcmVhbGx5IHN0YW5kYXJkLCBhbmQganVzdA0KZG9lc24ndCBj
dXQgdGhlIG11c3RhcmQgZm9yIG1vc3QgcmVhbCBhcHBzLg0KDQpUaGlzIGlzIG5vdCBzb21ldGhp
bmcgd2Ugc2hvdWxkIGNvbnNpZGVyIGZvciAwLjgsIHRob3VnaCENCg0KUmVnYXJkcywNClJvZA0K

FW: [Springframework-developer] paged lists

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

UmVzZW5kaW5nIHdpdGggYW4gZXZlbiBzbWFsbGVyIEpBUiBmaWxlIHdpdGhvdXQgY2xhc3MgZmls
ZXMgLSB0aGUgZm9ybWVyIGRpZG4ndCBnZXQgdGhyb3VnaHQgdG8gdGhlIGxpc3QgYmVjYXVzZSBv
ZiB0aGUgYXR0YWNobWVudCBzaXplLi4uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
CkZyb206IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF0gDQpTZW50OiBUdWVzZGF5LCBNYXkgMjcs
IDIwMDMgODowNSBQTQ0KVG86IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXINClN1YmplY3Q6IFJF
OiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gcGFnZWQgbGlzdHMNCg0KDQpJJ3ZlIGF0dGFj
aGVkIHRoZSByZXdvcmtlZCB2ZXJzaW9uIG9mIHRoZSBwYWdlZCBsaXN0IGV4YW1wbGUuIEkndmUg
b21pdHRlZCBhbGwgdGhlIEpBUiBmaWxlcyB0byBrZWVwIHRoZSBKQVIgc21hbGwuIFlvdSdsbCBz
dGlsbCBuZWVkIGEgY3VycmVudCBzcHJpbmctZnVsbCwgbG9nNGosIGFuZCBqc3RsLmphciArIHN0
YW5kYXJkLmphciBmb3IgQXBhY2hlJ3MgSlNUTCBpbXBsZW1lbnRhdGlvbi4NCg0KSnVlcmdlbg0K
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBqw7xyZ2VuIGjDtmxsZXIgW3dl
cmszQVRdIA0KU2VudDogTW9uZGF5LCBNYXkgMjYsIDIwMDMgMTA6MDcgUE0NClRvOiBqcC5wYXds
YWtAdGlzY2FsaS5mcg0KQ2M6IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXINClN1YmplY3Q6IFJl
OiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gcGFnZWQgbGlzdHMNCg0KDQpKZWFuLVBpZXJy
ZSwNCiANCkkndmUganVzdCBjb21taXR0ZWQgbXkgcmV3b3JrZWQgdmVyc2lvbi4NCiANClRoZXJl
J3Mgbm93IGEgU29ydERlZmluaXRpb24gaW50ZXJmYWNlIGluIGNvbS5pbnRlcmZhY2UyMS5iZWFu
cywgd2l0aCBhIE11dGFibGVTb3J0RGVmaW5pdGlvbiBpbXBsZW1lbnRhdGlvbi4gVGhlIHNvcnQg
bWV0aG9kcyBoYXZlIG1vdmVkIGZyb20gQmVhblV0aWxzIHRvIFByb3BlcnR5Q29tcGFyYXRvci4N
CiANClBhZ2VkTGlzdEhvbGRlciBpcyBxdWl0ZSBzaW1pbGFyIHRvIGJlZm9yZSwgdGFyZ2V0dGVk
IGFuIGltbXV0YWJsZSBsaXN0cywgYnV0IHdpdGggYmluZGluZy1mcmllbmRseSBzb3J0aW5nIHN1
cHBvcnQgdmlhIFNvcnREZWZpbml0aW9uLiBJJ3ZlIHR1cm5lZCBQYWdlTGlzdEF1dG9Ib2xkZXIg
aW50byBSZWZyZXNoYWJsZVBhZ2VkTGlzdEhvbGRlciwgYWRkaW5nIHJlZnJlc2hpbmcgZnJvbSBh
IHNvdXJjZSBwcm92aWRlciBvbiBjaGFuZ2VkIExvY2FsZSBvciBmaWx0ZXIuIEZpbHRlciBpcyBh
IGdlbmVyaWMgT2JqZWN0IHByb3BlcnR5IG5vdywgYWxsb3dpbmcgZm9yIGFueSBmaWx0ZXIgc2V0
dGluZ3MgYmVpbmcgcGFzc2VkIHRocm91Z2ggdG8gdGhlIHJlc3BlY3RpdmUgc291cmNlIHByb3Zp
ZGVyLg0KIA0KSSdsbCBzZW5kIHRoZSBhZGFwdGVkIHZlcnNpb24gb2YgeW91ciBleGFtcGxlIGFw
cCB0byB0aGUgbGlzdCB0b21vcnJvdy4gVGhlcmUgaGF2ZW4ndCBiZWVuIG1hbnkgY2hhbmdlcyB0
byB0aGUgY29udHJvbGxlciBhbmQgdmlldywgYnV0IHdoeSBmaWd1cmUgb3V0IHlvdXJzZWxmPyA6
LSkNCiANClJlZ2FyZHMsDQpKdWVyZ2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5h
Y2hyaWNodC0tLS0tIA0KCVZvbjoganAucGF3bGFrQHRpc2NhbGkuZnIgW21haWx0bzpqcC5wYXds
YWtAdGlzY2FsaS5mcl0gDQoJR2VzZW5kZXQ6IFNvIDI1LjA1LjIwMDMgMTU6MDggDQoJQW46IGrD
vHJnZW4gaMO2bGxlciBbd2VyazNBVF0gDQoJQ2M6IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIg
DQoJQmV0cmVmZjogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBwYWdlZCBsaXN0cw0K
CQ0KCQ0KDQoJSGkgSsO8cmdlbiwNCgkNCglZb3VyIHN1Z2dlc3RzIGFyZSB2ZXJ5IHdlbGNvbWUu
IEFzIHlvdSBoYXZlIGEgIGJldHRlciBrbm93bGVkZ2Ugb2IgdGhlIHdob2xlIFNwcmluZyBmcmFt
ZXdvcmssIHlvdSBzZWVuIHF1aWNrbHkgYmV0dGVyIGludGVyYWN0aW9uIHVzZS4gSSBhbSBub3Qg
YXQgaG9tZSwgSXQgc2VlbXMgeW91IGFyZSBhbHJlYWR5IG1ha2luZyB0aGUgY2hhbmdlLiBJZiB5
b3UgZXhwZXh0IGFueXRoaW5nIGZyb20gbWUsIHRhbGsgbWUganVzdCBhYm91dC4gDQoJDQoJUmVn
YXJkcywNCglKZWFuLVBpZXJyZQ0KCQ0KCS0tLS0tLS0tLS0gSW5pdGlhbCBIZWFkZXIgLS0tLS0t
LS0tLS0NCgkNCglGcm9tICAgICAgOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyLWFkbWluQGxp
c3RzLnNvdXJjZWZvcmdlLm5ldA0KCVRvICAgICAgICAgIDogIkpQIFBhd2xhayIgPGpwLnBhd2xh
a0B0aXNjYWxpLmZyPiwiU3ByaW5nIERldmVsb3BlcnMiIDxzcHJpbmdmcmFtZXdvcmstZGV2ZWxv
cGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldD4NCglDYyAgICAgICAgICA6DQoJRGF0ZSAgICAgIDog
U3VuLCAyNSBNYXkgMjAwMyAxNDo0ODozNCArMDIwMA0KCVN1YmplY3QgOiBSZTogW1NwcmluZ2Zy
YW1ld29yay1kZXZlbG9wZXJdIHBhZ2VkIGxpc3RzDQoJDQoJSGkgSmVhbi1QaWVycmUsDQoJDQoJ
QlRXLCB0aGUgdGVzdHMgaGF2ZSBhbGwgd29ya2VkIGZvciBtZSBvbiBGcmlkYXkgLSBJJ2xsIHJl
Y2hlY2sgdG9tb3Jyb3cuDQoJDQoJUmVnYXJkaW5nIFBhZ2VkTGlzdEF1dG9Ib2xkZXI6IEkgYXBw
cmVjaWF0ZSBpdHMgYWRkZWQgZnVuY3Rpb25hbGl0eS4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3Rs
eSwgaXQncyB0YXJnZXR0ZWQgYXQgZWFzeSB1c2FnZSBpbiBhIHdlYiBjb250cm9sbGVyLiBNeSBp
bml0aWFsIFBhZ2VkTGlzdEhvbGRlciB3YXMganVzdCBhIGZpcnN0IHRha2UsIGRyYXduIGZyb20g
YW4gYXBwbGljYXRpb24gcHJvamVjdC4gSSdtIHZlcnkgbXVjaCBmb3Igd29ya2luZyBhbGwgb2Yg
dGhpcyBpbnRvIGEgcmVmaW5lZCB2ZXJzaW9uLCBldmVuIGJlZm9yZSAwLjguIEknbGwgcHJvYmFi
bHkgdXNlIGl0IGluIG91ciBhcHBsaWNhdGlvbiBwcm9qZWN0IHRvby4NCgkNCgktLS0NCgkNCglJ
J3ZlIGdvdCBzb21lIGNvbmNyZXRlIGlzc3VlczoNCgkNCgktIEdlbmVyYWxseSwgd2Ugc2hvdWxk
IHRyeSB0byB1c2UgZGF0YSBiaW5kaW5nIHdoZXJldmVyIHBvc3NpYmxlLCB0byBrZWVwIHRoZSBt
b2RlbCBhbmQgdGhlIGFjdGlvbnMgYXMgT08gcmVzcC4gYmVhbi1zdHlsZSBhcyBwb3NzaWJsZS4g
SSdtIG5vdCBhIGdyZWF0IGZhbiBvZiBtYW51YWwgcGFyYW1ldGVyIHBhcnNpbmcgKGhhdmUgdXNl
ZCBpdCBmYXIgdG9vIG1hbnkgdGltZXMgbXlzZWxmKSwgYmUgaXQgZnJvbSB0aGUgU2VydmxldFJl
cXVlc3Qgb3IgZnJvbSBhIFN0cmluZy1iYXNlZCBwYXJhbWV0ZXIgbWFwLiBTcHJpbmcncyBTZXJ2
bGV0UmVxdWVzdERhdGFCaW5kZXIgYWxsb3dzIGZvciB2ZXJ5IHBvd2VyZnVsIGJpbmRpbmcgb2Yg
cmVxdWVzdCBwYXJhbWV0ZXJzIHRvIGJlYW4gaW5zdGFuY2VzLCBldmVuIG9uZSB0byByZXF1ZXN0
IHRvIG11bHRpcGxlIGJlYW5zLiBNYW51YWwgU3RyaW5nIHBhcmFtZXRlciBldmFsdWF0aW9uIGRv
ZXNuJ3QgYmVsb25nIGluIGEgcHJvcGVyIG1vZGVsIG9iamVjdCwgSU1PLg0KCQ0KCS0gZ2V0TWF4
RGlzcGxheVBhZ2VzLCBnZXRGaXJzdERpc3BsYXlQYWdlLCBnZXRMYXN0RGlzcGxheVBhZ2Ugc2hv
dWxkIHByb2JhYmx5IGJlIGNhbGxlZCBnZXRNYXhMaW5rZWRQYWdlcywgZ2V0Rmlyc3RMaW5rZWRQ
YWdlLCBnZXRMYXN0TGlua2VkUGFnZSAtIGFzIHRoZXkgYXJlbid0IHJlYWxseSBkaXNwbGF5ZWQg
dGhlbXNlbHZlcyBidXQgcmF0aGVyIGp1c3QgbGlua2VkIGZyb20gdGhlIGN1cnJlbnRseSBkaXNw
bGF5ZWQgcGFnZS4NCgkNCgktIEknZCBsaWtlIHRvIHR1cm4geW91ciAiU29ydCIgaW5uZXIgY2xh
c3MgaW50byBhIGdlbmVyaWMgY29tLmludGVyZmFjZTIxLmJlYW5zLlNvcnREZWZpbml0aW9uIGlu
dGVyZmFjZSwgYW5kIG9mZmVyIGFuIGFjY29tcGFueWluZyBCZWFuVXRpbHMuc29ydEJ5UHJvcGVy
dHkoTGlzdCxTb3J0RGVmaW5pdGlvbikgbWV0aG9kLiBZb3VyIGN1cnJlbnQgU29ydCBpbXBsZW1l
bnRhdGlvbiBjb3VsZCBzZXJ2ZSBhcyBEZWZhdWx0U29ydERlZmluaXRpb24gaW1wbGVtZW50YXRp
b24uDQoJDQoJLSBBcyB5b3UndmUgYWRkcmVzc2VkIHdpdGggZXh0ZW5kZWRJbmZvLCByZWxvYWRp
bmcgY2FuIGRlcGVuZCBvbiB2YXJpb3VzIHNwZWNpZmljIHBhcmFtZXRlcnMuIEJ1dCBmaWx0ZXJp
bmcgY291bGQgYmUgYmFzZWQgbm90IG9ubHkgb24gcGVyLWZpZWxkIG1hdGNoaW5nIHZhbHVlcyBi
dXQgb24gcmVndWxhciBleHByZXNzaW9ucyBldGMuIEEgZ2VuZXJpYyAiZmlsdGVyIiBwcm9wZXJ0
eSBvZiB0eXBlIE9iamVjdCB3aWxsIGFsbG93IHRoZSBjb250cm9sbGVyIHRvIHN0b3JlIGEgc3Rh
dGUgb2JqZWN0IHJlcHJlc2VudGluZyB0aGUgY3VycmVudCBmaWx0ZXIgc2V0dGluZ3MsIGNvbWJp
bmluZyB5b3VyIGZpbHRlck1hcCBhbmQgZXh0ZW5kZWRJbmZvIGluIG9uZSBnZW5lcmljIE9iamVj
dC4gTm90ZSB0aGF0IFBhZ2VkTGlzdEhvbGRlciBkb2VzIG5vdCBhbmQgc2hvdWxkIG5vdCBuZWVk
IHRvIGtub3cgYWJvdXQgdGhlIHNlbWFudGljcyBvZiAiZmlsdGVyIi4NCgkNCgktIFNvbWUgcHJv
cGVydGllcyByZXByZXNlbnQgTGlzdCBtZXRhIGRhdGE6ICJzb3J0IiBvZiB0eXBlIFNvcnREZWZp
bml0aW9uLCAiZmlsdGVyIiBvZiB0eXBlIE9iamVjdCwgImxvY2FsZSIgb2YgdHlwZSBMb2NhbGUu
IFRoZXNlIGNhbiBlYXNpbHkgYmUgaW5jbHVkZWQgaW4gUGFnZWRMaXN0SG9sZGVyLCBqdXN0IGxp
a2UgdGhlIGxpbmtlZCBwYWdlcyBzdXBwb3J0IHRvbyAoaW4gdGhlIGVuZCwgbGV0J3MgbWVyZ2Ug
UGFnZWRMaXN0SG9sZGVyIGFuZCBQYWdlZExpc3RBdXRvSG9sZGVyIC0gd2UgcHJvYmFibHkgZG9u
J3QgbmVlZCBib3RoKS4gUGFnZWRMaXN0U291cmNlUHJvdmlkZXIgd291bGQgaGF2ZSBhIGdlbmVy
aWMgbG9hZExpc3QoT2JqZWN0IEZpbHRlciwgTG9jYWxlIGxvY2FsZSkgdGhlbi4NCgkNCgktIFBh
Z2VkTGlzdEhvbGRlciBwcm9wZXJ0aWVzIGxpa2UgcGFnZVNpemUsIHBhZ2VOciwgbWF4TGlua2Vk
UGFnZXMgc2hvdWxkIGJlIHBvcHVsYXRlZCB2aWEgYmluZGluZyAodGhhdCdzIGhvdyBteSBpbml0
aWFsIHZlcnNpb24gd2FzIG1lYW50IHRvIGJlIHVzZWQpLiBMZXQncyB0cmVhdCBQYWdlZExpc3RI
b2xkZXIgYXMgYSBmb3JtIGJlYW4sIHdpdGggcmVxdWVzdCBwYXJhbWV0ZXJzIGdldHRpbmcgYm91
bmQgdG8gaXQgb24gZXZlcnkgc3VibWl0IC0gbm8gU3RyaW5nIHBhcmFtZXRlciBwYXJzaW5nLCBu
byBJbnRlZ2VyLnBhcnNlSW50LiBUaGUgc2FtZSBhcHBsaWVzIHRvICJzb3J0IiBhbmQgImZpbHRl
ciI6IEEgY29udHJvbGxlciBjYW4gc2V0IHNwZWNpZmljIGluc3RhbmNlcyB0byB0aGUgUGFnZWRM
aXN0SG9sZGVyIGluc3RhbmNlIG9uIHNldHVwLiBUaGVzZSBpbnN0YW5jZXMgY2FuIGJlIHBvcHVs
YXRlZCB2aWEgdGhlIHNhbWUgYmluZGluZyBzdGVwLCB1c2luZyBuZXN0ZWQgcGF0aHMgbGlrZSAi
c29ydC5hc2NlbmRpbmciIGV0Yy4NCgkNCgktIFBhZ2VkTGlzdEhvbGRlcidzIHJlZnJlc2ggbWV0
aG9kIHNob3VsZCBkbyBlcXVhbHMgY2hlY2tzIG9uICJzb3J0IiBhbmQgImZpbHRlciIgKHVzaW5n
IHN0b3JlZCBjb3BpZXMgZnJvbSB0aGUgbGFzdCByZWZyZXNoKSwgYW5kIHBlcmZvcm0gcmVzb3J0
aW5nIHJlc3AuIHJlbG9hZGluZyBpZiBuZWNlc3NhcnkgKHNldHRpbmcgY3VycmVudCB2ZXJzaW9u
cyBhcyBzdG9yZWQgY29waWVzKS4gVGh1cywgYSBjb250cm9sbGVyIHNob3VsZCBpbnZva2UgcmVm
cmVzaCBhZnRlciBlYWNoIGJlYW4gcG9wdWxhdGlvbiwgaS5lLiBvbiBlYWNoIHJlcXVlc3QuIEEg
cmVhbCByZWZyZXNoIGNhbiBiZSBlbmZvcmNlZCBieSBhIHJlc3BlY3RpdmUgcmVxdWVzdCBwYXJh
bWV0ZXIsIGJ1dCB0aGlzIHNob3VsZCBiZSBjaGVja2VkIGJ5IHRoZSBzcGVjaWZpYyB3ZWIgY29u
dHJvbGxlciwgdHJpZ2dlcmluZyBhIHJlZnJlc2goYm9vbGVhbiBlbmZvcmNlKSBjYWxsIHdpdGgg
dHJ1ZSB0aGVuLg0KCQ0KCS0gQWxsIHRoaW5ncyBjb25zaWRlcmVkLCB0aGUgdW5pZmllZCBQYWdl
ZExpc3RIb2xkZXIgd2lsbCBub3QgbmVlZCB0byBrbm93IGFueXRoaW5nIGFib3V0IHJlcXVlc3Qg
cGFyYW1ldGVycy4gUGFnZWRMaXN0QXV0b0hvbGRlcidzIHh4eFBhcmFtIHByb3BlcnRpZXMgYW5k
IGl0cyBxdWl0ZSBsZW5ndGh5IGV4ZWN1dGUgbWV0aG9kIGFyZW4ndCBuZWNlc3NhcnkgdGhlbiwg
bW9zdCBzdHVmZiBjYW4gd29yayB2aWEgZGF0YSBiaW5kaW5nIGFuZCByZWZyZXNoLiBJZiBvbmUg
d2FudHMgdG8gdXNlIGRpZmZlcmVudCByZXF1ZXN0IHBhcmFtZXRlcnMsIG9uZSBjYW4gYWx3YXlz
IHBlcmZvcm0gbWFudWFsIHBvc3QtYmluZGluZywgYnV0IHRoZSBiZWFuIHByb3BlcnR5IG5hbWVz
IHNob3VsZCBiZSBwcmV0dHkgc3RyYWlnaHRmb3J3YXJkIGFzIHBhcmFtZXRlciBuYW1lcyBhbnl3
YXkuIFRoZSBiaW5kaW5nIHBhdGhzIG1hdGNoIHRoZSBKU1RMIEVMIGV4cHJlc3Npb25zIG5pY2Vs
eSwgbGlrZSAic29ydC5hc2NlbmRpbmciLg0KCQ0KCS0tLQ0KCQ0KCUEgY29udHJvbGxlciBpbXBs
ZW1lbnRhdGlvbiBpcyBhcyBzaW1wbGUgYXMgYmVmb3JlLiBJdCBqdXN0IG5lZWRzIHRvIHRyaWdn
ZXIgdGhlIGJpbmRpbmcgYW5kIGNhbGwgdGhlIHJlZnJlc2ggbWV0aG9kIGFmdGVyd2FyZHMsIGlu
c3RlYWQgb2YgdGhlIGN1cnJlbnQgZXhlY3V0ZSBjYWxsLiBUaGUgcmVzcGVjdGl2ZSBjb2RlIGlu
IHlvdXIgUGFnZWRMaXN0Q29udHJvbGxlciBleGFtcGxlIHdvdWxkIGxvb2sgYWJvdXQgYXMgZm9s
bG93czoNCgkNCglwdWJsaWMgTW9kZWxBbmRWaWV3IHNob3dNYWluKEh0dHBTZXJ2bGV0UmVxdWVz
dCByZXF1ZXN0LCBIdHRwU2VydmxldFJlc3BvbnNlIHJlc3BvbnNlKSB7DQoJICBQYWdlZExpc3RB
dXRvSG9sZGVyIGxpc3RIb2xkZXIgPQ0KCSAgICAoUGFnZWRMaXN0QXV0b0hvbGRlcilyZXF1ZXN0
LmdldFNlc3Npb24odHJ1ZSkuZ2V0QXR0cmlidXRlKENPVU5UUklFU19BVFRSKTsNCgkgIGlmIChu
dWxsID09IGxpc3RIb2xkZXIpIHsNCgkgICAgbGlzdEhvbGRlciA9IChQYWdlZExpc3RBdXRvSG9s
ZGVyKXRoaXMuZ2V0QXBwbGljYXRpb25Db250ZXh0KCkuZ2V0QmVhbigiYXV0b0xpc3RIb2xkZXIi
KTsNCgkgICAgbGlzdEhvbGRlci5zZXRTb3VyY2VQcm92aWRlcihuZXcgQ291bnRyaWVzUHJvdmlk
ZXIoKSk7DQoJICAgIGxpc3RIb2xkZXIuc2V0RmlsdGVyKG5ldyBDb3VudHJpZXNGaWx0ZXIoKSk7
DQoJICAgIGxpc3RIb2xkZXIuc2V0U29ydChuZXcgRGVmYXVsdFNvcnREZWZpbml0aW9uKCkpOw0K
CSAgICByZXF1ZXN0LmdldFNlc3Npb24odHJ1ZSkuc2V0QXR0cmlidXRlKENPVU5UUklFU19BVFRS
LCBsaXN0SG9sZGVyKTsgDQoJICB9DQoJICBCaW5kRXhjZXB0aW9uIGV4ID0gQmluZFV0aWxzLmJp
bmQocmVxdWVzdCwgbGlzdEhvbGRlciwgImNvdW50cmllcyIpOw0KCSAgYm9vbGVhbiBmb3JjZVJl
ZnJlc2ggPSByZXF1ZXN0LmdldFBhcmFtZXRlcigiZm9yY2VSZWZyZXNoKSAhPSBudWxsOw0KCSAg
bGlzdEhvbGRlci5yZWZyZXNoKGZvcmNlUmVmcmVzaCk7DQoJICByZXR1cm4gbmV3IE1vZGVsQW5k
VmlldygibWFpblZpZXciLCBleC5nZXRNb2RlbCgpKTsNCgl9DQoJDQoJcHVibGljIGNsYXNzIENv
dW50cmllc0ZpbHRlciB7DQoJICBwcml2YXRlIFN0cmluZyBuYW1lOw0KCSAgcHJpdmF0ZSBTdHJp
bmcgY29kZTsNCgkgIHB1YmxpYyBTdHJpbmcgZ2V0TmFtZSgpIHsNCgkgICAgcmV0dXJuIG5hbWU7
DQoJICB9DQoJICBwdWJsaWMgdm9pcyBzZXROYW1lKFN0cmluZyBuYW1lKSB7DQoJICAgIHRoaXMu
bmFtZSA9IG5hbWU7DQoJICB9DQoJICBwdWJsaWMgU3RyaW5nIGdldENvZGUoKSB7DQoJICAgIHJl
dHVybiBjb2RlOw0KCSAgfQ0KCSAgcHVibGljIHZvaXMgc2V0Q29kZShTdHJpbmcgY29kZSkgew0K
CSAgICB0aGlzLmNvZGUgPSBjb2RlOw0KCSAgfQ0KCX0NCgkNCglGaWx0ZXJpbmcgZG9lc24ndCB3
b3JrIHZpYSBwYXJhbWV0ZXIgbmFtZXMgdGhhdCBzZXJ2ZSBhcyBmaWx0ZXIgbmFtZXMgYW55bW9y
ZSwgYnV0IHdpdGggYSBuZXN0ZWQgImZpbHRlciIgb2JqZWN0IG9mIHR5cGUgQ291bnRyaWVzRmls
dGVyLiBTbyB5b3VyIG1haW4uanNwIHdvdWxkIG5lZWQgdG8gdXNlICJjb3VudHJpZXMuZmlsdGVy
LmNvZGUiIEVMIGZvciBtYXRjaGluZywgc2VuZGluZyAiZmlsdGVyLmNvZGUiIGFzIHJlcXVlc3Qg
cGFyYW1ldGVyIG5hbWUgZm9yIGNoYW5naW5nLiBUaGUgc2FtZSBhcHBsaWVzIHRvIHNvcnRpbmcs
IHVzaW5nIHRoZSBuZXN0ZWQgInNvcnQiIG9iamVjdDogZS5nLiAiY291bnRyaWVzLnNvcnQuYXNj
ZW5kaW5nIiBFTCBmb3IgZXZhbHVhdGlvbiAoanVzdCBsaWtlIGluIHlvdXIgY3VycmVudCB2ZXJz
aW9uKSwgInNvcnQuYXNjZW5kaW5nIiBhcyByZXF1ZXN0IHBhcmFtZXRlciBuYW1lLg0KCQ0KCS0t
LQ0KCQ0KCVdoYXQgZG8geW91IHRoaW5rPyBJJ20ga2VlbiBvbiBhcHBseWluZyB0aGVzZSBjaGFu
Z2VzIHByb21wdGx5LCBpZiB5b3UgZG9uJ3QgbWluZCwgaWYgcG9zc2libGUgYWxyZWFkeSB0b21v
cnJvdy4gQlRXLCBJJ20gd3JpdGluZyB0aGlzIG9uIGEgbm9uLWRldmVsb3BtZW50IFBDIGF0IGhv
bWUsIHNvIEkgaGF2ZW4ndCBhY3R1YWxseSBwcm90b3R5cGVkIHRoZSBkZXNpZ24sIGJ1dCBJIGV4
cGVjdCBpdCB0byB3b3JrIG5pY2VseS4gV2Ugc2hvdWxkIGVuZCB1cCB3aXRoIHNpZ25pZmljYW50
bHkgbGVzcyBhbmQgbW9yZSBtYWludGFpbmFibGUgY29kZSwgSSBob3BlLg0KCQ0KCVJlZ2FyZHMs
DQoJSnVlcmdlbg0KCQ0KCQ0KCQ0KCSAgICAgICAgLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmlj
aHQtLS0tLQ0KCSAgICAgICAgVm9uOiBKUCBQYXdsYWsgW21haWx0bzpqcC5wYXdsYWtAdGlzY2Fs
aS5mcl0NCgkgICAgICAgIEdlc2VuZGV0OiBGciAyMy4wNS4yMDAzIDIyOjIwDQoJICAgICAgICBB
bjogU3ByaW5nIERldmVsb3BlcnMNCgkgICAgICAgIENjOg0KCSAgICAgICAgQmV0cmVmZjogW1Nw
cmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIHBhZ2VkIGxpc3RzDQoJICAgICAgIA0KCSAgICAgICAN
CgkNCgkNCgkgICAgICAgIEhpLA0KCSAgICAgICANCgkgICAgICAgIEV4Y3VzZSBtZSBmcm9tIGRp
c3R1cmJpbmcgZnJvbSBmdW5kYW1lbnRhbCBpc3N1ZXMgbGlrZSB0aGUgS2V5QmluZGVyDQoJICAg
ICAgICBwb3N0ZWQgYnkgSXNhYmVsbGUgYW5kIHRoZSBicm9rZW4gdGVzdHMgSSd2ZSBqdXN0IHBv
c3RlZC4NCgkgICAgICAgDQoJICAgICAgICBBcyBJIHRhbGtlZCBhYm91dCwgSSBoYXZlIGFkZGVk
IHRocmVlIGZpbGVzOg0KCSAgICAgICAgSW4gc3JjOg0KCSAgICAgICAgICAgLSBjb20uaW50ZXJm
YWNlMjEudXRpbC5QYWdlZExpc3RBdXRvSG9sZGVyLmphdmEgKENsYXNzIGRlcml2ZWQgZnJvbQ0K
CSAgICAgICAgUGFnZWRMaXN0SG9sZGVyKQ0KCSAgICAgICAgICAgLSBjb20uaW50ZXJmYWNlMjEu
dXRpbC5QYWdlZExpc3RTb3VyY2VQcm92aWRlci5qYXZhIChJbnRlcmZhY2UpDQoJICAgICAgICBp
biB0ZXN0Og0KCSAgICAgICAgICAgLSBjb20uaW50ZXJmYWNlMjEudXRpbC5QYWdlZExpc3RBdXRv
SG9sZGVyVGVzdHMuamF2YSAoQ2xhc3MpDQoJICAgICAgIA0KCSAgICAgICAgVGhpcyBhbGwgZm9y
IGVhc3kgdXNlIG9mIGEgbW9yZSBwb3dlcmZ1bGwgcGFnZWQgTGlzdC4NCgkgICAgICAgIFRoZSBq
YXZhZG9jIGFuZCBldmVudHVhbGx5IHRlc3Qgc291cmNlIHdpbGwgbm9ybWFsbHkgc3VmZmljZSB0
bw0KCSAgICAgICAgdW5kZXJzdGFuZCB0aGUgdXNlLg0KCSAgICAgICAgTmV2ZXJ0aGVsZXNzLCBp
ZiBJIHdpbGwgbm90IGJlIGltcGFjdGVkIGJ5IHRoZSBjdXJyZW50IHRlc3QgaXNzdWVzLCBJDQoJ
ICAgICAgICB3aWxsIHRyeSB0byBwcm92aWRlIGEgdGlueSBzYW1wbGUgYXBwbGljYXRpb24gZm9y
IGRlbW9uc3RyYXRpbmcuDQoJICAgICAgIA0KCSAgICAgICAgQWZ0ZXIgMC44IHdpbGwgYmUgcmVs
ZWFzZWQsIEkgY291bGQgaGF2ZSBzb21lIGhlbHAgZm9yIHJld2lldmluZyB0aGUNCgkgICAgICAg
IGphdmFkb2MgY29tbWVudHMgYXMgbXkgRW5nbGlzaCBpcyB2ZXJ5IGZhciBmcm9tIHBlcmZlY3Qu
DQoJICAgICAgIA0KCSAgICAgICAgUmVnYXJkcywNCgkgICAgICAgIF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KCSAgICAgICAgSmVhbi1QaWVycmUgUGF3bGFrDQoJICAgICAgICBqcC5w
YXdsYWtAdGlzY2FsaS5mcg0KCSAgICAgICAgDQoJICAgICAgIA0KCSAgICAgICANCgkgICAgICAg
DQoJICAgICAgIA0KCSAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KCSAgICAgICAgVGhpcyBTRi5uZXQgZW1haWwgaXMgc3BvbnNv
cmVkIGJ5OiBPYmplY3RTdG9yZS4NCgkgICAgICAgIElmIGZsYXR0ZW5pbmcgb3V0IEMrKyBvciBK
YXZhIGNvZGUgdG8gbWFrZSB5b3VyIGFwcGxpY2F0aW9uIGZpdCBpbiBhDQoJICAgICAgICByZWxh
dGlvbmFsIGRhdGFiYXNlIGlzIHBhaW5mdWwsIGRvbid0IGRvIGl0ISBDaGVjayBvdXQgT2JqZWN0
U3RvcmUuDQoJICAgICAgICBOb3cgcGFydCBvZiBQcm9ncmVzcyBTb2Z0d2FyZS4gaHR0cDovL3d3
dy5vYmplY3RzdG9yZS5uZXQvc291cmNlZm9yZ2UNCgkgICAgICAgIF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJICAgICAgICBTcHJpbmdmcmFtZXdvcmst
ZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0KCSAgICAgICAgU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Bl
ckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCgkgICAgICAgIGh0dHBzOi8vbGlzdHMuc291cmNlZm9y
Z2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXINCgkgICAgICAg
DQoJDQoJDQoJDQoJKioqKioqKioqKiBTUEVDSUFMIEFEU0wgKioqKioqKioqKg0KCUwnQURTTCDD
oCBwYXJ0aXIgZGUgMTUsOTUgRVVSL21vaXMgZXQgbGUgbW9kZW0gQURTTCBvZmZlcnQgPyAgQydl
c3QgZW4gZXhjbHVzaXZpdMOpIGNoZXogVGlzY2FsaSAhDQoJUG91ciBwcm9maXRlciBkZSBjZXR0
ZSBvZmZyZSwgY2xpcXVleiBpY2k6IGh0dHA6Ly9yZWdpc3Rlci50aXNjYWxpLmZyL2Fkc2wvDQoJ
T2ZmcmUgc291bWlzZSDDoCBjb25kaXRpb25zLg0KCQ0KCQ0KCQ0KDQpOGEhZ3rXpmopYJ3VuNyto
H35WDQouL1oodWgeyotqZcat34rYp2pq2KhdatabaseidnYNChc5ctStDQpaHz4gLErehmkw4oCg
eWzenX9xB9qZKEdeaGopYgli1KkpfnsNCivXr3paKXpiLHkr3rYbbSstLsefHn8rLWLYp37sprja
mShHXmgNCg==

Re: [Springframework-developer] Problem with MySqlMaxValueIncrementer

[Isabelle M. <isa...@me...>]

Hi Thomas,

This is indeed better. I didn't know you could give last_insert_id an argument, which is why I was looping.

Isabelle

On Sat, May 31, 2003 at 02:11:56PM -0400, tri...@tr... wrote:
> Isabelle and All,
> 
> I have commited my changes to the MySQLMaxValueIncrementer.  
> 
> You now declare the "sequence" table like this:
>  
>    create table sequence (id int not null) type=MYISAM;
>    insert into sequence values(0);
> 
> No need for auto-increment for either table.  The "type=MYISAM" is nor 
> necessary, but it underscores that this table is not part of any transaction.
> 
> Everything else works the same.
> 
> I changed the increment logic to use
> 
>    update sequence set id=last_insert_id(id+?);
> 
> where ? is the batch size.
> 
> This works fine during my testing.  Let me know if you run in to any problems.
> 
> I'll make some changes to the OracleSequenceMaxValueIncrementer next.
> 
> --Thomas
> 
> 
> 

-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

Re: [Springframework-developer] Problem with MySqlMaxValueIncrementer

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

Isabelle and All,

I have made some changes the OracleSequenceMaxValueIncrementer.  It now 
retrieves all new values for a batch calling NEXTVAL on the sequence for each 
value.  It stores them in an array and then hands them out one by one.  I'll 
look into a more efficient solution when I have more time.

I also renamed incrementBy to cacheSize -- its more clear that way what it is 
used for.  For MySQL we always increment the values by 1, and for Oracle the 
increment is defined in the sequence.

--Thomas

Re: [Springframework-developer] Problem with MySqlMaxValueIncrementer

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

Isabelle and All,

I have commited my changes to the MySQLMaxValueIncrementer.  

You now declare the "sequence" table like this:
 
   create table sequence (id int not null) type=MYISAM;
   insert into sequence values(0);

No need for auto-increment for either table.  The "type=MYISAM" is nor 
necessary, but it underscores that this table is not part of any transaction.

Everything else works the same.

I changed the increment logic to use

   update sequence set id=last_insert_id(id+?);

where ? is the batch size.

This works fine during my testing.  Let me know if you run in to any problems.

I'll make some changes to the OracleSequenceMaxValueIncrementer next.

--Thomas

[Springframework-developer] (no subject)

[JP P. <jp....@ti...>]

As it seems access issues and I cannot check it now,

I send the files in the list as they are tiny,

__________________________________ 
Jean-Pierre Pawlak
jp....@ti...

Re: [Springframework-developer] DTD and XML

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

Chris & Jean-Pierre,

I just tried again and I can access both links now

http://www.jppawlak.info/spring/pagedlist-servlet.xml

and

http://www.jppawlak.info/spring/spring-beans_0_8.dtd

--Thomas


> You can get the xml at
> http://www.jppawlak.info/spring/pagedlist-servlet.xml
> 
> But can't get the DTD at
> http://www.jppawlak.info/spring/spring-beans_0_8.dtd
> --- tri...@tr... wrote:
> > Jean-Pierre:
> > 
> > I can't access these files.
> > 
> > I can't even ping the server.  I can however ping
> > www.jppawlak.info.
> > 
> > >ping tech.jppawlak.info
> > Ping request could not find host tech.jppawlak.info.
> > Please check the name and t
> > ry again.
> > 
> > >ping www.jppawlak.info
> > 
> > Pinging jppawlak.info [81.166.145.206] with 32 bytes
> > of data:
> > 
> > Reply from 81.166.145.206: bytes=32 time=165ms
> > TTL=49
> > Reply from 81.166.145.206: bytes=32 time=190ms
> > TTL=49
> > Reply from 81.166.145.206: bytes=32 time=160ms
> > TTL=49
> > Reply from 81.166.145.206: bytes=32 time=158ms
> > TTL=49
> > 
> > Ping statistics for 81.166.145.206:
> >     Packets: Sent = 4, Received = 4, Lost = 0 (0%
> > loss),
> > Approximate round trip times in milli-seconds:
> >     Minimum = 158ms, Maximum = 190ms, Average =
> > 168ms
> > 
> > --Thomas
> > 
> > 
> > > The files as I have understood are downlodable:
> > > 
> > >
> >
> http://tech.jppawlak.info/spring/spring-beans_0_8.dtd
> > > 
> > >
> >
> http://tech.jppawlak.info/spring/pagedlist-servlet.xml
> > > 
> > > __________________________________ 
> > > Jean-Pierre Pawlak
> > > jp....@ti...
> > > 
> > > 
> > > 
> > > 
> > >
> >
> -------------------------------------------------------
> > > This SF.net email is sponsored by: eBay
> > > Get office equipment for less on eBay!
> > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > >
> >
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > > 
> > 
> > 
> > 
> > 
> > 
> >
> -------------------------------------------------------
> > This SF.net email is sponsored by: eBay
> > Get office equipment for less on eBay!
> > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> http://calendar.yahoo.com
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] DTD and XML

[Chris A. <ca...@ya...>]

You can get the xml at
http://www.jppawlak.info/spring/pagedlist-servlet.xml

But can't get the DTD at
http://www.jppawlak.info/spring/spring-beans_0_8.dtd
--- tri...@tr... wrote:
> Jean-Pierre:
> 
> I can't access these files.
> 
> I can't even ping the server.  I can however ping
> www.jppawlak.info.
> 
> >ping tech.jppawlak.info
> Ping request could not find host tech.jppawlak.info.
> Please check the name and t
> ry again.
> 
> >ping www.jppawlak.info
> 
> Pinging jppawlak.info [81.166.145.206] with 32 bytes
> of data:
> 
> Reply from 81.166.145.206: bytes=32 time=165ms
> TTL=49
> Reply from 81.166.145.206: bytes=32 time=190ms
> TTL=49
> Reply from 81.166.145.206: bytes=32 time=160ms
> TTL=49
> Reply from 81.166.145.206: bytes=32 time=158ms
> TTL=49
> 
> Ping statistics for 81.166.145.206:
>     Packets: Sent = 4, Received = 4, Lost = 0 (0%
> loss),
> Approximate round trip times in milli-seconds:
>     Minimum = 158ms, Maximum = 190ms, Average =
> 168ms
> 
> --Thomas
> 
> 
> > The files as I have understood are downlodable:
> > 
> >
>
http://tech.jppawlak.info/spring/spring-beans_0_8.dtd
> > 
> >
>
http://tech.jppawlak.info/spring/pagedlist-servlet.xml
> > 
> > __________________________________ 
> > Jean-Pierre Pawlak
> > jp....@ti...
> > 
> > 
> > 
> > 
> >
>
-------------------------------------------------------
> > This SF.net email is sponsored by: eBay
> > Get office equipment for less on eBay!
> > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > 
> 
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Re: [Springframework-developer] Problem with MySqlMaxValueIncrementer

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

Isabelle,

> There is a problem with MySQLMaxValueIncrementer (and I think with the Oracle
> one as well). Currently the code doesn't do any transaction management which
> has 3 consequences :
> (1) if the calling code does a rollback, the value(s) cached in / handed out
> by the object are invalid

I'm not sure what you mean by invalid.  If the caller rolls back the
transaction, then the retrieved keys are wasted - there will be gaps.  The
sequence should be independent of any transaction, at least that is how Oracle's
sequence works.  I beleive most auto-increment implementations work the same way.

> (2) the code requires the caller to do a commit, which I'm sure most people
> will forget to do if using the framework.

I'm not sure about this one either.  In what way is the caller required to do a
commit.  They are only required to do a commit if they explicitly started a
transaction.  If not then they should be in either "container managed" mode or
auto-commit.

> (3) when requesting a bunch of keys, it is possible to get a series of
> non-sequential numbers from the database. This because of the loop in the
> code, which is requred by mySQL last_insert_id() semantics. This particular
> problem could be solved by maintaining an array of values, instead of just a
> maxId. I'll make this change over the weekend. This particular problem won't
> show up in the Oracle implementation.

The MySQL implementation that I have seen for a "sequence" is this:

  create table sequence (id int not null);
  insert into sequence values(0);

and to increment it you do:

  update sequence set id=last_insert_id(id+1);

then last_insert_id() will give you the next sequnce value to use.

If you want to get a batch of id:s could you not use:

  update sequence set id=last_insert_id(id+?);

where ? is your batch size.

This way there is no need to loop and later clean up the extra inserted rows.  I
would think that a simple update would perform better than insert/delete
statements as well.

For the Oracle implementation it looks like we are using the INCREMENT_BY value
from an Oracle sequence to use as a cached batch of id:s.  I'm not sure that is
a good idea since we don't know for sure why that INCREMENT_BY value is beeing
used.  Maybe the DBA wanted to space out the keys or only use odd numbers - who
knows.  Plus, I don't think our code would work with negative INCREMENT_BY
values.  As far as I know there is no way to figure out what the initial value
of the sequence was.  There is a min and a max value, but neither one is certain
to be the value where the sequence was set to start.

I would suggest that we try to fix these issues before the 0.8 release, or if
there is not enough time then we should skip the caching for now, and just
retrieve the next value from the sequence.  We could add caching in .9 or 1.0 if
we come up with a workable solution.

--Thomas

Re: [Springframework-developer] DTD and XML

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

Jean-Pierre:

I can't access these files.

I can't even ping the server.  I can however ping www.jppawlak.info.

>ping tech.jppawlak.info
Ping request could not find host tech.jppawlak.info. Please check the name and t
ry again.

>ping www.jppawlak.info

Pinging jppawlak.info [81.166.145.206] with 32 bytes of data:

Reply from 81.166.145.206: bytes=32 time=165ms TTL=49
Reply from 81.166.145.206: bytes=32 time=190ms TTL=49
Reply from 81.166.145.206: bytes=32 time=160ms TTL=49
Reply from 81.166.145.206: bytes=32 time=158ms TTL=49

Ping statistics for 81.166.145.206:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 158ms, Maximum = 190ms, Average = 168ms

--Thomas


> The files as I have understood are downlodable:
> 
> http://tech.jppawlak.info/spring/spring-beans_0_8.dtd
> 
> http://tech.jppawlak.info/spring/pagedlist-servlet.xml
> 
> __________________________________ 
> Jean-Pierre Pawlak
> jp....@ti...
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] DTD and XML

[JP P. <jp....@ti...>]

The files as I have understood are downlodable:

http://tech.jppawlak.info/spring/spring-beans_0_8.dtd

http://tech.jppawlak.info/spring/pagedlist-servlet.xml

__________________________________ 
Jean-Pierre Pawlak
jp....@ti...

Re: [Springframework-developer] value/ref

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

JP,

I still think that interpreting the contents of a tag differently depending
on its context is inelegant, and hard to validate.

Regards,
Rod

----- Original Message -----
From: "JP Pawlak" <jp....@ti...>
To: "Spring Developers" <spr...@li...>
Sent: Friday, May 30, 2003 3:12 PM
Subject: [Springframework-developer] value/ref


> Hi Rod, everybody,
>
> You will say I come back with an old horse and continue to discuss what
> I approved, but I prefer clarify now than when code is written.
>
> As the XML goes to complexify, we have almost everywhere to handle with
> ref/values and constantly mix both.
> Why not have a single tag with an optional ref attribute. In a SAX
> handler, it is only a matter of switching depending of the presence of
> the ref attribute instead of treating two diffrerent events.
>
> Can you done an example for which a single tag is not so handy as two?
>
> Regards
> _____________________________
> Jean-Pierre Pawlak
> jp....@ti...
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: RE : RE : [Springframework-developer] Problem with MySqlMaxValueIncrementer

[Isabelle M. <isa...@me...>]

Yes, i think so too. Problem is I haven't done anything yet with tx and aop in the framework, and I think this should be solved before 0.8.

Isabelle

On Fri, May 30, 2003 at 04:51:10PM +0200, JP Pawlak wrote:
> At this point, Rod or Juergen will certainly be more helpful as AOP will certainly have to enter in the dance.
> 
> Jean-Pierre
> 
> 
> > -----Message d'origine-----
> > De : Isabelle Muszynski [mailto:isa...@me...] 
> > Envoyé : vendredi 30 mai 2003 16:43
> > À : JP Pawlak
> > Cc : spr...@li...
> > Objet : Re: RE : [Springframework-developer] Problem with 
> > MySqlMaxValueIncrementer
> > 
> > 
> > Hi JP,
> > 
> > As a matter of fact I also thought of requiring the 
> > equivalent of EJB's Requires New transaction. The problem 
> > still is how to implement this: how do I know whether the 
> > code is running in a CMP/BMP EJB, under JTA, ... I'm a bit 
> > baffled, don't know the answer.
> > 
> > There is a solution which makes the whole implementation 
> > redundant : for the user to cast the Statement or 
> > PreparedStatement to a com.mysql.Statement 
> > (PreparedStatement) and then call getLastInsertId(). I don't 
> > want to do this in the framework, because then compilation 
> > becomes dependent on the mysql JDBC library.
> > 
> > Isabelle
> > 
> > On Fri, May 30, 2003 at 04:29:30PM +0200, JP Pawlak wrote:
> > > Hi Isabelle,
> > > 
> > > Ah, the continuously problematic MaxValueIncrementer ;-) !
> > > As with the key search we will always have potentially two 
> > Sql orders, 
> > > how manage this? The best would be to have the possibility to treat 
> > > separately. It would be convenient to assure the key search 
> > being out 
> > > of any transaction and being committed regardless of a current 
> > > transaction. In this case, simply the key(s) used by the rollbacked 
> > > operations are lost. I don't know, so quickly, if it is 
> > possible and 
> > > how.
> > > 
> > > Jean-Pierre
> > >  
> > > 
> > > > -----Message d'origine-----
> > > > De : spr...@li...
> > > > [mailto:spr...@li...]
> > > >  De la part de Isabelle Muszynski
> > > > Envoyé : vendredi 30 mai 2003 15:28
> > > > À : spr...@li...
> > > > Objet : [Springframework-developer] Problem with 
> > > > MySqlMaxValueIncrementer
> > > > 
> > > > 
> > > > Hi everyone,
> > > > 
> > > > There is a problem with MySQLMaxValueIncrementer (and I think
> > > > with the Oracle one as well). Currently the code doesn't do 
> > > > any transaction management which has 3 consequences :
> > > > (1) if the calling code does a rollback, the value(s) cached 
> > > > in / handed out by the object are invalid
> > > > (2) the code requires the caller to do a commit, which I'm 
> > > > sure most people will forget to do if using the framework.
> > > > (3) when requesting a bunch of keys, it is possible to get a 
> > > > series of non-sequential numbers from the database. This 
> > > > because of the loop in the code, which is requred by mySQL 
> > > > last_insert_id() semantics. This particular problem could be 
> > > > solved by maintaining an array of values, instead of just a 
> > > > maxId. I'll make this change over the weekend. This 
> > > > particular problem won't show up in the Oracle 
> > > > implementation. I'm not sure how to solve the items 1 & 2 
> > > > though. The code can be called in a variety of circumstances 
> > > > (BMP and CMP beans, no EJB, ...). Can we even assume the 
> > > > presence of a transaction manager?
> > > > 
> > > > Any ideas?
> > > > 
> > > > 
> > > > --
> > > > Isabelle Muszynski
> > > > Software Engineer
> > > > Zandweellaan 4
> > > > 2660 Antwerpen
> > > > Belgium
> > > > Tel. 32-(0)3-830 18 54
> > > > Mobile: 32-(0)485 49 50 89
> > > > Email: isa...@me...
> > > > Website: www.meta-logix.com
> > > > 
> > > > 
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by: eBay
> > > > Get office equipment for less on eBay!
> > > > http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5
> > > > 
> > > > _______________________________________________
> > > > 
> > > > Springframework-developer mailing list
> > > > Spr...@li...
> > > > 
> > https://lists.sourceforge.net/lists/listinfo/s> pringframework-developer
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > -- 
> > Isabelle Muszynski
> > Software Engineer
> > Zandweellaan 4
> > 2660 Antwerpen
> > Belgium
> > Tel. 32-(0)3-830 18 54
> > Mobile: 32-(0)485 49 50 89
> > Email: isa...@me...
> > Website: www.meta-logix.com
> > 
> 
> 
> 
> 

-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

RE : RE : [Springframework-developer] Problem with MySqlMaxValueIncrementer

[JP P. <jp....@ti...>]

At this point, Rod or Juergen will certainly be more helpful as AOP will =
certainly have to enter in the dance.

Jean-Pierre


> -----Message d'origine-----
> De : Isabelle Muszynski [mailto:isa...@me...]=20
> Envoy=C3=A9 : vendredi 30 mai 2003 16:43
> =C3=80 : JP Pawlak
> Cc : spr...@li...
> Objet : Re: RE : [Springframework-developer] Problem with=20
> MySqlMaxValueIncrementer
>=20
>=20
> Hi JP,
>=20
> As a matter of fact I also thought of requiring the=20
> equivalent of EJB's Requires New transaction. The problem=20
> still is how to implement this: how do I know whether the=20
> code is running in a CMP/BMP EJB, under JTA, ... I'm a bit=20
> baffled, don't know the answer.
>=20
> There is a solution which makes the whole implementation=20
> redundant : for the user to cast the Statement or=20
> PreparedStatement to a com.mysql.Statement=20
> (PreparedStatement) and then call getLastInsertId(). I don't=20
> want to do this in the framework, because then compilation=20
> becomes dependent on the mysql JDBC library.
>=20
> Isabelle
>=20
> On Fri, May 30, 2003 at 04:29:30PM +0200, JP Pawlak wrote:
> > Hi Isabelle,
> >=20
> > Ah, the continuously problematic MaxValueIncrementer ;-) !
> > As with the key search we will always have potentially two=20
> Sql orders,=20
> > how manage this? The best would be to have the possibility to treat=20
> > separately. It would be convenient to assure the key search=20
> being out=20
> > of any transaction and being committed regardless of a current=20
> > transaction. In this case, simply the key(s) used by the rollbacked=20
> > operations are lost. I don't know, so quickly, if it is=20
> possible and=20
> > how.
> >=20
> > Jean-Pierre
> > =20
> >=20
> > > -----Message d'origine-----
> > > De : spr...@li...
> > > [mailto:spr...@li...]
> > >  De la part de Isabelle Muszynski
> > > Envoy=C3=83=C2=A9 : vendredi 30 mai 2003 15:28
> > > =C3=83=E2=82=AC : spr...@li...
> > > Objet : [Springframework-developer] Problem with=20
> > > MySqlMaxValueIncrementer
> > >=20
> > >=20
> > > Hi everyone,
> > >=20
> > > There is a problem with MySQLMaxValueIncrementer (and I think
> > > with the Oracle one as well). Currently the code doesn't do=20
> > > any transaction management which has 3 consequences :
> > > (1) if the calling code does a rollback, the value(s) cached=20
> > > in / handed out by the object are invalid
> > > (2) the code requires the caller to do a commit, which I'm=20
> > > sure most people will forget to do if using the framework.
> > > (3) when requesting a bunch of keys, it is possible to get a=20
> > > series of non-sequential numbers from the database. This=20
> > > because of the loop in the code, which is requred by mySQL=20
> > > last_insert_id() semantics. This particular problem could be=20
> > > solved by maintaining an array of values, instead of just a=20
> > > maxId. I'll make this change over the weekend. This=20
> > > particular problem won't show up in the Oracle=20
> > > implementation. I'm not sure how to solve the items 1 & 2=20
> > > though. The code can be called in a variety of circumstances=20
> > > (BMP and CMP beans, no EJB, ...). Can we even assume the=20
> > > presence of a transaction manager?
> > >=20
> > > Any ideas?
> > >=20
> > >=20
> > > --
> > > Isabelle Muszynski
> > > Software Engineer
> > > Zandweellaan 4
> > > 2660 Antwerpen
> > > Belgium
> > > Tel. 32-(0)3-830 18 54
> > > Mobile: 32-(0)485 49 50 89
> > > Email: isa...@me...
> > > Website: www.meta-logix.com
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: eBay
> > > Get office equipment for less on eBay!
> > > http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5
> > >=20
> > > _______________________________________________
> > >=20
> > > Springframework-developer mailing list
> > > Spr...@li...
> > >=20
> https://lists.sourceforge.net/lists/listinfo/s> =
pringframework-developer
> > >=20
> >=20
> >=20
> >=20
> >=20
>=20
> --=20
> Isabelle Muszynski
> Software Engineer
> Zandweellaan 4
> 2660 Antwerpen
> Belgium
> Tel. 32-(0)3-830 18 54
> Mobile: 32-(0)485 49 50 89
> Email: isa...@me...
> Website: www.meta-logix.com
>=20

Re: RE : [Springframework-developer] Problem with MySqlMaxValueIncrementer

[Isabelle M. <isa...@me...>]

Hi JP,

As a matter of fact I also thought of requiring the equivalent of EJB's Requires New transaction. The problem still is how to implement this: how do I know whether the code is running in a CMP/BMP EJB, under JTA, ...
I'm a bit baffled, don't know the answer.

There is a solution which makes the whole implementation redundant : for the user to cast the Statement or PreparedStatement to a com.mysql.Statement (PreparedStatement) and then call getLastInsertId(). I don't want to do this in the framework, because then compilation becomes dependent on the mysql JDBC library.

Isabelle

On Fri, May 30, 2003 at 04:29:30PM +0200, JP Pawlak wrote:
> Hi Isabelle,
> 
> Ah, the continuously problematic MaxValueIncrementer ;-) !
> As with the key search we will always have potentially two Sql orders,
> how manage this?
> The best would be to have the possibility to treat separately. It would
> be convenient to assure the key search being out of any transaction and
> being committed regardless of a current transaction. In this case,
> simply the key(s) used by the rollbacked operations are lost. I don't
> know, so quickly, if it is possible and how.
> 
> Jean-Pierre
>  
> 
> > -----Message d'origine-----
> > De : spr...@li... 
> > [mailto:spr...@li...]
> >  De la part de Isabelle Muszynski
> > Envoyé : vendredi 30 mai 2003 15:28
> > À : spr...@li...
> > Objet : [Springframework-developer] Problem with 
> > MySqlMaxValueIncrementer
> > 
> > 
> > Hi everyone,
> > 
> > There is a problem with MySQLMaxValueIncrementer (and I think 
> > with the Oracle one as well). Currently the code doesn't do 
> > any transaction management which has 3 consequences :
> > (1) if the calling code does a rollback, the value(s) cached 
> > in / handed out by the object are invalid
> > (2) the code requires the caller to do a commit, which I'm 
> > sure most people will forget to do if using the framework.
> > (3) when requesting a bunch of keys, it is possible to get a 
> > series of non-sequential numbers from the database. This 
> > because of the loop in the code, which is requred by mySQL 
> > last_insert_id() semantics. This particular problem could be 
> > solved by maintaining an array of values, instead of just a 
> > maxId. I'll make this change over the weekend. This 
> > particular problem won't show up in the Oracle 
> > implementation. I'm not sure how to solve the items 1 & 2 
> > though. The code can be called in a variety of circumstances 
> > (BMP and CMP beans, no EJB, ...). Can we even assume the 
> > presence of a transaction manager?
> > 
> > Any ideas?
> > 
> > 
> > -- 
> > Isabelle Muszynski
> > Software Engineer
> > Zandweellaan 4
> > 2660 Antwerpen
> > Belgium
> > Tel. 32-(0)3-830 18 54
> > Mobile: 32-(0)485 49 50 89
> > Email: isa...@me...
> > Website: www.meta-logix.com
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: eBay
> > Get office equipment for less on eBay! 
> > http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5
> > 
> > _______________________________________________
> > 
> > Springframework-developer mailing list 
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > 
> 
> 
> 
> 

-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

RE : [Springframework-developer] Problem with MySqlMaxValueIncrementer

[JP P. <jp....@ti...>]

Hi Isabelle,

Ah, the continuously problematic MaxValueIncrementer ;-) !
As with the key search we will always have potentially two Sql orders,
how manage this?
The best would be to have the possibility to treat separately. It would
be convenient to assure the key search being out of any transaction and
being committed regardless of a current transaction. In this case,
simply the key(s) used by the rollbacked operations are lost. I don't
know, so quickly, if it is possible and how.

Jean-Pierre
=20

> -----Message d'origine-----
> De : spr...@li...=20
> [mailto:spr...@li...]
>  De la part de Isabelle Muszynski
> Envoy=E9 : vendredi 30 mai 2003 15:28
> =C0 : spr...@li...
> Objet : [Springframework-developer] Problem with=20
> MySqlMaxValueIncrementer
>=20
>=20
> Hi everyone,
>=20
> There is a problem with MySQLMaxValueIncrementer (and I think=20
> with the Oracle one as well). Currently the code doesn't do=20
> any transaction management which has 3 consequences :
> (1) if the calling code does a rollback, the value(s) cached=20
> in / handed out by the object are invalid
> (2) the code requires the caller to do a commit, which I'm=20
> sure most people will forget to do if using the framework.
> (3) when requesting a bunch of keys, it is possible to get a=20
> series of non-sequential numbers from the database. This=20
> because of the loop in the code, which is requred by mySQL=20
> last_insert_id() semantics. This particular problem could be=20
> solved by maintaining an array of values, instead of just a=20
> maxId. I'll make this change over the weekend. This=20
> particular problem won't show up in the Oracle=20
> implementation. I'm not sure how to solve the items 1 & 2=20
> though. The code can be called in a variety of circumstances=20
> (BMP and CMP beans, no EJB, ...). Can we even assume the=20
> presence of a transaction manager?
>=20
> Any ideas?
>=20
>=20
> --=20
> Isabelle Muszynski
> Software Engineer
> Zandweellaan 4
> 2660 Antwerpen
> Belgium
> Tel. 32-(0)3-830 18 54
> Mobile: 32-(0)485 49 50 89
> Email: isa...@me...
> Website: www.meta-logix.com
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!=20
> http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5
>=20
> _______________________________________________
>=20
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

[Springframework-developer] value/ref

[JP P. <jp....@ti...>]

Hi Rod, everybody,

You will say I come back with an old horse and continue to discuss what
I approved, but I prefer clarify now than when code is written.

As the XML goes to complexify, we have almost everywhere to handle with
ref/values and constantly mix both.
Why not have a single tag with an optional ref attribute. In a SAX
handler, it is only a matter of switching depending of the presence of
the ref attribute instead of treating two diffrerent events.

Can you done an example for which a single tag is not so handy as two?

Regards
_____________________________
Jean-Pierre Pawlak
jp....@ti...

[Springframework-developer] Problem with MySqlMaxValueIncrementer

[Isabelle M. <isa...@me...>]

Hi everyone,

There is a problem with MySQLMaxValueIncrementer (and I think with the Oracle one as well). Currently the code doesn't do any transaction management which has 3 consequences :
(1) if the calling code does a rollback, the value(s) cached in / handed out by the object are invalid
(2) the code requires the caller to do a commit, which I'm sure most people will forget to do if using the framework.
(3) when requesting a bunch of keys, it is possible to get a series of non-sequential numbers from the database. This because of the loop in the code, which is requred by mySQL last_insert_id() semantics. This particular problem could be solved by maintaining an array of values, instead of just a maxId. I'll make this change over the weekend. This particular problem won't show up in the Oracle implementation.
I'm not sure how to solve the items 1 & 2 though. The code can be called in a variety of circumstances (BMP and CMP beans, no EJB, ...). Can we even assume the presence of a transaction manager?

Any ideas?


-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com