springframework-developer — Spring Framework developers list

[Springframework-developer] src for long keys

[JP PAWLAK\(Tiscali\) <jp....@ti...>]

Hi Isabelle,

Related on my last post on the Spring Framework list, I enclosed my
proposals of changes to handle long keys on databases.
As I'm not registered as developer, I cannot upload. And in all cases,
it's your work, so your approval is also mandatory.

NB: It's nothing about caching in this proposal.

Best regards,
Jean-Pierre PAWLAK
jp....@ti...
 

[Springframework-developer] longs and cached key-generator

[JP PAWLAK\(Tiscali\) <jp....@ti...>]

Hi everybody,

First, thanks a lot to J=FCergen and Rod for their explanations about
transactions and AOP.

For now, starting at the start, I have to use the key-generator (I'm
using MySql with InnoDB).
In this area, I will talk about two topics. 1) the use of longs 2)
caching in the key-generator

1) LONGS
I'm wondering on general lack for the use of longs and Longs in the
framework.
For the keys, are for now available ints, doubles(?) and ints as
strings. My strategy is having a unique key-generator for the whole
database, so an id is unique in the whole database. Using ints could
suffice, but handling longs has sense.
The first thing seems to add this code in the SqlFunction class (method
extract, switch statement):
------
  case Types.BIGINT :
      obj =3D new Long(rs.getLong(1));
      break;
------
And after adding long handling methods from DataFieldMaxValueIncrementer
(long nextLongValue()) to the different classes implementing this
interface.

So, if the team accepts this idea, I can implement this and send the
sources to Isabelle for integrating.

2) CACHING
Every need of a key makes for now a RDBMS operation, this is not
necessary. Accepting eventually a few more holes in the numbering, it
could be attractive to have an increment greater than one and having by
the way a range to serve keys without querying the database. This has a
sense if the key-generator is not created each time but is a singleton.
It request the first time the database incrementing the sequence of an
increment value done in the bean definition, saying 20. It serves this
key minus 19. The next call, it serves the key minus 18 without querying
the database. And so on, when the reserve is empty, it will query the
database for a new set. The only drawback is the loosing of pending keys
when the server stops.=20
If the default value for the increment is 1, not providing an increment
value will disable the caching and run like today. In this case, only a
memory test is performed more that for now.=20
This could improve the performance, but is clearly more useful in a per
database case as in the case of a per table key-generator.
Is this best modified on the core classes or in an extended class?

As I used this mechanism with the old i21 framework, I could also make
the job.

I'm waiting for answers to know if I can go and in which way.

Regards,
Jean-Pierre PAWLAK

Fw: [Springframework-developer] docs & tutorial

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

Just thought I should provide some context for the AOP tx stuff by sharing
the notes I sent Isabelle for the bean factory tutorial.

There are no notes on AOP framework at the moment. It has many features the
tx tutorial doesn't touch on, and which I'll try to document next week. The
aop framework tests are a good place to look, as they have 95% coverage!


> Here are some notes on the current bean factory functionality. I'll add
some
> on ApplicationContext later. I think code examples would be good to
> illustrate the points: there are many in the tests and of course there's
> probably going to be a new sample app.
>
> I'll also try to put together an AOP one, but that's probably going to be
> after Easter now.
>
> I've put asteriscs against things that are new or changed since the book.
> The first part of chapter 11 has lots on the motivation of the bean
factory,
> so I haven't recapped too much of that.
>
>
> OVERVIEW
> A BeanFactory is a simple interface that provides a directory of
configured
> objects. Spring emphasises Java Beans heavily, and BeanFactories are used
> heavily by other Spring functionality. We've found BeanFactories to be an
> elegant way of providing a lightweight directory, and encouraging good
> practice by programming to interfaces rather than concrete classes.
Chapter
> 11 of "Expert One on One J2EE Design and Development" discusses the
> motivation of the bean factory, and ways in which it's superior to common
> alternative solutions to the problems it addresses.
>
> Bean instances are obtained from a BeanFactory by name. BeanFactory
> implementations support "singleton" bean instances (the commonest
> requirement) and "prototype" instances. With a singleton instance,
repeated
> call to the bean factory to obtain a particular bean by name will always
> return the same object. With prototype instances, each call will return an
> independent instance, expressing the Prototype GoF design pattern, rather
> than the Singleton. We've found singleton beans to be most useful, and
find
> that they tend to avoid any need to have multiple singletons scattered
> around an application. Avoiding multiple singletons or many independent
> factories is a Good Thing. For example, it facilitates unit testing: it's
> very easy to configure a factory at test time to return a mock object or
> other stub instead of a business object that requires resources beyond the
> scope of the test.
>
> How bean instances are configured is factory-specific, although XML
> documents and properties files are the commonest form. The syntax is
> intuitive, based around the specification of a fully qualified class name
> and JavaBean properties.
>
> **** Example of XML and properties syntax
>
> Although it's possible to cast beans to a specific class, it's strongly
> recommended that all application code knows only the interface(s)
> implemented by each bean. This ensures maximum pluggability. (Note that in
> the case of beans requiring an AOP proxy, it's impossible to code to the
> specific class, and interfaces _must_ be used.)
>
>
> From the user's perspective, all BeanFactory implementations are used
> identically. This means that it's possible to switch easily from a test
bean
> factory, which may replace some business objects with mock objects or
stubs,
> to a real bean factory without impacting client-side application code.
>
> ListableBeanFactory is a subinterface of BeanFactory implemented by
> BeanFactories that can enumerate the names and types of all beans they
> manage. Most of the supplied bean factories implement this interface.
> Sometimes code using BeanFactories will depend on a ListableBeanFactory.
For
> example, Spring's web functionality looks for an enumeration of beans that
> can handle HTTP requests.
>
>
> FACTORY BEANS
> Sometimes a bean definition is more complex than the definition of the
class
> to return along with its JavaBeans properties. We might want to perform
some
> special steps between definition and returned object, for example, with
the
> returned class varying depending on some state.
>
> We might want to do return a proxy to an underlying object: for example,
an
> AOP proxy that invokes a number of interceptors before the target, or a
> proxy concealing access to a remote object.
>
> The FactoryBean interface provides an additional step of abstraction in
> which the FactoryBean manages the lifecycle of a single type of bean. Any
> class that implements that com.interface21.beans.factory.FactoryBean
> interface will automatically be treated as  a factory bean.
>
> Note that this replaces the more complex "custom bean definition" approach
> discussed in "Expert 1:1 J2EE". *
>
> Because a factory bean introduces two objects (the FactoryBean and the
> object(s) it returns) we also need to be able to get to the factory. All
> BeanFactory implementations support a special syntax to allow this,
inspired
> by C/C++ pointer dereferencing.
>
> getBean("&factoryName")
>
> will return the factory, rather than an instance of the bean managed by
the
> factory. The ampersand syntax may only be used on factory beans: a
> BeanIsNotAFactoryException will be thrown if it is used on ordinary beans.
>
> Being able to obtain the factory gives us the option of altering or
querying
> factory settings programmatically. (As this reduces implementation
choices,
> it shouldn't be done lightly.)
>
> ADVANCED FEATURES
> All bean factory implementations support the creation of references
amongst
> beans. This enables the easy creation of sophisticated object graphs. It
> also enables application objects used as beans in a BeanFactory to avoid
any
> dependence on the BeanFactory or other Spring APIs, merely exposing
JavaBean
> properties that will be set to the value of other beans at runtime. This
> ability for application code to avoid dependence on proprietary APIs is
one
> of Spring's major advantages.
>
> EXAMPLE of references**
>
> Most BeanFactory implementations, such as XML and properties-based
> implementations, use string representations of JavaBean properties. What
if
> we want to specify an object other than a reference to another bean using
a
> string? All BeanFactory implementations (and the underlying
> com.interface21.beans JavaBean manipulation API) uses the standard
JavaBeans
> PropertyEditor functionality. Installed PropertyEditors will automatically
> be invoked to create JavaBean instances from Strings if necessary. Thus
> Spring provides a number of PropertyEditor implementations itself, in the
> com.interface21.beans.propertyeditors package, for types such as
> java.util.Properties and String[], but can automatically take advantage of
> any other available PropertyEditors, including those provided for
primitive
> type wrappers with the core JavaBeans API.
>
>
> Sometimes multiple beans inherit from a common base bean definition (or
> hierarchy of bean definitions), meaning that the descendant beans
"inherit"
> all properties from the ancestor definitions, but can override and add
> further properties as they desire. This can safe a lot of typing and allow
> for consistent changes in a single place only when many beans share a lot
of
> properties. A common use of this is web tier views, in which many views
> share most of their properties.
>
>
> INHERITANCE
>
> The concept of inheritance doesn't apply only to bean instances in the
same
> factory; BeanFactories themselves can also have parents, to an arbitrary
> depth. Each bean instance will be sought by the parent if not found in a
> child bean factory.
>
> Why is this useful? Consider how the Spring MVC framework uses Spring's
> BeanFactories. Each controller servlet has its own BeanFactory
> implementation, backed by default by its own XML file. However all
servlets
> extend a shared BeanFactory that is ServletContext wide, enabling them to
> share common objects but override specific objects and add new objects as
> they desire.
>
> A base bean factory can contain common definitions, such as AOP
> interceptors, which may be used across a whole application.
>
> Note that another way to get reuse out of bean definitions when using an
XML
> bean factory is to import content in the form of XML entity references.
This
> avoids the duplication of boilerplate code.
>
>
> FUTURE DIRECTIONS
> - BeanFactories are likely to support dynamic reconfiguration of
beans--for
> example, by monitoring an XML or properties file and reapplying any
changed
> properties.
> - We may introduce "private" beans. These will be available to configure
> other beans, but will not be accessible to user code with the getBean()
> method. This might be used to conceal the underlying object behind an AOP
> proxy, for example, to ensure that the necessary interception always
occurs.
> - More BeanFactory implementations may be added. For example, a
BeanFactory
> could easily be added to expose all SLSB instances in a JNDI tree, or all
> web services at a specific location. Exactly what new factories are added
> are up to you, as Spring users. Both these are just examples of what can
be
> done: we're hoping for suggestions and contributions that people have
found
> useful in real applications. Because the BeanFactory, and even
> ListableBeanFactory, interface is so simple, it's very easy to implement
> additional bean factories.
>
> All BeanFactory changes are likely to be backward compatible.
>
>
>
>
> Rod
>
>
>
> > Hi everyone,
> >
> > Rod's ideas are fine by me.
> >
> > (1) create a new module in cvs called samples, at the same level as main
> (I don't think I have the privileges to do that, so I hereby delegate this
> task)
> > (2) we should have separate examples for each area; so for ex. some jdbc
> examples, some jndi examples etc... Everyone should send me whatever they
> have (maybe the stuff they used for testing, playing etc..). I will
collate
> and create examples where they are lacking. If I get into trouble (for ex.
> with the AOP stuff, which I haven't looked at yet) I will ask for help.
> > (3) everyone should send me some documentation on what they did.
Together
> with Rod's book, this will hopefully be enough to put together the 1.0
docs
> > (4) we should also have an end-to-end application with maybe a tutorial.
I
> did not like the example app in Rod's book very much, I felt the business
> logic obscured the point here and there and something simpler would have
> come across better. Maybe we could do a bookstore with
> > a) entry screen with promotions, a list of categories to browse and a
> search button
> > (b) the search button offers a screen where one can fill in either
author,
> title or keywords
> > (c) in each category a list of books with author, title, etc... and the
> possibility to purchase
> > (d) a shopping cart
> > (e) a checkout screen
> >
> > If everybody agrees with this idea for the tutorial, I will create the
> database design and UML model, and we can apportion the work from there
> >
> > Isabelle
> >
> > --
> > Isabelle Muszynski
> > Zandweellaan 4
> > 2660 Antwerpen
> > Belgium
> > Tel. 32-(0)3-830 18 54
> > Mobile: 32-(0)485 49 50 89
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Etnus, makers of TotalView, The
> debugger
> > for complex code. Debugging C/C++ programs can leave you feeling lost
and
> > disoriented. TotalView can help you find your way. Available on major
UNIX
> > and Linux platforms. Try it free. www.etnus.com
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

RE: [Springframework-developer] Using the framework

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

Rod,

thanks a lot for the description of AOP usage. I'll take a look at it, try
it and give you a feedback. It looks very interesting :-)

Dmitriy. 

-----Original Message-----
From: Rod Johnson
To: JP PAWLAK(Tiscali); Spring Developers (E-mail)
Sent: 5/2/2003 5:16 PM
Subject: Re: [Springframework-developer] Using the framework

JP, Dmitriy,

Juergen has described the callback template. I've just finished the
first
usable cut of the AOP declarative tx management.  I'm very excited about
this. It still has some limitations, but I think it's ready to try to
anger.

Here's a summary of how it works. Also see the tests for
com.interface21.aop.interceptor.transaction. BeanFactoryTransactionTests
and
the XML file, from which I've pasted the following.

The mechanism behind it is AOP. This means that we have an interface, a
set
of interceptors in a chain, invoked in a given order, and (usually) a
target
object, that actually implements the interface. (The InvokerInterceptor
invokes the target reflectively. A target isn't required if the last
interceptor in the chain wants to do something else.)

The developer's responsibility is to configure the target, interceptors
and
AOP proxy as beans. So in the XML format it will be something like this:

Define the target. Just an ordinary bean definition:

<bean name="target" class="com.interface21.beans.TestBean">
     <property name="name">Rod</property>
     <property name="age">32</property>
</bean>

Define any interceptors you want. Of course the bean definitions can be
in
any order, as usual. The interceptors must implement the
org.aopalliance.MethodInterceptor interface. I've included a debug
interceptor, which logs to the console:

<bean name="debugInterceptor"
class="com.interface21.aop.interceptor.misc.DebugInterceptor">
</bean>

You'll need to configure a transaction interceptor. These are
threadsafe, so
all AOP proxies can share one singleton instance. The most interesting
thing
here is the transactionAttributeSource, which can be a string
representation
of the transaction rules. See the TransactionAttributeSourceEditor class
and
tests for descriptions. The format is

FQN.methodName=PROPAGATION_CODE,[ISOLATION_CODE,rollback_rules*]

where codes are the constant names in PLATFORM_TRANSACTION_MANAGER. For
example:

<bean name="txInterceptor"
class="com.interface21.aop.interceptor.transaction.TransactionIntercepto
r">
     <property name="transactionAttributeSource">
          com.interface21.beans.ITestBean.setAge=PROPAGATION_REQUIRED
     </property>
</bean>

Here I've only described one method, but other methods can be on
separate
lines. Rollback rules look like
+ServletException,-MyException
This means commit on ServletException or subclasses, but rollback on
MyException and subclasses. With no explicit rollback rules it behaves
like
EJB, with rollback on unchecked. Configurable rollback is the one thing
that
the AOP approach can do that the TransactionTemplate can't (besides the
transparent declarative model). And it's a capability that EJB doesn't
have.
I've always been disappointed to have to explicitly rollback on checked
exceptions, as I typically want these to cause transaction rollback.

Now you declare the factory bean from which you'll get references. Note
that
you specify the proxy interfaces, and the interceptor names. These are
the
names of beans. Note that the last one is the target bean: an
InvokerIntercepter will be created automatically. I added the
FactoryBean
functionality: see the tests to understand this, as it's not AOP
specific.

<bean name="txtest"
  class="com.interface21.aop.framework.ProxyFactoryBean"
>
     <property
name="proxyInterfaces">com.interface21.beans.ITestBean</property>

     <property
name="interceptorNames">debugInterceptor,txInterceptor,target</property>

</bean>

And that's that. You ask for beans from the FactoryBean, not the target,
but
the proxying and interception is completely transparent. Like this:

ITestBean tb = (ITestBean) beanFactory.getBean("txtest");

When the transaction interceptor finds a method with a tx descriptor, it
creates a transaction. It commits on success, and rolls back if the user
sets rollback only (see TransactionInterceptorTests for how to do this)
or
if it throws an exception that its rollback rules say should cause
rollback.
Rollback only on runtime exceptions if no explicit rollback rules.

The transaction and other interceptors do not change any exceptions
thrown.
Whether or not the tx interceptor rolls back, it will return exactly the
same exception to the client. The transaction interceptor does nothing
but
pass through to the next interceptor if there's no transaction
descriptor.

I've done some profiling and the performance overhead seems small.

It should be solid now--the tests are pretty thorough. The limitations
are:
- must use fully qualified class name
- no support for method overloading
- no wildcards

Ultimately I think the best approach is transaction descriptors in
source
files, as metadata attributes, as in .NET. I've partially implemented
this
using Attrib4j, but Attrib4j still lacks some features I need. You'll
need
Attrib4j jar to get the example to work as it's referenced by the
TransactionAttribute.

If you want to customize transaction management, you can set the
platformTransactionManager property of the TransactionTemplate. Default
is
JtaTransactionManager.

I'd encourage you to try it, and appreciate any feedback on both
usability
and functionality.

Regards,
Rod

----- Original Message -----

But a main topic rests unclear to me apart certain parts: the
transactions.
Could anyone (I think especially to Jüergen or Rod), give a roadmap or a
tiny example of their use. If possible, for the two ways, programmatic
and declarative.
For the programmatic way, the question could simply be : if a
TransactionTemplate.execute() method throws an exception, are the RDBMS
operations in earlier execute() calls with the same template or earlier
executed in the same execute call rollbacked ?




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Using the framework

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

JP, Dmitriy,

Juergen has described the callback template. I've just finished the first
usable cut of the AOP declarative tx management.  I'm very excited about
this. It still has some limitations, but I think it's ready to try to anger.

Here's a summary of how it works. Also see the tests for
com.interface21.aop.interceptor.transaction. BeanFactoryTransactionTests and
the XML file, from which I've pasted the following.

The mechanism behind it is AOP. This means that we have an interface, a set
of interceptors in a chain, invoked in a given order, and (usually) a target
object, that actually implements the interface. (The InvokerInterceptor
invokes the target reflectively. A target isn't required if the last
interceptor in the chain wants to do something else.)

The developer's responsibility is to configure the target, interceptors and
AOP proxy as beans. So in the XML format it will be something like this:

Define the target. Just an ordinary bean definition:

<bean name="target" class="com.interface21.beans.TestBean">
     <property name="name">Rod</property>
     <property name="age">32</property>
</bean>

Define any interceptors you want. Of course the bean definitions can be in
any order, as usual. The interceptors must implement the
org.aopalliance.MethodInterceptor interface. I've included a debug
interceptor, which logs to the console:

<bean name="debugInterceptor"
class="com.interface21.aop.interceptor.misc.DebugInterceptor">
</bean>

You'll need to configure a transaction interceptor. These are threadsafe, so
all AOP proxies can share one singleton instance. The most interesting thing
here is the transactionAttributeSource, which can be a string representation
of the transaction rules. See the TransactionAttributeSourceEditor class and
tests for descriptions. The format is

FQN.methodName=PROPAGATION_CODE,[ISOLATION_CODE,rollback_rules*]

where codes are the constant names in PLATFORM_TRANSACTION_MANAGER. For
example:

<bean name="txInterceptor"
class="com.interface21.aop.interceptor.transaction.TransactionInterceptor">
     <property name="transactionAttributeSource">
          com.interface21.beans.ITestBean.setAge=PROPAGATION_REQUIRED
     </property>
</bean>

Here I've only described one method, but other methods can be on separate
lines. Rollback rules look like
+ServletException,-MyException
This means commit on ServletException or subclasses, but rollback on
MyException and subclasses. With no explicit rollback rules it behaves like
EJB, with rollback on unchecked. Configurable rollback is the one thing that
the AOP approach can do that the TransactionTemplate can't (besides the
transparent declarative model). And it's a capability that EJB doesn't have.
I've always been disappointed to have to explicitly rollback on checked
exceptions, as I typically want these to cause transaction rollback.

Now you declare the factory bean from which you'll get references. Note that
you specify the proxy interfaces, and the interceptor names. These are the
names of beans. Note that the last one is the target bean: an
InvokerIntercepter will be created automatically. I added the FactoryBean
functionality: see the tests to understand this, as it's not AOP specific.

<bean name="txtest"
  class="com.interface21.aop.framework.ProxyFactoryBean"
>
     <property
name="proxyInterfaces">com.interface21.beans.ITestBean</property>

     <property
name="interceptorNames">debugInterceptor,txInterceptor,target</property>

</bean>

And that's that. You ask for beans from the FactoryBean, not the target, but
the proxying and interception is completely transparent. Like this:

ITestBean tb = (ITestBean) beanFactory.getBean("txtest");

When the transaction interceptor finds a method with a tx descriptor, it
creates a transaction. It commits on success, and rolls back if the user
sets rollback only (see TransactionInterceptorTests for how to do this) or
if it throws an exception that its rollback rules say should cause rollback.
Rollback only on runtime exceptions if no explicit rollback rules.

The transaction and other interceptors do not change any exceptions thrown.
Whether or not the tx interceptor rolls back, it will return exactly the
same exception to the client. The transaction interceptor does nothing but
pass through to the next interceptor if there's no transaction descriptor.

I've done some profiling and the performance overhead seems small.

It should be solid now--the tests are pretty thorough. The limitations are:
- must use fully qualified class name
- no support for method overloading
- no wildcards

Ultimately I think the best approach is transaction descriptors in source
files, as metadata attributes, as in .NET. I've partially implemented this
using Attrib4j, but Attrib4j still lacks some features I need. You'll need
Attrib4j jar to get the example to work as it's referenced by the
TransactionAttribute.

If you want to customize transaction management, you can set the
platformTransactionManager property of the TransactionTemplate. Default is
JtaTransactionManager.

I'd encourage you to try it, and appreciate any feedback on both usability
and functionality.

Regards,
Rod

----- Original Message -----

But a main topic rests unclear to me apart certain parts: the
transactions.
Could anyone (I think especially to Jüergen or Rod), give a roadmap or a
tiny example of their use. If possible, for the two ways, programmatic
and declarative.
For the programmatic way, the question could simply be : if a
TransactionTemplate.execute() method throws an exception, are the RDBMS
operations in earlier execute() calls with the same template or earlier
executed in the same execute call rollbacked ?




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] transactions, datasource package, Hibernate

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

SGkgZXZlcnlib2R5LA0KDQpJJ3ZlIHByb3RvdHlwZWQgbXkgcHJvcG9zYWwgdG9kYXkgYW5kIG5h
bWVkIGl0ICJEYXRhU291cmNlVHJhbnNhY3Rpb25NYW5hZ2VyIiwgY29uZmlndXJlZCB0byBhIGNl
cnRhaW4gRGF0YVNvdXJjZSBhbmQgY2FwYWJsZSBvZiBoYW5kbGluZyB0cmFuc2FjdGlvbnMgdmlh
IHRocmVhZC1ib3VuZCBjb25uZWN0aW9ucy4gSXQncyBhY3R1YWxseSBhIHJld29ya2luZyBvZiB0
aGUgZm9ybWVyIFNpbmdsZUNvbm5lY3Rpb25UcmFuc2FjdGlvbk1hbmFnZXIsIG5vdyBpbmNvcnBv
cmF0aW5nIGl0cyBzcGVjaWFsIHRyZWF0aW5nIG9mIFNpbmdsZUNvbm5lY3Rpb25EYXRhU291cmNl
IChubyBuZWVkIGZvciB0aHJlYWQgYmluZGluZyBoZXJlKS4gVGhlIHNwZWNpYWwgbG9va3VwIGZv
ciB0aHJlYWQtYm91bmQgY29ubmVjdGlvbnMgaXMgaW4gb3VyIHN0YW5kYXJkIERhdGFTb3VyY2VV
dGlscy5nZXRDb25uZWN0aW9uIHdoaWNoIGlzIG5vdyByZXF1aXJlZCBmb3IgRGF0YVNvdXJjZVRy
YW5zYWN0aW9uTWFuYWdlci1jYXBhYmxlIGNvZGUuDQoNCkFzIGZhciBhcyBJJ3ZlIHRlc3RlZCBp
dCB0b2RheSwgaXQgd29ya3MgbmljZWx5ISBJJ2QgbGlrZSB0byBjaGVjayBpdCBpbiBwcm9tcHRs
eSwgYnV0IEkndmUgcmV3b3JrZWQgdGhlIEpEQkMgcGFja2FnZSBhIGJpdCBpbiB0aGUgY291cnNl
IG9mIGRldmVsb3BpbmcgaXQuIEkndmUgY3JlYXRlZCBhIG5ldyBjb20uaW50ZXJmYWNlMjEuamRi
Yy5kYXRhc291cmNlIHBhY2thZ2UsIGNvbnRhaW5pbmcgdGhlIDIgZGF0YSBzb3VyY2VzIGZyb20g
Y29tLmludGVyZmFjZTIxLmpkYmMubW9jayAodGhhdCBhcmVuJ3Qgc28gbW9jayBhbnl3YXkpICsg
RGF0YVNvdXJjZVV0aWxzICsgU21hcnREYXRhU291cmNlICsgdGhlIDIgY29ubmVjdGlvbiBoYW5k
bGluZyBleGNlcHRpb25zLiBjb20uaW50ZXJmYWNlMjEuamRiYy5jb3JlIGlzIHNvbWV3aGF0IGxh
cmdlIGFueXdheSwgc28gSU1PIGl0IG1ha2VzIHNlbnNlIHRvIGludHJvZHVjZSB0aGlzIG5ldyBw
YWNrYWdlLiBBbnkgb2JqZWN0aW9ucz8NCg0KQlRXLCBJJ3ZlIGFkZGVkIGEgZ2VuZXJpYyBUaHJl
YWRPYmplY3RNYW5hZ2VyIHRvIGNvbS5pbnRlcmZhY2UyMS51dGlsLCB1c2VkIGFzIGluc3RhbmNl
IGluIERhdGFTb3VyY2VVdGlscy4gSXQgYWxsb3dzIERhdGFTb3VyY2VUcmFuc2FjdGlvbk1hbmFn
ZXIgdG8gYmluZCBjb25uZWN0aW9ucyB0byB0aHJlYWRzLCBhbmQgRGF0YVNvdXJjZVV0aWxzIHRv
IGxvb2sgdXAgdGhyZWFkLWJvdW5kIGNvbm5lY3Rpb25zICh3aXRob3V0IGRlcGVuZGVuY3kgb24g
RGF0YVNvdXJjZVRyYW5zYWN0aW9uTWFuYWdlcikuIEZ1cnRoZXJtb3JlLCBpdCBzZXJ2ZXMgYSBz
aW1pbGFyIHB1cnBvc2UgaW4gdGhlIEhpYmVybmF0ZVRyYW5zYWN0aW9uTWFuYWdlci4NCg0KQXBy
b3BvczogSSd2ZSBhbHNvIHByb3RvdHlwZWQgYSB0cmFuc2FjdGlvbiBtYW5hZ2VyIHRoYXQgYmlu
ZHMgSGliZXJuYXRlIHNlc3Npb25zIHRvIHRocmVhZHMsIGFsbG93aW5nIGZvciBhYnN0cmFjdCB0
cmFuc2FjdGlvbiBoYW5kbGluZyB3aXRoIGZ1bGwgc3VwcG9ydCBmb3IgSGliZXJuYXRlJ3MgdHJh
bnNhY3Rpb25hbCBjYWNoaW5nIChub3QgcG9zc2libGUgd2l0aCBEYXRhU291cmNlVHJhbnNhY3Rp
b25NYW5hZ2VyLCBhbmQgcXVpdGUgYSBwYWluIHdpdGggSlRBLCBleGNlcHQgd2hlbiB1c2luZyBh
IEpDQSBjb25uZWN0b3IpLiBJJ3ZlIGFsc28gYWRkZWQgSGliZXJuYXRlVGVtcGxhdGUgYW5kIEhp
YmVybmF0ZUNhbGxiYWNrIHRoYXQgd2UndmUgYmVlbiB1c2luZyBmb3IgYSB3aGlsZSBhdCB3ZXJr
M0FULCBhbmQgY3JlYXRlZCBhIEhpYmVybmF0ZVV0aWxzIGhlbHBlciBjbGFzcy4gVGhlIHRlbXBs
YXRlIG5lZWRlZCBzb21lIHJld29ya2luZyB0byBzdXBwb3J0IEhpYmVybmF0ZVRyYW5zYWN0aW9u
TWFuYWdlciwgaXQgbmVlZHMgdG8gdXNlIEhpYmVybmF0ZVV0aWxzIGluIHRoZSBzYW1lIHdheSBh
cyBEYXRhU291cmNlVHJhbnNhY3Rpb25NYW5hZ2VyLWNhcGFibGUgY29kZSBuZWVkcyB0byB1c2Ug
RGF0YVNvdXJjZVV0aWxzLg0KDQpUaGUgRGF0YVNvdXJjZS1yZWxhdGVkIHN0dWZmIGFscmVhZHkg
aGFzIGRvY3MgYW5kIHRlc3RzLCBzbyBJJ20gZ29ubmEgY2hlY2sgaXQgaW4gb24gTW9uZGF5IGlm
IHRoZXJlIGFyZW4ndCBhbnkgaXNzdWVzLiBUaGUgSGliZXJuYXRlIHN1cHBvcnQgaXMgc3RpbGwg
YSBiaXQgcm91Z2gsIHNvIGl0IHdvbid0IG1ha2UgTW9uZGF5LCBJIGd1ZXNzLiBBbmQgdGhlcmUn
cyBzdGlsbCB0aGUgcGFja2FnZSBpc3N1ZSBmb3IgTy9SIG1hcHBpbmcgc3R1ZmYgbGlrZSBIaWJl
cm5hdGUgYW5kIEpETzogQ3VycmVudGx5LCBJJ3ZlIGNob3NlbiBjb20uaW50ZXJmYWNlMjEub3Jt
LmhpYmVybmF0ZSAob3RoZXIgc3VnZ2VzdGlvbnMgaW5zdGVhZCBvZiAib3JtIiB3ZXJlICJvcG0i
IGFuZCAib3AiLCAicCIgbWVhbmluZyBwZXJzaXN0ZW5jZSkuDQoNClJlZ2FyZHMsDQpKdWVyZ2Vu
DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvZCBKb2huc29uIFttYWls
dG86cm9kLmpvaG5zb25AaW50ZXJmYWNlMjEuY29tXQ0KU2VudDogVGh1cnNkYXksIE1heSAwMSwg
MjAwMyAxMTo0NyBQTQ0KVG86IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF07IEtlbiBLcmViczsg
SXNhYmVsbGUgTXVzenluc2tpDQpDYzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5z
b3VyY2Vmb3JnZS5uZXQNClN1YmplY3Q6IFJlOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0g
RGVtby90dXRvcmlhbCBjb250ZW50DQoNCg0KSXQncyBhbGwgYWJvdXQgInRoZSBzaW1wbGVzdCB0
aGluZyB0aGF0IGNvdWxkIHBvc3NpYmx5IHdvcmsiLg0KDQpMZXQncyBnaXZlIGl0IGEgZ28uDQoN
Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJqw7xyZ2VuIGjDtmxsZXIgW3dl
cmszQVRdIiA8anVlcmdlbi5ob2VsbGVyQHdlcmszYXQuY29tPg0KVG86ICJSb2QgSm9obnNvbiIg
PHJvZC5qb2huc29uQGludGVyZmFjZTIxLmNvbT47ICJLZW4gS3JlYnMiIDxra0Bra3RlYy5jb20+
Ow0KIklzYWJlbGxlIE11c3p5bnNraSIgPGlzYWJlbGxlQG1ldGEtbG9naXguY29tPg0KQ2M6IDxz
cHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldD4NClNlbnQ6IFRo
dXJzZGF5LCBNYXkgMDEsIDIwMDMgMTA6NDMgUE0NClN1YmplY3Q6IFJlOiBbU3ByaW5nZnJhbWV3
b3JrLWRldmVsb3Blcl0gRGVtby90dXRvcmlhbCBjb250ZW50DQoNCg0KPiBJIHdhcyByZWZlcnJp
bmcgdG8gbXkgcHJldmlvdXMgcHJvcG9zYWw6DQo+DQo+IDxxdW90ZT4NCj4gRm9yIHRoZSB3ZWIg
YXBwIGRlbW8sIEknbSBub3Qgc3VyZSBpZiB3ZSBuZWVkIEpUQSBhdCBhbGwsIHRob3VnaC4gU3By
aW5nJ3MNCm5ldyB0cmFuc2FjdGlvbiBzdXBwb3J0IGNvdWxkIGFsbG93IGZvciBhIGRpZmZlcmVu
dCB0cmFuc2FjdGlvbiBoYW5kbGluZw0Kc3RyYXRlZ3kgaW4gdGhlIHNpbmdsZSByZXNvdXJjZSBj
YXNlLiBUaGUgaWRlYSBpcyB0byBoYW5kbGUgYSB0cmFuc2FjdGlvbg0KdmlhIGEgVGhyZWFkTG9j
YWwgSkRCQyBjb25uZWN0aW9uIGFuZCBhIHJlc3BlY3RpdmUgcmVzb3VyY2UgbG9va3VwIHN0cmF0
ZWd5DQppbiB0aGUgZGF0YSBhY2Nlc3MgY29kZSAoZmlyc3QgY2hlY2tpbmcgdGhlIFRocmVhZExv
Y2FsIHZhcmlhYmxlLCB0aGVuIHRoZQ0KSk5ESSBEYXRhU291cmNlKS4NCj4NCj4gVGhpcyB3b3Vs
ZCBiZSBhbmFsb2dvdXMgdG8gb3VyIGV4aXN0aW5nDQpTaW5nbGVDb25uZWN0aW9uVHJhbnNhY3Rp
b25NYW5hZ2VyLCBqdXN0IGZvciBwb29sZWQgY29ubmVjdGlvbnMgYW5kDQpyZXF1aXJpbmcgc3Bl
Y2lhbCBjb25zaWRlcmF0aW9uIGF0IHJlc291cmNlIGxvb2t1cC4gSSd2ZSBiZWVuIHRoaW5raW5n
IGFib3V0DQpzdWNoIGEgc29sdXRpb24gZm9yIGEgd2hpbGUsIGFsc28gZm9yIEhpYmVybmF0ZSBT
ZXNzaW9uLWNvbnRyb2xsZWQNCnRyYW5zYWN0aW9ucyAoYW5kIEpETyBQZXJzaXN0ZW5jZU1hbmFn
ZXItY29udHJvbGxlZCBvbmVzKS4gV2Ugd291bGQgbmVlZCB0bw0KcHJvdG90eXBlIGl0IGZpcnN0
LCBvZiBjb3Vyc2UuDQo+IDwvcXVvdGU+DQo+DQo+IEl0J3MgZXhhY3RseSBhYm91dCB0aGUgc2Nl
bmFyaW8geW91IG1lbnRpb25lZDogTWFueSBhcHBzIHdpbGwgbmV2ZXIgdXNlDQptb3JlIHRoYW4g
b25lIGRhdGFiYXNlLg0KPg0KPiBBcyBJJ3ZlIG1lbnRpb25lZCBhYm92ZSwgdGhpcyBzdHJhdGVn
eSBzaG91bGQgYmUgYXBwbGljYWJsZSB0byBzdGFuZGFyZA0KSk5ESSByZXNvdXJjZSBwb29scywg
aW4gY29udHJhc3QgdG8gU2luZ2xlQ29ubmVjdGlvblRyYW5zYWN0aW9uTWFuYWdlciB0aGF0DQpq
dXN0IHdvcmtzIGZvciB0aGUgbm9uLXBvb2xlZCBTaW5nbGVDb25uZWN0aW9uRGF0YVNvdXJjZS4g
SXQgZW5mb3JjZXMgdGhlDQptZW50aW9uZWQgbG9va3VwIHN0cmF0ZWd5LCB0aG91Z2gsIGJ1dCBv
ZiBjb3Vyc2UgdGhpcyBsb29rdXAgcGF0dGVybiB3aWxsDQphbHNvIHdvcmsgd2l0aCBhbnkgb3Ro
ZXIgdHJhbnNhY3Rpb24gbWFuYWdlbWVudCBzdHJhdGVneSwgYXMgaXQganVzdCBjaGVja3MNCmZv
ciBhIFRocmVhZExvY2FsIENvbm5lY3Rpb24gZmlyc3QgYW5kIHRoZW4gZmFsbHMgYmFjayB0byBh
IHN0YW5kYXJkIEpOREkNCkRhdGFTb3VyY2UgbG9va3VwLg0KPg0KPiBJIHdpbGwgcHJvdG90eXBl
IHRoaXMgdG9tb3Jyb3csIGFuZCBJJ20gY3VyaW91cyBteXNlbGYgaWYgaXQgd2lsbCB3b3JrIG91
dA0KYXMgZXhwZWN0ZWQhDQo+DQo+IEp1ZXJnZW4NCj4NCj4NCj4NCj4NCj4gLS0tLS1VcnNwcsO8
bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246IFJvZCBKb2huc29uIFttYWlsdG86cm9kLmpv
aG5zb25AaW50ZXJmYWNlMjEuY29tXQ0KPiBHZXNlbmRldDogRG8gMDEuMDUuMjAwMyAyMzowNA0K
PiBBbjogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXTsgS2VuIEtyZWJzOyBJc2FiZWxsZSBNdXN6
eW5za2kNCj4gQ2M6IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2Uu
bmV0DQo+IEJldHJlZmY6IFJlOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gRGVtby90dXRv
cmlhbCBjb250ZW50DQo+DQo+DQo+DQo+ID4gLSBvciB1c2UgYSBkaWZmZXJlbnQgUGxhdGZvcm1U
cmFuc2FjdGlvbk1hbmFnZXIgaW1wbGVtZW50YXRpb24gZm9yIHRoZQ0KPiBub24tSlRBIHNpbmds
ZSByZXNvdXJjZSBjYXNlIChhcyBJJ3ZlIHByb3Bvc2VkIGVhcmxpZXIsIEknbSBnb25uYQ0KcHJv
dG90eXBlDQo+IHRoaXMgdG9tb3Jyb3cpLg0KPg0KPiBJIHRoaW5rIHRoaXMgaXMgYW4gaW50ZXJl
c3RpbmcgYXBwcm9hY2gsIHdoaWNoIHdlIGNhbiBzdXBwb3J0IHRocm91Z2ggb3VyDQo+IHRyYW5z
YWN0aW9uIGluZnJhc3RydWN0dXJlLiBNYW55IHNpbXBsZSBhcHBzIGFyZSBvbmx5IGV2ZXIgZ29p
bmcgdG8gdXNlDQpvbmUNCj4gZGF0YWJhc2UuDQo+DQo+IFdoYXQgYWJvdXQgcG9vbGluZz8NCj4N
Cj4gUm9kDQo+DQo+DQo+DQo+DQoNCg==

Re: [Springframework-developer] Demo/tutorial content

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

It's all about "the simplest thing that could possibly work".

Let's give it a go.

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: "Rod Johnson" <rod...@in...>; "Ken Krebs" <kk...@kk...>;
"Isabelle Muszynski" <isa...@me...>
Cc: <spr...@li...>
Sent: Thursday, May 01, 2003 10:43 PM
Subject: Re: [Springframework-developer] Demo/tutorial content


> I was referring to my previous proposal:
>
> <quote>
> For the web app demo, I'm not sure if we need JTA at all, though. Spring's
new transaction support could allow for a different transaction handling
strategy in the single resource case. The idea is to handle a transaction
via a ThreadLocal JDBC connection and a respective resource lookup strategy
in the data access code (first checking the ThreadLocal variable, then the
JNDI DataSource).
>
> This would be analogous to our existing
SingleConnectionTransactionManager, just for pooled connections and
requiring special consideration at resource lookup. I've been thinking about
such a solution for a while, also for Hibernate Session-controlled
transactions (and JDO PersistenceManager-controlled ones). We would need to
prototype it first, of course.
> </quote>
>
> It's exactly about the scenario you mentioned: Many apps will never use
more than one database.
>
> As I've mentioned above, this strategy should be applicable to standard
JNDI resource pools, in contrast to SingleConnectionTransactionManager that
just works for the non-pooled SingleConnectionDataSource. It enforces the
mentioned lookup strategy, though, but of course this lookup pattern will
also work with any other transaction management strategy, as it just checks
for a ThreadLocal Connection first and then falls back to a standard JNDI
DataSource lookup.
>
> I will prototype this tomorrow, and I'm curious myself if it will work out
as expected!
>
> Juergen
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Rod Johnson [mailto:rod...@in...]
> Gesendet: Do 01.05.2003 23:04
> An: jürgen höller [werk3AT]; Ken Krebs; Isabelle Muszynski
> Cc: spr...@li...
> Betreff: Re: [Springframework-developer] Demo/tutorial content
>
>
>
> > - or use a different PlatformTransactionManager implementation for the
> non-JTA single resource case (as I've proposed earlier, I'm gonna
prototype
> this tomorrow).
>
> I think this is an interesting approach, which we can support through our
> transaction infrastructure. Many simple apps are only ever going to use
one
> database.
>
> What about pooling?
>
> Rod
>
>
>
>
> NuYzJjz⢙qz~z jz

Re: [Springframework-developer] Demo/tutorial content

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

SSB3YXMgcmVmZXJyaW5nIHRvIG15IHByZXZpb3VzIHByb3Bvc2FsOg0KIA0KPHF1b3RlPg0KRm9y
IHRoZSB3ZWIgYXBwIGRlbW8sIEknbSBub3Qgc3VyZSBpZiB3ZSBuZWVkIEpUQSBhdCBhbGwsIHRo
b3VnaC4gU3ByaW5nJ3MgbmV3IHRyYW5zYWN0aW9uIHN1cHBvcnQgY291bGQgYWxsb3cgZm9yIGEg
ZGlmZmVyZW50IHRyYW5zYWN0aW9uIGhhbmRsaW5nIHN0cmF0ZWd5IGluIHRoZSBzaW5nbGUgcmVz
b3VyY2UgY2FzZS4gVGhlIGlkZWEgaXMgdG8gaGFuZGxlIGEgdHJhbnNhY3Rpb24gdmlhIGEgVGhy
ZWFkTG9jYWwgSkRCQyBjb25uZWN0aW9uIGFuZCBhIHJlc3BlY3RpdmUgcmVzb3VyY2UgbG9va3Vw
IHN0cmF0ZWd5IGluIHRoZSBkYXRhIGFjY2VzcyBjb2RlIChmaXJzdCBjaGVja2luZyB0aGUgVGhy
ZWFkTG9jYWwgdmFyaWFibGUsIHRoZW4gdGhlIEpOREkgRGF0YVNvdXJjZSkuDQoNClRoaXMgd291
bGQgYmUgYW5hbG9nb3VzIHRvIG91ciBleGlzdGluZyBTaW5nbGVDb25uZWN0aW9uVHJhbnNhY3Rp
b25NYW5hZ2VyLCBqdXN0IGZvciBwb29sZWQgY29ubmVjdGlvbnMgYW5kIHJlcXVpcmluZyBzcGVj
aWFsIGNvbnNpZGVyYXRpb24gYXQgcmVzb3VyY2UgbG9va3VwLiBJJ3ZlIGJlZW4gdGhpbmtpbmcg
YWJvdXQgc3VjaCBhIHNvbHV0aW9uIGZvciBhIHdoaWxlLCBhbHNvIGZvciBIaWJlcm5hdGUgU2Vz
c2lvbi1jb250cm9sbGVkIHRyYW5zYWN0aW9ucyAoYW5kIEpETyBQZXJzaXN0ZW5jZU1hbmFnZXIt
Y29udHJvbGxlZCBvbmVzKS4gV2Ugd291bGQgbmVlZCB0byBwcm90b3R5cGUgaXQgZmlyc3QsIG9m
IGNvdXJzZS4NCjwvcXVvdGU+DQogDQpJdCdzIGV4YWN0bHkgYWJvdXQgdGhlIHNjZW5hcmlvIHlv
dSBtZW50aW9uZWQ6IE1hbnkgYXBwcyB3aWxsIG5ldmVyIHVzZSBtb3JlIHRoYW4gb25lIGRhdGFi
YXNlLg0KIA0KQXMgSSd2ZSBtZW50aW9uZWQgYWJvdmUsIHRoaXMgc3RyYXRlZ3kgc2hvdWxkIGJl
IGFwcGxpY2FibGUgdG8gc3RhbmRhcmQgSk5ESSByZXNvdXJjZSBwb29scywgaW4gY29udHJhc3Qg
dG8gU2luZ2xlQ29ubmVjdGlvblRyYW5zYWN0aW9uTWFuYWdlciB0aGF0IGp1c3Qgd29ya3MgZm9y
IHRoZSBub24tcG9vbGVkIFNpbmdsZUNvbm5lY3Rpb25EYXRhU291cmNlLiBJdCBlbmZvcmNlcyB0
aGUgbWVudGlvbmVkIGxvb2t1cCBzdHJhdGVneSwgdGhvdWdoLCBidXQgb2YgY291cnNlIHRoaXMg
bG9va3VwIHBhdHRlcm4gd2lsbCBhbHNvIHdvcmsgd2l0aCBhbnkgb3RoZXIgdHJhbnNhY3Rpb24g
bWFuYWdlbWVudCBzdHJhdGVneSwgYXMgaXQganVzdCBjaGVja3MgZm9yIGEgVGhyZWFkTG9jYWwg
Q29ubmVjdGlvbiBmaXJzdCBhbmQgdGhlbiBmYWxscyBiYWNrIHRvIGEgc3RhbmRhcmQgSk5ESSBE
YXRhU291cmNlIGxvb2t1cC4NCiANCkkgd2lsbCBwcm90b3R5cGUgdGhpcyB0b21vcnJvdywgYW5k
IEknbSBjdXJpb3VzIG15c2VsZiBpZiBpdCB3aWxsIHdvcmsgb3V0IGFzIGV4cGVjdGVkIQ0KIA0K
SnVlcmdlbg0KIA0KIA0KDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0K
CVZvbjogUm9kIEpvaG5zb24gW21haWx0bzpyb2Quam9obnNvbkBpbnRlcmZhY2UyMS5jb21dIA0K
CUdlc2VuZGV0OiBEbyAwMS4wNS4yMDAzIDIzOjA0IA0KCUFuOiBqw7xyZ2VuIGjDtmxsZXIgW3dl
cmszQVRdOyBLZW4gS3JlYnM7IElzYWJlbGxlIE11c3p5bnNraSANCglDYzogc3ByaW5nZnJhbWV3
b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJQmV0cmVmZjogUmU6IFtTcHJp
bmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBEZW1vL3R1dG9yaWFsIGNvbnRlbnQNCgkNCgkNCg0KCT4g
LSBvciB1c2UgYSBkaWZmZXJlbnQgUGxhdGZvcm1UcmFuc2FjdGlvbk1hbmFnZXIgaW1wbGVtZW50
YXRpb24gZm9yIHRoZQ0KCW5vbi1KVEEgc2luZ2xlIHJlc291cmNlIGNhc2UgKGFzIEkndmUgcHJv
cG9zZWQgZWFybGllciwgSSdtIGdvbm5hIHByb3RvdHlwZQ0KCXRoaXMgdG9tb3Jyb3cpLg0KCQ0K
CUkgdGhpbmsgdGhpcyBpcyBhbiBpbnRlcmVzdGluZyBhcHByb2FjaCwgd2hpY2ggd2UgY2FuIHN1
cHBvcnQgdGhyb3VnaCBvdXINCgl0cmFuc2FjdGlvbiBpbmZyYXN0cnVjdHVyZS4gTWFueSBzaW1w
bGUgYXBwcyBhcmUgb25seSBldmVyIGdvaW5nIHRvIHVzZSBvbmUNCglkYXRhYmFzZS4NCgkNCglX
aGF0IGFib3V0IHBvb2xpbmc/DQoJDQoJUm9kDQoJDQoJDQoJDQoNCg==

Re: [Springframework-developer] Using the framework

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

SGkgSlAsDQogDQpJJ20gZGVsaWdodGVkIHRvIGhlYXIgdGhhdCB5b3UgcGxhbiB0byB1c2Ugc3Vj
aCBhIGxvdCBvZiBTcHJpbmcncyBmZWF0dXJlcyBpbiBhIHByb2plY3QuIEl0IHNlZW1zIHRoYXQg
eW91IHdpbGwgdXNlIGV2ZW4gbW9yZSBvZiB0aGVtIHRoYW4gd2UgZG8gZm9yIG91ciBuZXcgd2Vi
IGFwcCBwcm9kdWN0IGF0IHdlcmszQVQgOy0pDQogDQpSZWdhcmRpbmcgcHJvZ3JhbW1hdGljIHRy
YW5zYWN0aW9uIG1hbmFnZW1lbnQ6IFRyYW5zYWN0aW9uVGVtcGxhdGUgaXMgYSBzaW1wbGUgaGVs
cGVyIHRvIHVzZSBhIFBsYXRmb3JtVHJhbnNhY3Rpb25NYW5hZ2VyIHZpYSBhIGNhbGxiYWNrIGFw
cHJvYWNoLiBPbmUgZXhlY3V0ZSBjYWxsIGV4ZWN1dGVzIHRoZSBnaXZlbiBjYWxsYmFjayBpbXBs
ZW1lbnRhdGlvbiBpbiBvbmUgdHJhbnNhY3Rpb24sIGNvbW1pdHRpbmcgaXQgYXQgdGhlIGVuZCAo
cmVzcGVjdGl2ZWx5IHRha2luZyBwYXJ0IGluIGFuIGV4aXN0aW5nIHRyYW5zYWN0aW9uIGFjY29y
ZGluZyB0byB0aGUgZ2l2ZW4gcHJvcGFnYXRpb24gYmVoYXZpb3IpLg0KIA0KSWYgdGhlIGNhbGxi
YWNrIHRocm93cyBhIFJ1bnRpbWVFeGNlcHRpb24sIHRoZSB0cmFuc2FjdGlvbiBhbmQgdGh1cyBh
bGwgdHJhbnNhY3Rpb25hbCBvcGVyYXRpb25zIHdpdGhpbiBpdCB3aWxsIGJlIHJvbGxlZCBiYWNr
IGltcGxpY3RseSAocmVzcGVjdGl2ZWx5IHdpbGwgc2V0IHRoZSBleGlzdGluZyB0cmFuc2FjdGlv
biByb2xsYmFjay1vbmx5KS4gVGhlIGNhbGxiYWNrIGNhbiBhbHNvIGNhbGwgc2V0Um9sbGJhY2tP
bmx5IG9uIHRoZSBUcmFuc2FjdGlvblN0YXR1cyBpbnN0YW5jZSBmb3IgZXhwbGljaXQgcm9sbGJh
Y2suDQogDQpJbiBhbnkgY2FzZSwgYW4gZXhlY3V0ZSBjYWxsIHdpbGwgb25seSBhZmZlY3QgaXRz
IG93biB0cmFuc2FjdGlvbiByZXNwZWN0aXZlbHkgdGhlIHRyYW5zYWN0aW9uIGl0IHRha2VzIHBh
cnQgaW4uIEEgdHJhbnNhY3Rpb24gaXMgYWx3YXlzIGJvdW5kIHRvIHRoZSB0aHJlYWQsIG5vdCB0
byB0aGUgVHJhbnNhY3Rpb25UZW1wbGF0ZSBpbnN0YW5jZSwgdGhlcmVmb3JlIGNhbGxpbmcgZXhl
Y3V0ZSBvbiB0aGUgc2FtZSBvciBhbm90aGVyIHRlbXBsYXRlIGluc3RhbmNlIGlzbid0IHJlbGV2
YW50Lg0KIA0KVGhlIGNhbGxiYWNrIHdpbGwgdHlwaWNhbGx5IGJlIGFuIGFub255bW91cyBpbm5l
ciBjbGFzcywgcGVyZm9ybWluZyBvcGVyYXRpb25zIGl0c2VsZiBvciBkZWxlZ2F0aW5nIHRvIHZh
cmlvdXMgb3BlcmF0aW9uYWwgbWV0aG9kcy4gVGhpcyBjb2RlIGRvZXNuJ3QgbmVlZCB0byBiZSB0
cmFuc2FjdGlvbi1hd2FyZSBhdCBhbGwsIGl0IGp1c3QgbWF5IGxldmVyYWdlIFRyYW5zYWN0aW9u
U3RhdHVzIGlmIGl0IHdhbnRzIHRvLiBUaGlzIGFsbG93cyBmb3IgY2xlYXIgc2VwYXJhdGlvbiBv
ZiBjb25jZXJuczogVGhlIHRyYW5zYWN0aW9uIGRlbWFyY2F0aW9uIG1heSBvY2N1ciBhdCB0aGUg
ZmFjYWRlIGxldmVsLCBkZWxlZ2F0aW5nIHRvIGxvd2VyIGxldmVsIHNlcnZpY2VzIHdpdGhpbi4N
CiANCk5vdGUgdGhhdCB3aXRoIEp0YVRyYW5zYWN0aW9uTWFuYWdlciwgdGhlIHJlc291cmNlcyBu
ZWVkIHRvIGJlIHRyYW5zYWN0aW9uYWwgKFhBLWNhcGFibGUpIEpOREkgcmVzb3VyY2VzLCBqdXN0
IGxpa2Ugd2l0aCBhbnkgSlRBIHVzYWdlLiBPdGhlciBQbGF0Zm9ybVRyYW5zYWN0aW9uTWFuYWdl
ciBpbXBsZW1lbnRhdGlvbnMgbGlrZSBTaW5nbGVDb25uZWN0aW9uVHJhbnNhY3Rpb25NYW5hZ2Vy
IChmb3IgdGhlIG5vbi1wb29sZWQgc3RhbmRhbG9uZSBjYXNlKSBvciB0aGUgZm9ydGhjb21pbmcg
bm9uLUpUQSBjb250YWluZXIgb25lIChmb3IgYSBzaW5nbGUgcG9vbGVkIHJlc291cmNlKSBzdXBw
b3J0IHN0YW5kYXJkIG5vbi1YQSByZXNvdXJjZXMgdG9vLg0KIA0KRmluYWxseSwgSSBndWVzcyBS
b2Qgc2hvdWxkIGNvbW1lbnQgb24gZGVjbGFyYXRpdmUgdHJhbnNhY3Rpb24gbWFuYWdlbWVudCwg
YXMgaGUncyByZXNwb25zaWJsZSBmb3IgdGhlIEFPUCBpbXBsZW1lbnRhdGlvbi4NCiANClJlZ2Fy
ZHMsDQpKdWVyZ2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0t
IA0KCVZvbjogSlAgUEFXTEFLKFRpc2NhbGkpIFttYWlsdG86anAucGF3bGFrQHRpc2NhbGkuZnJd
IA0KCUdlc2VuZGV0OiBEbyAwMS4wNS4yMDAzIDE5OjAxIA0KCUFuOiBTcHJpbmcgRGV2ZWxvcGVy
cyAoRS1tYWlsKSANCglDYzogDQoJQmV0cmVmZjogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJd
IFVzaW5nIHRoZSBmcmFtZXdvcmsNCgkNCgkNCg0KCUhlbGxvLA0KCUFzIEkgdGFsa2VkIGFib3V0
IGEgZmV3IGxhc3Qgd2VlaywgSSB3aWxsIGdvIGZyb20gdXNpbmcgb3JpZ2luYWwgaTIxDQoJZnJh
bWV3b3JrIHRvIFNwcmluZyBmb3IgYXQgbGVhc3Qgb25lIG9mIHRoZSB0d28gcHJvamVjdHMuIEkg
aGF2ZSByZXJlYWQNCglzb21lIG1lc3NhZ2VzIG9mIHRoZSBsaXN0LCBwaWNrIHVwIGluZm9ybWF0
aW9uIG9uIHRoZSBqYXZhZG9jLCBzb3VyY2VzDQoJYW5kIHRlc3RzLg0KCVNvLCB5ZXQgYXJlIHRo
ZSBmZXcgbWFpbiB0b3BpY3MgY2xlYXIgKGxvY2FsaXphdGlvbiwNCglXaXphcmRGb3JtQ29udHJv
bGxlciwga2V5IGdlbmVyYXRvcnMgZm9yIFJEQk1TLCBBT1Agc2NoZW1lLCAuLi4pLg0KCQ0KCUJ1
dCBhIG1haW4gdG9waWMgcmVzdHMgdW5jbGVhciB0byBtZSBhcGFydCBjZXJ0YWluIHBhcnRzOiB0
aGUNCgl0cmFuc2FjdGlvbnMuDQoJQ291bGQgYW55b25lIChJIHRoaW5rIGVzcGVjaWFsbHkgdG8g
SsO8ZXJnZW4gb3IgUm9kKSwgZ2l2ZSBhIHJvYWRtYXAgb3IgYQ0KCXRpbnkgZXhhbXBsZSBvZiB0
aGVpciB1c2UuIElmIHBvc3NpYmxlLCBmb3IgdGhlIHR3byB3YXlzLCBwcm9ncmFtbWF0aWMNCglh
bmQgZGVjbGFyYXRpdmUuDQoJRm9yIHRoZSBwcm9ncmFtbWF0aWMgd2F5LCB0aGUgcXVlc3Rpb24g
Y291bGQgc2ltcGx5IGJlIDogaWYgYQ0KCVRyYW5zYWN0aW9uVGVtcGxhdGUuZXhlY3V0ZSgpIG1l
dGhvZCB0aHJvd3MgYW4gZXhjZXB0aW9uLCBhcmUgdGhlIFJEQk1TDQoJb3BlcmF0aW9ucyBpbiBl
YXJsaWVyIGV4ZWN1dGUoKSBjYWxscyB3aXRoIHRoZSBzYW1lIHRlbXBsYXRlIG9yIGVhcmxpZXIN
CglleGVjdXRlZCBpbiB0aGUgc2FtZSBleGVjdXRlIGNhbGwgcm9sbGJhY2tlZCA/DQoJDQoNCg==

Re: [Springframework-developer] Demo/tutorial content

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

> - or use a different PlatformTransactionManager implementation for the
non-JTA single resource case (as I've proposed earlier, I'm gonna prototype
this tomorrow).

I think this is an interesting approach, which we can support through our
transaction infrastructure. Many simple apps are only ever going to use one
database.

What about pooling?

Rod

Re: [Springframework-developer] Demo/tutorial content

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

SGkgS2VuLCBJc2FiZWxsZSwNCiANCkkgYWN0dWFsbHkgYWdyZWUgd2l0aCBLZW46IEZvciB0aGUg
InNpbXBsZSIgdmVyc2lvbiwgSSBlbnZpc2FnZSBhIHdlYiBhcHAgdXNpbmcgYXQgbGVhc3QgYW4g
QXBwbGljYXRpb25Db250ZXh0LCBTcHJpbmcgTVZDLCBTcHJpbmcgdmFsaWRhdGlvbiwgU3ByaW5n
IEpEQkMuIEl0IHNob3VsZCBiZSB3ZWxsLWFyY2hpdGVjdGVkIChub3Qgb3Zlci1zaW1wbGlmaWVk
KSBidXQgc3RpbGwgcnVuIG9uIFRvbWNhdCBhbmQgdGhlIGxpa2UuDQogDQpJTU8sIHdlbGwtYXJj
aGl0ZWN0ZWQgYXQgbGVhc3QgbWVhbnMgY2xlYXIgbGF5ZXJpbmc6DQotIGJ1c2luZXNzIGxvZ2lj
IHNlcnZpY2VzLCBtb2RlbGxlZCBhcyB3ZWItaW5kZXBlbmRlbnQgYmVhbnMgKG1hbmFnZWQgYnkg
YSBnZW5lcmFsIGFwcGxpY2F0aW9uIGNvbnRleHQpLCBkb2luZyBhbGwgdGhlIGRhdGEgYWNjZXNz
IGFuZCBwcm9jZXNzaW5nLCBwcm92aWRpbmcgYSBjb25jaXNlIEFQSSBmb3IgY2xpZW50cyBsaWtl
IGEgd2ViIHRpZXI7DQotIHdlYiBjb250cm9sbGVycyAoZGVmaW5lZCBpbiBhIENvbnRyb2xsZXJT
ZXJ2bGV0IGNvbnRleHQpLCBhY2Nlc3NpbmcgdGhlIGJ1c2luZXNzIGxvZ2ljIHNlcnZpY2VzICh2
aWEgYmVhbiByZWZzIHRvIHRoZSBnZW5lcmFsIGNvbnRleHQpLCBpbXBsZW1lbnRpbmcgdGhlIHdl
YiB3b3JrZmxvdyBhcyB0aGluIGxheWVyIG92ZXIgdGhlIGJ1c2luZXNzIGxvZ2ljIHNlcnZpY2Vz
Ow0KLSB2aWV3cyB0aGF0IGp1c3QgcmVuZGVyIGRhdGEgZnJvbSB0aGUgbW9kZWwgKG5vIHNlc3Np
b24gYWNjZXNzLCBubyBwcm9jZXNzaW5nKSBhbmQgb2ZmZXIgZm9ybXMgdG8gZ2VuZXJhdGUgcmVx
dWVzdHMuDQogDQpGb3IgbW9yZSBjb21wbGV4IGFwcGxpY2F0aW9ucywgb25lIGNvdWxkIGludHJv
ZHVjZSBhIGRlZGljYXRlZCBkYXRhIGFjY2VzcyBsYXllciBiZWxvdyB0aGUgYnVzaW5lc3MgbG9n
aWMgbGF5ZXIsIGJ1dCBJIGRvbid0IGNvbnNpZGVyIHRoYXQgZXNzZW50aWFsIGZvciBvdXIgZGVt
byBhcHAsIGF0IGxlYXN0IG5vdCBpbml0aWFsbHkuIEVzcGVjaWFsbHkgd2hlbiB1c2luZyBhbiBP
L1IgbWFwcGluZyB0b29sa2l0LCBkYXRhIGFjY2VzcyBzZXJ2aWNlcyB0eXBpY2FsbHkganVzdCBk
ZWxlZ2F0ZSB0byBpdCB3aXRob3V0IGFkZGluZyBub3Rld29ydGh5IGZ1bmN0aW9uYWxpdHkgYW55
d2F5LiBUaHVzLCB0aGV5IG9ubHkgbmVlZCB0byBiZSBzZXBhcmF0ZWQgZnJvbSB0aGUgcmVzcGVj
dGl2ZSBidXNpbmVzcyBsb2dpYyBzZXJ2aWNlcyBpZiB0aGUgZGF0YSBhY2Nlc3MgaW1wbGVtZW50
YXRpb24gc2hvdWxkIGJlIHJlcGxhY2FibGUgYnkgYSBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb24u
DQogDQpOb3RlIHRoYXQgdGhlIGJ1c2luZXNzIGxvZ2ljIGxheWVyIHNob3VsZCBub3QgYmUgd2Vi
LWRlcGVuZGVudCwgdG8gYWxsb3cgZm9yIGEgcHJvcGVyIHN0YW5kYWxvbmUgdGVzdCBzdWl0ZSwg
YW5kIHRvIGVuYWJsZSByZXVzZSBpbiBzdGFuZGFsb25lIGFwcHMsIG9yIHdpdGggRUpCIFNlc3Np
b24gQmVhbiByZW1vdGUgZmFjYWRlcywgZXRjLiBJbiB0aGUgd2ViIGFwcCBjYXNlLCB0aGUgYXBw
bGljYXRpb25Db250ZXh0LnhtbCB3aWxsIGJlIG1hbmFnZWQgYnkgYSBXZWJBcHBsaWNhdGlvbkNv
bnRleHQgaW1wbGVtZW50YXRpb24sIGJ1dCBpdCBuZWVkIG5vdCBkZXBlbmQgb24gdGhhdCBvciBl
dmVuIGJlIGF3YXJlIG9mIGl0LiBCVFcsIHdlJ3JlIHVzaW5nIHRoYXQgYXBwcm9hY2ggc3VjY2Vz
c2Z1bGx5IGZvciBhIG5ldyB3ZWIgYXBwIHByb2R1Y3QgYXQgd2VyazNBVC4NCiANCkRldmVsb3Bl
cnMgdGhhdCBqdXN0IHdhbnQgdG8gdXNlIGEgcGFydGljdWxhciBTcHJpbmcgbW9kdWxlIGNhbiBs
b29rIGF0IHRoZSByZXNwZWN0aXZlIHBhcnQgb2YgdGhlIGRlbW8gYXBwLCBvciBhdCB0aGUgdHV0
b3JpYWwgdHJhaWwgZm9yIHRoZSBtb2R1bGUuIE9mIGNvdXJzZSwgd2UgY291bGQgYWxzbyBvZmZl
ciBhIGRlbW8gYXBwIGZvciBTdHJ1dHMgaW50ZWdyYXRpb24sIG9yIGJldHRlciB0aGUgc2FtZSBi
YXNpYyBkZW1vIGFwcCB1c2luZyBTdHJ1dHMgTVZDLiBUaGUgbmljZSB0aGluZyBpcyB0aGF0IGl0
IGNvdWxkIHJldXNlIGV4YWN0bHkgdGhlIHNhbWUgYnVzaW5lc3MgbG9naWMgbGF5ZXIsIGV2ZW4g
dGhlIHNhbWUgQXBwbGljYXRpb25Db250ZXh0IGRlZmluaXRpb24uIEl0IGp1c3QgbmVlZHMgdG8g
cHJvdmlkZSBkaWZmZXJlbnQgY29udHJvbGxlciBpbXBsZW1lbnRhdGlvbnMgKHRoYXQgbWFudWFs
bHkgbG9vayB1cCB0aGUgYnVzaW5lc3MgbG9naWMgc2VydmljZXMgZnJvbSB0aGUgQXBwbGljYXRp
b25Db250ZXh0KSwgYW5kIGRpZmZlcmVudCB0YWdzIGluIHRoZSB2aWV3cy4NCiANCkpTUC9KU1RM
IGFzIHZpZXcgdGVjaG5vbG9neSBpcyBmaW5lIHdpdGggbWUsIGFsdGhvdWdoIEknZCBhbHNvIGxp
a2UgdG8gc2hvdyBob3cgc2ltcGxlIGFuZCBzdHJhaWdodGZvcndhcmQgdGhlIGludGVncmF0aW9u
IG9mIFZlbG9jaXR5IHRlbXBsYXRlcyBpcy4gQnV0IHRoYXQgbmVlZCBub3QgYmUgaW4gdGhlIGJh
c2ljIGRlbW8sIGFzIGl0IGlzIHNhZmUgdG8gYXNzdW1lIHRoYXQgbW9zdCBkZXZlbG9wZXJzIGtu
b3cgYW5kIHR5cGljYWxseSB1c2UgSlNQIChidXQgbm90IG5lY2Vzc2FyaWx5IEpTVEwsIGFsdGhv
dWdoIHRoaXMgc2hvdWxkIGNoYW5nZSkuDQogDQpBbiBvcGVuIGlzc3VlIGlzIHRyYW5zYWN0aW9u
IG1hbmFnZW1lbnQuIFdlIGNvdWxkIGFuZCBwcm9iYWJseSBzaG91bGQgYWRkcmVzcyBwcm9wZXIg
dHJhbnNhY3Rpb24gbWFuYWdlbWVudCBhbHJlYWR5IGluIHRoZSBiYXNpYyBkZW1vIGFwcCwgbGV2
ZXJhZ2luZyBTcHJpbmcncyBQbGF0Zm9ybVRyYW5zYWN0aW9uTWFuYWdlciBhYnN0cmFjdGlvbiBh
bmQgdGhlIFRyYW5zYWN0aW9uVGVtcGxhdGUgaGVscGVyLiBCdXQgSSBndWVzcyB3ZSBzaG91bGQg
YXZvaWQgZGVwZW5kaW5nIG9uIEpUQSAoYWx0aG91Z2ggYWNoaWV2YWJsZSB3aXRoIFRvbWNhdCtU
eXJleCkgZm9yIHNpbXBsaWNpdHkncyBzYWtlLCB3aGljaCBsZWF2ZXMgMiBvcHRpb25zIChzaW1w
bHkgc3dpdGNoYWJsZSBieSBjaGFuZ2luZyB0aGUgY29uZmlndXJhdGlvbiEpOg0KLSBuZXZlcnRo
ZWxlc3MgdXNlIHRoZSBKdGFUcmFuc2FjdGlvbk1hbmFnZXIgaW1wbGVtZW50YXRpb24sIGJ1dCBl
bmFibGUgImFsbG93Tm9uVHJhbnNhY3Rpb25FeGVjdXRpb24iIChpLmUuIHJ1biBub24tdHJhbnNh
Y3Rpb25hbGx5IHdoZW4gSlRBIGlzbid0IGF2YWlsYWJsZSk7DQotIG9yIHVzZSBhIGRpZmZlcmVu
dCBQbGF0Zm9ybVRyYW5zYWN0aW9uTWFuYWdlciBpbXBsZW1lbnRhdGlvbiBmb3IgdGhlIG5vbi1K
VEEgc2luZ2xlIHJlc291cmNlIGNhc2UgKGFzIEkndmUgcHJvcG9zZWQgZWFybGllciwgSSdtIGdv
bm5hIHByb3RvdHlwZSB0aGlzIHRvbW9ycm93KS4NCiANCktlbiwgcHJvY2VlZGluZyBhbmQgZGlz
Y3Vzc2luZyBhIGNvbmNyZXRlIHByb3RvdHlwZSBpcyBhIGdvb2Qgd2F5IGZvcndhcmQhIEknbSBs
b29raW5nIGZvcndhcmQgdG8gaXQhDQogDQpSZWdhcmRzLA0KSnVlcmdlbg0KIA0KIA0KDQoJLS0t
LS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IEtlbiBLcmVicyBbbWFpbHRv
OmtrQGtrdGVjLmNvbV0gDQoJR2VzZW5kZXQ6IERvIDAxLjA1LjIwMDMgMTk6NTQgDQoJQW46IElz
YWJlbGxlIE11c3p5bnNraSANCglDYzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5z
b3VyY2Vmb3JnZS5uZXQgDQoJQmV0cmVmZjogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIERl
bW8vdHV0b3JpYWwgY29udGVudA0KCQ0KCQ0KDQoJSXNhYmVsbGUgTXVzenluc2tpIHdyb3RlOg0K
CQ0KCT5IaSBLZW4sDQoJPg0KCT5JdCBzZWVtcyB0byBtZSB0aGF0IDIgbWFqb3IgZ3JvdXBzIG9m
IGRldmVsb3BlcmVzIHdpbGwgYmUgdXNpbmcgU3ByaW5nLiBPbmUgb2YgdGhlc2Ugd291bGQgdXNl
IG9ubHkgdGhlIHBlcnNpc3RlbmNlIGZyYW1ld29yaywgdG9nZXRoZXIgd2l0aCBhbiBleHRlcm5h
bCBNVkMgZnJhbWV3b3JrIHN1Y2ggYXMgU3RydXRzLiBUaGUgb3RoZXIgd291bGQgdXNlIHRoZSBT
cHJpbmcgTVZDIGZyYW1ld29yayBhcyB3ZWxsIChpLmUuIHRoZSB3aG9sZSBlbmNoaWxhZGEpLg0K
CT5TbyBmb3IgdGhlIDFzdCBzdGFnZSBJIHNlZSBzb21lIHZlcnkgc2ltcGxlIHBhZ2VzIHdoaWNo
IGFsbG93IHRoZSB1c2VyIHRvIGVudGVyIGJhc2UgZGF0YSAocmVnaXN0ZXIgYSBwZXQgd2l0aCB0
aGUgY2xpbmljLCBtYW5hZ2UgdGhlIHZldHMsIC4uLikuIFRoaXMgc3RhZ2UgdXNlcyBhIHNpbXBs
ZSBzZXJ2bGV0IGFuZCAvIG9yIEpTUC4NCgk+VGhlbiB0aGUgc2Vjb25kIHN0YWdlIGluY29ycG9y
YXRlcyB0aGUgV2ViIGZyYW1ld29yaywgYW5kIGhhcyBmb3IgZXguIHNpY2sgcGV0cyB2aXNpdGlu
ZyB0aGUgdmV0Lg0KCT4NCgk+SSBhbSBjdXJyZW50bHkgd29ya2luZyBvbiBjaGFydGluZyBTcHJp
bmcgaW4gVU1MLiBJZGVhbGx5IHRoZXJlIHNob3VsZCBiZSBhIHBhcmFsbGVsIGJldHdlZW4geW91
ciB3b3JrIGFuZCBtaW5lLiBZb3Ugc2hvdyB0aGUgY29kZSwgSSBzaG93IHRoZSBmcmFtZXdvcmsg
aW5uYXJkcy4NCgk+DQoJPklzYWJlbGxlDQoJPg0KCT4gDQoJPg0KCQ0KCQ0KCUlzYWJlbGxlLA0K
CQ0KCUFsdGhvdWdoIEkgYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVudCByZWdhcmRpbmcgdGhlIDIg
bGlrZWx5IHNldHMgb2YNCglkZXZlbG9wZXJzIHRoYXQgbWF5IHVzZSBTcHJpbmcsIEkgcmVzcGVj
dGZ1bGx5IGRpc2FncmVlIHN0cmF0ZWdpY2FsbHkNCgl3aXRoIHRoZSBhcHByb2FjaCB5b3Ugc3Vn
Z2VzdCBvZiB1c2luZyBhIHNpbXBsZSBzZXJ2bGV0IGZvciB0aGUgZmlyc3QNCglpdGVyYXRpb24g
b2YgdGhlIGRlbW8vdHV0b3JpYWwuDQoJDQoJSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgcHJpbWFy
eSBlbXBoYXNpcyBvZiB0aGUgZGVtby90dXRvcmlhbCBzaG91bGQgYmUNCgl0byBzaG93Y2FzZSB3
aGF0IHRoZSBTcHJpbmcgZnJhbWV3b3JrcyBoYXZlIHRvIG9mZmVyIHRvIHRoZSBkZXZlbG9wZXIu
IEkNCgl0aGluayB0aGF0IHRoZSB2ZXJ5IGhlYXJ0IG9mIFNwcmluZyBpcyB0aGUgd2ViIGFwcGxp
Y2F0aW9uIGZyYW1ld29yay4NCglBbHRob3VnaCBtb3N0IG9mIHRoZSBvdGhlciBmcmFtZXdvcmtz
IGFyZSB1c2VmdWwgd2l0aG91dCBpdCwgdGhleSBleGlzdA0KCXByaW1hcmlseSBhcyBjb252ZW5p
ZW5jZXMgdG8gc2ltcGx5IG1ha2UgdGhlIGRldmVsb3BlcnMgd2ViIGFwcGxpY2F0aW9uDQoJd29y
ayBlYXNpZXIuIFNwcmluZydzIGludGVncmF0aW9uIGNhcGFiaWxpdHkgd2l0aCBvdGhlciB0ZWNo
bm9sb2dpZXMsIGJlDQoJdGhleSBwcmVzZW50YXRpb24gb3IgcGVyc2lzdGVuY2Ugb3JpZW50ZWQg
c2hvdWxkIGJlIHBhcnQgb2YgdGhlIHNpZGUNCglzaG93L3RyYWlscywgSU1PLg0KCQ0KCUkgYWxz
byB0aGluayB0aGF0IHRoZSBncm91cCB1c2luZyB0aGUgIndob2xlIGVuY2hpbGRhZGEiIHNob3Vs
ZCBiZSB0aGUNCglwcmltYXJ5IHRhcmdldCBhdWRpZW5jZSBhdCBsZWFzdCBmb3IgdGhlIGZpcnN0
IGl0ZXJhdGlvbiBvZiB0aGUNCglkZW1vL3R1dG9yaWFsLg0KCQ0KCVNpZGUgdHJhaWxzIHRoYXQg
c2hvdyBob3cgdG8gdXNlIHRoZSBTcHJpbmcgZnJhbWV3b3JrcyB3aXRoIFN0cnV0cywNCglzZXJ2
bGV0cywgZmF0IGNsaWVudHMsIG9iamVjdC1yZWxhdGlvbmFsIG1hcHBlcnMsIGV0Yy4gYXJlIHNv
bWUgb2YgdGhlDQoJZnV0dXJlIHBvc3NpYmlsaXRpZXMuIEFub3RoZXIgc2lkZSB0cmFpbCB0aGF0
IGNvbXBhcmVzIHRoZSBTcHJpbmcgd2ViDQoJZnJhbWV3b3JrIHRvIFN0cnV0cyBmb3IgaW5zdGFu
Y2UgaXMgYW5vdGhlciBwb3NzaWJpbGl0eS4gVGhhdCBwYXJ0aWN1bGFyDQoJdHJhaWwsIGhvd2V2
ZXIsIHdvdWxkIG5lZWQgdG8gYmUgYSB2ZXJ5IGNhcmVmdWxseSBwbGFubmVkIHVuZGVydGFraW5n
IGlmDQoJaXQgaXMgdG8gYmUgZWZmZWN0aXZlIGluIGNvbnZpbmNpbmcgZGV2ZWxvcGVycyB0byBj
aG9vc2UgU3ByaW5nIG92ZXIgU3RydXRzLg0KCQ0KCUl0IGlzIGFsc28gaW1wb3J0YW50IHRvIGtl
ZXAgaW4gbWluZCB0aGF0IHRoZSBkZW1vL3R1dG9yaWFsIFBldGNsaW5pYw0KCW1ldGFwaG9yIGl0
c2VsZiBpcyBhbHNvIHBhcnQgb2YgdGhlIHNpZGUgc2hvdy4gVGhlIGVtcGhhc2lzLA0KCXBhcnRp
Y3VsYXJseSBpbiB0aGUgZmlyc3QgaXRlcmF0aW9uLCBuZWVkcyB0byBiZSBvbiB0aGUgbW9zdCBp
bXBvcnRhbnQNCglTcHJpbmcgZmVhdHVyZXMvY2xhc3Nlcy4gVGhlIHR1dG9yaWFsIHRleHQgc2hv
dWxkIGZpcnN0IGRpc2N1c3MgdGhlDQoJZnJhbWV3b3JrJ3MgbW9zdCBpbXBvcnRhbnQgcGllY2Vz
IGFuZCB3aGF0IGNvbW1vbiBwcm9ibGVtcyB0aGV5IGNhbiBiZQ0KCXVzZWQgdG8gYWRkcmVzcy4g
SXQgc2hvdWxkIHRoZW4gc2hvdyBob3cgdG8gdXNlIHRoZW0gYXMgdGhlICBkZW1vIGl0c2VsZg0K
CWV2b2x2ZXMuDQoJDQoJVGhlIFBldGNsaW5pYyBtZXRhcGhvciBzaG91bGQgZXZvbHZlIGFzIG5l
Y2Vzc2FyeSB0byBzdWl0IHRoZSBuZWVkcyBvZg0KCXRoZSBkZW1vL3R1dG9yaWFsLiBPYnZpb3Vz
bHksIHRoaXMgaXMgbm90IHRoZSB3YXkgcmVhbCBhcHBsaWNhdGlvbnMgYXJlDQoJZGV2ZWxvcGVk
IGJ1dCBpdCBpcyB1c2VmdWwgdG8gbWVldCB0aGUgZ29hbHMgb2YgdGhpcyBlZmZvcnQuIFRoZQ0K
CXR1dG9yaWFsIGV4cG9zaXRpb24gaXRzZWxmIGhvd2V2ZXIgc2hvdWxkIGV2b2x2ZSB0byBzaG93
IGhvdyB0byBzb2x2ZQ0KCXRoZSBQZXRjbGluaWMgYnVzaW5lc3MgcHJvYmxlbXMgaW4gdGhlIG1v
cmUgdXN1YWwgd2F5IGZyb20gdGhlDQoJZGV2ZWxvcGVycyBwb2ludCBvZiB2aWV3LiBQZXJoYXBz
IHRoZSBiZXN0IHdheSB0byBkbyB0aGlzIGlzIHRvIHVzZSBhbg0KCWFwcHJvYWNoIHNpbWlsYXIg
dG8gdGhhdCBvZiB0aGUgU3VuIEphdmEgRGV2ZWxvcGVyIENlcnRpZmljYXRpb24gRXhhbQ0KCXdo
ZXJlaW4gdGhlcmUgYWxyZWFkeSBleGlzdHMgYSBkYXRhYmFzZSBmdWxsIG9mIGRhdGEgdGhhdCBu
ZWVkcyB0byBiZQ0KCWFjY2Vzc2VkIGluIGEgbmV3IHdheS4gV2UgY2FuIHByZXRlbmQgdGhhdCBz
b21lIG9mIHRoZSBmdW5jdGlvbmFsaXR5DQoJd2lsbCBiZSBwcm92aWRlZCBieSBleGlzdGluZyBz
b2Z0d2FyZSBhdCBsZWFzdCB0ZW1wb3JhcmlseS4gUGFydHMgb2YgdGhlDQoJZGF0YWJhc2UgdGhh
dCBkb24ndCBhZGQgYW55dGhpbmcgbmV3IHRvIHRoZSB0dXRvcmlhbCBwcm9iYWJseSBzaG91bGQg
YmUNCglwcnVuZWQgYXdheSwgZm9yIGluc3RhbmNlLCB0aGUgVmV0cyB0YWJsZSBtYXkgbm90IGJl
IG5lZWRlZC4gQXQgc29tZQ0KCXBvaW50IHdlIHdpbGwgbmVlZCB0byBhZGQgc2Vzc2lvbiBhbmQg
dHJhbnNhY3Rpb24gcmVsYXRlZCBzdHVmZiBzbyBtYXliZQ0KCXdlIGFkZCB0aGUgaW52b2ljaW5n
IG9mIHNlcnZpY2VzL21lZGljYXRpb25zIG9yIHByb3ZpZGUgdGhlIGFiaWxpdHkgdG8NCglwdXJj
aGFzZSBzcGVjaWFsIHBldCBmb29kIG9ubGluZS4gSnVzdCB0aGlua2luZyBvdXQgbG91ZCBoZXJl
Lg0KCQ0KCVRoZSBmb2xsb3dpbmcgYXJlIHNvbWUgZXhhbXBsZXMgb2YgdGhlIGltcG9ydGFudCBj
bGFzc2VzL2ludGVyZmFjZXMgdGhhdA0KCUkgdGhpbmsgbmVlZCB0byBiZSBleHBsYWluZWQvZGVt
b25zdHJhdGVkIGluIHRoZSBsZXNzIGFkdmFuY2VkDQoJdmVyc2lvbihzKSBvZiB0aGUgZGVtby90
dXRvcmlhbDoNCgkNCgktIGZyb20gY29tLmludGVyZmFjZTIxLmJlYW5zLmZhY3RvcnkgOiBJbml0
aWFsaXppbmdCZWFuDQoJLSBmcm9tIGNvbS5pbnRlcmZhY2UyMS52YWxpZGF0aW9uIDogRXJyb3Jz
LCBWYWxpZGF0b3INCgkNCgktIGZyb20gY29tLmludGVyZmFjZTIxLmpkYmMub2JqZWN0IDogTWFu
dWFsRXh0cmFjdGlvblNxbFF1ZXJ5LFNxbFVwZGF0ZQ0KCS0gZnJvbSBjb20uaW50ZXJmYWNlMjEu
amRiYy5jb3JlIDogU21hcnREYXRhU291cmNlIGFuZC9vciBEYXRhU291cmNlVXRpbHMNCgkNCgkt
IGZyb20gY29tLmludGVyZmFjZTIxLndlYi5zZXJ2bGV0IDogQ29udHJvbGxlclNlcnZsZXQNCgkt
IGZyb20gY29tLmludGVyZmFjZTIxLndlYi5zZXJ2bGV0Lm12YyA6IEZvcm1Db250cm9sbGVyIGFu
ZCBsYXRlcg0KCVNlc3Npb25Gb3JtQ29udHJvbGxlciBhbmQgV2l6YXJkRm9ybUNvbnRyb2xsZXIN
CgktIGZyb20gY29tLmludGVyZmFjZTIxLndlYi5zZXJ2bGV0Lm12Yy5tdWx0aWFjdGlvbiA6DQoJ
TXVsdGlBY3Rpb25Db250cm9sbGVyLCBQcm9wZXJ0aWVzTWV0aG9kTmFtZVJlc29sdmVyDQoJLSBm
cm9tIGNvbS5pbnRlcmZhY2UyMS53ZWIuc2VydmxldC5oYW5kbGVyIDogU2ltcGxlVXJsSGFuZGxl
ck1hcHBpbmcNCgktIGZyb20gY29tLmludGVyZmFjZTIxLndlYi5zZXJ2bGV0LnZpZXcgOiBSZXNv
dXJjZUJ1bmRsZVZpZXdSZXNvbHZlciwNCglJbnRlcm5hbFJlc291cmNlVmlldyBvciBKc3RsVmll
dw0KCS0gZnJvbSBjb20uaW50ZXJmYWNlMjEud2ViLmNvbnRleHQgOiBDb250ZXh0TG9hZGVyU2Vy
dmxldA0KCS0gZnJvbSBjb20uaW50ZXJmYWNlMjEud2ViLmNvbnRleHQuc3VwcG9ydCA6IFhtbFdl
YkFwcGxpY2F0aW9uQ29udGV4dA0KCS0gZnJvbSBjb20uaW50ZXJmYWNlMjEud2ViLnRhZ3MgOiBC
aW5kVGFnDQoJDQoJSSB3b3VsZCBzdWdnZXN0IHRoYXQgdGhlIG9wZW5pbmcgc2VjdGlvbiBvZiB0
aGUgdHV0b3JpYWwgdGV4dCBzaG91bGQgYmUNCgl0aGUgc2FtZSBhcyB3aGF0IHdvdWxkIGJlIG9u
IHRoZSBmcm9udCBwYWdlIG9mIHRoZSB3ZWJzaXRlLiBJIHdvdWxkIGFsc28NCglzdWdnZXN0IHRo
YXQgdGhpcyBzaG91bGQgYmUgc29tZSBzb3J0IG9mIHN0YXRlbWVudCB0aGF0IFNwcmluZyBpcyBh
DQoJY29sbGVjdGlvbiBvZiBsb29zZWx5IGNvdXBsZWQsIGZsZXhpYmxlIGZyYW1ld29ya3Mgd2hp
Y2ggY2FuIGJlIHVzZWQgYXMNCgluZWVkZWQgd2l0aG91dCBoYXZpbmcgdG8gYnV5IGludG8gdGhl
IHdob2xlIGNvbGxlY3Rpb24uIEl0IHdvdWxkIHRoZW4NCglwcm92aWRlIGEgYnJpZWYgaW50cm9k
dWN0aW9uIHRvIGVhY2ggb2YgdGhlIFNwcmluZyBmcmFtZXdvcmtzIHdpdGggYQ0KCXN5bm9wc2lz
IG9mIHdoYXQgdGhleSBwcm92aWRlIGZvciB0aGUgcG90ZW50aWFsIGRldmVsb3Blci4gTXVjaCBv
ZiB0aGlzDQoJY291bGQgcHJvYmFibHkgYmUgZGVyaXZlZCBkaXJlY3RseSBmcm9tIGluZm9ybWF0
aW9uIHByZXNlbnRlZCBpbiB0aGUgYm9vay4NCgkNCglJIGFtIGFsc28gZ29pbmcgdG8gYXNzdW1l
IHRoZSBmb2xsb3dpbmcgZm9yIHRoZSBpbml0aWFsIHZlcnNpb246DQoJLSBUaGUgdmlldyB0ZWNo
bm9sb2d5IHdpbGwgYmUgSlNQIGFuZCBKU1RMLg0KCS0gVGhlIHBhZ2VzIHdpbGwgYmUgdmVyeSBz
aW1wbGUgZm9ybXMvdmlld3Mgd2l0aG91dCBzdHlsZSBzaGVldHMsDQoJaGVhZGVycy9mb290ZXJz
L21lbnVzLCBvciBpbnRlcm5hdGlvbmFsaXphdGlvbi4NCgktIE5vIGF1dGhlbnRpY2F0aW9uL2F1
dGhvcml6YXRpb24uDQoJLSBObyBzZXNzaW9uLg0KCQ0KCQ0KCUFzIEkgYW0gYmVnaW5uaW5nIHRv
IGZlZWwgYSBjb21wZWxsaW5nIG5lZWQgdG8gcHJvZHVjZSBzb21ldGhpbmcNCglzdWJzdGFudGl2
ZSwgSSBhbSBnb2luZyB0byBwcm9jZWVkIG9uIHRoaXMgYmFzaXMuIEl0IHdpbGwgcHJvYmFibHkN
CglpbmNsdWRlIGFsbCB0aGUgc3R1ZmYgcmVsYXRlZCB0byB0aGUgUGV0cyBhbmQgdGhlaXIgT3du
ZXJzLiBJZiB3ZSBkZWNpZGUNCgl0byB1c2UgYSBzZXJ2bGV0IGluc3RlYWQsIHdlIGNhbiBqdXN0
IGNob3Agb3V0IHRoZSB3ZWIgZnJhbWV3b3JrIHN0dWZmDQoJZm9yIHVzZSBsYXRlciBhcyBuZWVk
ZWQgYW5kIHB1dCBpbiB0aGUgc2VydmxldC4gSSB3aWxsIHB1dCBzb21ldGhpbmcNCgl0b2dldGhl
ciwgcG9zdCBpdCwgYW5kIHRoZW4gd2UgY2FuIGhhY2sgYXdheSBhdCBpdC4gV2UgY2FuIHRoZW4g
ZGlzY3Vzcw0KCWhvdyB0byBzdGFnZSBpdCB3aXRoaW4gdGhlIHR1dG9yaWFsLg0KCQ0KCQ0KCVdo
YXQgZG8geW91IHRoaW5rID8NCgkNCgkNCglJZiBhbnlib2R5IGVsc2UgaGFzIGFueXRoaW5nIHRv
IGFkZCB0byB0aGlzIGRpc2N1c3Npb24sIHBsZWFzZSBkbyBzby4NCgkNCgkNCglLZW4NCg0K

[Springframework-developer] Demo/tutorial content

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

Isabelle Muszynski wrote:

>Hi Ken,
>
>It seems to me that 2 major groups of developeres will be using Spring. One of these would use only the persistence framework, together with an external MVC framework such as Struts. The other would use the Spring MVC framework as well (i.e. the whole enchilada).
>So for the 1st stage I see some very simple pages which allow the user to enter base data (register a pet with the clinic, manage the vets, ...). This stage uses a simple servlet and / or JSP.
>Then the second stage incorporates the Web framework, and has for ex. sick pets visiting the vet.
>
>I am currently working on charting Spring in UML. Ideally there should be a parallel between your work and mine. You show the code, I show the framework innards.
>
>Isabelle
>
>  
>


Isabelle,

Although I agree with your statement regarding the 2 likely sets of 
developers that may use Spring, I respectfully disagree strategically 
with the approach you suggest of using a simple servlet for the first 
iteration of the demo/tutorial.

It seems to me that the primary emphasis of the demo/tutorial should be 
to showcase what the Spring frameworks have to offer to the developer. I 
think that the very heart of Spring is the web application framework. 
Although most of the other frameworks are useful without it, they exist 
primarily as conveniences to simply make the developers web application 
work easier. Spring's integration capability with other technologies, be 
they presentation or persistence oriented should be part of the side 
show/trails, IMO.

I also think that the group using the "whole enchildada" should be the 
primary target audience at least for the first iteration of the 
demo/tutorial.

Side trails that show how to use the Spring frameworks with Struts, 
servlets, fat clients, object-relational mappers, etc. are some of the 
future possibilities. Another side trail that compares the Spring web 
framework to Struts for instance is another possibility. That particular 
trail, however, would need to be a very carefully planned undertaking if 
it is to be effective in convincing developers to choose Spring over Struts.

It is also important to keep in mind that the demo/tutorial Petclinic 
metaphor itself is also part of the side show. The emphasis, 
particularly in the first iteration, needs to be on the most important 
Spring features/classes. The tutorial text should first discuss the 
framework's most important pieces and what common problems they can be 
used to address. It should then show how to use them as the  demo itself 
evolves.

The Petclinic metaphor should evolve as necessary to suit the needs of 
the demo/tutorial. Obviously, this is not the way real applications are 
developed but it is useful to meet the goals of this effort. The 
tutorial exposition itself however should evolve to show how to solve 
the Petclinic business problems in the more usual way from the 
developers point of view. Perhaps the best way to do this is to use an 
approach similar to that of the Sun Java Developer Certification Exam 
wherein there already exists a database full of data that needs to be 
accessed in a new way. We can pretend that some of the functionality 
will be provided by existing software at least temporarily. Parts of the 
database that don't add anything new to the tutorial probably should be 
pruned away, for instance, the Vets table may not be needed. At some 
point we will need to add session and transaction related stuff so maybe 
we add the invoicing of services/medications or provide the ability to 
purchase special pet food online. Just thinking out loud here.

The following are some examples of the important classes/interfaces that 
I think need to be explained/demonstrated in the less advanced 
version(s) of the demo/tutorial:

- from com.interface21.beans.factory : InitializingBean
- from com.interface21.validation : Errors, Validator

- from com.interface21.jdbc.object : ManualExtractionSqlQuery,SqlUpdate
- from com.interface21.jdbc.core : SmartDataSource and/or DataSourceUtils

- from com.interface21.web.servlet : ControllerServlet
- from com.interface21.web.servlet.mvc : FormController and later 
SessionFormController and WizardFormController
- from com.interface21.web.servlet.mvc.multiaction : 
MultiActionController, PropertiesMethodNameResolver
- from com.interface21.web.servlet.handler : SimpleUrlHandlerMapping
- from com.interface21.web.servlet.view : ResourceBundleViewResolver, 
InternalResourceView or JstlView
- from com.interface21.web.context : ContextLoaderServlet
- from com.interface21.web.context.support : XmlWebApplicationContext
- from com.interface21.web.tags : BindTag

I would suggest that the opening section of the tutorial text should be 
the same as what would be on the front page of the website. I would also 
suggest that this should be some sort of statement that Spring is a 
collection of loosely coupled, flexible frameworks which can be used as 
needed without having to buy into the whole collection. It would then 
provide a brief introduction to each of the Spring frameworks with a 
synopsis of what they provide for the potential developer. Much of this 
could probably be derived directly from information presented in the book.

I am also going to assume the following for the initial version:
- The view technology will be JSP and JSTL.
- The pages will be very simple forms/views without style sheets, 
headers/footers/menus, or internationalization.
- No authentication/authorization.
- No session.


As I am beginning to feel a compelling need to produce something 
substantive, I am going to proceed on this basis. It will probably 
include all the stuff related to the Pets and their Owners. If we decide 
to use a servlet instead, we can just chop out the web framework stuff 
for use later as needed and put in the servlet. I will put something 
together, post it, and then we can hack away at it. We can then discuss 
how to stage it within the tutorial.


What do you think ?


If anybody else has anything to add to this discussion, please do so.


Ken

[Springframework-developer] Using the framework

[JP PAWLAK\(Tiscali\) <jp....@ti...>]

Hello,
As I talked about a few last week, I will go from using original i21
framework to Spring for at least one of the two projects. I have reread
some messages of the list, pick up information on the javadoc, sources
and tests.
So, yet are the few main topics clear (localization,
WizardFormController, key generators for RDBMS, AOP scheme, ...).

But a main topic rests unclear to me apart certain parts: the
transactions.
Could anyone (I think especially to J=FCergen or Rod), give a roadmap or =
a
tiny example of their use. If possible, for the two ways, programmatic
and declarative.
For the programmatic way, the question could simply be : if a
TransactionTemplate.execute() method throws an exception, are the RDBMS
operations in earlier execute() calls with the same template or earlier
executed in the same execute call rollbacked ?

Re: [Springframework-developer] Demo/tutorial content

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

Hi Ken,

It seems to me that 2 major groups of developeres will be using Spring. One of these would use only the persistence framework, together with an external MVC framework such as Struts. The other would use the Spring MVC framework as well (i.e. the whole enchilada).
So for the 1st stage I see some very simple pages which allow the user to enter base data (register a pet with the clinic, manage the vets, ...). This stage uses a simple servlet and / or JSP.
Then the second stage incorporates the Web framework, and has for ex. sick pets visiting the vet.

I am currently working on charting Spring in UML. Ideally there should be a parallel between your work and mine. You show the code, I show the framework innards.

Isabelle

On Wed, Apr 30, 2003 at 06:20:27PM -0500, Ken Krebs wrote:
> To Juergen,
> 
> Thanks for your offer of input to the demo apps. I especially look forward 
> to your code reviews. Feel free to slash away unmercifully as I hope to 
> learn a lot while doing this. I will save my ego-tripping temper tantrums 
> for when I am on the golf course  :-) .
> 
> 
> 
> To all,
> 
> There certainly was a lot of activity this weekend regarding the 
> server/database platform selection. I had also hoped to get some input on 
> the content and form of the demo/tutorials but people seem to be more 
> interested in the platform selection at least for now. Hopefully we can 
> settle on the platforms soon and move on.
> 
> I anticipate that eventually we will settle on at least 2 major flavors of 
> the Petclinic demo/tutorial each consisting of several discrete stages and 
> possibly side trails. The first will probably be a simple webapp without 
> transactions or EJB's that does not require a full J2EE application server. 
> The first stage of this will probably have very limited functionality and 
> probably have approx. 5-8 display pages, a few of which are forms.
> 
> I am very interested in getting input from developers as to what features 
> and advantages of using Spring they think need to be emphasized and in what 
> flavors/stages they should be included.
> 
> I will very soon be posting some content suggestions for the first stage of 
> the first flavor of the Petclinic. Please feel free to make your own 
> comments and/or suggestions on this.
> 
> 
> Regards,
> Ken 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> 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

[Springframework-developer] Demo/tutorial content

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

To Juergen,

Thanks for your offer of input to the demo apps. I especially look forward to your code reviews. Feel free to slash away unmercifully as I hope to learn a lot while doing this. I will save my ego-tripping temper tantrums for when I am on the golf course  :-) .



To all,

There certainly was a lot of activity this weekend regarding the server/database platform selection. I had also hoped to get some input on the content and form of the demo/tutorials but people seem to be more interested in the platform selection at least for now. Hopefully we can settle on the platforms soon and move on.

I anticipate that eventually we will settle on at least 2 major flavors of the Petclinic demo/tutorial each consisting of several discrete stages and possibly side trails. The first will probably be a simple webapp without transactions or EJB's that does not require a full J2EE application server. The first stage of this will probably have very limited functionality and probably have approx. 5-8 display pages, a few of which are forms.

I am very interested in getting input from developers as to what features and advantages of using Spring they think need to be emphasized and in what flavors/stages they should be included.

I will very soon be posting some content suggestions for the first stage of the first flavor of the Petclinic. Please feel free to make your own comments and/or suggestions on this.


Regards,
Ken 

[Springframework-developer] Maven Files Uploaded...

[Luke T. <luk...@fr...>]

Hi all,

I've committed the Maven project and properties files and also some 
example xdocs to illustrate how the site structure might pan out. An 
example of the output can be viewed at

http://www.monkeymachine.ltd.uk/spring/index.html

The "project reports" section is of particular interest.

If you want to try it out there are a few steps (plus some others which 
I'll probably forget :).

The first thing is to download maven 1.0-beta-9 from maven.apache.org 
and install it. This should be straightforward. I think you'll also have 
to set up MAVEN_HOME to point to the directory you unpack it to.

One of the main features of Maven is its ability to handle dependencies 
on third-party libraries across your projects. The dependencies are 
specified in the project.xml file (have a look to see how it's done). 
Maven will automatically download these as required from an online 
repository (at http://www.ibiblio.org/maven) and maintain a local 
repository. So the idea is that you don't have to store jar files in cvs 
anymore. Unfortunately due to licensing issues with Sun, a lot of key 
jar files can't be provided by the online repository. Others may be 
missing because they aren't well known projects or just because nobody's 
asked yet. The solution is to insert these into the local repository 
yourself.

For each unsatisfied dependency, create your own directory in 
MAVEN_HOME/repository and copy the jar file(s) there. e.g. for the ejb 
classes the project.xml entry is

<dependency>
   <id>ejb</id>
   <version>2.0</version>
   <jar>ejb.jar</jar>
</dependency>

So you create directory MAVEN_HOME/repository/ejb/jar and copy ejb.jar 
into it.

Repeat this for jta, jms, javamail, aopalliance and attrib4j entries. 
The rest should be handled automatically. I've specified the jdk1.4 
version of mockobjects 'cos that's what I'm building with so that may 
cause problems if you're using 1.3.

Once that's done, there are a few things you can try. All output goes to 
the "target" directory.

maven -Dmaven.test.skip=true dist

will build a set of distribution files (binary and src, tar.gz and zip) 
in the distribution directory.

maven site

will generate the documentation and web site in "docs". This should look 
like the one at the above URL.

If you have any problems post them here. Use "maven --debug" if 
something's going drastically wrong.

Have fun,

Luke.


-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

[Springframework-developer] For those who haven't yet

[Travis C. <tra...@le...>]

Go out and vote Rod's book as best book for 2003 at JDJ.

*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~
Travis L. Chase
Microsoft Certified Solutions Developer (MCSD)
Senior Programmer Analyst
Leggett & Platt, Inc.
tra...@le...
417-358-8131 ext.3865
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*

"A dead thing can go with the stream, but only a living=20
 thing can go against it." - G. K. Chesterton

"Impartiality is a pompous name for indifference, which=20
 is an elegant name for ignorance." - G. K. Chesterton

=20

RE: [Springframework-developer] database for demos

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

JMX microkernel architecture rules!!!

+1 JBoss/HSQL

-----Original Message-----
From: William G. Thompson, Jr. [mailto:wg...@rc...]
Sent: Monday, April 28, 2003 22:57 PM
To: Thomas Risberg
Cc: spr...@li...
Subject: Re: [Springframework-developer] database for demos


Thomas Risberg wrote:
> Luke Taylor wrote:
> 
> 
>>I think someone mentioned that it was an old version 
>>of HSQL that is included but it is in fact an up to date one (1.7x).
>>
>  
> Yes, you are right.  The latest download includes HSQL 1.7.1.
> 
> 
>>As someone has already pointed out, it is easier to 
>>supply an extra service configuration file along with your application 
>>and say "drop these into the deploy directory" than it is to ask users 
>>to edit particular sections of an existing configuration file. This 
>>approach can be used for adding datasources, JMS destinations or other 
>>services which are required for your application. 
> 
> 
> This is as I see it the biggest advantage of using JBoss for our demo
> app.  The following task is all you need in your Ant deployment target
> 
>   <copy todir="${jboss.home}/server/${jboss.server}/deploy"
>     file="deploy/jboss/ticket-service.xml"/> 
> 
> (I copied this from the build script that came with the Ticket sample
> application from Rod's book.)
> 
> My vote is for JBoss/HSQL.
> 
> Thomas Risberg
> 

+1 for JBoss/HSQL

Bill








-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] database for demos

[John V. <jv...@ia...>]

We already have MySQL and JBoss running here, as do most people I 
know. I'd love to see examples written with MySQL in mind because 
that means the road from example to code I can actually use is 
shorter.

Retreating to lurkhood,

John

Re: [Springframework-developer] database for demos

[William G. T. Jr. <wg...@rc...>]

Thomas Risberg wrote:
> Luke Taylor wrote:
> 
> 
>>I think someone mentioned that it was an old version 
>>of HSQL that is included but it is in fact an up to date one (1.7x).
>>
>  
> Yes, you are right.  The latest download includes HSQL 1.7.1.
> 
> 
>>As someone has already pointed out, it is easier to 
>>supply an extra service configuration file along with your application 
>>and say "drop these into the deploy directory" than it is to ask users 
>>to edit particular sections of an existing configuration file. This 
>>approach can be used for adding datasources, JMS destinations or other 
>>services which are required for your application. 
> 
> 
> This is as I see it the biggest advantage of using JBoss for our demo
> app.  The following task is all you need in your Ant deployment target
> 
>   <copy todir="${jboss.home}/server/${jboss.server}/deploy"
>     file="deploy/jboss/ticket-service.xml"/> 
> 
> (I copied this from the build script that came with the Ticket sample
> application from Rod's book.)
> 
> My vote is for JBoss/HSQL.
> 
> Thomas Risberg
> 

+1 for JBoss/HSQL

Bill

Re: [Springframework-developer] database for demos

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

Luke Taylor wrote:

> I think someone mentioned that it was an old version 
> of HSQL that is included but it is in fact an up to date one (1.7x).
> 

Yes, you are right.  The latest download includes HSQL 1.7.1.

> As someone has already pointed out, it is easier to 
> supply an extra service configuration file along with your application 
> and say "drop these into the deploy directory" than it is to ask users 
> to edit particular sections of an existing configuration file. This 
> approach can be used for adding datasources, JMS destinations or other 
> services which are required for your application. 

This is as I see it the biggest advantage of using JBoss for our demo
app.  The following task is all you need in your Ant deployment target

  <copy todir="${jboss.home}/server/${jboss.server}/deploy"
    file="deploy/jboss/ticket-service.xml"/> 

(I copied this from the build script that came with the Ticket sample
application from Rod's book.)

My vote is for JBoss/HSQL.

Thomas Risberg

Re: [Springframework-developer] database for demos

[Luke T. <ne...@fr...>]

Rod Johnson wrote:
>>I do wish they
>>would separate the JBoss Group from JBoss the Open Source Project more
>>clearly.  Right now they share the website and it is hard to tell where
>>the line is drawn.
> 
> Absolutely. Selling consultancy around a product, whether open source or
> commercial, is absolutely fine. But when there's no division between OSS
> development and a commercial operation there's always a risk that the open
> source offering will intentionally leave gaps for the consulting to fill.
> (Not that I think there's a problem with JBoss as a product.)
> 

As there have been endless discussions elsewhere, I don't think this 
should become a forum for expressing opinions on the ethics of the JBoss 
development approach. However as someone who done some work on JBoss and 
benefitted from working with/for the JBoss Group I feel I should put 
forward a few points in their defence and a few general comments on 
using the server.

On documentation: Contrary to popular opinion there is not a conspiracy 
to deliberately provide inadequate documentation in order to force 
people to buy the pay-for version. It has always been seen as a pressing 
issue that the documentation was inadequate and I have been asked 
previously to help with updating it so I am probably as much to blame as 
anyone. There is the beginning of a rewrite languishing at

http://www.monkeymachine.ltd.uk/JBossStart/JBossStart.html

but it is little more than an intro to the server layout at present. 
Writing decent, accurate documentation is painstaking stuff and takes a 
lot of time and like most people I have other things to do and it tends 
to take a back seat. The introduction of pay-for docs was an attempt to 
solve this problem by giving an incentive to the developers to write and 
maintain documentation. There was a genuine realization that something 
as complicated as a J2EE server was going to require in-depth 
documentation and that's where Scott Stark's book comes in. It's 
meticulously detailed and the repeated editing cycles quickly stretch 
out into "a lengthy and stressful process" ((c) Rod Johnson :-); there's 
no way someone could realistically be expected to put in that much work 
for nothing. Most of us buy IT books - I don't see why the attitude to 
paying for books written by JBoss folk should be any different.
(NB. I wasn't actually aware of the Wrox JBoss book or the serverside 
arguments until I read about them here, so not having read it I can't 
comment on that one way or the other).

On violating the "Open Source Spirit": There is no way JBoss would be 
where it is today without the commitment of Marc Fleury and the other 
core developers who are working full or part-time for JBoss Group. It 
would just not be possible. They have done an extraordinary job in 
keeping it together. As with most projects there are voices raised 
everywhere complaining about one thing or another - I remember at one 
point the web site was being run from Marc's home and he was wrestling 
with the attention of script-kiddie hackers and being a newbie linux 
admin, as well as architecting the JBoss code and dealing with the all 
the corporate level issues as well. Such things are never perfect and it 
has often been very much a seat-of-the-pants thing. Bringing full time 
people on board (like Scott Stark) to manage the development and keep a 
grip on the codebase was an essential step if JBoss was to compete 
realistically with commercial servers. These guys have been hard at it 
for several years, mainly because it's what they want to do and they 
fight hard because they take a lot of flak from all sides - from the OS 
purists and from the commercial vendors who slag them off for giving 
away their work for free. They could all probably have made more money 
working for some investment bank or other - they certainly aren't taking 
the easy option. And the J2EE landscape is all the more interesting for it.

The JBoss code is open source and always will be. Whatever the 
attractions of other commercial servers may be they are still black 
boxes and I've been badly burnt in the past by bugs in servers like JRun 
and Weblogic. With any J2EE server you will invariably become familiar 
with some of the internal server classnames - with commercial servers 
that will usually be through some stacktrace and that will be your lot. 
This can be immensely frustrating. With open source you always have the 
option of tracking things into the server code and that is often 
invaluable. To argue that JBoss isn't doing open source as some people 
would like it defined and therefore go with a completely closed source 
commercial option for the full J2EE server seems like strange logic to me.

On the default Datasource: This is extremely useful when setting up a 
demo - all other servers that I am aware of require setting up an 
external database. I think someone mentioned that it was an old version 
of HSQL that is included but it is in fact an up to date one (1.7x).

On the "multiple configuration files issue": This is something which has 
  again caused a lot of complaints but once you start to see JBoss as a 
set of pluggable components, rather than a monolithic server with a 
single configuration file crammed with unrelated entries then it starts 
to make more sense. As someone has already pointed out, it is easier to 
supply an extra service configuration file along with your application 
and say "drop these into the deploy directory" than it is to ask users 
to edit particular sections of an existing configuration file. This 
approach can be used for adding datasources, JMS destinations or other 
services which are required for your application. This is one thing I 
*have* covered in the stalled "Intro to JBoss" docs mentioned above - 
please send any constructive feedback to lukeATmonkeymachine.ltd.uk :-).

On server startup speed: having hot deployment of both services and 
applications makes this less of an issue, but you can always remove the 
services you don't need from the deploy directory and increase the 
startup speed substantially.

Luke.

-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

Re: [Springframework-developer] website

[Luke T. <ne...@fr...>]

Rod Johnson wrote:
> I think Maven could make everyone's life easier by generating Javadoc,
> source cross-reference etc. But I agree with Isabelle, for 1.0 we will stick
> with Ant as our build tool and whatever we do with Maven must make things
> easier, not harder. I think we could use it to generate some parts of the
> web site even for 1.0.
> 

I see I've gow R/W now so I'll check the project file in later and try 
and knock up an explanation on using it...

Luke.

-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

Re: [Springframework-developer] Spring Framework Logo

[Luke T. <ne...@fr...>]

Isabelle Muszynski wrote:
> Well, if "J2EE made easy" is not quite right, how about "J2EE for the masses"? Just kidding. Maybe "J2EE the right way" or something in that direction?
> Or "The road to J2EE"
> Or "J2EE Nirvana"
> Or "The Zen of J2EE"
> I actually kind of like the last two...
> 

Well I suppose "Zen in the art of J2EE" would fit well with the Japanese 
logo :-)...

I remember the original cover of the book "Zen and the art of Motorcycle 
Maintenance" had a spanner sprouting into a lotus flower. You could try 
a play on that of some kind.

Luke.

-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

[Springframework-developer] demo/tutorial(s)

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

It's great to hear so much input on this subject over the last few days.

A few of my own opinions:

1. We need to make a decision fairly soon about which server/database 
platforms to use.
Doing this will allow us to better focus the energy of the group on the 
much more significant decisions that need to be made regarding the 
content of the demo/tutorial(s). Presumably Rod will either make the 
final decision or set up a framework for doing so.

2. When making these platform choices, we should strive to maximize 
potential developer buy-in to Spring.
It seems clear to me that the best way to achieve this is to make it as 
easy as possible for potential developers of all skill levels to get up 
to speed, particularly for the "entry-level" version of the 
demo/tutorial. Tomcat probably is an easy winner for the server platform 
in the "entry-level" version because virtually everybody has it already 
installed and its so easy to setup and administer. As to the "advanced" 
version server platform, I really don't have a good opinion as I don't 
know all the issues. We should however consider popularity of the 
platform as well as ease-of-use and configuration. Unless there is 
widespread hostility for a particular platform that would reduce 
potential buy-in, we should probably try to avoid the politics of what 
is truly open-source. With regard to the database platform, it seems 
that either mySQL or  HSQL  would be good, popular choices. The fact 
that HSQL is lightweight and can be run in-process without requiring 
user configuration is certainly advantageous for its use in a demo. The 
fact that it supports transactions out-of-the-box is also a plus.

3. We very much need to clearly articulate the needs that Spring is 
trying to address with each of its core elements and what the advantages 
are to developers.
This "document" should be the frontpiece of the website. It should also 
emphasize the unobtrusive nature of the framework and that its parts can 
be used to advantage with other frameworks, even in non-J2EE 
applications. The demo/tutorial(s) ahould attempt to reinforce these 
ideas and clearly demonstrate as many of them as is practicable.

Ken