springframework-developer — Spring Framework developers list

[Springframework-developer] Sybase MaxValueIncrementer

[Rim, M. <mar...@cs...>]

i'd like to submit a Sybase MaxValueIncrementer for review.

is this appropriate for this list ?



==============================================================================
This message is for the named person's use only. It may contain sensitive and
private proprietary or legally privileged information. No confidentiality or
privilege is waived or lost by any mistransmission. If you are not the
intended recipient, please immediately delete it and all copies of it from
your system, destroy any hard copies of it and notify the sender. You must
not, directly or indirectly, use, disclose, distribute, print, or copy any
part of this message if you are not the intended recipient. CREDIT SUISSE
GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE
ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the
right to monitor all e-mail communications through its networks. Any views
expressed in this message are those of the individual sender, except where the
message states otherwise and the sender is authorized to state them to be the
views of any such entity.
Unless otherwise stated, any pricing information given in this message is
indicative  only, is subject to change and does not constitute an offer to
deal at any price quoted. Any reference to the terms of executed transactions
should be treated as  preliminary only and subject to our formal written
confirmation.
==============================================================================

Re: [Springframework-developer] Mail support

[Darren D. <da...@da...>]

Juergen, Rod, Dmitry, 

I just pricked my ears up some way into this discussion: 

> I know that this is completely different than the current mail support
> model. The main difference is that there is no attempt to abstract
> JavaMail completely, rather a helper for simplified usage like
> HibernateTemplate. I don't see much value in complete abstraction anyway:
> What alternative implementations might there be?


Lotus Notes/Domino has an enormous corporate install base (many millions of 
seats), so an abstraction that allows plugability of either JavaMail or 
native Notes Mail might potentially be of great interest to some commercial 
users.  Me for one!

Notes servers can be configured to offer SMTP, but companies that use Notes 
tend only to use SMTP at gateway servers and rely on the native Notes mail 
services internally.  Often, all mail destined for external (internet) 
recipients will still have to originate on internal mail servers with no 
SMTP.

The API proposed would allow a Notes/Domino implementation using the interface 
MailSender, and SimpleMessage could probably be extended directly to offer 
the richer notes options and different handling of attachments and encryption 
to JavaMail.  I'm not proposing adding such an implementation to Spring, but 
simply point out that it would be worthwhile to have the abstraction.  Maybe 
a future example implementation and mini-project for the website or something 
would suffice.



-- 

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

Re: [Springframework-developer] wiring business objects

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

Thanks Rajeev,

I've fixed it.

Regards,
Rod

----- Original Message ----- 
From: "Rajeev Kaul" <Ra...@cu...>
To: <spr...@li...>
Sent: Monday, October 06, 2003 6:16 PM
Subject: Re: [Springframework-developer] wiring business objects


Rod,

A very minor correction to the test case code for the prototype invoker
interceptor:

public void testPrototypeAndSingletonBehaveDifferently() {
  SideEffectBean singleton = (SideEffectBean)
beanFactory.getBean("singleton");
  assertEquals(INITIAL_COUNT, singleton.getCount() );
  singleton.doWork();
  assertEquals(INITIAL_COUNT + 1, singleton.getCount() );

  SideEffectBean prototype = (SideEffectBean)
beanFactory.getBean("prototype");
  assertEquals(INITIAL_COUNT, prototype.getCount() );
  singleton.doWork();  // should be prototype.doWork();
  assertEquals(INITIAL_COUNT, prototype.getCount() );
 }

----- Original Message ----- 
From: "Rod Johnson" <rod...@in...>
To: "Rajeev Kaul" <Ra...@cu...>;
<spr...@li...>
Sent: Monday, October 06, 2003 2:46 AM
Subject: Re: [Springframework-developer] wiring business objects


> Rajeev,
>
> I've just committed the type of interceptor I've described,
> org.springframework.aop.interceptor.PrototypeInvokerInterceptor.
>
> This creates a new instance of the target, which should be a prototype,
for
> each invocation. See the test case in the /test tree for example usage.
>
> It's purely configured in XML, and transparent to calling code. (Although
it
> would be important to document the assumption of a new instance each
time!)
>
> Regards,
> Rod
>
> ----- Original Message ----- 
> From: "Rod Johnson" <rod...@in...>
> To: "Rajeev Kaul" <Ra...@cu...>;
> <spr...@li...>
> Sent: Sunday, October 05, 2003 9:32 AM
> Subject: Re: [Springframework-developer] wiring business objects
>
>
> > Interesting point. Yes, if you use the <ref> element, you'll always be
> using
> > the same object regardless of whether you've specified it as a singleton
> or
> > prototype.
> >
> > So you could make it a prototype and your shared handler can ask the
> > WebApplicationContext (which it has a reference to and can get in a
> > protected method) for an instance each time you use it:
> >
> > BusinessObject bOcj = (BusinessObject) getBean("whatever")
> >
> > This will work fine.
> >
> > However, it does require coding and it does break Inversion of Control
> > somewhat.
> >
> > I've always used this solution when I have this requirement (which
hasn't
> > been often).
> >
> > One potential solution is to add to Spring a generic AOP factory that
> > creates a new object before every request, yet pretends to be a plain
> > object. So you could set a reference to this magic factory and you would
> get
> > a new instance every time you invoked it, preserving strong typing and
> > simple code in your handler. This would be a new object per method call.
> >
> > I might prototype this if it would be helpful to you. Or you could, if
you
> > like. (Email me to discuss it further if you're interested.)
> >
> > Regards,
> > Rod
> >
> > ----- Original Message ----- 
> > From: "Rajeev Kaul" <Ra...@cu...>
> > To: <spr...@li...>
> > Sent: Thursday, October 02, 2003 9:06 PM
> > Subject: [Springframework-developer] wiring business objects
> >
> >
> > What is the best way to wire business objects to the web handlers?  I
want
> > to keep a shared instance of the handlers for my web requests.  But each
> > request must work with a new instance of a business object.  If  I set a
> > property for the "singleton" handler to a business objct, then won't it
> > always fetch the same instance (of business object) , no matter what I
> > specify for "singleton" attribute of the business object in the
> application
> > context?  I am thinking of using an intermediary like a business object
> > factory, which will ensure that I get a new instance of the business
> object
> > every time, and not specify the business object in the application
> context.
> > Is there a better way of dealing with it in Spring?
> >
> >
> >
> > Rajeev Kaul
> > Customer Care, Inc.
> > 925 277 069
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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] wiring business objects

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

Rod,

A very minor correction to the test case code for the prototype invoker =
interceptor:

public void testPrototypeAndSingletonBehaveDifferently() {
  SideEffectBean singleton =3D (SideEffectBean) =
beanFactory.getBean("singleton");
  assertEquals(INITIAL_COUNT, singleton.getCount() );
  singleton.doWork();
  assertEquals(INITIAL_COUNT + 1, singleton.getCount() );
 =20
  SideEffectBean prototype =3D (SideEffectBean) =
beanFactory.getBean("prototype");
  assertEquals(INITIAL_COUNT, prototype.getCount() );
  singleton.doWork();  // should be prototype.doWork();
  assertEquals(INITIAL_COUNT, prototype.getCount() );
 }

----- Original Message -----=20
From: "Rod Johnson" <rod...@in...>
To: "Rajeev Kaul" <Ra...@cu...>; =
<spr...@li...>
Sent: Monday, October 06, 2003 2:46 AM
Subject: Re: [Springframework-developer] wiring business objects


> Rajeev,
>=20
> I've just committed the type of interceptor I've described,
> org.springframework.aop.interceptor.PrototypeInvokerInterceptor.
>=20
> This creates a new instance of the target, which should be a =
prototype, for
> each invocation. See the test case in the /test tree for example =
usage.
>=20
> It's purely configured in XML, and transparent to calling code. =
(Although it
> would be important to document the assumption of a new instance each =
time!)
>=20
> Regards,
> Rod
>=20
> ----- Original Message -----=20
> From: "Rod Johnson" <rod...@in...>
> To: "Rajeev Kaul" <Ra...@cu...>;
> <spr...@li...>
> Sent: Sunday, October 05, 2003 9:32 AM
> Subject: Re: [Springframework-developer] wiring business objects
>=20
>=20
> > Interesting point. Yes, if you use the <ref> element, you'll always =
be
> using
> > the same object regardless of whether you've specified it as a =
singleton
> or
> > prototype.
> >
> > So you could make it a prototype and your shared handler can ask the
> > WebApplicationContext (which it has a reference to and can get in a
> > protected method) for an instance each time you use it:
> >
> > BusinessObject bOcj =3D (BusinessObject) getBean("whatever")
> >
> > This will work fine.
> >
> > However, it does require coding and it does break Inversion of =
Control
> > somewhat.
> >
> > I've always used this solution when I have this requirement (which =
hasn't
> > been often).
> >
> > One potential solution is to add to Spring a generic AOP factory =
that
> > creates a new object before every request, yet pretends to be a =
plain
> > object. So you could set a reference to this magic factory and you =
would
> get
> > a new instance every time you invoked it, preserving strong typing =
and
> > simple code in your handler. This would be a new object per method =
call.
> >
> > I might prototype this if it would be helpful to you. Or you could, =
if you
> > like. (Email me to discuss it further if you're interested.)
> >
> > Regards,
> > Rod
> >
> > ----- Original Message -----=20
> > From: "Rajeev Kaul" <Ra...@cu...>
> > To: <spr...@li...>
> > Sent: Thursday, October 02, 2003 9:06 PM
> > Subject: [Springframework-developer] wiring business objects
> >
> >
> > What is the best way to wire business objects to the web handlers?  =
I want
> > to keep a shared instance of the handlers for my web requests.  But =
each
> > request must work with a new instance of a business object.  If  I =
set a
> > property for the "singleton" handler to a business objct, then won't =
it
> > always fetch the same instance (of business object) , no matter what =
I
> > specify for "singleton" attribute of the business object in the
> application
> > context?  I am thinking of using an intermediary like a business =
object
> > factory, which will ensure that I get a new instance of the business
> object
> > every time, and not specify the business object in the application
> context.
> > Is there a better way of dealing with it in Spring?
> >
> >
> >
> > Rajeev Kaul
> > Customer Care, Inc.
> > 925 277 069
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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] avoiding direct dependecy on Hibernate

[dosapati <dos...@ge...>]

Hi,

I read the article on 'Data Access with the Spring Framework' at
hibernate.org.

Can we completely eliminate Hibernate SessionFactory and Session usage in
my classes[ProductDaoImpl in the article] using AOP interceptors. If I want
to use
Sun-JDO implementation in place of Hibernate as persistence manger. How many
changes do I need to make to the ProductDaoImpl class?


Before reading this article I wrote a wrapper class which will have save(),
update(),
delete() which in turn calls actual Hibernate Session to save, update
and delete the passed objects respectively. And also the wrapper class have
a method
load(), which will call Session.load(Class, ID) to load the object.

In my entity class I'll make calls to the above wrapper class. This way I am
avoiding the direct
dependency on Hibernate in my entity classes. The wrapper class has a method
to create
Session object and stores it in ThreadLocal. So that all the next requests
will use the stored
Session object. And the wrapper class has a method to close the Session
object.
But everytime I need to make these calls createSession() and closeSession()
of Wrapper class
to start a Session and close the session in a transaction. Can this be
decalrativley achieved using
Spring Framework.

Thanks in advance!
Dosapati

Re: [Springframework-developer] wiring business objects

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

Rod,

Thanks a lot.  It looks like a very clean solution.

regards,

Rajeev
----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "Rajeev Kaul" <Ra...@cu...>;
<spr...@li...>
Sent: Monday, October 06, 2003 2:46 AM
Subject: Re: [Springframework-developer] wiring business objects


> Rajeev,
>
> I've just committed the type of interceptor I've described,
> org.springframework.aop.interceptor.PrototypeInvokerInterceptor.
>
> This creates a new instance of the target, which should be a prototype,
for
> each invocation. See the test case in the /test tree for example usage.
>
> It's purely configured in XML, and transparent to calling code. (Although
it
> would be important to document the assumption of a new instance each
time!)
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: "Rod Johnson" <rod...@in...>
> To: "Rajeev Kaul" <Ra...@cu...>;
> <spr...@li...>
> Sent: Sunday, October 05, 2003 9:32 AM
> Subject: Re: [Springframework-developer] wiring business objects
>
>
> > Interesting point. Yes, if you use the <ref> element, you'll always be
> using
> > the same object regardless of whether you've specified it as a singleton
> or
> > prototype.
> >
> > So you could make it a prototype and your shared handler can ask the
> > WebApplicationContext (which it has a reference to and can get in a
> > protected method) for an instance each time you use it:
> >
> > BusinessObject bOcj = (BusinessObject) getBean("whatever")
> >
> > This will work fine.
> >
> > However, it does require coding and it does break Inversion of Control
> > somewhat.
> >
> > I've always used this solution when I have this requirement (which
hasn't
> > been often).
> >
> > One potential solution is to add to Spring a generic AOP factory that
> > creates a new object before every request, yet pretends to be a plain
> > object. So you could set a reference to this magic factory and you would
> get
> > a new instance every time you invoked it, preserving strong typing and
> > simple code in your handler. This would be a new object per method call.
> >
> > I might prototype this if it would be helpful to you. Or you could, if
you
> > like. (Email me to discuss it further if you're interested.)
> >
> > Regards,
> > Rod
> >
> > ----- Original Message -----
> > From: "Rajeev Kaul" <Ra...@cu...>
> > To: <spr...@li...>
> > Sent: Thursday, October 02, 2003 9:06 PM
> > Subject: [Springframework-developer] wiring business objects
> >
> >
> > What is the best way to wire business objects to the web handlers?  I
want
> > to keep a shared instance of the handlers for my web requests.  But each
> > request must work with a new instance of a business object.  If  I set a
> > property for the "singleton" handler to a business objct, then won't it
> > always fetch the same instance (of business object) , no matter what I
> > specify for "singleton" attribute of the business object in the
> application
> > context?  I am thinking of using an intermediary like a business object
> > factory, which will ensure that I get a new instance of the business
> object
> > every time, and not specify the business object in the application
> context.
> > Is there a better way of dealing with it in Spring?
> >
> >
> >
> > Rajeev Kaul
> > Customer Care, Inc.
> > 925 277 069
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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] Mail support

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

Juergen,

The proposed API looks good to me.

Regards,
Dmitriy.

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Monday, October 06, 2003 2:48 AM
To: Rod Johnson; Kopylenko, Dmitry
Cc: spr...@li...
Subject: Re: [Springframework-developer] Mail support


Rod, Dmitriy,
=20
I agree in terms of Store support - let's concentrate on mail sending =
for
now. I also tend to agree in terms of abstracting JavaMail for simple =
enough
mail sending requirements. I forgot that Session is final, BTW. =
JavaMail is
really messy - API design seems to be an art... ;-)
=20
So let me suggest a meet-in-the-middle solution: As I've initially =
intended,
let's separate transport-related (host, username, password) and
message-related properties, i.e. drop MailSettings in its current form, =
move
transport settings to the MailSender implementation, and introduce a
SimpleMessage class.
=20
As the effect of the current MailTemplate/MailCallback combo =
(overriding
certain pre-defined mail settings) can be achieved with using a
SimpleMessage copy constructor, I suggest to drop MailTemplate and
MailCallback. This leaves SimpleMessage, MailSender, and a =
JavaMailSender
implementation.
=20
To offer more power for those who need it, I suggest to offer =
additional
methods in JavaMailSender. Whoever wants to use those should cast to
JavaMailSender, respectively offer a bean property of type =
JavaMailSender to
be populated by a bean reference. All other application classes can =
work
with the MailSender interface.
=20
MailSender interface users are easily testable with a mock MailSender
implementation. It will be a bit harder with JavaMailSender users, but =
still
possible: A mock JavaMailSender subclass that overrides =
send(MimeMessage)
and send(MimeMessage[]) should allow for easy testing too. Note that a
connection to the mail server is only required for actual mail sending, =
not
for Session setup.
=20
public class SimpleMessage{
  private String from;
  private String to;
  private String[] cc;
  private String subject;
  private String text;
 =20
  public SimpleMessage(SimpleMessage original) {
    // copy constructor
  }
=20
  (getters and setters)
}
=20
public interface MailSender {
  void send(SimpleMessage message);
}
=20
public class JavaMailSender implements MailSender, InitializingBean {
  private String host;
  private String username;
  private String password;
=20
  (getters and setters)
=20
  public void afterPropertiesSet() {
    // create and keep Session instance
  }
=20
  public void send(SimpleMessage message) {
    // send SimpleMessage via JavaMail
    // creating a MimeMessage internally and delegating to =
send(MimeMessage)
}
=20
  public void send(MimeMessage message) {
    // send JavaMail MimeMessage
    // using a Transport instance: connect, sendMessage, disconnect
  }
=20
  public void send(MimeMessage[] messages) {
    // send multiple JavaMail MimeMessages in one batch
    // using a Transport instance: connect, multiple sendMessage, =
disconnect
  }
=20
  public MimeMessage createMimeMessage() {
    // create JavaMail MimeMessage for the Session of this sender
    // necessary because of MimeMessage(Session) constructor
  }
}
=20
I consider this the best of both worlds. Applications can choose to use =
the
full abstraction (MailSender) for simple purposes, or use =
JavaMailSender for
more sophisticated requirements. As testing such apps does not require
mocking JavaMail itself in any case, we should have reached all our =
goals.
=20
What do you think? If we agree on the API design, I'll be happy to =
rework
our mail support that way for 1.0 M2.
=20
Regards,
Juergen
=20
=20

	-----Urspr=FCngliche Nachricht-----=20
	Von: Rod Johnson [mailto:rod...@in...]=20
	Gesendet: So 05.10.2003 11:38=20
	An: j=FCrgen h=F6ller [werk3AT]; Kopylenko, Dmitry=20
	Cc:=20
	Betreff: Re: [Springframework-developer] Mail support
=09
=09

	> After in-depth consideration of the mail sending requirements in
werk3AT
	products and study of the JavaMail spec, I'm inclined to suggest a
	significantly different kind of mail support than the current one.
The main
	reasons are certain limitations of the current Spring mail sender,
not
	allowing for quite a lot of JavaMail functionality:
	>
	> 1. How to send blind copies (bcc)?
	> 2. How to specify a name for sender or recipient addresses (to
make mail
	clients show something like "Juergen Hoeller <jh...@we...>")?
	> 3. How to set a charset for subject and text (very important for
localized
	mails)?
	> 4. How to authenticate against the SMTP server if necessary
(username,
	password)?
	> 5. How to send multiple messages in batch, within a single mail
server
	connection?
	> 6. How to access a mail store, i.e. an inbox for reading mails?
	>
	> The first three require the option to configure a MimeMessage
directly,
	instead of just creating one internally from simplified arguments.
There's a
	lot of useful functionality in there, we should not try to abstract
that -
	just offer simple convenience methods as shortcuts.
	>
	> Nr. 4 can be overcome by two mechanisms, either passing an
Authenticator
	implementation on Session.getInstance, or using a Transport instance
	explicitly, passing host, username, and password on the connect
call.
	Furthermore, an explicit Transport instance allows to send multiple
messages
	within one connection - Nr. 5.
	>
	> Nr. 6 needs the option to work within a Store, as opposed to a
Transport
	for sending.
=09
	I'm not sure we need to worry about 6 now, so long as we can support
it
	eventually. I think most people are interested primarily in sending
mail.
=09
	> So the most appropriate mail support seems to me a MailTemplate
class
	that's focused on making JavaMail usage easier rather than general
	abstraction. I envisage the following bean properties:
	>
	> - transportProtocol (default "smtp");
	> - storeProtocol (default "pop3");
	> - transportHost (aka "mail.smtp.host");
	> - storeHost (aka "mail.pop3.host");
	> - username (default empty);
	> - password (default empty).
	>
	> The following methods allow to work within a properly managed
Transport or
	Store resource, analogous to HibernateTemplate with a Hibernate
Session:
	>
	> - executeInTransport(MailTransportCallback);
	> - executeInStore(MailStoreCallback);
	>
	> with the following callback interfaces:
	>
	>   public interface MailTransportCallback() {
	>     doInTransport(Session session, Transport transport);
	>   }
	>
	>   public interface MailStoreCallback() {
	>     doInStore(Session session, Store store);
	>   }
	>
	> Of course, like with HibernateTemplate, there's a lot of
opportunity for
	convenience methods on MailTemplate, to avoid having to implement a
	callback: just for transport though, as store-related work will
always be
	custom.
	>
	> - sendMessage(MimeMessage);
	> - sendMessages(MimeMessage[]);
	> - sendMessage(SimpleMessage message);
	> - sendMessage(String from, String to, String subject, String
text);
	> - sendMessage(String from, String to, String[] cc, String subject,
String
	text);
	> - etc.
	>
	> So sending a plain message is straightforward: Populate a
MailTemplate
	with transportHost, username, and password (e.g. in the application
	context), pass it to your application object; invoke one of the
sendMessage
	methods. But if you need it, the full power of JavaMail is at your
	fingertips in a custom callback implementation!
	>
	> Preconfiguring mail settings is still possible: the
"transportHost" in the
	MailTemplate instance, the mail addresses and contents via
SimpleMessage.
	The latter with "from", "to", "subject", "text", and a copy
constructor can
	serve the role of the current MailSettings, just without "host": a
	simplified object representation of a plain message.
	>
	>   SimpleMessage msg =3D new SimpleMessage(preconfiguredMessage);
	>   msg.setXXX(...);
	>   mailTemplate.sendMessage(msg);
	>
	> -----
=09
	I agree regarding utility methods. I like the proposed API model
(callbacks
	only for custom stuff).
=09
	> I know that this is completely different than the current mail
support
	model. The main difference is that there is no attempt to abstract
JavaMail
	completely, rather a helper for simplified usage like
HibernateTemplate. I
	don't see much value in complete abstraction anyway: What
alternative
	implementations might there be?
=09
	JavaMail is a messy API. There are alternatives such as the old Sun
mail
	packages, which I've used successfully, which are usually easier to
	configure. I don't think JavaMail is a great abstraction.
=09
	> Regarding testing, that should be easier with the above model:
Besides
	Session.getInstance, no static JavaMail methods are involved, as
Transport
	and Store and handled as instances. Thus, if we isolate the
	Session.getInstance call in a protected method, we should be able to
test
	our mail support with mock objects, i.e. mock subclasses of Session,
	Transport, and Store.
=09
	Session is final. Transport is not a real object--ie the most
important
	methods are static. JavaMail sucks from a testability perspective,
so I'm
	not sure we can avoid those limitations without greater abstraction.
=09
	> The main reason why I'm very keen on implementing the above
support is
	that the current abstraction is too simple: It loses much of
JavaMail's
	power. IMO, the better tradeoff is to work with JavaMail exclusively
and
	make its usage simpler.
=09
	I think more power is needed. I'm still not convinced that we need
to be
	JavaMail only to deliver that.
=09
	Regards,
	Rod
=09
=09
=09

Re: [Springframework-developer] wiring business objects

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

Rajeev,

I've just committed the type of interceptor I've described,
org.springframework.aop.interceptor.PrototypeInvokerInterceptor.

This creates a new instance of the target, which should be a prototype, for
each invocation. See the test case in the /test tree for example usage.

It's purely configured in XML, and transparent to calling code. (Although it
would be important to document the assumption of a new instance each time!)

Regards,
Rod

----- Original Message ----- 
From: "Rod Johnson" <rod...@in...>
To: "Rajeev Kaul" <Ra...@cu...>;
<spr...@li...>
Sent: Sunday, October 05, 2003 9:32 AM
Subject: Re: [Springframework-developer] wiring business objects


> Interesting point. Yes, if you use the <ref> element, you'll always be
using
> the same object regardless of whether you've specified it as a singleton
or
> prototype.
>
> So you could make it a prototype and your shared handler can ask the
> WebApplicationContext (which it has a reference to and can get in a
> protected method) for an instance each time you use it:
>
> BusinessObject bOcj = (BusinessObject) getBean("whatever")
>
> This will work fine.
>
> However, it does require coding and it does break Inversion of Control
> somewhat.
>
> I've always used this solution when I have this requirement (which hasn't
> been often).
>
> One potential solution is to add to Spring a generic AOP factory that
> creates a new object before every request, yet pretends to be a plain
> object. So you could set a reference to this magic factory and you would
get
> a new instance every time you invoked it, preserving strong typing and
> simple code in your handler. This would be a new object per method call.
>
> I might prototype this if it would be helpful to you. Or you could, if you
> like. (Email me to discuss it further if you're interested.)
>
> Regards,
> Rod
>
> ----- Original Message ----- 
> From: "Rajeev Kaul" <Ra...@cu...>
> To: <spr...@li...>
> Sent: Thursday, October 02, 2003 9:06 PM
> Subject: [Springframework-developer] wiring business objects
>
>
> What is the best way to wire business objects to the web handlers?  I want
> to keep a shared instance of the handlers for my web requests.  But each
> request must work with a new instance of a business object.  If  I set a
> property for the "singleton" handler to a business objct, then won't it
> always fetch the same instance (of business object) , no matter what I
> specify for "singleton" attribute of the business object in the
application
> context?  I am thinking of using an intermediary like a business object
> factory, which will ensure that I get a new instance of the business
object
> every time, and not specify the business object in the application
context.
> Is there a better way of dealing with it in Spring?
>
>
>
> Rajeev Kaul
> Customer Care, Inc.
> 925 277 069
>
>
>
>
> -------------------------------------------------------
> 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] Mail support

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

Um9kLCBEbWl0cml5LA0KIA0KSSBhZ3JlZSBpbiB0ZXJtcyBvZiBTdG9yZSBzdXBwb3J0IC0gbGV0
J3MgY29uY2VudHJhdGUgb24gbWFpbCBzZW5kaW5nIGZvciBub3cuIEkgYWxzbyB0ZW5kIHRvIGFn
cmVlIGluIHRlcm1zIG9mIGFic3RyYWN0aW5nIEphdmFNYWlsIGZvciBzaW1wbGUgZW5vdWdoIG1h
aWwgc2VuZGluZyByZXF1aXJlbWVudHMuIEkgZm9yZ290IHRoYXQgU2Vzc2lvbiBpcyBmaW5hbCwg
QlRXLiBKYXZhTWFpbCBpcyByZWFsbHkgbWVzc3kgLSBBUEkgZGVzaWduIHNlZW1zIHRvIGJlIGFu
IGFydC4uLiA7LSkNCiANClNvIGxldCBtZSBzdWdnZXN0IGEgbWVldC1pbi10aGUtbWlkZGxlIHNv
bHV0aW9uOiBBcyBJJ3ZlIGluaXRpYWxseSBpbnRlbmRlZCwgbGV0J3Mgc2VwYXJhdGUgdHJhbnNw
b3J0LXJlbGF0ZWQgKGhvc3QsIHVzZXJuYW1lLCBwYXNzd29yZCkgYW5kIG1lc3NhZ2UtcmVsYXRl
ZCBwcm9wZXJ0aWVzLCBpLmUuIGRyb3AgTWFpbFNldHRpbmdzIGluIGl0cyBjdXJyZW50IGZvcm0s
IG1vdmUgdHJhbnNwb3J0IHNldHRpbmdzIHRvIHRoZSBNYWlsU2VuZGVyIGltcGxlbWVudGF0aW9u
LCBhbmQgaW50cm9kdWNlIGEgU2ltcGxlTWVzc2FnZSBjbGFzcy4NCiANCkFzIHRoZSBlZmZlY3Qg
b2YgdGhlIGN1cnJlbnQgTWFpbFRlbXBsYXRlL01haWxDYWxsYmFjayBjb21ibyAob3ZlcnJpZGlu
ZyBjZXJ0YWluIHByZS1kZWZpbmVkIG1haWwgc2V0dGluZ3MpIGNhbiBiZSBhY2hpZXZlZCB3aXRo
IHVzaW5nIGEgU2ltcGxlTWVzc2FnZSBjb3B5IGNvbnN0cnVjdG9yLCBJIHN1Z2dlc3QgdG8gZHJv
cCBNYWlsVGVtcGxhdGUgYW5kIE1haWxDYWxsYmFjay4gVGhpcyBsZWF2ZXMgU2ltcGxlTWVzc2Fn
ZSwgTWFpbFNlbmRlciwgYW5kIGEgSmF2YU1haWxTZW5kZXIgaW1wbGVtZW50YXRpb24uDQogDQpU
byBvZmZlciBtb3JlIHBvd2VyIGZvciB0aG9zZSB3aG8gbmVlZCBpdCwgSSBzdWdnZXN0IHRvIG9m
ZmVyIGFkZGl0aW9uYWwgbWV0aG9kcyBpbiBKYXZhTWFpbFNlbmRlci4gV2hvZXZlciB3YW50cyB0
byB1c2UgdGhvc2Ugc2hvdWxkIGNhc3QgdG8gSmF2YU1haWxTZW5kZXIsIHJlc3BlY3RpdmVseSBv
ZmZlciBhIGJlYW4gcHJvcGVydHkgb2YgdHlwZSBKYXZhTWFpbFNlbmRlciB0byBiZSBwb3B1bGF0
ZWQgYnkgYSBiZWFuIHJlZmVyZW5jZS4gQWxsIG90aGVyIGFwcGxpY2F0aW9uIGNsYXNzZXMgY2Fu
IHdvcmsgd2l0aCB0aGUgTWFpbFNlbmRlciBpbnRlcmZhY2UuDQogDQpNYWlsU2VuZGVyIGludGVy
ZmFjZSB1c2VycyBhcmUgZWFzaWx5IHRlc3RhYmxlIHdpdGggYSBtb2NrIE1haWxTZW5kZXIgaW1w
bGVtZW50YXRpb24uIEl0IHdpbGwgYmUgYSBiaXQgaGFyZGVyIHdpdGggSmF2YU1haWxTZW5kZXIg
dXNlcnMsIGJ1dCBzdGlsbCBwb3NzaWJsZTogQSBtb2NrIEphdmFNYWlsU2VuZGVyIHN1YmNsYXNz
IHRoYXQgb3ZlcnJpZGVzIHNlbmQoTWltZU1lc3NhZ2UpIGFuZCBzZW5kKE1pbWVNZXNzYWdlW10p
IHNob3VsZCBhbGxvdyBmb3IgZWFzeSB0ZXN0aW5nIHRvby4gTm90ZSB0aGF0IGEgY29ubmVjdGlv
biB0byB0aGUgbWFpbCBzZXJ2ZXIgaXMgb25seSByZXF1aXJlZCBmb3IgYWN0dWFsIG1haWwgc2Vu
ZGluZywgbm90IGZvciBTZXNzaW9uIHNldHVwLg0KIA0KcHVibGljIGNsYXNzIFNpbXBsZU1lc3Nh
Z2V7DQogIHByaXZhdGUgU3RyaW5nIGZyb207DQogIHByaXZhdGUgU3RyaW5nIHRvOw0KICBwcml2
YXRlIFN0cmluZ1tdIGNjOw0KICBwcml2YXRlIFN0cmluZyBzdWJqZWN0Ow0KICBwcml2YXRlIFN0
cmluZyB0ZXh0Ow0KICANCiAgcHVibGljIFNpbXBsZU1lc3NhZ2UoU2ltcGxlTWVzc2FnZSBvcmln
aW5hbCkgew0KICAgIC8vIGNvcHkgY29uc3RydWN0b3INCiAgfQ0KIA0KICAoZ2V0dGVycyBhbmQg
c2V0dGVycykNCn0NCiANCnB1YmxpYyBpbnRlcmZhY2UgTWFpbFNlbmRlciB7DQogIHZvaWQgc2Vu
ZChTaW1wbGVNZXNzYWdlIG1lc3NhZ2UpOw0KfQ0KIA0KcHVibGljIGNsYXNzIEphdmFNYWlsU2Vu
ZGVyIGltcGxlbWVudHMgTWFpbFNlbmRlciwgSW5pdGlhbGl6aW5nQmVhbiB7DQogIHByaXZhdGUg
U3RyaW5nIGhvc3Q7DQogIHByaXZhdGUgU3RyaW5nIHVzZXJuYW1lOw0KICBwcml2YXRlIFN0cmlu
ZyBwYXNzd29yZDsNCiANCiAgKGdldHRlcnMgYW5kIHNldHRlcnMpDQogDQogIHB1YmxpYyB2b2lk
IGFmdGVyUHJvcGVydGllc1NldCgpIHsNCiAgICAvLyBjcmVhdGUgYW5kIGtlZXAgU2Vzc2lvbiBp
bnN0YW5jZQ0KICB9DQogDQogIHB1YmxpYyB2b2lkIHNlbmQoU2ltcGxlTWVzc2FnZSBtZXNzYWdl
KSB7DQogICAgLy8gc2VuZCBTaW1wbGVNZXNzYWdlIHZpYSBKYXZhTWFpbA0KICAgIC8vIGNyZWF0
aW5nIGEgTWltZU1lc3NhZ2UgaW50ZXJuYWxseSBhbmQgZGVsZWdhdGluZyB0byBzZW5kKE1pbWVN
ZXNzYWdlKQ0KIH0NCiANCiAgcHVibGljIHZvaWQgc2VuZChNaW1lTWVzc2FnZSBtZXNzYWdlKSB7
DQogICAgLy8gc2VuZCBKYXZhTWFpbCBNaW1lTWVzc2FnZQ0KICAgIC8vIHVzaW5nIGEgVHJhbnNw
b3J0IGluc3RhbmNlOiBjb25uZWN0LCBzZW5kTWVzc2FnZSwgZGlzY29ubmVjdA0KICB9DQogDQog
IHB1YmxpYyB2b2lkIHNlbmQoTWltZU1lc3NhZ2VbXSBtZXNzYWdlcykgew0KICAgIC8vIHNlbmQg
bXVsdGlwbGUgSmF2YU1haWwgTWltZU1lc3NhZ2VzIGluIG9uZSBiYXRjaA0KICAgIC8vIHVzaW5n
IGEgVHJhbnNwb3J0IGluc3RhbmNlOiBjb25uZWN0LCBtdWx0aXBsZSBzZW5kTWVzc2FnZSwgZGlz
Y29ubmVjdA0KICB9DQogDQogIHB1YmxpYyBNaW1lTWVzc2FnZSBjcmVhdGVNaW1lTWVzc2FnZSgp
IHsNCiAgICAvLyBjcmVhdGUgSmF2YU1haWwgTWltZU1lc3NhZ2UgZm9yIHRoZSBTZXNzaW9uIG9m
IHRoaXMgc2VuZGVyDQogICAgLy8gbmVjZXNzYXJ5IGJlY2F1c2Ugb2YgTWltZU1lc3NhZ2UoU2Vz
c2lvbikgY29uc3RydWN0b3INCiAgfQ0KfQ0KIA0KSSBjb25zaWRlciB0aGlzIHRoZSBiZXN0IG9m
IGJvdGggd29ybGRzLiBBcHBsaWNhdGlvbnMgY2FuIGNob29zZSB0byB1c2UgdGhlIGZ1bGwgYWJz
dHJhY3Rpb24gKE1haWxTZW5kZXIpIGZvciBzaW1wbGUgcHVycG9zZXMsIG9yIHVzZSBKYXZhTWFp
bFNlbmRlciBmb3IgbW9yZSBzb3BoaXN0aWNhdGVkIHJlcXVpcmVtZW50cy4gQXMgdGVzdGluZyBz
dWNoIGFwcHMgZG9lcyBub3QgcmVxdWlyZSBtb2NraW5nIEphdmFNYWlsIGl0c2VsZiBpbiBhbnkg
Y2FzZSwgd2Ugc2hvdWxkIGhhdmUgcmVhY2hlZCBhbGwgb3VyIGdvYWxzLg0KIA0KV2hhdCBkbyB5
b3UgdGhpbms/IElmIHdlIGFncmVlIG9uIHRoZSBBUEkgZGVzaWduLCBJJ2xsIGJlIGhhcHB5IHRv
IHJld29yayBvdXIgbWFpbCBzdXBwb3J0IHRoYXQgd2F5IGZvciAxLjAgTTIuDQogDQpSZWdhcmRz
LA0KSnVlcmdlbg0KIA0KIA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSAN
CglWb246IFJvZCBKb2huc29uIFttYWlsdG86cm9kLmpvaG5zb25AaW50ZXJmYWNlMjEuY29tXSAN
CglHZXNlbmRldDogU28gMDUuMTAuMjAwMyAxMTozOCANCglBbjogasO8cmdlbiBow7ZsbGVyIFt3
ZXJrM0FUXTsgS29weWxlbmtvLCBEbWl0cnkgDQoJQ2M6IA0KCUJldHJlZmY6IFJlOiBbU3ByaW5n
ZnJhbWV3b3JrLWRldmVsb3Blcl0gTWFpbCBzdXBwb3J0DQoJDQoJDQoNCgk+IEFmdGVyIGluLWRl
cHRoIGNvbnNpZGVyYXRpb24gb2YgdGhlIG1haWwgc2VuZGluZyByZXF1aXJlbWVudHMgaW4gd2Vy
azNBVA0KCXByb2R1Y3RzIGFuZCBzdHVkeSBvZiB0aGUgSmF2YU1haWwgc3BlYywgSSdtIGluY2xp
bmVkIHRvIHN1Z2dlc3QgYQ0KCXNpZ25pZmljYW50bHkgZGlmZmVyZW50IGtpbmQgb2YgbWFpbCBz
dXBwb3J0IHRoYW4gdGhlIGN1cnJlbnQgb25lLiBUaGUgbWFpbg0KCXJlYXNvbnMgYXJlIGNlcnRh
aW4gbGltaXRhdGlvbnMgb2YgdGhlIGN1cnJlbnQgU3ByaW5nIG1haWwgc2VuZGVyLCBub3QNCglh
bGxvd2luZyBmb3IgcXVpdGUgYSBsb3Qgb2YgSmF2YU1haWwgZnVuY3Rpb25hbGl0eToNCgk+DQoJ
PiAxLiBIb3cgdG8gc2VuZCBibGluZCBjb3BpZXMgKGJjYyk/DQoJPiAyLiBIb3cgdG8gc3BlY2lm
eSBhIG5hbWUgZm9yIHNlbmRlciBvciByZWNpcGllbnQgYWRkcmVzc2VzICh0byBtYWtlIG1haWwN
CgljbGllbnRzIHNob3cgc29tZXRoaW5nIGxpa2UgIkp1ZXJnZW4gSG9lbGxlciA8amhvQHdlcmsz
YXQuY29tPiIpPw0KCT4gMy4gSG93IHRvIHNldCBhIGNoYXJzZXQgZm9yIHN1YmplY3QgYW5kIHRl
eHQgKHZlcnkgaW1wb3J0YW50IGZvciBsb2NhbGl6ZWQNCgltYWlscyk/DQoJPiA0LiBIb3cgdG8g
YXV0aGVudGljYXRlIGFnYWluc3QgdGhlIFNNVFAgc2VydmVyIGlmIG5lY2Vzc2FyeSAodXNlcm5h
bWUsDQoJcGFzc3dvcmQpPw0KCT4gNS4gSG93IHRvIHNlbmQgbXVsdGlwbGUgbWVzc2FnZXMgaW4g
YmF0Y2gsIHdpdGhpbiBhIHNpbmdsZSBtYWlsIHNlcnZlcg0KCWNvbm5lY3Rpb24/DQoJPiA2LiBI
b3cgdG8gYWNjZXNzIGEgbWFpbCBzdG9yZSwgaS5lLiBhbiBpbmJveCBmb3IgcmVhZGluZyBtYWls
cz8NCgk+DQoJPiBUaGUgZmlyc3QgdGhyZWUgcmVxdWlyZSB0aGUgb3B0aW9uIHRvIGNvbmZpZ3Vy
ZSBhIE1pbWVNZXNzYWdlIGRpcmVjdGx5LA0KCWluc3RlYWQgb2YganVzdCBjcmVhdGluZyBvbmUg
aW50ZXJuYWxseSBmcm9tIHNpbXBsaWZpZWQgYXJndW1lbnRzLiBUaGVyZSdzIGENCglsb3Qgb2Yg
dXNlZnVsIGZ1bmN0aW9uYWxpdHkgaW4gdGhlcmUsIHdlIHNob3VsZCBub3QgdHJ5IHRvIGFic3Ry
YWN0IHRoYXQgLQ0KCWp1c3Qgb2ZmZXIgc2ltcGxlIGNvbnZlbmllbmNlIG1ldGhvZHMgYXMgc2hv
cnRjdXRzLg0KCT4NCgk+IE5yLiA0IGNhbiBiZSBvdmVyY29tZSBieSB0d28gbWVjaGFuaXNtcywg
ZWl0aGVyIHBhc3NpbmcgYW4gQXV0aGVudGljYXRvcg0KCWltcGxlbWVudGF0aW9uIG9uIFNlc3Np
b24uZ2V0SW5zdGFuY2UsIG9yIHVzaW5nIGEgVHJhbnNwb3J0IGluc3RhbmNlDQoJZXhwbGljaXRs
eSwgcGFzc2luZyBob3N0LCB1c2VybmFtZSwgYW5kIHBhc3N3b3JkIG9uIHRoZSBjb25uZWN0IGNh
bGwuDQoJRnVydGhlcm1vcmUsIGFuIGV4cGxpY2l0IFRyYW5zcG9ydCBpbnN0YW5jZSBhbGxvd3Mg
dG8gc2VuZCBtdWx0aXBsZSBtZXNzYWdlcw0KCXdpdGhpbiBvbmUgY29ubmVjdGlvbiAtIE5yLiA1
Lg0KCT4NCgk+IE5yLiA2IG5lZWRzIHRoZSBvcHRpb24gdG8gd29yayB3aXRoaW4gYSBTdG9yZSwg
YXMgb3Bwb3NlZCB0byBhIFRyYW5zcG9ydA0KCWZvciBzZW5kaW5nLg0KCQ0KCUknbSBub3Qgc3Vy
ZSB3ZSBuZWVkIHRvIHdvcnJ5IGFib3V0IDYgbm93LCBzbyBsb25nIGFzIHdlIGNhbiBzdXBwb3J0
IGl0DQoJZXZlbnR1YWxseS4gSSB0aGluayBtb3N0IHBlb3BsZSBhcmUgaW50ZXJlc3RlZCBwcmlt
YXJpbHkgaW4gc2VuZGluZyBtYWlsLg0KCQ0KCT4gU28gdGhlIG1vc3QgYXBwcm9wcmlhdGUgbWFp
bCBzdXBwb3J0IHNlZW1zIHRvIG1lIGEgTWFpbFRlbXBsYXRlIGNsYXNzDQoJdGhhdCdzIGZvY3Vz
ZWQgb24gbWFraW5nIEphdmFNYWlsIHVzYWdlIGVhc2llciByYXRoZXIgdGhhbiBnZW5lcmFsDQoJ
YWJzdHJhY3Rpb24uIEkgZW52aXNhZ2UgdGhlIGZvbGxvd2luZyBiZWFuIHByb3BlcnRpZXM6DQoJ
Pg0KCT4gLSB0cmFuc3BvcnRQcm90b2NvbCAoZGVmYXVsdCAic210cCIpOw0KCT4gLSBzdG9yZVBy
b3RvY29sIChkZWZhdWx0ICJwb3AzIik7DQoJPiAtIHRyYW5zcG9ydEhvc3QgKGFrYSAibWFpbC5z
bXRwLmhvc3QiKTsNCgk+IC0gc3RvcmVIb3N0IChha2EgIm1haWwucG9wMy5ob3N0Iik7DQoJPiAt
IHVzZXJuYW1lIChkZWZhdWx0IGVtcHR5KTsNCgk+IC0gcGFzc3dvcmQgKGRlZmF1bHQgZW1wdHkp
Lg0KCT4NCgk+IFRoZSBmb2xsb3dpbmcgbWV0aG9kcyBhbGxvdyB0byB3b3JrIHdpdGhpbiBhIHBy
b3Blcmx5IG1hbmFnZWQgVHJhbnNwb3J0IG9yDQoJU3RvcmUgcmVzb3VyY2UsIGFuYWxvZ291cyB0
byBIaWJlcm5hdGVUZW1wbGF0ZSB3aXRoIGEgSGliZXJuYXRlIFNlc3Npb246DQoJPg0KCT4gLSBl
eGVjdXRlSW5UcmFuc3BvcnQoTWFpbFRyYW5zcG9ydENhbGxiYWNrKTsNCgk+IC0gZXhlY3V0ZUlu
U3RvcmUoTWFpbFN0b3JlQ2FsbGJhY2spOw0KCT4NCgk+IHdpdGggdGhlIGZvbGxvd2luZyBjYWxs
YmFjayBpbnRlcmZhY2VzOg0KCT4NCgk+ICAgcHVibGljIGludGVyZmFjZSBNYWlsVHJhbnNwb3J0
Q2FsbGJhY2soKSB7DQoJPiAgICAgZG9JblRyYW5zcG9ydChTZXNzaW9uIHNlc3Npb24sIFRyYW5z
cG9ydCB0cmFuc3BvcnQpOw0KCT4gICB9DQoJPg0KCT4gICBwdWJsaWMgaW50ZXJmYWNlIE1haWxT
dG9yZUNhbGxiYWNrKCkgew0KCT4gICAgIGRvSW5TdG9yZShTZXNzaW9uIHNlc3Npb24sIFN0b3Jl
IHN0b3JlKTsNCgk+ICAgfQ0KCT4NCgk+IE9mIGNvdXJzZSwgbGlrZSB3aXRoIEhpYmVybmF0ZVRl
bXBsYXRlLCB0aGVyZSdzIGEgbG90IG9mIG9wcG9ydHVuaXR5IGZvcg0KCWNvbnZlbmllbmNlIG1l
dGhvZHMgb24gTWFpbFRlbXBsYXRlLCB0byBhdm9pZCBoYXZpbmcgdG8gaW1wbGVtZW50IGENCglj
YWxsYmFjazoganVzdCBmb3IgdHJhbnNwb3J0IHRob3VnaCwgYXMgc3RvcmUtcmVsYXRlZCB3b3Jr
IHdpbGwgYWx3YXlzIGJlDQoJY3VzdG9tLg0KCT4NCgk+IC0gc2VuZE1lc3NhZ2UoTWltZU1lc3Nh
Z2UpOw0KCT4gLSBzZW5kTWVzc2FnZXMoTWltZU1lc3NhZ2VbXSk7DQoJPiAtIHNlbmRNZXNzYWdl
KFNpbXBsZU1lc3NhZ2UgbWVzc2FnZSk7DQoJPiAtIHNlbmRNZXNzYWdlKFN0cmluZyBmcm9tLCBT
dHJpbmcgdG8sIFN0cmluZyBzdWJqZWN0LCBTdHJpbmcgdGV4dCk7DQoJPiAtIHNlbmRNZXNzYWdl
KFN0cmluZyBmcm9tLCBTdHJpbmcgdG8sIFN0cmluZ1tdIGNjLCBTdHJpbmcgc3ViamVjdCwgU3Ry
aW5nDQoJdGV4dCk7DQoJPiAtIGV0Yy4NCgk+DQoJPiBTbyBzZW5kaW5nIGEgcGxhaW4gbWVzc2Fn
ZSBpcyBzdHJhaWdodGZvcndhcmQ6IFBvcHVsYXRlIGEgTWFpbFRlbXBsYXRlDQoJd2l0aCB0cmFu
c3BvcnRIb3N0LCB1c2VybmFtZSwgYW5kIHBhc3N3b3JkIChlLmcuIGluIHRoZSBhcHBsaWNhdGlv
bg0KCWNvbnRleHQpLCBwYXNzIGl0IHRvIHlvdXIgYXBwbGljYXRpb24gb2JqZWN0OyBpbnZva2Ug
b25lIG9mIHRoZSBzZW5kTWVzc2FnZQ0KCW1ldGhvZHMuIEJ1dCBpZiB5b3UgbmVlZCBpdCwgdGhl
IGZ1bGwgcG93ZXIgb2YgSmF2YU1haWwgaXMgYXQgeW91cg0KCWZpbmdlcnRpcHMgaW4gYSBjdXN0
b20gY2FsbGJhY2sgaW1wbGVtZW50YXRpb24hDQoJPg0KCT4gUHJlY29uZmlndXJpbmcgbWFpbCBz
ZXR0aW5ncyBpcyBzdGlsbCBwb3NzaWJsZTogdGhlICJ0cmFuc3BvcnRIb3N0IiBpbiB0aGUNCglN
YWlsVGVtcGxhdGUgaW5zdGFuY2UsIHRoZSBtYWlsIGFkZHJlc3NlcyBhbmQgY29udGVudHMgdmlh
IFNpbXBsZU1lc3NhZ2UuDQoJVGhlIGxhdHRlciB3aXRoICJmcm9tIiwgInRvIiwgInN1YmplY3Qi
LCAidGV4dCIsIGFuZCBhIGNvcHkgY29uc3RydWN0b3IgY2FuDQoJc2VydmUgdGhlIHJvbGUgb2Yg
dGhlIGN1cnJlbnQgTWFpbFNldHRpbmdzLCBqdXN0IHdpdGhvdXQgImhvc3QiOiBhDQoJc2ltcGxp
ZmllZCBvYmplY3QgcmVwcmVzZW50YXRpb24gb2YgYSBwbGFpbiBtZXNzYWdlLg0KCT4NCgk+ICAg
U2ltcGxlTWVzc2FnZSBtc2cgPSBuZXcgU2ltcGxlTWVzc2FnZShwcmVjb25maWd1cmVkTWVzc2Fn
ZSk7DQoJPiAgIG1zZy5zZXRYWFgoLi4uKTsNCgk+ICAgbWFpbFRlbXBsYXRlLnNlbmRNZXNzYWdl
KG1zZyk7DQoJPg0KCT4gLS0tLS0NCgkNCglJIGFncmVlIHJlZ2FyZGluZyB1dGlsaXR5IG1ldGhv
ZHMuIEkgbGlrZSB0aGUgcHJvcG9zZWQgQVBJIG1vZGVsIChjYWxsYmFja3MNCglvbmx5IGZvciBj
dXN0b20gc3R1ZmYpLg0KCQ0KCT4gSSBrbm93IHRoYXQgdGhpcyBpcyBjb21wbGV0ZWx5IGRpZmZl
cmVudCB0aGFuIHRoZSBjdXJyZW50IG1haWwgc3VwcG9ydA0KCW1vZGVsLiBUaGUgbWFpbiBkaWZm
ZXJlbmNlIGlzIHRoYXQgdGhlcmUgaXMgbm8gYXR0ZW1wdCB0byBhYnN0cmFjdCBKYXZhTWFpbA0K
CWNvbXBsZXRlbHksIHJhdGhlciBhIGhlbHBlciBmb3Igc2ltcGxpZmllZCB1c2FnZSBsaWtlIEhp
YmVybmF0ZVRlbXBsYXRlLiBJDQoJZG9uJ3Qgc2VlIG11Y2ggdmFsdWUgaW4gY29tcGxldGUgYWJz
dHJhY3Rpb24gYW55d2F5OiBXaGF0IGFsdGVybmF0aXZlDQoJaW1wbGVtZW50YXRpb25zIG1pZ2h0
IHRoZXJlIGJlPw0KCQ0KCUphdmFNYWlsIGlzIGEgbWVzc3kgQVBJLiBUaGVyZSBhcmUgYWx0ZXJu
YXRpdmVzIHN1Y2ggYXMgdGhlIG9sZCBTdW4gbWFpbA0KCXBhY2thZ2VzLCB3aGljaCBJJ3ZlIHVz
ZWQgc3VjY2Vzc2Z1bGx5LCB3aGljaCBhcmUgdXN1YWxseSBlYXNpZXIgdG8NCgljb25maWd1cmUu
IEkgZG9uJ3QgdGhpbmsgSmF2YU1haWwgaXMgYSBncmVhdCBhYnN0cmFjdGlvbi4NCgkNCgk+IFJl
Z2FyZGluZyB0ZXN0aW5nLCB0aGF0IHNob3VsZCBiZSBlYXNpZXIgd2l0aCB0aGUgYWJvdmUgbW9k
ZWw6IEJlc2lkZXMNCglTZXNzaW9uLmdldEluc3RhbmNlLCBubyBzdGF0aWMgSmF2YU1haWwgbWV0
aG9kcyBhcmUgaW52b2x2ZWQsIGFzIFRyYW5zcG9ydA0KCWFuZCBTdG9yZSBhbmQgaGFuZGxlZCBh
cyBpbnN0YW5jZXMuIFRodXMsIGlmIHdlIGlzb2xhdGUgdGhlDQoJU2Vzc2lvbi5nZXRJbnN0YW5j
ZSBjYWxsIGluIGEgcHJvdGVjdGVkIG1ldGhvZCwgd2Ugc2hvdWxkIGJlIGFibGUgdG8gdGVzdA0K
CW91ciBtYWlsIHN1cHBvcnQgd2l0aCBtb2NrIG9iamVjdHMsIGkuZS4gbW9jayBzdWJjbGFzc2Vz
IG9mIFNlc3Npb24sDQoJVHJhbnNwb3J0LCBhbmQgU3RvcmUuDQoJDQoJU2Vzc2lvbiBpcyBmaW5h
bC4gVHJhbnNwb3J0IGlzIG5vdCBhIHJlYWwgb2JqZWN0LS1pZSB0aGUgbW9zdCBpbXBvcnRhbnQN
CgltZXRob2RzIGFyZSBzdGF0aWMuIEphdmFNYWlsIHN1Y2tzIGZyb20gYSB0ZXN0YWJpbGl0eSBw
ZXJzcGVjdGl2ZSwgc28gSSdtDQoJbm90IHN1cmUgd2UgY2FuIGF2b2lkIHRob3NlIGxpbWl0YXRp
b25zIHdpdGhvdXQgZ3JlYXRlciBhYnN0cmFjdGlvbi4NCgkNCgk+IFRoZSBtYWluIHJlYXNvbiB3
aHkgSSdtIHZlcnkga2VlbiBvbiBpbXBsZW1lbnRpbmcgdGhlIGFib3ZlIHN1cHBvcnQgaXMNCgl0
aGF0IHRoZSBjdXJyZW50IGFic3RyYWN0aW9uIGlzIHRvbyBzaW1wbGU6IEl0IGxvc2VzIG11Y2gg
b2YgSmF2YU1haWwncw0KCXBvd2VyLiBJTU8sIHRoZSBiZXR0ZXIgdHJhZGVvZmYgaXMgdG8gd29y
ayB3aXRoIEphdmFNYWlsIGV4Y2x1c2l2ZWx5IGFuZA0KCW1ha2UgaXRzIHVzYWdlIHNpbXBsZXIu
DQoJDQoJSSB0aGluayBtb3JlIHBvd2VyIGlzIG5lZWRlZC4gSSdtIHN0aWxsIG5vdCBjb252aW5j
ZWQgdGhhdCB3ZSBuZWVkIHRvIGJlDQoJSmF2YU1haWwgb25seSB0byBkZWxpdmVyIHRoYXQuDQoJ
DQoJUmVnYXJkcywNCglSb2QNCgkNCgkNCgkNCg0K

Re: [Springframework-developer] wiring business objects

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

Interesting point. Yes, if you use the <ref> element, you'll always be using
the same object regardless of whether you've specified it as a singleton or
prototype.

So you could make it a prototype and your shared handler can ask the
WebApplicationContext (which it has a reference to and can get in a
protected method) for an instance each time you use it:

BusinessObject bOcj = (BusinessObject) getBean("whatever")

This will work fine.

However, it does require coding and it does break Inversion of Control
somewhat.

I've always used this solution when I have this requirement (which hasn't
been often).

One potential solution is to add to Spring a generic AOP factory that
creates a new object before every request, yet pretends to be a plain
object. So you could set a reference to this magic factory and you would get
a new instance every time you invoked it, preserving strong typing and
simple code in your handler. This would be a new object per method call.

I might prototype this if it would be helpful to you. Or you could, if you
like. (Email me to discuss it further if you're interested.)

Regards,
Rod

----- Original Message ----- 
From: "Rajeev Kaul" <Ra...@cu...>
To: <spr...@li...>
Sent: Thursday, October 02, 2003 9:06 PM
Subject: [Springframework-developer] wiring business objects


What is the best way to wire business objects to the web handlers?  I want
to keep a shared instance of the handlers for my web requests.  But each
request must work with a new instance of a business object.  If  I set a
property for the "singleton" handler to a business objct, then won't it
always fetch the same instance (of business object) , no matter what I
specify for "singleton" attribute of the business object in the application
context?  I am thinking of using an intermediary like a business object
factory, which will ensure that I get a new instance of the business object
every time, and not specify the business object in the application context.
Is there a better way of dealing with it in Spring?



Rajeev Kaul
Customer Care, Inc.
925 277 069

Re: [Springframework-developer] Any sort of defined policy w/rega rds to tab/space usage and indentation?

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

Maybe you should give IDEA a try ...

> Well, it does and it doesn't. That is, there is no way on a project by 
> project basis to set the tab key to spit out tabs or spaces when you press
> Tab to indent. And there is no easy way to switch back and forth; you 
> actually have to go to two separate places in the preferences. There is 
> also no easy way to switch the defined tab/indent size, only via the 
> preferences. Actually, if Eclipse is set for spaces, there is no way to 
> even spit out a hard tab.   This all basically means you have to use one 
> worksapce for your projects that use spaces for indents, and one for 
> your projects that use tabs.
> 
> Anyways, while I personally don't like them, I respect everyone's right 
> to like them, and I understand the history here :-). I just wanted to 
> know what the policy was...
> 
> 
> Kopylenko, Dmitry wrote:
> 
> >I also use tabs and Eclipse supports them very well ;-)
> >
> >Dmitriy.
> >
> >-----Original Message-----
> >From: Rod Johnson [mailto:rod...@in...] 
> >Sent: Wednesday, October 01, 2003 3:37 AM
> >To: Colin Sampaleanu; jue...@we...
> >Cc: Spring Developers
> >Subject: Re: [Springframework-developer] Any sort of defined policy
> >w/regards to tab/space usage and indentation?
> >
> >
> >The use of tabs is historical. I'm in the minority of people who use
> tabs,
> >so the original code base had tabs and I still use them. I know most
> people
> >in open source projects hate tabs, so we might eventually need to change
> >this.
> >
> >We did consider the use of Jalopy before check in at one point.
> >
> >I'd prefer not to mess with the formatting process before 1.0 unless we
> >really need to.
> >
> >Regards,
> >Rod
> >
> >----- Original Message ----- 
> >From: "Colin Sampaleanu" <col...@ex...>
> >To: <rod...@in...>; <jue...@we...>
> >Cc: "Spring Developers" <spr...@li...>
> >Sent: Tuesday, September 30, 2003 10:14 PM
> >Subject: [Springframework-developer] Any sort of defined policy w/regards
> to
> >tab/space usage and indentation?
> >
> >
> >  
> >
> >>I notice that most of the codebase in Spring uses hard tabs as opposed 
> >>to spaces for indentation. From looking at some comment text which 
> >>does have some embedded spaces, as far as I can tell the assumption is 
> >>that tabs equate to 4 chars, although most of the code itself does not 
> >>seem to make this assumption?
> >>
> >>Is there any sort of project policy or guideline on this? i.e. 
> >>something like 'all code must use hard tabs, and align elements only 
> >>with tabs', etc.? I can hopefully work with any policy, but I'd just 
> >>like to know if one exists... (although if I am forced to use hard 
> >>tabs I would actually have to set up another Eclipse workspace, right 
> >>now my tab key puts out spaces).
> >>
> >>fwiw, I have personally found that hard tabs are somewhat of a 
> >>disaster (or at least a problem) in many team environents. In my 
> >>teams, it's generally the one rule we apply with no exceptions, "no 
> >>hard tabs". The problem is that while hard tabs have the ideal benefit 
> >>of allowing users to indent to whatever size they like, in practice 
> >>people seem to not have the discipline to stick to using tabs only, or 
> >>their editor of the moment doesn't allow them to set the tab size to 
> >>something else easilly, so spaces creep in. Once that happens to any 
> >>extent, the code looks broken to anybody else using another tab size.
> >>
> >>Regards,
> >>Colin
> >>    
> >>
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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] New addition to BindTag

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

Done.

Dmitriy.

-----Original Message-----
From: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
Sent: Thursday, October 02, 2003 3:06 PM
To: 'Kopylenko, Dmitry'; 'j=FCrgen h=F6ller [werk3AT]'; 'Spring =
Developers'
Subject: RE: [Springframework-developer] New addition to BindTag


Dmitry,

There's some documentation about the tags in docs/taglib, would you =
mind
updating them the newly including property? I can do it as well, but =
haven't
got much time right now...

Thnx,

Alef

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Kopylenko, Dmitry
Verzonden: Thursday, October 02, 2003 5:32 PM
Aan: 'j=FCrgen h=F6ller [werk3AT]'; Kopylenko, Dmitry; 'Spring =
Developers'
Onderwerp: RE: [Springframework-developer] New addition to BindTag


I've now committed the suggested change. The behavior of this tag is =
now
based on the "property" parameter:

- "property" empty =3D global errors
- "property=3DmyProperty" =3D just the errors for "myProperty"
- "property=3D*" =3D all errors, both global and for all properties

Regards,
Dmitriy

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Thursday, October 02, 2003 5:13 AM
To: Kopylenko, Dmitry; Spring Developers
Subject: Re: [Springframework-developer] New addition to BindTag


Dmitriy,
=20
That's definitely useful. I'm wondering if there's an alternative to a
"showAllErrors" boolean, though - as this parameter is just applied if
parameter "property" is empty. We could for example define =
"property=3D*" as
showing all errors, for all properties. That would mean:
=20
- "property" empty =3D global errors
- "property=3DmyProperty" =3D just the errors for "myProperty"
- "property=3D*" =3D all errors, both global and for all properties
=20
The good thing would be that there's no ambiguity, i.e. no invalid
combinations of parameters.
=20
Juergen
=20

	-----Urspr=FCngliche Nachricht-----=20
	Von: Kopylenko, Dmitry [mailto:dko...@ac...]=20
	Gesendet: Mi 01.10.2003 15:00=20
	An: 'Spring Developers'=20
	Cc:=20
	Betreff: [Springframework-developer] New addition to BindTag
=09
=09

	Hello everyone,=20

	I came across the following limitation in using BindTag to render
ObjectErrors (in our case anyway :-). The thing is that we use generic =
JSP
to render validation errors which we include in each JSP by using it =
like
this:

	                <spring:bind path=3D"${command}">=20
	                        <div class=3D"error">=20
	                                <ul style=3D"margin:0;padding:0;">

	                                        <c:forEach
items=3D"${status.errorMessages}" var=3D"msg">=20
	                                                <li><c:out
value=3D"${msg}"/></li>=20
	                                        </c:forEach>=20
	                                </ul>=20
	                        </div>=20
	                </spring:bind>=20

	By using it like this(without specifying property name) it shows
only "Global Errors, but we need to show all errors (like typeMismatch
etc.)

	So, I've added an optional boolean attribute to the tag called
showAllErrors and when it's set to "true" then the tag will expose all
errors. By default it's false:

	                <spring:bind path=3D"${command}" =
showAllErrors=3D"true">

	                        <div class=3D"error">=20
	                                <ul style=3D"margin:0;padding:0;">

	                                        <c:forEach
items=3D"${status.errorMessages}" var=3D"msg">=20
	                                                <li><c:out
value=3D"${msg}"/></li>=20
	                                        </c:forEach>=20
	                                </ul>=20
	                        </div>=20
	                </spring:bind>=20

	Here are the code changes in BindTag.java:=20

	private boolean showAllErrors =3D false;=20

	public void setShowAllErrors(String showAllErrors){=20
	        CustomBooleanEditor booleanEditor =3D new
CustomBooleanEditor(false);=20
	        booleanEditor.setAsText(showAllErrors);=20
	        this.showAllErrors =3D
((Boolean)booleanEditor.getValue()).booleanValue();=20
	}=20

	protected int doStartTagInternal() throws Exception {=20

	//...Previous code=20

	if (this.property !=3D null) {=20
	        fes =3D this.errors.getFieldErrors(this.property);=20
	        value =3D this.errors.getFieldValue(this.property);=20
	        editor =3D this.errors.getCustomEditor(this.property);=20
	        if (isHtmlEscape() && value instanceof String) {=20
	                value =3D HtmlUtils.htmlEscape((String) value);=20
	        }=20
	}=20
	//This is my change=20
	else {=20
	        if(showAllErrors)=20
	                fes =3D this.errors.getAllErrors();=20
	        else=20
	                fes =3D this.errors.getGlobalErrors();=20
	}=20

	If there are no serious objections, I could commit this.=20

	Regards,=20
	Dmitriy.=20



-------------------------------------------------------
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] wiring business objects

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

What is the best way to wire business objects to the web handlers?  I =
want to keep a shared instance of the handlers for my web requests.  But =
each request must work with a new instance of a business object.  If  I =
set a property for the "singleton" handler to a business object, then =
won't it always fetch the same instance (of business object) , no matter =
what I specify for "singleton" attribute of the business object in the =
application context?  I am thinking of using an intermediary like a =
business object factory, which will ensure that I get a new instance of =
the business object every time, and not specify the business object in =
the application context. Is there a better way of dealing with it in =
Spring?



Rajeev Kaul
Customer Care, Inc.
925 277 0696

RE: [Springframework-developer] New addition to BindTag

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

Dmitry,

There's some documentation about the tags in docs/taglib, would you mind
updating them the newly including property? I can do it as well, but
haven't got much time right now...

Thnx,

Alef

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Kopylenko, Dmitry
Verzonden: Thursday, October 02, 2003 5:32 PM
Aan: 'j=FCrgen h=F6ller [werk3AT]'; Kopylenko, Dmitry; 'Spring =
Developers'
Onderwerp: RE: [Springframework-developer] New addition to BindTag


I've now committed the suggested change. The behavior of this tag is now
based on the "property" parameter:

- "property" empty =3D global errors
- "property=3DmyProperty" =3D just the errors for "myProperty"
- "property=3D*" =3D all errors, both global and for all properties

Regards,
Dmitriy

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Thursday, October 02, 2003 5:13 AM
To: Kopylenko, Dmitry; Spring Developers
Subject: Re: [Springframework-developer] New addition to BindTag


Dmitriy,
=20
That's definitely useful. I'm wondering if there's an alternative to a
"showAllErrors" boolean, though - as this parameter is just applied if
parameter "property" is empty. We could for example define =
"property=3D*"
as showing all errors, for all properties. That would mean:
=20
- "property" empty =3D global errors
- "property=3DmyProperty" =3D just the errors for "myProperty"
- "property=3D*" =3D all errors, both global and for all properties
=20
The good thing would be that there's no ambiguity, i.e. no invalid
combinations of parameters.
=20
Juergen
=20

	-----Urspr=FCngliche Nachricht-----=20
	Von: Kopylenko, Dmitry [mailto:dko...@ac...]=20
	Gesendet: Mi 01.10.2003 15:00=20
	An: 'Spring Developers'=20
	Cc:=20
	Betreff: [Springframework-developer] New addition to BindTag
=09
=09

	Hello everyone,=20

	I came across the following limitation in using BindTag to
render ObjectErrors (in our case anyway :-). The thing is that we use
generic JSP to render validation errors which we include in each JSP by
using it like
this:

	                <spring:bind path=3D"${command}">=20
	                        <div class=3D"error">=20
	                                <ul style=3D"margin:0;padding:0;">

	                                        <c:forEach
items=3D"${status.errorMessages}" var=3D"msg">=20
	                                                <li><c:out
value=3D"${msg}"/></li>=20
	                                        </c:forEach>=20
	                                </ul>=20
	                        </div>=20
	                </spring:bind>=20

	By using it like this(without specifying property name) it shows
only "Global Errors, but we need to show all errors (like typeMismatch
etc.)

	So, I've added an optional boolean attribute to the tag called
showAllErrors and when it's set to "true" then the tag will expose all
errors. By default it's false:

	                <spring:bind path=3D"${command}"
showAllErrors=3D"true">

	                        <div class=3D"error">=20
	                                <ul style=3D"margin:0;padding:0;">

	                                        <c:forEach
items=3D"${status.errorMessages}" var=3D"msg">=20
	                                                <li><c:out
value=3D"${msg}"/></li>=20
	                                        </c:forEach>=20
	                                </ul>=20
	                        </div>=20
	                </spring:bind>=20

	Here are the code changes in BindTag.java:=20

	private boolean showAllErrors =3D false;=20

	public void setShowAllErrors(String showAllErrors){=20
	        CustomBooleanEditor booleanEditor =3D new
CustomBooleanEditor(false);=20
	        booleanEditor.setAsText(showAllErrors);=20
	        this.showAllErrors =3D
((Boolean)booleanEditor.getValue()).booleanValue();=20
	}=20

	protected int doStartTagInternal() throws Exception {=20

	//...Previous code=20

	if (this.property !=3D null) {=20
	        fes =3D this.errors.getFieldErrors(this.property);=20
	        value =3D this.errors.getFieldValue(this.property);=20
	        editor =3D this.errors.getCustomEditor(this.property);=20
	        if (isHtmlEscape() && value instanceof String) {=20
	                value =3D HtmlUtils.htmlEscape((String) value);=20
	        }=20
	}=20
	//This is my change=20
	else {=20
	        if(showAllErrors)=20
	                fes =3D this.errors.getAllErrors();=20
	        else=20
	                fes =3D this.errors.getGlobalErrors();=20
	}=20

	If there are no serious objections, I could commit this.=20

	Regards,=20
	Dmitriy.=20



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

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

This has absolutely nothing to do with current Spring functionality, but 
I though Spring developers might find mod_pubsub interesting, since the 
mechanism used is fairly uncommon so far, and there are some interesing 
possible applications.
 http://www.mod-pubsub.org/

RE: [Springframework-developer] New addition to BindTag

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

I've now committed the suggested change. The behavior of this tag is =
now
based on the "property" parameter:

- "property" empty =3D global errors
- "property=3DmyProperty" =3D just the errors for "myProperty"
- "property=3D*" =3D all errors, both global and for all properties

Regards,
Dmitriy

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Thursday, October 02, 2003 5:13 AM
To: Kopylenko, Dmitry; Spring Developers
Subject: Re: [Springframework-developer] New addition to BindTag


Dmitriy,
=20
That's definitely useful. I'm wondering if there's an alternative to a
"showAllErrors" boolean, though - as this parameter is just applied if
parameter "property" is empty. We could for example define =
"property=3D*" as
showing all errors, for all properties. That would mean:
=20
- "property" empty =3D global errors
- "property=3DmyProperty" =3D just the errors for "myProperty"
- "property=3D*" =3D all errors, both global and for all properties
=20
The good thing would be that there's no ambiguity, i.e. no invalid
combinations of parameters.
=20
Juergen
=20

	-----Urspr=FCngliche Nachricht-----=20
	Von: Kopylenko, Dmitry [mailto:dko...@ac...]=20
	Gesendet: Mi 01.10.2003 15:00=20
	An: 'Spring Developers'=20
	Cc:=20
	Betreff: [Springframework-developer] New addition to BindTag
=09
=09

	Hello everyone,=20

	I came across the following limitation in using BindTag to render
ObjectErrors (in our case anyway :-). The thing is that we use generic =
JSP
to render validation errors which we include in each JSP by using it =
like
this:

	                <spring:bind path=3D"${command}">=20
	                        <div class=3D"error">=20
	                                <ul style=3D"margin:0;padding:0;">=20
	                                        <c:forEach
items=3D"${status.errorMessages}" var=3D"msg">=20
	                                                <li><c:out
value=3D"${msg}"/></li>=20
	                                        </c:forEach>=20
	                                </ul>=20
	                        </div>=20
	                </spring:bind>=20

	By using it like this(without specifying property name) it shows
only "Global Errors, but we need to show all errors (like typeMismatch =
etc.)

	So, I've added an optional boolean attribute to the tag called
showAllErrors and when it's set to "true" then the tag will expose all
errors. By default it's false:

	                <spring:bind path=3D"${command}" =
showAllErrors=3D"true">

	                        <div class=3D"error">=20
	                                <ul style=3D"margin:0;padding:0;">=20
	                                        <c:forEach
items=3D"${status.errorMessages}" var=3D"msg">=20
	                                                <li><c:out
value=3D"${msg}"/></li>=20
	                                        </c:forEach>=20
	                                </ul>=20
	                        </div>=20
	                </spring:bind>=20

	Here are the code changes in BindTag.java:=20

	private boolean showAllErrors =3D false;=20

	public void setShowAllErrors(String showAllErrors){=20
	        CustomBooleanEditor booleanEditor =3D new
CustomBooleanEditor(false);=20
	        booleanEditor.setAsText(showAllErrors);=20
	        this.showAllErrors =3D
((Boolean)booleanEditor.getValue()).booleanValue();=20
	}=20

	protected int doStartTagInternal() throws Exception {=20

	//...Previous code=20

	if (this.property !=3D null) {=20
	        fes =3D this.errors.getFieldErrors(this.property);=20
	        value =3D this.errors.getFieldValue(this.property);=20
	        editor =3D this.errors.getCustomEditor(this.property);=20
	        if (isHtmlEscape() && value instanceof String) {=20
	                value =3D HtmlUtils.htmlEscape((String) value);=20
	        }=20
	}=20
	//This is my change=20
	else {=20
	        if(showAllErrors)=20
	                fes =3D this.errors.getAllErrors();=20
	        else=20
	                fes =3D this.errors.getGlobalErrors();=20
	}=20

	If there are no serious objections, I could commit this.=20

	Regards,=20
	Dmitriy.=20

RE: [Springframework-developer] New addition to BindTag

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

Juergen,

This looks cleaner ;-) I'll try to implement your suggestion.

Regards,
Dmitriy.

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Thursday, October 02, 2003 5:13 AM
To: Kopylenko, Dmitry; Spring Developers
Subject: Re: [Springframework-developer] New addition to BindTag


Dmitriy,
=20
That's definitely useful. I'm wondering if there's an alternative to a
"showAllErrors" boolean, though - as this parameter is just applied if
parameter "property" is empty. We could for example define =
"property=3D*" as
showing all errors, for all properties. That would mean:
=20
- "property" empty =3D global errors
- "property=3DmyProperty" =3D just the errors for "myProperty"
- "property=3D*" =3D all errors, both global and for all properties
=20
The good thing would be that there's no ambiguity, i.e. no invalid
combinations of parameters.
=20
Juergen
=20

	-----Urspr=FCngliche Nachricht-----=20
	Von: Kopylenko, Dmitry [mailto:dko...@ac...]=20
	Gesendet: Mi 01.10.2003 15:00=20
	An: 'Spring Developers'=20
	Cc:=20
	Betreff: [Springframework-developer] New addition to BindTag
=09
=09

	Hello everyone,=20

	I came across the following limitation in using BindTag to render
ObjectErrors (in our case anyway :-). The thing is that we use generic =
JSP
to render validation errors which we include in each JSP by using it =
like
this:

	                <spring:bind path=3D"${command}">=20
	                        <div class=3D"error">=20
	                                <ul style=3D"margin:0;padding:0;">=20
	                                        <c:forEach
items=3D"${status.errorMessages}" var=3D"msg">=20
	                                                <li><c:out
value=3D"${msg}"/></li>=20
	                                        </c:forEach>=20
	                                </ul>=20
	                        </div>=20
	                </spring:bind>=20

	By using it like this(without specifying property name) it shows
only "Global Errors, but we need to show all errors (like typeMismatch =
etc.)

	So, I've added an optional boolean attribute to the tag called
showAllErrors and when it's set to "true" then the tag will expose all
errors. By default it's false:

	                <spring:bind path=3D"${command}" =
showAllErrors=3D"true">

	                        <div class=3D"error">=20
	                                <ul style=3D"margin:0;padding:0;">=20
	                                        <c:forEach
items=3D"${status.errorMessages}" var=3D"msg">=20
	                                                <li><c:out
value=3D"${msg}"/></li>=20
	                                        </c:forEach>=20
	                                </ul>=20
	                        </div>=20
	                </spring:bind>=20

	Here are the code changes in BindTag.java:=20

	private boolean showAllErrors =3D false;=20

	public void setShowAllErrors(String showAllErrors){=20
	        CustomBooleanEditor booleanEditor =3D new
CustomBooleanEditor(false);=20
	        booleanEditor.setAsText(showAllErrors);=20
	        this.showAllErrors =3D
((Boolean)booleanEditor.getValue()).booleanValue();=20
	}=20

	protected int doStartTagInternal() throws Exception {=20

	//...Previous code=20

	if (this.property !=3D null) {=20
	        fes =3D this.errors.getFieldErrors(this.property);=20
	        value =3D this.errors.getFieldValue(this.property);=20
	        editor =3D this.errors.getCustomEditor(this.property);=20
	        if (isHtmlEscape() && value instanceof String) {=20
	                value =3D HtmlUtils.htmlEscape((String) value);=20
	        }=20
	}=20
	//This is my change=20
	else {=20
	        if(showAllErrors)=20
	                fes =3D this.errors.getAllErrors();=20
	        else=20
	                fes =3D this.errors.getGlobalErrors();=20
	}=20

	If there are no serious objections, I could commit this.=20

	Regards,=20
	Dmitriy.=20

Re: [Springframework-developer] New addition to BindTag

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

RG1pdHJpeSwNCiANClRoYXQncyBkZWZpbml0ZWx5IHVzZWZ1bC4gSSdtIHdvbmRlcmluZyBpZiB0
aGVyZSdzIGFuIGFsdGVybmF0aXZlIHRvIGEgInNob3dBbGxFcnJvcnMiIGJvb2xlYW4sIHRob3Vn
aCAtIGFzIHRoaXMgcGFyYW1ldGVyIGlzIGp1c3QgYXBwbGllZCBpZiBwYXJhbWV0ZXIgInByb3Bl
cnR5IiBpcyBlbXB0eS4gV2UgY291bGQgZm9yIGV4YW1wbGUgZGVmaW5lICJwcm9wZXJ0eT0qIiBh
cyBzaG93aW5nIGFsbCBlcnJvcnMsIGZvciBhbGwgcHJvcGVydGllcy4gVGhhdCB3b3VsZCBtZWFu
Og0KIA0KLSAicHJvcGVydHkiIGVtcHR5ID0gZ2xvYmFsIGVycm9ycw0KLSAicHJvcGVydHk9bXlQ
cm9wZXJ0eSIgPSBqdXN0IHRoZSBlcnJvcnMgZm9yICJteVByb3BlcnR5Ig0KLSAicHJvcGVydHk9
KiIgPSBhbGwgZXJyb3JzLCBib3RoIGdsb2JhbCBhbmQgZm9yIGFsbCBwcm9wZXJ0aWVzDQogDQpU
aGUgZ29vZCB0aGluZyB3b3VsZCBiZSB0aGF0IHRoZXJlJ3Mgbm8gYW1iaWd1aXR5LCBpLmUuIG5v
IGludmFsaWQgY29tYmluYXRpb25zIG9mIHBhcmFtZXRlcnMuDQogDQpKdWVyZ2VuDQogDQoNCgkt
LS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogS29weWxlbmtvLCBEbWl0
cnkgW21haWx0bzpka29weWxlbmtvQGFjcy5ydXRnZXJzLmVkdV0gDQoJR2VzZW5kZXQ6IE1pIDAx
LjEwLjIwMDMgMTU6MDAgDQoJQW46ICdTcHJpbmcgRGV2ZWxvcGVycycgDQoJQ2M6IA0KCUJldHJl
ZmY6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBOZXcgYWRkaXRpb24gdG8gQmluZFRhZw0K
CQ0KCQ0KDQoJSGVsbG8gZXZlcnlvbmUsIA0KDQoJSSBjYW1lIGFjcm9zcyB0aGUgZm9sbG93aW5n
IGxpbWl0YXRpb24gaW4gdXNpbmcgQmluZFRhZyB0byByZW5kZXIgT2JqZWN0RXJyb3JzIChpbiBv
dXIgY2FzZSBhbnl3YXkgOi0pLiBUaGUgdGhpbmcgaXMgdGhhdCB3ZSB1c2UgZ2VuZXJpYyBKU1Ag
dG8gcmVuZGVyIHZhbGlkYXRpb24gZXJyb3JzIHdoaWNoIHdlIGluY2x1ZGUgaW4gZWFjaCBKU1Ag
YnkgdXNpbmcgaXQgbGlrZSB0aGlzOg0KDQoJICAgICAgICAgICAgICAgIDxzcHJpbmc6YmluZCBw
YXRoPSIke2NvbW1hbmR9Ij4gDQoJICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0i
ZXJyb3IiPiANCgkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx1bCBzdHlsZT0ibWFy
Z2luOjA7cGFkZGluZzowOyI+IA0KCSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA8Yzpmb3JFYWNoIGl0ZW1zPSIke3N0YXR1cy5lcnJvck1lc3NhZ2VzfSIgdmFyPSJtc2ci
PiANCgkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bGk+
PGM6b3V0IHZhbHVlPSIke21zZ30iLz48L2xpPiANCgkgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPC9jOmZvckVhY2g+IA0KCSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPC91bD4gDQoJICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+IA0KCSAgICAgICAg
ICAgICAgICA8L3NwcmluZzpiaW5kPiANCg0KCUJ5IHVzaW5nIGl0IGxpa2UgdGhpcyh3aXRob3V0
IHNwZWNpZnlpbmcgcHJvcGVydHkgbmFtZSkgaXQgc2hvd3Mgb25seSAiR2xvYmFsIEVycm9ycywg
YnV0IHdlIG5lZWQgdG8gc2hvdyBhbGwgZXJyb3JzIChsaWtlIHR5cGVNaXNtYXRjaCBldGMuKQ0K
DQoJU28sIEkndmUgYWRkZWQgYW4gb3B0aW9uYWwgYm9vbGVhbiBhdHRyaWJ1dGUgdG8gdGhlIHRh
ZyBjYWxsZWQgc2hvd0FsbEVycm9ycyBhbmQgd2hlbiBpdCdzIHNldCB0byAidHJ1ZSIgdGhlbiB0
aGUgdGFnIHdpbGwgZXhwb3NlIGFsbCBlcnJvcnMuIEJ5IGRlZmF1bHQgaXQncyBmYWxzZToNCg0K
CSAgICAgICAgICAgICAgICA8c3ByaW5nOmJpbmQgcGF0aD0iJHtjb21tYW5kfSIgc2hvd0FsbEVy
cm9ycz0idHJ1ZSI+IA0KCSAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImVycm9y
Ij4gDQoJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dWwgc3R5bGU9Im1hcmdpbjow
O3BhZGRpbmc6MDsiPiANCgkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PGM6Zm9yRWFjaCBpdGVtcz0iJHtzdGF0dXMuZXJyb3JNZXNzYWdlc30iIHZhcj0ibXNnIj4gDQoJ
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGxpPjxjOm91
dCB2YWx1ZT0iJHttc2d9Ii8+PC9saT4gDQoJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDwvYzpmb3JFYWNoPiANCgkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDwvdWw+IA0KCSAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2PiANCgkgICAgICAgICAgICAg
ICAgPC9zcHJpbmc6YmluZD4gDQoNCglIZXJlIGFyZSB0aGUgY29kZSBjaGFuZ2VzIGluIEJpbmRU
YWcuamF2YTogDQoNCglwcml2YXRlIGJvb2xlYW4gc2hvd0FsbEVycm9ycyA9IGZhbHNlOyANCg0K
CXB1YmxpYyB2b2lkIHNldFNob3dBbGxFcnJvcnMoU3RyaW5nIHNob3dBbGxFcnJvcnMpeyANCgkg
ICAgICAgIEN1c3RvbUJvb2xlYW5FZGl0b3IgYm9vbGVhbkVkaXRvciA9IG5ldyBDdXN0b21Cb29s
ZWFuRWRpdG9yKGZhbHNlKTsgDQoJICAgICAgICBib29sZWFuRWRpdG9yLnNldEFzVGV4dChzaG93
QWxsRXJyb3JzKTsgDQoJICAgICAgICB0aGlzLnNob3dBbGxFcnJvcnMgPSAoKEJvb2xlYW4pYm9v
bGVhbkVkaXRvci5nZXRWYWx1ZSgpKS5ib29sZWFuVmFsdWUoKTsgDQoJfSANCg0KCXByb3RlY3Rl
ZCBpbnQgZG9TdGFydFRhZ0ludGVybmFsKCkgdGhyb3dzIEV4Y2VwdGlvbiB7IA0KDQoJLy8uLi5Q
cmV2aW91cyBjb2RlIA0KDQoJaWYgKHRoaXMucHJvcGVydHkgIT0gbnVsbCkgeyANCgkgICAgICAg
IGZlcyA9IHRoaXMuZXJyb3JzLmdldEZpZWxkRXJyb3JzKHRoaXMucHJvcGVydHkpOyANCgkgICAg
ICAgIHZhbHVlID0gdGhpcy5lcnJvcnMuZ2V0RmllbGRWYWx1ZSh0aGlzLnByb3BlcnR5KTsgDQoJ
ICAgICAgICBlZGl0b3IgPSB0aGlzLmVycm9ycy5nZXRDdXN0b21FZGl0b3IodGhpcy5wcm9wZXJ0
eSk7IA0KCSAgICAgICAgaWYgKGlzSHRtbEVzY2FwZSgpICYmIHZhbHVlIGluc3RhbmNlb2YgU3Ry
aW5nKSB7IA0KCSAgICAgICAgICAgICAgICB2YWx1ZSA9IEh0bWxVdGlscy5odG1sRXNjYXBlKChT
dHJpbmcpIHZhbHVlKTsgDQoJICAgICAgICB9IA0KCX0gDQoJLy9UaGlzIGlzIG15IGNoYW5nZSAN
CgllbHNlIHsgDQoJICAgICAgICBpZihzaG93QWxsRXJyb3JzKSANCgkgICAgICAgICAgICAgICAg
ZmVzID0gdGhpcy5lcnJvcnMuZ2V0QWxsRXJyb3JzKCk7IA0KCSAgICAgICAgZWxzZSANCgkgICAg
ICAgICAgICAgICAgZmVzID0gdGhpcy5lcnJvcnMuZ2V0R2xvYmFsRXJyb3JzKCk7IA0KCX0gDQoN
CglJZiB0aGVyZSBhcmUgbm8gc2VyaW91cyBvYmplY3Rpb25zLCBJIGNvdWxkIGNvbW1pdCB0aGlz
LiANCg0KCVJlZ2FyZHMsIA0KCURtaXRyaXkuIA0KDQo=

Re: [Springframework-developer] Any sort of defined policy w/regards to tab/space usage and indentation?

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

I took a better look at Jalopy. My only previous experience with it had 
been with the OSWorkflow project, where a build seemed to modify every 
file, as a result of Jalopy running. Now in fact, the Jalopy ant task is 
smart enough to use a checksum to not touch files which don't end up 
getting reformatted, and the OSWorkflow guys were not overriding this. 
However, they were forcing it to use unix line endings, even on windows 
systems.

So Jalopy would probably be a realistic option. There is a plugin for 
Eclipse too...

Regards,
Colin

Colin Sampaleanu wrote:

> I think the only issue with using Jalopy before checkin is that CVS is 
> not really optimized for this; unless Jalopy is smart enough to not 
> touch file dates on files that don't get reformatted, you end up doing 
> a diff on every file to do a checkin. I realize that only the actually 
> modified files get checked in, but the contents still get set across, 
> since CVS doesn't keep local original versions (like say Subversion, 
> which is optimized to reduce bandwidth usage at the expense of local 
> space).
>
> Regards,
> Colin
>
> Rod Johnson wrote:
>
>> The use of tabs is historical. I'm in the minority of people who use 
>> tabs,
>> so the original code base had tabs and I still use them. I know most 
>> people
>> in open source projects hate tabs, so we might eventually need to change
>> this.
>>
>> We did consider the use of Jalopy before check in at one point.
>>
>> I'd prefer not to mess with the formatting process before 1.0 unless we
>> really need to.
>>
>> Regards,
>> Rod
>>
>> ----- Original Message ----- From: "Colin Sampaleanu" 
>> <col...@ex...>
>> To: <rod...@in...>; <jue...@we...>
>> Cc: "Spring Developers" 
>> <spr...@li...>
>> Sent: Tuesday, September 30, 2003 10:14 PM
>> Subject: [Springframework-developer] Any sort of defined policy 
>> w/regards to
>> tab/space usage and indentation?
>>
>>
>>  
>>
>>> I notice that most of the codebase in Spring uses hard tabs as opposed
>>> to spaces for indentation. From looking at some comment text which does
>>> have some embedded spaces, as far as I can tell the assumption is that
>>> tabs equate to 4 chars, although most of the code itself does not seem
>>> to make this assumption?
>>>
>>> Is there any sort of project policy or guideline on this? i.e. 
>>> something
>>> like 'all code must use hard tabs, and align elements only with tabs',
>>> etc.? I can hopefully work with any policy, but I'd just like to 
>>> know if
>>> one exists... (although if I am forced to use hard tabs I would 
>>> actually
>>> have to set up another Eclipse workspace, right now my tab key puts out
>>> spaces).
>>>
>>> fwiw, I have personally found that hard tabs are somewhat of a disaster
>>> (or at least a problem) in many team environents. In my teams, it's
>>> generally the one rule we apply with no exceptions, "no hard tabs". The
>>> problem is that while hard tabs have the ideal benefit of allowing 
>>> users
>>> to indent to whatever size they like, in practice people seem to not
>>> have the discipline to stick to using tabs only, or their editor of the
>>> moment doesn't allow them to set the tab size to something else 
>>> easilly,
>>> so spaces creep in. Once that happens to any extent, the code looks
>>> broken to anybody else using another tab size.
>>>
>>> Regards,
>>> Colin
>>>    
>>

RE: [Springframework-developer] New addition to BindTag

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

Seems useful, as long as the default is indeed false it;s ok with me...
 
By the way, I recently added the transform tag (to also transform
reference data using hte same propertyeditors in the object). I did
_not_ include it in the TLD yet, maybe people want to first check it
out...
 
alef
 

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Kopylenko, Dmitry
Verzonden: Wednesday, October 01, 2003 3:01 PM
Aan: 'Spring Developers'
Onderwerp: [Springframework-developer] New addition to BindTag



Hello everyone, 

I came across the following limitation in using BindTag to render
ObjectErrors (in our case anyway :-). The thing is that we use generic
JSP to render validation errors which we include in each JSP by using it
like this:

                <spring:bind path="${command}"> 
                        <div class="error"> 
                                <ul style="margin:0;padding:0;"> 
                                        <c:forEach
items="${status.errorMessages}" var="msg"> 
                                                <li><c:out
value="${msg}"/></li> 
                                        </c:forEach> 
                                </ul> 
                        </div> 
                </spring:bind> 

By using it like this(without specifying property name) it shows only
"Global Errors, but we need to show all errors (like typeMismatch etc.)

So, I've added an optional boolean attribute to the tag called
showAllErrors and when it's set to "true" then the tag will expose all
errors. By default it's false:

                <spring:bind path="${command}" showAllErrors="true"> 
                        <div class="error"> 
                                <ul style="margin:0;padding:0;"> 
                                        <c:forEach
items="${status.errorMessages}" var="msg"> 
                                                <li><c:out
value="${msg}"/></li> 
                                        </c:forEach> 
                                </ul> 
                        </div> 
                </spring:bind> 

Here are the code changes in BindTag.java: 

private boolean showAllErrors = false; 

public void setShowAllErrors(String showAllErrors){ 
        CustomBooleanEditor booleanEditor = new
CustomBooleanEditor(false); 
        booleanEditor.setAsText(showAllErrors); 
        this.showAllErrors =
((Boolean)booleanEditor.getValue()).booleanValue(); 
} 

protected int doStartTagInternal() throws Exception { 

//...Previous code 

if (this.property != null) { 
        fes = this.errors.getFieldErrors(this.property); 
        value = this.errors.getFieldValue(this.property); 
        editor = this.errors.getCustomEditor(this.property); 
        if (isHtmlEscape() && value instanceof String) { 
                value = HtmlUtils.htmlEscape((String) value); 
        } 
} 
//This is my change 
else { 
        if(showAllErrors) 
                fes = this.errors.getAllErrors(); 
        else 
                fes = this.errors.getGlobalErrors(); 
} 

If there are no serious objections, I could commit this. 

Regards, 
Dmitriy. 

[Springframework-developer] New addition to BindTag

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

Hello everyone,

I came across the following limitation in using BindTag to render
ObjectErrors (in our case anyway :-). The thing is that we use generic JSP
to render validation errors which we include in each JSP by using it like
this:
		<spring:bind path="${command}">
			<div class="error">
				<ul style="margin:0;padding:0;">
					<c:forEach
items="${status.errorMessages}" var="msg">
						<li><c:out
value="${msg}"/></li>
					</c:forEach>
				</ul>
			</div>
		</spring:bind>

By using it like this(without specifying property name) it shows only
"Global Errors, but we need to show all errors (like typeMismatch etc.)
So, I've added an optional boolean attribute to the tag called showAllErrors
and when it's set to "true" then the tag will expose all errors. By default
it's false:

		<spring:bind path="${command}" showAllErrors="true">
			<div class="error">
				<ul style="margin:0;padding:0;">
					<c:forEach
items="${status.errorMessages}" var="msg">
						<li><c:out
value="${msg}"/></li>
					</c:forEach>
				</ul>
			</div>
		</spring:bind>

Here are the code changes in BindTag.java:

private boolean showAllErrors = false;

public void setShowAllErrors(String showAllErrors){
	CustomBooleanEditor booleanEditor = new CustomBooleanEditor(false);
	booleanEditor.setAsText(showAllErrors);
	this.showAllErrors =
((Boolean)booleanEditor.getValue()).booleanValue();
}

protected int doStartTagInternal() throws Exception {

//...Previous code

if (this.property != null) {
	fes = this.errors.getFieldErrors(this.property);
	value = this.errors.getFieldValue(this.property);
	editor = this.errors.getCustomEditor(this.property);
	if (isHtmlEscape() && value instanceof String) {
		value = HtmlUtils.htmlEscape((String) value);
	}
}
//This is my change
else {
	if(showAllErrors)
		fes = this.errors.getAllErrors();
	else
		fes = this.errors.getGlobalErrors();
}

If there are no serious objections, I could commit this.

Regards,
Dmitriy.

RE: [Springframework-developer] Any sort of defined policy w/regards to tab/space usage and indentation?

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

I use tabs, but I tend to ignore most formatting, using the "auto-format"
function of Eclipse routinely.  The only problem with this is that it will
mess up CVS if you reformat and submit.

Trevor

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: October 1, 2003 3:37 AM
To: Colin Sampaleanu; jue...@we...
Cc: Spring Developers
Subject: Re: [Springframework-developer] Any sort of defined policy
w/regards to tab/space usage and indentation?


The use of tabs is historical. I'm in the minority of people who use tabs,
so the original code base had tabs and I still use them. I know most people
in open source projects hate tabs, so we might eventually need to change
this.

We did consider the use of Jalopy before check in at one point.

I'd prefer not to mess with the formatting process before 1.0 unless we
really need to.

Regards,
Rod

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <rod...@in...>; <jue...@we...>
Cc: "Spring Developers" <spr...@li...>
Sent: Tuesday, September 30, 2003 10:14 PM
Subject: [Springframework-developer] Any sort of defined policy w/regards to
tab/space usage and indentation?


> I notice that most of the codebase in Spring uses hard tabs as opposed
> to spaces for indentation. From looking at some comment text which does
> have some embedded spaces, as far as I can tell the assumption is that
> tabs equate to 4 chars, although most of the code itself does not seem
> to make this assumption?
>
> Is there any sort of project policy or guideline on this? i.e. something
> like 'all code must use hard tabs, and align elements only with tabs',
> etc.? I can hopefully work with any policy, but I'd just like to know if
> one exists... (although if I am forced to use hard tabs I would actually
> have to set up another Eclipse workspace, right now my tab key puts out
> spaces).
>
> fwiw, I have personally found that hard tabs are somewhat of a disaster
> (or at least a problem) in many team environents. In my teams, it's
> generally the one rule we apply with no exceptions, "no hard tabs". The
> problem is that while hard tabs have the ideal benefit of allowing users
> to indent to whatever size they like, in practice people seem to not
> have the discipline to stick to using tabs only, or their editor of the
> moment doesn't allow them to set the tab size to something else easilly,
> so spaces creep in. Once that happens to any extent, the code looks
> broken to anybody else using another tab size.
>
> Regards,
> Colin
>
>
>
>
> -------------------------------------------------------
> 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] Any sort of defined policy w/regards to tab/space usage and indentation?

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

I think the only issue with using Jalopy before checkin is that CVS is 
not really optimized for this; unless Jalopy is smart enough to not 
touch file dates on files that don't get reformatted, you end up doing a 
diff on every file to do a checkin. I realize that only the actually 
modified files get checked in, but the contents still get set across, 
since CVS doesn't keep local original versions (like say Subversion, 
which is optimized to reduce bandwidth usage at the expense of local space).

Regards,
Colin

Rod Johnson wrote:

>The use of tabs is historical. I'm in the minority of people who use tabs,
>so the original code base had tabs and I still use them. I know most people
>in open source projects hate tabs, so we might eventually need to change
>this.
>
>We did consider the use of Jalopy before check in at one point.
>
>I'd prefer not to mess with the formatting process before 1.0 unless we
>really need to.
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: "Colin Sampaleanu" <col...@ex...>
>To: <rod...@in...>; <jue...@we...>
>Cc: "Spring Developers" <spr...@li...>
>Sent: Tuesday, September 30, 2003 10:14 PM
>Subject: [Springframework-developer] Any sort of defined policy w/regards to
>tab/space usage and indentation?
>
>
>  
>
>>I notice that most of the codebase in Spring uses hard tabs as opposed
>>to spaces for indentation. From looking at some comment text which does
>>have some embedded spaces, as far as I can tell the assumption is that
>>tabs equate to 4 chars, although most of the code itself does not seem
>>to make this assumption?
>>
>>Is there any sort of project policy or guideline on this? i.e. something
>>like 'all code must use hard tabs, and align elements only with tabs',
>>etc.? I can hopefully work with any policy, but I'd just like to know if
>>one exists... (although if I am forced to use hard tabs I would actually
>>have to set up another Eclipse workspace, right now my tab key puts out
>>spaces).
>>
>>fwiw, I have personally found that hard tabs are somewhat of a disaster
>>(or at least a problem) in many team environents. In my teams, it's
>>generally the one rule we apply with no exceptions, "no hard tabs". The
>>problem is that while hard tabs have the ideal benefit of allowing users
>>to indent to whatever size they like, in practice people seem to not
>>have the discipline to stick to using tabs only, or their editor of the
>>moment doesn't allow them to set the tab size to something else easilly,
>>so spaces creep in. Once that happens to any extent, the code looks
>>broken to anybody else using another tab size.
>>
>>Regards,
>>Colin
>>    
>>

Re: [Springframework-developer] Any sort of defined policy w/rega rds to tab/space usage and indentation?

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

Well, it does and it doesn't. That is, there is no way on a project by 
project basis to set the tab key to spit out tabs or spaces when you press
Tab to indent. And there is no easy way to switch back and forth; you 
actually have to go to two separate places in the preferences. There is 
also no easy way to switch the defined tab/indent size, only via the 
preferences. Actually, if Eclipse is set for spaces, there is no way to 
even spit out a hard tab.   This all basically means you have to use one 
worksapce for your projects that use spaces for indents, and one for 
your projects that use tabs.

Anyways, while I personally don't like them, I respect everyone's right 
to like them, and I understand the history here :-). I just wanted to 
know what the policy was...


Kopylenko, Dmitry wrote:

>I also use tabs and Eclipse supports them very well ;-)
>
>Dmitriy.
>
>-----Original Message-----
>From: Rod Johnson [mailto:rod...@in...] 
>Sent: Wednesday, October 01, 2003 3:37 AM
>To: Colin Sampaleanu; jue...@we...
>Cc: Spring Developers
>Subject: Re: [Springframework-developer] Any sort of defined policy
>w/regards to tab/space usage and indentation?
>
>
>The use of tabs is historical. I'm in the minority of people who use tabs,
>so the original code base had tabs and I still use them. I know most people
>in open source projects hate tabs, so we might eventually need to change
>this.
>
>We did consider the use of Jalopy before check in at one point.
>
>I'd prefer not to mess with the formatting process before 1.0 unless we
>really need to.
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: "Colin Sampaleanu" <col...@ex...>
>To: <rod...@in...>; <jue...@we...>
>Cc: "Spring Developers" <spr...@li...>
>Sent: Tuesday, September 30, 2003 10:14 PM
>Subject: [Springframework-developer] Any sort of defined policy w/regards to
>tab/space usage and indentation?
>
>
>  
>
>>I notice that most of the codebase in Spring uses hard tabs as opposed 
>>to spaces for indentation. From looking at some comment text which 
>>does have some embedded spaces, as far as I can tell the assumption is 
>>that tabs equate to 4 chars, although most of the code itself does not 
>>seem to make this assumption?
>>
>>Is there any sort of project policy or guideline on this? i.e. 
>>something like 'all code must use hard tabs, and align elements only 
>>with tabs', etc.? I can hopefully work with any policy, but I'd just 
>>like to know if one exists... (although if I am forced to use hard 
>>tabs I would actually have to set up another Eclipse workspace, right 
>>now my tab key puts out spaces).
>>
>>fwiw, I have personally found that hard tabs are somewhat of a 
>>disaster (or at least a problem) in many team environents. In my 
>>teams, it's generally the one rule we apply with no exceptions, "no 
>>hard tabs". The problem is that while hard tabs have the ideal benefit 
>>of allowing users to indent to whatever size they like, in practice 
>>people seem to not have the discipline to stick to using tabs only, or 
>>their editor of the moment doesn't allow them to set the tab size to 
>>something else easilly, so spaces creep in. Once that happens to any 
>>extent, the code looks broken to anybody else using another tab size.
>>
>>Regards,
>>Colin
>>    
>>

RE: [Springframework-developer] Any sort of defined policy w/regards to tab/space usage and indentation?

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

Ongoing discussion in the company here. I use tabs all the time and the
other people don't want to adjust the checkstyle properties to I keep on
getting remarks abou my tabs (but I keep using them)!

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Kopylenko, Dmitry
Verzonden: Wednesday, October 01, 2003 1:46 PM
Aan: 'Rod Johnson'; 'Colin Sampaleanu'; 'jue...@we...'
CC: 'Spring Developers'
Onderwerp: RE: [Springframework-developer] Any sort of defined policy
w/regards to tab/space usage and indentation?


I also use tabs and Eclipse supports them very well ;-)

Dmitriy.

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...] 
Sent: Wednesday, October 01, 2003 3:37 AM
To: Colin Sampaleanu; jue...@we...
Cc: Spring Developers
Subject: Re: [Springframework-developer] Any sort of defined policy
w/regards to tab/space usage and indentation?


The use of tabs is historical. I'm in the minority of people who use
tabs, so the original code base had tabs and I still use them. I know
most people in open source projects hate tabs, so we might eventually
need to change this.

We did consider the use of Jalopy before check in at one point.

I'd prefer not to mess with the formatting process before 1.0 unless we
really need to.

Regards,
Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <rod...@in...>; <jue...@we...>
Cc: "Spring Developers"
<spr...@li...>
Sent: Tuesday, September 30, 2003 10:14 PM
Subject: [Springframework-developer] Any sort of defined policy
w/regards to tab/space usage and indentation?


> I notice that most of the codebase in Spring uses hard tabs as opposed
> to spaces for indentation. From looking at some comment text which 
> does have some embedded spaces, as far as I can tell the assumption is

> that tabs equate to 4 chars, although most of the code itself does not

> seem to make this assumption?
>
> Is there any sort of project policy or guideline on this? i.e.
> something like 'all code must use hard tabs, and align elements only 
> with tabs', etc.? I can hopefully work with any policy, but I'd just 
> like to know if one exists... (although if I am forced to use hard 
> tabs I would actually have to set up another Eclipse workspace, right 
> now my tab key puts out spaces).
>
> fwiw, I have personally found that hard tabs are somewhat of a
> disaster (or at least a problem) in many team environents. In my 
> teams, it's generally the one rule we apply with no exceptions, "no 
> hard tabs". The problem is that while hard tabs have the ideal benefit

> of allowing users to indent to whatever size they like, in practice 
> people seem to not have the discipline to stick to using tabs only, or

> their editor of the moment doesn't allow them to set the tab size to 
> something else easilly, so spaces creep in. Once that happens to any 
> extent, the code looks broken to anybody else using another tab size.
>
> Regards,
> Colin
>
>
>
>
> -------------------------------------------------------
> 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


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