springframework-developer — Spring Framework developers list

RE: [Springframework-developer] FreeMarker

[Cameron B. <ca...@da...>]

I havn't done any real integration with the sandbox code, but one =
suggestion
that I can make is to move the core freemarker configuration classes =
from
web into somewhere else, sice its not just a web technology.

I use freemarker for email generation as well as views.

I would presume that the same can be said and done for velocity, even =
xslt
etc..

Cameron



> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of Darren Davison
> Sent: Saturday, 6 March 2004 6:12 AM
> To: spr...@li...
> Subject: [Springframework-developer] FreeMarker
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> I've committed freemarker ui and view components to the=20
> sandbox as there are a couple of things still outstanding to=20
> do, and they're not fully tested.
>=20
> Cameron - if you're able to take a look and see if you can=20
> get the shared variables aspect working in your project that=20
> would be helpful.
>=20
> Specify a FreemarkerConfig bean in your servlet context file like so;
>=20
> <!-- freemarker config -->
> <bean
>   id=3D"freemarkerConfig"
>   class=3D"org.springfr...view.freemarker.FreemarkerConfigurer"
>=20
>   <!-- optional -->
>   <property name=3D"freemarkerSettings">
>     <props>
>       <prop key=3D"localized_lookup">true</prop>
>       <!-- etc... -->
>     </props>
>   </property>
>=20
>   <!-- optional -->
>   <map name=3D"freemarkerVariables">
>     <entry key=3D"my_helper">
>       <ref local=3D"freemarkerHelperObject"/>
>     </entry>
>     <!-- etc... -->
>   </map>
> </bean>
>=20
>=20
>=20
> and similar to the following to define a view;
>=20
> fmView.class=3Dorg.springframework.web.servlet.view.freemarker.F
> reemarkerView
> # if you don't specify a templateContext, WEB-INF/freemarker=20
> will be # searched for templates fmView.templateContext=3DWEB-INF/ftl
> fmView.url=3Dtest.ftl
>=20
>=20
>=20
> - --=20
>=20
> Darren Davison
> Public Key: http://www.davison.uk.net/key.jsp -----BEGIN PGP=20
> SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>=20
> iD8DBQFASN8IKLMLAN01aw0RAqClAJ4pPlH0MaHWvp2TPxk4j3/T6J3rqwCdG4ny
> DOuc/+gNCQrVqZdPuFB7Ug0=3D
> =3DpFHR
> -----END PGP SIGNATURE-----
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials Free=20
> Linux tutorial presented by Daniel Robbins, President and CEO=20
> of GenToo technologies. Learn everything from fundamentals to=20
> system =
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

Re: [Springframework-developer] RE: Log4J configuration

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

There have been some issues with the reloading of WARs when using the =
"webapp.root" system property for context-relative log file paths. =
However, those should all have been sorted out. I haven't come across =
the behavior that you encountered yet, though.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von James Cook
Gesendet: Mi 03.03.2004 20:03
An: spr...@li...
Betreff: [Springframework-developer] RE: Log4J configuration



No one having any log4J problems? Any ideas on what I may be doing =
wrong?

> -----Original Message-----
> From: James Cook [mailto:jim...@do...]
> Sent: Tuesday, March 02, 2004 2:41 PM
> To: 'spr...@li...'
> Subject: Log4J configuration
>
> I'm trying to get my web-tier to log to a file, and my configuration =
is
> based on the JPetstore example. My web.xml file contains the following
> entries:
>
> <context-param>
>     <param-name>log4jConfigLocation</param-name>
>     <param-value>/WEB-INF/classes/log4j.properties</param-value>
> </context-param>
>
> <listener>
>     <listener-
> =
class>org.springframework.web.util.Log4jConfigListener</listener-class>
> </listener>
>
> I am deploying to Tomcat 5.0.18, and I have added -Dlog4j.debug=3Dtrue =
to
> the Tomcat startup.
>
> In the Tomcat5 console, I begin to see JDK 1.4 style logging =
statements
> describing the Tomcat, Hibernate and Spring startup. About half-way
> through, the listener is loaded and I see Spring's loading of my
> log4j.properties file from the proper directory. Because I turned =
log4j
> debug on, I see the successful parsing of the log4j properties file. =
Now I
> would expect any future logging to be directed to my log4j appenders =
(both
> console and file), however the JDK-style logging continues. In the =
end,
> the log4j debug file was created, but has 0 bytes.
>
> I am not deploying a war file to Tomcat (either packed or unpacked.) I =
am
> simply pointing Tomcat at my directory structure.
>
> Any ideas?




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] EJBs and their Bean Factories

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

I think the warning should still be in BeanFactoryLocator, with 
references to it in the actual impl. classes...

Alef Arendsen wrote:

>>As for passivation/activation, it's not an issue for
>>stateless beans, as those are not legal states. 
>>    
>>
>Oops, you're right. It seems like I'm already forgetting some of that
>horrible stuff I've been using for the last 3 years (of which I'm glad ;-).
>
>By the way, I was looking for that really big warning you had put up in the
>SingletonBeanFactoryLocator (wasn't it), but couldn't find it anymore. No
>warnings anymore ;-)?
>
>Alef
>
>
>
>  
>
>>For stateful beans, you
>>will get an unload and reload on the passivation/activation, but this is
>>not for real if there is already a shared instance, all that will be
>>unloaded/reloaded is the reference to the shared context/beanfactory.
>>
>>Regards,
>>Colin
>>
>>
>>Alef Arendsen wrote:
>>
>>    
>>
>>>>Looking at the code for the EJB base classes, unless I'm missing
>>>>something obvious (not unheard of), it seems that by default a separate
>>>>bean factory is created for each bean instance.
>>>>
>>>>
>>>>        
>>>>
>>>Well, to put it bluntly: you're not mistaken; it's the way it is.
>>>
>>>As far as I'm concerned, the issue basically is that without violated any
>>>rules that apply to implementing EJBs, it's just not possible to get an
>>>ApplicationContext shared across multiple multiple beans of different
>>>      
>>>
>>types,
>>    
>>
>>>not even across multiple instances of the same type.
>>>
>>>For one because resources instantiated as fields of EJBs should either be
>>>serializable (which the ApplicationContext isn't, not even mentioning any
>>>beans inside it), or transient (or closed and thrown away on
>>>      
>>>
>>passivation).
>>    
>>
>>>Another solution would be (and I hate to say this, but this is what we're
>>>currently using in one of our applications that is still based on EJBs
>>>      
>>>
>>but
>>    
>>
>>>in the process of being migrated to Spring) to bind the context in a JNDI
>>>tree, but here, the Serializable argument also applies. So that (when
>>>applying the rules really strict) is one to throw away as well.
>>>
>>>Of course when using certain EJB container, you won't have to worry about
>>>serializable issues when not accessing the JNDI from outside the VM the
>>>server is running in. Also, having the ApplicationContext defined as a
>>>singleton or something (ughh!) wouldn't result in too many problems using
>>>      
>>>
>>a
>>    
>>
>>>simple EJB container, but I guess that's not really an option we (Spring)
>>>are eager to offer. The same applies to providing an approach based on
>>>static fields.
>>>
>>>Ohh, there is something like the BeanFactoryLocator, but this only reads
>>>      
>>>
>>in
>>    
>>
>>>BeanFactory I believe.
>>>
>>>Basically my approach is to avoid the use EJBs where possible and if
>>>      
>>>
>>needed,
>>    
>>
>>>implement an EJB using Spring's EJB layer and don't worry about one or
>>>      
>>>
>>two
>>    
>>
>>>applicationcontexts too much being created. I mean, afterall, one of the
>>>reasons I choose Spring in the first place is to be able to get rid of
>>>      
>>>
>>EJBs.
>>    
>>
>>>(I won't start a rant here, that might just be personal ;-).
>>>
>>>I don't know if this satisfies or if somebody else has opinions?
>>>
>>>Alef
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>>>GenToo technologies. Learn everything from fundamentals to system
>>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>      
>>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>>GenToo technologies. Learn everything from fundamentals to system
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

RE: [Springframework-developer] EJBs and their Bean Factories

[Alef A. <al...@jt...>]

> Maybe I'll try extending JndiBeanFactoryLocator and implement
> createBeanFactory to just load the bean factory once, then set the
> locator in my EJBs. I'm only using stateless beans and I don't really
> care about the spec if it works... or perhaps I'll just bite the bullet
> and suggest that we get rid of them altogether.
Well, you can always try to of course ;-).

In the meantime I hope you've read Colin's take on it.

Regards,
Alef
> 
> Alef Arendsen wrote:
> 
> >>Looking at the code for the EJB base classes, unless I'm missing
> >>something obvious (not unheard of), it seems that by default a separate
> >>bean factory is created for each bean instance.
> >
> > Well, to put it bluntly: you're not mistaken; it's the way it is.
> >
> > As far as I'm concerned, the issue basically is that without violated
> any
> > rules that apply to implementing EJBs, it's just not possible to get an
> > ApplicationContext shared across multiple multiple beans of different
> types,
> > not even across multiple instances of the same type.
> >
> > For one because resources instantiated as fields of EJBs should either
> be
> > serializable (which the ApplicationContext isn't, not even mentioning
> any
> > beans inside it), or transient (or closed and thrown away on
> passivation).
> >
> > Another solution would be (and I hate to say this, but this is what
> we're
> > currently using in one of our applications that is still based on EJBs
> but
> > in the process of being migrated to Spring) to bind the context in a
> JNDI
> > tree, but here, the Serializable argument also applies. So that (when
> > applying the rules really strict) is one to throw away as well.
> >
> > Of course when using certain EJB container, you won't have to worry
> about
> > serializable issues when not accessing the JNDI from outside the VM the
> > server is running in. Also, having the ApplicationContext defined as a
> > singleton or something (ughh!) wouldn't result in too many problems
> using a
> > simple EJB container, but I guess that's not really an option we
> (Spring)
> > are eager to offer. The same applies to providing an approach based on
> > static fields.
> >
> > Ohh, there is something like the BeanFactoryLocator, but this only reads
> in
> > BeanFactory I believe.
> >
> > Basically my approach is to avoid the use EJBs where possible and if
> needed,
> > implement an EJB using Spring's EJB layer and don't worry about one or
> two
> > applicationcontexts too much being created. I mean, afterall, one of the
> > reasons I choose Spring in the first place is to be able to get rid of
> EJBs.
> > (I won't start a rant here, that might just be personal ;-).
> >
> > I don't know if this satisfies or if somebody else has opinions?
> >
> > Alef
> >
> >
> >
> 
> 
> 
> --
>   Luke Taylor.                      Monkey Machine Ltd.
>   PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] EJBs and their Bean Factories

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

Thanks Colin... I'll try that :).

Colin Sampaleanu wrote:

> Actually, you can quite successfully use the BeanFactoryLocator variants 
> to share the same ApplicationContext or BeanFactory instance(s) across 
> multiple EJBs in a webapp. I am doing this in JBoss (although happilly 
> am almost done removing all ejbs). Just override the default 
> setSessionContext in a fashion similar to:
> 



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

Re: [Springframework-developer] EJBs and their Bean Factories

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

Unfortunately migration to an entire Spring solution isn't always an 
option for political reasons - my current client has invested a lot of 
time reading EJB books and I don't think they'd swallow it if I said we 
were going to ditch them altogether. I'm just using local stateless 
session beans which do nothing other than delegating calls to other 
business objects, but they aren't really serving any purpose other than 
getting in the way of a nicely configured application.

Maybe I'll try extending JndiBeanFactoryLocator and implement 
createBeanFactory to just load the bean factory once, then set the 
locator in my EJBs. I'm only using stateless beans and I don't really 
care about the spec if it works... or perhaps I'll just bite the bullet 
and suggest that we get rid of them altogether.

Alef Arendsen wrote:

>>Looking at the code for the EJB base classes, unless I'm missing
>>something obvious (not unheard of), it seems that by default a separate
>>bean factory is created for each bean instance.
> 
> Well, to put it bluntly: you're not mistaken; it's the way it is.
> 
> As far as I'm concerned, the issue basically is that without violated any
> rules that apply to implementing EJBs, it's just not possible to get an
> ApplicationContext shared across multiple multiple beans of different types,
> not even across multiple instances of the same type. 
> 
> For one because resources instantiated as fields of EJBs should either be
> serializable (which the ApplicationContext isn't, not even mentioning any
> beans inside it), or transient (or closed and thrown away on passivation). 
> 
> Another solution would be (and I hate to say this, but this is what we're
> currently using in one of our applications that is still based on EJBs but
> in the process of being migrated to Spring) to bind the context in a JNDI
> tree, but here, the Serializable argument also applies. So that (when
> applying the rules really strict) is one to throw away as well.
> 
> Of course when using certain EJB container, you won't have to worry about
> serializable issues when not accessing the JNDI from outside the VM the
> server is running in. Also, having the ApplicationContext defined as a
> singleton or something (ughh!) wouldn't result in too many problems using a
> simple EJB container, but I guess that's not really an option we (Spring)
> are eager to offer. The same applies to providing an approach based on
> static fields.
> 
> Ohh, there is something like the BeanFactoryLocator, but this only reads in
> BeanFactory I believe.
> 
> Basically my approach is to avoid the use EJBs where possible and if needed,
> implement an EJB using Spring's EJB layer and don't worry about one or two
> applicationcontexts too much being created. I mean, afterall, one of the
> reasons I choose Spring in the first place is to be able to get rid of EJBs.
> (I won't start a rant here, that might just be personal ;-).
> 
> I don't know if this satisfies or if somebody else has opinions?
> 
> Alef
> 
> 
> 



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

RE: [Springframework-developer] EJBs and their Bean Factories

[Alef A. <al...@jt...>]

> As for passivation/activation, it's not an issue for
> stateless beans, as those are not legal states. 
Oops, you're right. It seems like I'm already forgetting some of that
horrible stuff I've been using for the last 3 years (of which I'm glad ;-).

By the way, I was looking for that really big warning you had put up in the
SingletonBeanFactoryLocator (wasn't it), but couldn't find it anymore. No
warnings anymore ;-)?

Alef



> For stateful beans, you
> will get an unload and reload on the passivation/activation, but this is
> not for real if there is already a shared instance, all that will be
> unloaded/reloaded is the reference to the shared context/beanfactory.
> 
> Regards,
> Colin
> 
> 
> Alef Arendsen wrote:
> 
> >>Looking at the code for the EJB base classes, unless I'm missing
> >>something obvious (not unheard of), it seems that by default a separate
> >>bean factory is created for each bean instance.
> >>
> >>
> >Well, to put it bluntly: you're not mistaken; it's the way it is.
> >
> >As far as I'm concerned, the issue basically is that without violated any
> >rules that apply to implementing EJBs, it's just not possible to get an
> >ApplicationContext shared across multiple multiple beans of different
> types,
> >not even across multiple instances of the same type.
> >
> >For one because resources instantiated as fields of EJBs should either be
> >serializable (which the ApplicationContext isn't, not even mentioning any
> >beans inside it), or transient (or closed and thrown away on
> passivation).
> >
> >Another solution would be (and I hate to say this, but this is what we're
> >currently using in one of our applications that is still based on EJBs
> but
> >in the process of being migrated to Spring) to bind the context in a JNDI
> >tree, but here, the Serializable argument also applies. So that (when
> >applying the rules really strict) is one to throw away as well.
> >
> >Of course when using certain EJB container, you won't have to worry about
> >serializable issues when not accessing the JNDI from outside the VM the
> >server is running in. Also, having the ApplicationContext defined as a
> >singleton or something (ughh!) wouldn't result in too many problems using
> a
> >simple EJB container, but I guess that's not really an option we (Spring)
> >are eager to offer. The same applies to providing an approach based on
> >static fields.
> >
> >Ohh, there is something like the BeanFactoryLocator, but this only reads
> in
> >BeanFactory I believe.
> >
> >Basically my approach is to avoid the use EJBs where possible and if
> needed,
> >implement an EJB using Spring's EJB layer and don't worry about one or
> two
> >applicationcontexts too much being created. I mean, afterall, one of the
> >reasons I choose Spring in the first place is to be able to get rid of
> EJBs.
> >(I won't start a rant here, that might just be personal ;-).
> >
> >I don't know if this satisfies or if somebody else has opinions?
> >
> >Alef
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: IBM Linux Tutorials
> >Free Linux tutorial presented by Daniel Robbins, President and CEO of
> >GenToo technologies. Learn everything from fundamentals to system
> >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] declarative rules-based bean validator w/ attributes in sandbox

[Keith D. <kd...@cs...>]

Sam,

Up until some design changes this weekend, I had a working source
implementation that would let you build validation configuration information
programatically (either java or a scripting shell like groovy/beanshell) or
by using a Spring context (xml.)  I haven't checked it back in yet, but I
will do so ASAP.  Thanks for pointing that out, Keith

----- Original Message ----- 
From: "Sam Newman" <sam...@ma...>
To: <spr...@li...>
Sent: Monday, March 08, 2004 5:31 PM
Subject: Re: [Springframework-developer] declarative rules-based bean
validator w/ attributes in sandbox


> Keith,
>
> At present can validation rules only be configured from in code
> attributes? Many people will not be happy using this quite new (and
> relatively non-standard) technique. I appreciate this might become more
> widespread with the metadata support in 1.5 but it will be a while
> before this is universally being used. As it stands, many people dislike
> the need for tools like XDoclet. Is there currently support for reading
> validation rules from a config file?
>
> Keith Donald wrote:
>
> > I just committed the rules-based bean validator Seth and I have been
> > working on to the spring/sandbox under the
> > 'org.springframework.validation' package.  The design has now gone
> > through several internal iterations and is waiting for your review and
> > feedback.
> >
> > Within 'validation', you'll find the following interfaces:
> >
> >     BeanValidationService
> >         (the main client interface, extends
> >     org.springframework.validation.Validator)
> >
> >     BeanValidatorSource
> >         (encapsulates logic for loading validator configuration
> >     information from a specific source.)
> >
> >     PropertyValidator
> >         (encapsulates the validation of all PropertyValidationRules that
> >     apply to a particular property.)
> >
> >     PropertyValidationRule
> >         (encapsulates a single validation rule and typing-hint/error
> >     message building logic.)
> >
> >     ValidationResultsCollector
> >         (data-collector with callbacks to track validation progress.  Is
> >     also used to populate an Errors object.)
> >
> > Within 'validation.rules', you'll find the out-of-the-box rules built
> > to-date.  Obviously we want to build up a rich library of commonly-used
> > rules.
> >
> > Within  'validation.support', you'll find implementations for the above
> > interfaces, as well as the "AttributesValidatorSource" implementation
> > which is responsible for loading validators declaratively defined in
> > source-metadata using commons-attributes.
> >
> > To use with a commons-attributes source, declare the following in a
> > spring-context definition:
> >
> > <bean id="beanValidationService"
> >
class="org.springframework.validation.support.DefaultBeanValidationService"/
>
> >     <constructor-arg index="0">
> >                     <description>The source providing validator
> > configuration information.</description>
> >         <bean id="attributesSource"
> >
class="org.springframework.validation.support.AttributesValidatorSource"/>
> >     </constructor-arg>
> > </bean>
> >
> > Again, beanValidationService is just a regular Spring validator, so you
> > can treat it as such.
> >
> > Internally, the design leverages the java-beans BeanInfo paradigm to
> > store validators loaded from a particular source.  If a bean is
> > validateable, it's associated BeanInfo.BeanDescriptor will have a
> > property called "isValidated" set to true.  In addition, each
> > PropertyDescriptor will also have a "isValidated" property, and if true
> > will have a PropertyValidator reference stored under the "validator"
> > property.  I thought this was a good way to leverage the existing
> > javabeans metadata API (and the good thing is it removes us from having
> > to cache anything ourselves or maintain some parallel hierarchy of bean
> > validators...)  The generic validation algorithm simply iterates over
> > each BeanInfo and PropertyDescriptor looking for attached validators...
> > (which could've been populated by any source.)
> >
> > As a result of these commits, some common (small) utility classes were
> > also commited to sandbox/util.  All of these relocated straight from
> > spring-rcp.util.  Tests are also in sandbox/test, but I admit right now
> > the Validation stuff is in need of better tests.
> >
> > This framework should work equally well in web and rich-client
> > environments.  I think once we get a iteration or two more we'll be
there!
> >
> > Keith
>
>
> -- 
> sam
> http://www.magpiebrain.com/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] EJBs and their Bean Factories

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

Actually, you can quite successfully use the BeanFactoryLocator variants 
to share the same ApplicationContext or BeanFactory instance(s) across 
multiple EJBs in a webapp. I am doing this in JBoss (although happilly 
am almost done removing all ejbs). Just override the default 
setSessionContext in a fashion similar to:

  /*
   * (non-Javadoc)
   * @see javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext)
   */
  public void setSessionContext(SessionContext sessionContext) {
    super.setSessionContext(sessionContext);
    setBeanFactoryLocator(ContextSingletonBeanFactoryLocator.getInstance());
    setBeanFactoryLocatorKey(ServicesConstants.PRIMARY_CONTEXT_ID);
  }


then if you want to delegate to a real POJO service doing the work, you 
would also have something like:
  /*
   * (non-Javadoc)
   * @see 
org.springframework.ejb.support.AbstractStatelessSessionBean#onEjbCreate()
   */
  protected void onEjbCreate() throws CreateException {
    _appController = (ApplicationControllerService) 
getBeanFactory().getBean(
        CORE_SERVICES_APPLICATION_CONTROLLER_SERVICE);
  }


where _appController is the pojo service object all methods will 
delegate to.  As for passivation/activation, it's not an issue for 
stateless beans, as those are not legal states. For stateful beans, you 
will get an unload and reload on the passivation/activation, but this is 
not for real if there is already a shared instance, all that will be 
unloaded/reloaded is the reference to the shared context/beanfactory.

Regards,
Colin


Alef Arendsen wrote:

>>Looking at the code for the EJB base classes, unless I'm missing
>>something obvious (not unheard of), it seems that by default a separate
>>bean factory is created for each bean instance.
>>    
>>
>Well, to put it bluntly: you're not mistaken; it's the way it is.
>
>As far as I'm concerned, the issue basically is that without violated any
>rules that apply to implementing EJBs, it's just not possible to get an
>ApplicationContext shared across multiple multiple beans of different types,
>not even across multiple instances of the same type. 
>
>For one because resources instantiated as fields of EJBs should either be
>serializable (which the ApplicationContext isn't, not even mentioning any
>beans inside it), or transient (or closed and thrown away on passivation). 
>
>Another solution would be (and I hate to say this, but this is what we're
>currently using in one of our applications that is still based on EJBs but
>in the process of being migrated to Spring) to bind the context in a JNDI
>tree, but here, the Serializable argument also applies. So that (when
>applying the rules really strict) is one to throw away as well.
>
>Of course when using certain EJB container, you won't have to worry about
>serializable issues when not accessing the JNDI from outside the VM the
>server is running in. Also, having the ApplicationContext defined as a
>singleton or something (ughh!) wouldn't result in too many problems using a
>simple EJB container, but I guess that's not really an option we (Spring)
>are eager to offer. The same applies to providing an approach based on
>static fields.
>
>Ohh, there is something like the BeanFactoryLocator, but this only reads in
>BeanFactory I believe.
>
>Basically my approach is to avoid the use EJBs where possible and if needed,
>implement an EJB using Spring's EJB layer and don't worry about one or two
>applicationcontexts too much being created. I mean, afterall, one of the
>reasons I choose Spring in the first place is to be able to get rid of EJBs.
>(I won't start a rant here, that might just be personal ;-).
>
>I don't know if this satisfies or if somebody else has opinions?
>
>Alef
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] declarative rules-based bean validator w/ attributes in sandbox

[Seth L. <se...@eh...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sam Newman wrote:
| Keith,
|
| At present can validation rules only be configured from in code
| attributes? Many people will not be happy using this quite new (and
| relatively non-standard) technique. I appreciate this might become more
| widespread with the metadata support in 1.5 but it will be a while
| before this is universally being used. As it stands, many people dislike
| the need for tools like XDoclet. Is there currently support for reading
| validation rules from a config file?

Much of Keith's work is introducing new interfaces and classes to make
writing validators easier.  One possible implementation is an attributes
based validator.  Other options include an implementation based on
commons-validator, which uses an external XML file for its rules.
Daniel Miller is working on this exact code.

If you are waiting for metadata support but don't want jdk 1.5 or
xdoclet, look into commons-attributes.  It's quite nice.

In short, Keith is working on two things: new validation classes and
interfaces /and/ an implementation of a commons-attributes validator.
Daniel is working on the commons-validator implementation.

As with Spring, there are many choices! :)

Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFATPl05EIB1scRes8RAivsAJ4kZwNnppDhmrd3LJ+ctf+SGCKoVwCfXc6D
AT8Eh5tib2QWx+hZBVsuf68=
=odIu
-----END PGP SIGNATURE-----

Re: [Springframework-developer] declarative rules-based bean validator w/ attributes in sandbox

[Sam N. <sam...@ma...>]

Keith,

At present can validation rules only be configured from in code 
attributes? Many people will not be happy using this quite new (and 
relatively non-standard) technique. I appreciate this might become more 
widespread with the metadata support in 1.5 but it will be a while 
before this is universally being used. As it stands, many people dislike 
the need for tools like XDoclet. Is there currently support for reading 
validation rules from a config file?

Keith Donald wrote:

> I just committed the rules-based bean validator Seth and I have been 
> working on to the spring/sandbox under the 
> 'org.springframework.validation' package.  The design has now gone 
> through several internal iterations and is waiting for your review and 
> feedback.
>  
> Within 'validation', you'll find the following interfaces:
> 
>     BeanValidationService
>         (the main client interface, extends
>     org.springframework.validation.Validator)
>      
>     BeanValidatorSource
>         (encapsulates logic for loading validator configuration
>     information from a specific source.)
>      
>     PropertyValidator
>         (encapsulates the validation of all PropertyValidationRules that
>     apply to a particular property.)
>      
>     PropertyValidationRule
>         (encapsulates a single validation rule and typing-hint/error
>     message building logic.)
>      
>     ValidationResultsCollector
>         (data-collector with callbacks to track validation progress.  Is
>     also used to populate an Errors object.)
> 
> Within 'validation.rules', you'll find the out-of-the-box rules built 
> to-date.  Obviously we want to build up a rich library of commonly-used 
> rules.
>  
> Within  'validation.support', you'll find implementations for the above 
> interfaces, as well as the "AttributesValidatorSource" implementation 
> which is responsible for loading validators declaratively defined in 
> source-metadata using commons-attributes.
>  
> To use with a commons-attributes source, declare the following in a 
> spring-context definition:
>  
> <bean id="beanValidationService" 
> class="org.springframework.validation.support.DefaultBeanValidationService"/>
>     <constructor-arg index="0">
>                     <description>The source providing validator 
> configuration information.</description>
>         <bean id="attributesSource" 
> class="org.springframework.validation.support.AttributesValidatorSource"/>
>     </constructor-arg>
> </bean>
>  
> Again, beanValidationService is just a regular Spring validator, so you 
> can treat it as such.
>  
> Internally, the design leverages the java-beans BeanInfo paradigm to 
> store validators loaded from a particular source.  If a bean is 
> validateable, it's associated BeanInfo.BeanDescriptor will have a 
> property called "isValidated" set to true.  In addition, each 
> PropertyDescriptor will also have a "isValidated" property, and if true 
> will have a PropertyValidator reference stored under the "validator" 
> property.  I thought this was a good way to leverage the existing 
> javabeans metadata API (and the good thing is it removes us from having 
> to cache anything ourselves or maintain some parallel hierarchy of bean 
> validators...)  The generic validation algorithm simply iterates over 
> each BeanInfo and PropertyDescriptor looking for attached validators... 
> (which could've been populated by any source.)
>  
> As a result of these commits, some common (small) utility classes were 
> also commited to sandbox/util.  All of these relocated straight from 
> spring-rcp.util.  Tests are also in sandbox/test, but I admit right now 
> the Validation stuff is in need of better tests.
>  
> This framework should work equally well in web and rich-client 
> environments.  I think once we get a iteration or two more we'll be there!
>  
> Keith


-- 
sam
http://www.magpiebrain.com/

RE: [Springframework-developer] EJBs and their Bean Factories

[Alef A. <al...@jt...>]

> Looking at the code for the EJB base classes, unless I'm missing
> something obvious (not unheard of), it seems that by default a separate
> bean factory is created for each bean instance.
Well, to put it bluntly: you're not mistaken; it's the way it is.

As far as I'm concerned, the issue basically is that without violated any
rules that apply to implementing EJBs, it's just not possible to get an
ApplicationContext shared across multiple multiple beans of different types,
not even across multiple instances of the same type. 

For one because resources instantiated as fields of EJBs should either be
serializable (which the ApplicationContext isn't, not even mentioning any
beans inside it), or transient (or closed and thrown away on passivation). 

Another solution would be (and I hate to say this, but this is what we're
currently using in one of our applications that is still based on EJBs but
in the process of being migrated to Spring) to bind the context in a JNDI
tree, but here, the Serializable argument also applies. So that (when
applying the rules really strict) is one to throw away as well.

Of course when using certain EJB container, you won't have to worry about
serializable issues when not accessing the JNDI from outside the VM the
server is running in. Also, having the ApplicationContext defined as a
singleton or something (ughh!) wouldn't result in too many problems using a
simple EJB container, but I guess that's not really an option we (Spring)
are eager to offer. The same applies to providing an approach based on
static fields.

Ohh, there is something like the BeanFactoryLocator, but this only reads in
BeanFactory I believe.

Basically my approach is to avoid the use EJBs where possible and if needed,
implement an EJB using Spring's EJB layer and don't worry about one or two
applicationcontexts too much being created. I mean, afterall, one of the
reasons I choose Spring in the first place is to be able to get rid of EJBs.
(I won't start a rant here, that might just be personal ;-).

I don't know if this satisfies or if somebody else has opinions?

Alef

[Springframework-developer] EJBs and their Bean Factories

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

Looking at the code for the EJB base classes, unless I'm missing 
something obvious (not unheard of), it seems that by default a separate 
bean factory is created for each bean instance.

http://monkeymachine.co.uk/spring/xref/org/springframework/ejb/support/AbstractEnterpriseBean.html

Is this the desired behaviour? I would have expected them to share one 
for each JNDI key that is used.

At the moment, I have a single beans xml file which holds the 
configuration for my DAOs, AOP stuff etc. and which is used by a set of 
stateless session beans. Each session bean only uses one DAO but it 
seems that if I follow this approach I will end up with an exponentially 
growing number of objects as I add new EJBs. Even if I split each bean's 
configuration into a separate file it still seems inefficient and 
counterintuitive that I end up with an application context per EJB instance.

Luke.

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

Re: [Springframework-developer] declarative rules-based bean validator w/ attributes in sandbox

[Seth L. <se...@eh...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Keith Donald wrote:
| I just committed the rules-based bean validator Seth and I have been
| working on to the spring/sandbox under the
| 'org.springframework.validation' package.  The design has now gone
| through several internal iterations and is waiting for your review and
| feedback.

Keith,

I just got into work (crazy Hawaii time) and I saw this gem.  Can't wait
to check it out.

Thanks for all your work,
Seth

ps I wrote some more validation rules in the meantime that might be useful.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFATLkz5EIB1scRes8RAlFHAJ99GQ6ZUAgbc3oUvK4qq4jRkUFaCQCfYVhH
9+wdtuQbLs9AiotDpeQ+row=
=oaz8
-----END PGP SIGNATURE-----

Re: [Springframework-developer] Commons-Validator for Spring

[Seth L. <se...@eh...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Miller wrote:
| To all,
|
| I am looking into implementing the JavaScript portion of the
| Commons-Validator for Spring. I have a few questions on which I would
| appreciate some feedback:

Daniel,

This is great to see!  I have a few requests:

- - Make the javascript work with XHTML 1.0 Strict or >.  Currently,
Struts' javascript works with a <form> with a name attribute.  The name
attribute is deprecated.  It's id now.

- - Selectively include the javascript functions being used on the form.
In Struts right now, if you choose to include Javascript validation, it
includes every possible function.


Good luck, and I'd love to help test it out.  Keith has been working on
some new APIs for validation, so they might be helpful.  I think they
are either in the RCP or sandbox.

Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFATLcI5EIB1scRes8RAiTRAJ4yg5FaX7YMcTIHKjSybVH1WB3jqwCeLDyZ
AJlkNlE1xImEtQlfEXYeqeE=
=mC24
-----END PGP SIGNATURE-----

[Springframework-developer] declarative rules-based bean validator w/ attributes in sandbox

[Keith D. <kd...@cs...>]

I just committed the rules-based bean validator Seth and I have been =
working
on to the spring/sandbox under the 'org.springframework.validation' =
package.
The design has now gone through several internal iterations and is =
waiting
for your review and feedback.
=20
Within 'validation', you'll find the following interfaces:

BeanValidationService
    (the main client interface, extends
org.springframework.validation.Validator)
=20
BeanValidatorSource
    (encapsulates logic for loading validator configuration information =
from
a specific source.)
=20
PropertyValidator
    (encapsulates the validation of all PropertyValidationRules that =
apply
to a particular property.)
=20
PropertyValidationRule
    (encapsulates a single validation rule and typing-hint/error message
building logic.)
=20
ValidationResultsCollector
    (data-collector with callbacks to track validation progress.  Is =
also
used to populate an Errors object.)

Within 'validation.rules', you'll find the out-of-the-box rules built
to-date.  Obviously we want to build up a rich library of commonly-used
rules.
=20
Within  'validation.support', you'll find implementations for the above
interfaces, as well as the "AttributesValidatorSource" implementation =
which
is responsible for loading validators declaratively defined in
source-metadata using commons-attributes.
=20
To use with a commons-attributes source, declare the following in a
spring-context definition:
=20
<bean id=3D"beanValidationService"
class=3D"org.springframework.validation.support.DefaultBeanValidationServ=
ice"/
>
    <constructor-arg index=3D"0">
                    <description>The source providing validator
configuration information.</description>
        <bean id=3D"attributesSource"
class=3D"org.springframework.validation.support.AttributesValidatorSource=
"/>
    </constructor-arg>
</bean>
=20
Again, beanValidationService is just a regular Spring validator, so you =
can
treat it as such.
=20
Internally, the design leverages the java-beans BeanInfo paradigm to =
store
validators loaded from a particular source.  If a bean is validateable, =
it's
associated BeanInfo.BeanDescriptor will have a property called =
"isValidated"
set to true.  In addition, each PropertyDescriptor will also have a
"isValidated" property, and if true will have a PropertyValidator =
reference
stored under the "validator" property.  I thought this was a good way to
leverage the existing javabeans metadata API (and the good thing is it
removes us from having to cache anything ourselves or maintain some =
parallel
hierarchy of bean validators...)  The generic validation algorithm =
simply
iterates over each BeanInfo and PropertyDescriptor looking for attached
validators... (which could've been populated by any source.)
=20
As a result of these commits, some common (small) utility classes were =
also
commited to sandbox/util.  All of these relocated straight from
spring-rcp.util.  Tests are also in sandbox/test, but I admit right now =
the
Validation stuff is in need of better tests.
=20
This framework should work equally well in web and rich-client =
environments.
I think once we get a iteration or two more we'll be there!
=20
Keith

Re: [Springframework-developer] GUI validation feedback

[Sam N. <sam...@ma...>]

Oh, I should point out that I would expect such an API to ship with a 
few template types, such as an Abstract base class for convenience, and 
classes displaying the validation information on a JLabel to the left, 
right, above and below a control, along with some measure of 
customization (text colour, font size etc). At present I am unsure to 
replace the notion of a TemplateClass with a TemplateFactory, as this 
seems to make a little more sense to me.

Sam Newman wrote:

> I've been thinking about the issue of feeding back validation 
> information to desktop applications (think: SWT or Swing) for 
> spring-rcp. If we take Struts as an example, we need:
> 
> 1. General message areas
> 2. Field specific feedback
> 
> So, if you are filling in a form and don't fill in a required field, you 
> really want an message to that affect next to the field. The problem is 
> that you do not want to require that the user define each and every 
> location for errors - it would be nice if you could just define simple 
> JTextFields, JLabels etc. and identify them as fields.
> My proposed solution is to add a Factory, which is capable of taking a 
> control (field, combobox, list etc) and a optional template, which then 
> produces a Component which includes the field and an for feedback which 
> will be propagated. The template will be a component which defines where 
> the field can be and where the message will be. I suggest the following 
> API:
> 
> void addTemplate(Class componentClass, FeedbackTemplate template)
> void setDefaultTemplate(FeedBackTemplate template);
> 

<snip>


-- 
sam
http://www.magpiebrain.com/

[Springframework-developer] GUI validation feedback

[Sam N. <sam...@ma...>]

I've been thinking about the issue of feeding back validation 
information to desktop applications (think: SWT or Swing) for 
spring-rcp. If we take Struts as an example, we need:

1. General message areas
2. Field specific feedback

So, if you are filling in a form and don't fill in a required field, you 
really want an message to that affect next to the field. The problem is 
that you do not want to require that the user define each and every 
location for errors - it would be nice if you could just define simple 
JTextFields, JLabels etc. and identify them as fields.
My proposed solution is to add a Factory, which is capable of taking a 
control (field, combobox, list etc) and a optional template, which then 
produces a Component which includes the field and an for feedback which 
will be propagated. The template will be a component which defines where 
the field can be and where the message will be. I suggest the following API:

void addTemplate(Class componentClass, FeedbackTemplate template)
void setDefaultTemplate(FeedBackTemplate template);

/**
  * Creates a component using the control classes template or the default
  * template
  */
Component createCompoment(String fieldName, Component control)

/**
  * Creates a component with a custom template
  */
Component createComponent(String fieldName, Component control, 
FeedbackTemplate template)

I need to look over the validation stuff to work out how these 
FeedbackTemplates will get their text, but the interface will look 
something like this:

FeedbackTemplate(String fieldName, Component control)

Component getUI();

void showMessage(String message);

getUI will be called by the factory. showMessage gets called to show the 
feedback.

Comments?

-- 
sam
http://www.magpiebrain.com/

RE: [Springframework-developer] Commons-Validator for Spring

[Cameron B. <ca...@da...>]

I have written some javascript validation code that extends the WebWork2
validator system by creating client site javascript.

I have been trying to find the time to extract out our application specific
code from the system to allow it to be shared with the community.

I am still willing to do this, and I have been working on this recently.

Currently it is integrated into our custom freemarker marco based forms
library, and using some javascript objects on the client.

I will attempt to get the code online somewhere for people to have a look
at.

I don't know if it is useable with spring, but it may provide some food for
thought.

Thanks,

Cameron.

> -----Original Message-----
> From: spr...@li... 
> [mailto:spr...@li...]
>  On Behalf Of Sam Newman
> Sent: Monday, 8 March 2004 8:42 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Commons-Validator for Spring
> 
> Daniel Miller wrote:
> > To all,
> > 
> > I am looking into implementing the JavaScript portion of the 
> > Commons-Validator for Spring. I have a few questions on 
> which I would 
> > appreciate some feedback:
> > 
> > 1. Rather than re-invent the wheel I was planning on using as much 
> > existing code as possible to implement JavaScript validation for 
> > Spring. It turns out that the Struts source contains a lot 
> of the code 
> > that "constructs" the JavaScript functions for the client. What are 
> > the policies for using code from other open-source projects 
> in Spring? 
> > Can I just rip a bunch of code out of the Struts source and 
> adapt it 
> > for Spring? Do I need to ask permission first?
> 
> No matter what the license says, I think it would be 
> advisable to ask - some goodwill from the struts developers 
> might well help the process. In fact the struts developers 
> are known to be a big fan of their code being rebuilt as 
> separate modules - the Jakarta commons projects started from 
> code in struts 1.0 being moved into separate projects. Struts 
> is licensed using the Apache license, as such their code can 
> be used without problem as long as correct attribution is 
> given - this amounts to stating in the code itself and the 
> documentation where it came from.
> 
> > 3. Would it be advisable to put the javascript generating 
> code in the 
> > tag library or in the ValidatorFactory (which holds the resources 
> > needed to build the code; things like message resources 
> would need to be passed in)?
> 
> A tag library would be my preferred choice (I hate Java 
> scriptlets in JSP pages - a maintenance nightmare) although I 
> suspect that the tag would be a relatively thin wrapper over 
> the ValidatorFactory itself.
> 
> --
> sam
> http://www.magpiebrain.com/
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 

Re: [Springframework-developer] Commons-Validator for Spring

[Sam N. <sam...@ma...>]

Daniel Miller wrote:
> To all,
> 
> I am looking into implementing the JavaScript portion of the
> Commons-Validator for Spring. I have a few questions on which I would
> appreciate some feedback:
> 
> 1. Rather than re-invent the wheel I was planning on using as much existing
> code as possible to implement JavaScript validation for Spring. It turns out
> that the Struts source contains a lot of the code that "constructs" the
> JavaScript functions for the client. What are the policies for using code
> from other open-source projects in Spring? Can I just rip a bunch of code
> out of the Struts source and adapt it for Spring? Do I need to ask
> permission first?

No matter what the license says, I think it would be advisable to ask - 
some goodwill from the struts developers might well help the process. In 
fact the struts developers are known to be a big fan of their code being 
rebuilt as separate modules - the Jakarta commons projects started from 
code in struts 1.0 being moved into separate projects. Struts is 
licensed using the Apache license, as such their code can be used 
without problem as long as correct attribution is given - this amounts 
to stating in the code itself and the documentation where it came from.

> 3. Would it be advisable to put the javascript generating code in the tag
> library or in the ValidatorFactory (which holds the resources needed to
> build the code; things like message resources would need to be passed in)?

A tag library would be my preferred choice (I hate Java scriptlets in 
JSP pages - a maintenance nightmare) although I suspect that the tag 
would be a relatively thin wrapper over the ValidatorFactory itself.

-- 
sam
http://www.magpiebrain.com/

RE: [Springframework-developer] Commons-Validator for Spring

[Daniel M. <mi...@pa...>]

To all,

I am looking into implementing the JavaScript portion of the
Commons-Validator for Spring. I have a few questions on which I would
appreciate some feedback:

1. Rather than re-invent the wheel I was planning on using as much existing
code as possible to implement JavaScript validation for Spring. It turns out
that the Struts source contains a lot of the code that "constructs" the
JavaScript functions for the client. What are the policies for using code
from other open-source projects in Spring? Can I just rip a bunch of code
out of the Struts source and adapt it for Spring? Do I need to ask
permission first?

2. Constructing the JavaScript validation requires access to resources such
as the validator resources (which are contained in my ValidatorFactory which
is wired up in a Spring context) and message resources. How should I access
these resources from the context of a tag library (how/where are they stored
within the Spring webapp/page-context)?

3. Would it be advisable to put the javascript generating code in the tag
library or in the ValidatorFactory (which holds the resources needed to
build the code; things like message resources would need to be passed in)?

4. Would it be advisable
	(a) to add another tag library (with a single tag) that allows web authors
to incorporate the generated JavaScript into their pages?
	(b) to add another tag to the existing Spring taglib?
	(c) to use some other mechanism to get the JavaScript into the view?


I am open to and will consider all input. Your response is greatly
appreciated.

Thank you,

Daniel


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Keith Donald
Sent: Friday, March 05, 2004 8:34 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Commons-Validator for Spring


Daniel,

I can take a look at it.  I'm curious if it is feasible to use the same
declarative validator design we're developing and apply another mechanism
(adapter) for configuration from commons-validator's format.  That'd be
nice, because we could use the same framework for all sources of
configuration.  I know I am already doing this in my implementation on my
system as I use Spring IoC for configuration, while Seth uses attributes.
But that might prove to be too much work, and that your way is better
overall.  I really can't say yet.

commons-validator handles javascript validation client-side, too, right?
Your adapter enables that? I know that's one area we have not addressed.
Keith

----- Original Message -----
From: "Daniel Miller" <mi...@pa...>
To: <spr...@li...>
Sent: Friday, March 05, 2004 12:10 AM
Subject: RE: [Springframework-developer] Commons-Validator for Spring


> Seth and Keith,
>
> Did you get a chance to look at my commons-validator adaptor? I was
> wondering if you had any feedback? Feel free to tell me that it sucks, or
> that it was so elementary that you didn't want to waste any more time
> talking to me about it :)
>
> I don't know much about commons-attributes, but from what I've been
picking
> up between the lines on your recent validator-related posts it's quite
> different from the commons-validator approach. The main difference seems
to
> be that validation meta-data is expressed directly in the source of the
bean
> to be validated, while the commons-validator approach uses the
> validation.xml file to hold all of that meta-data.
>
> Your attributes validator sounds a bit more powerful than the commons
> validator, but many of the objects that I want to validate are generated
(by
> Middlegen) and I have no way of adding meta-data to the objects without
> modifying the generated code. Of course, I could just write a wrapper for
> each object that I want to validate, but I might as well just write a
> validator class for each object. That being said, I think there is room
for
> both an attributes validator and a commons validator in the Spring
> framework.
>
> The main thing I am interested in knowing is the patch that you (Seth)
> posted to allow message resources to be nested (as arguments) in another
> message resource. Do you have any idea how soon this will make its way
into
> a Spring release or should I just get the source and build it in for my
own
> use?
>
> Thanks,
> Daniel
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Daniel Miller
> Sent: Tuesday, March 02, 2004 12:19 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Commons-Validator for Spring
>
>
> Seth,
>
> That looks great. This would make my validation support super easy to
> implement. You can grab my current source here:
>
>
http://www.paonline.com/millerd/Spring-commons-validator_no-dependencies.zip
>
> I have not had time to write up a good example, tests, or complete the
> documentation. Hopefully I will be able to do this soon.
>
> Thanks,
> Daniel
>
>
> Original Message: -----------------------------------------------------
>
> | (2) Improve the handling of Errors objects to allow message resources
> to be
> | specified as arguments that would not be resolved to their corresponding
> | messages until reaching the view. I really like this solution, but I
have
> | not thought it through completely. One more note: since the errorArgs
> | parameter is an array of Objects (not an array of Strings), maybe there
> | would be a way to use a "Message" object that would be resolved at a
later
> | time, while preserving the current functionality of Strings that are
used
> | directly as arguments. For all I know, there is already a way to do
> this (it
> | seems logical enough), and I just don't know about it. This J2EE stuff
> is so
> | hard to keep up with...
>
> Daniel,
>
> I just posted a simple patch w/ unit test for the functionality we've
> discussed.  Please review and see if it meets your needs.
>
>
http://opensource.atlassian.com/projects/spring/secure/ViewIssue.jspa?key=SP
> R-56
>
>
> Seth
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Where can i get all tests?

[Dmitriy K. <dko...@ru...>]

Andy,

all tests are included with the standard Spring distribution: http://umn.dl.sourceforge.net/sourceforge/springframework/spring-framework-1.0-rc2.zip

in **/test/** tree.

Regards,
Dmitriy.

----- Original Message -----
From: "Wu, Andy" <an...@ci...>
Date: Sunday, March 7, 2004 8:56 pm
Subject: [Springframework-developer] Where can i get all tests?

> Hi there:
> 	I'm new to Spring.And i know that Spring is a test-driven 
> project, i guess we can't find a more excellent example in both 
> J2EE framework and test-driven project than Spring. So i was 
> wondering where can i get all these tests......i can't find them 
> in website.
> 	Does anybody know?
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] BeanWrapperImpl(clazz) behaivior

[Keith D. <kd...@cs...>]

Should the BeanWrapperImpl(class) usage call class.newInstance()?  I'd =
like to be able to introspect the PropertyDescriptors of a bean using =
BeanWrapper without having to use the Javabeans API directly.  Currently =
this call prevents me from doing so for beans that don't have no-arg =
constructors, which is the case for a lot of our beans these days.

I noticed this when working with the attributes validator Seth and I =
have been putting together -- Seth was using the reflection API directly =
to find validateable properties in getter source-level attributes, and I =
updated it to use the BeanWrapper API to simplfy the work we have to do, =
when I encountered this issue.

Keith

[Springframework-developer] Where can i get all tests?

[Wu, A. <an...@ci...>]

Hi there:
	I'm new to Spring.And i know that Spring is a test-driven project, i =
guess we can't find a more excellent example in both J2EE framework and =
test-driven project than Spring. So i was wondering where can i get all =
these tests......i can't find them in website.
	Does anybody know?

Re: [Springframework-developer] FreeMarker

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

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 03 March 2004 12:29, j=FCrgen h=F6ller [werk3AT] wrote:

> The FreeMarker 2.2/2.3 issue is quite important: 2.3 is in "preview"
> state - not very convincing... This is a strong argument for *not*
> including it in Spring 1.0 final but indeed delaying it till 1.1 M1.

I see from the FreeMarker dev list that they're expecting to release 2.3-RC=
1=20
in a few days from now :)

=2D --=20

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAS3rbKLMLAN01aw0RAut3AKCS//9r45ztyri9pYR5JbGJK/vfWQCcD4f2
OW7nU5rJoVBUYaUM6mBH9bo=3D
=3DeyXp
=2D----END PGP SIGNATURE-----