springframework-developer — Spring Framework developers list

[Springframework-developer] Re: Quartz support

[Raymond L. <alp...@ya...>]

Hi,

Great to see Quartz support is here now.

From the imagedb example in CVS I could see how can I
set up scheduled tasks which the parameters may not be
dynamic. But what if I I want to set up tasks will
have dynamic parameters?

Say, an user placed an item for others to bid. As a
result a task is being created, and filled with
parameters like the user's ID, and item's ID, etc. and
a trigger with the task's execution time specified by
the user, which are set in code, instead of in
applicationContext.xml.

Any hint for me to dig deeper?

TIA,
Raymond

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools

RE : [Springframework-developer] DataFieldMaxValueIncrementer

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

+1. Like others I didn't see why handling doubles. The same for the
inner classes. As long as long are handled, I'm happy. Originally, the
long type was lacking in the whole JDBC package.

Jean-Pierre Pawlak

-----Message d'origine-----
De=A0: spr...@li...
[mailto:spr...@li...] De la
part de j=FCrgen h=F6ller [werk3AT]
Envoy=E9=A0: mercredi 25 f=E9vrier 2004 21:48
=C0=A0: spr...@li...
Objet=A0: [Springframework-developer] DataFieldMaxValueIncrementer

I've added PostgreSQLSequenceMaxValueIncrementer today, as attached to
our JIRA. On the occasion, I've reviewed the incrementer
implementations: They're too complicated for what they achieve,
IMO.Thus, I've dropped the inner class NextMaxValueProviders and moved
the code to the DataFieldMaxValueIncrementer class hierarchy itself.
=20
I've noticed that AbstractDataFieldMaxValueIncrementer's nextDoubleValue
effectively returns an integer, like nextIntValue/nextLongValue - after
all, the template method getNextKey returns a long, so there's no chance
for a true double. Thus, I see no point in keeping the nextDoubleValue
method in the DataFieldMaxValueIncrementer interface; all current
implementations do not return doubles here.
=20
Furthermore, why does getNextKey take a type parameter when it returns a
long anyway? Any JDBC driver will let you read both an int and a long
via rs.getLong, so there's no point in that type parameter. Simply
reading the value via getLong should be sufficient.
=20
This leaves a very simple DataFieldMaxValueIncrementer interface with
nextIntValue, nextLongValue and nextStringValue methods, with
implementations that achieve their goal in a straightforward fashion.
AbstractDataFieldMaxValueIncrementer delegates all three to getNextKey
which returns a long, casting the long to an int respectively converting
it to a string with optional padding.
=20
This should still cover all current usages and therefore not break
compatibility, and it should make it as easy as possible to implement an
AbstractDataFieldMaxValueIncrementer subclass for a specific database.
Thomas, Dmitrity, what do you think?
=20
Juergen
=20
P.S.:
Obviously, 1.0 RC2 won't be released tonight but rather at the end of
the week. I believe it's worth it, as I'd also like to wait for feedback
on the other recent changes.
=20


-------------------------------------------------------
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_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] DataFieldMaxValueIncrementer

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

+1

I never understood the need for a double as an incrementer anyway.  Simple is
better.  The OracleSequenceMaxValueIncrementer could use some refactoring too. 
We don't need a SqlFunction - we should be able to use the new queryForXxxx
methods on the JDBC Template.  Once you check in your changes, I can take a look
at the Oracle one.

Thomas

Quoting "jürgen höller [werk3AT]" <jue...@we...>:

> I've added PostgreSQLSequenceMaxValueIncrementer today, as attached to =
> our JIRA. On the occasion, I've reviewed the incrementer =
> implementations: They're too complicated for what they achieve, =
> IMO.Thus, I've dropped the inner class NextMaxValueProviders and moved =
> the code to the DataFieldMaxValueIncrementer class hierarchy itself.
> =20
> I've noticed that AbstractDataFieldMaxValueIncrementer's nextDoubleValue =
> effectively returns an integer, like nextIntValue/nextLongValue - after =
> all, the template method getNextKey returns a long, so there's no chance =
> for a true double. Thus, I see no point in keeping the nextDoubleValue =
> method in the DataFieldMaxValueIncrementer interface; all current =
> implementations do not return doubles here.
> =20
> Furthermore, why does getNextKey take a type parameter when it returns a =
> long anyway? Any JDBC driver will let you read both an int and a long =
> via rs.getLong, so there's no point in that type parameter. Simply =
> reading the value via getLong should be sufficient.
> =20
> This leaves a very simple DataFieldMaxValueIncrementer interface with =
> nextIntValue, nextLongValue and nextStringValue methods, with =
> implementations that achieve their goal in a straightforward fashion. =
> AbstractDataFieldMaxValueIncrementer delegates all three to getNextKey =
> which returns a long, casting the long to an int respectively converting =
> it to a string with optional padding.
> =20
> This should still cover all current usages and therefore not break =
> compatibility, and it should make it as easy as possible to implement an =
> AbstractDataFieldMaxValueIncrementer subclass for a specific database. =
> Thomas, Dmitrity, what do you think?
> =20
> Juergen
> =20
> P.S.:
> Obviously, 1.0 RC2 won't be released tonight but rather at the end of =
> the week. I believe it's worth it, as I'd also like to wait for feedback =
> on the other recent changes.
> =20
> 
> 
> -------------------------------------------------------
> 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
> 

RE: [Springframework-developer] DataFieldMaxValueIncrementer

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

Definitely +1 as I originally designed it with int, long and String... =
The
simpler the implemetation the better :-))

Regards,
Dmitriy.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Wednesday, February 25, 2004 3:48 PM
To: spr...@li...
Subject: [Springframework-developer] DataFieldMaxValueIncrementer


I've added PostgreSQLSequenceMaxValueIncrementer today, as attached to =
our
JIRA. On the occasion, I've reviewed the incrementer implementations:
They're too complicated for what they achieve, IMO.Thus, I've dropped =
the
inner class NextMaxValueProviders and moved the code to the
DataFieldMaxValueIncrementer class hierarchy itself.
=20
I've noticed that AbstractDataFieldMaxValueIncrementer's nextDoubleValue
effectively returns an integer, like nextIntValue/nextLongValue - after =
all,
the template method getNextKey returns a long, so there's no chance for =
a
true double. Thus, I see no point in keeping the nextDoubleValue method =
in
the DataFieldMaxValueIncrementer interface; all current implementations =
do
not return doubles here.
=20
Furthermore, why does getNextKey take a type parameter when it returns a
long anyway? Any JDBC driver will let you read both an int and a long =
via
rs.getLong, so there's no point in that type parameter. Simply reading =
the
value via getLong should be sufficient.
=20
This leaves a very simple DataFieldMaxValueIncrementer interface with
nextIntValue, nextLongValue and nextStringValue methods, with
implementations that achieve their goal in a straightforward fashion.
AbstractDataFieldMaxValueIncrementer delegates all three to getNextKey =
which
returns a long, casting the long to an int respectively converting it to =
a
string with optional padding.
=20
This should still cover all current usages and therefore not break
compatibility, and it should make it as easy as possible to implement an
AbstractDataFieldMaxValueIncrementer subclass for a specific database.
Thomas, Dmitrity, what do you think?
=20
Juergen
=20
P.S.:
Obviously, 1.0 RC2 won't be released tonight but rather at the end of =
the
week. I believe it's worth it, as I'd also like to wait for feedback on =
the
other recent changes.
=20


-------------------------------------------------------
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_id438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] DataFieldMaxValueIncrementer

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

I've added PostgreSQLSequenceMaxValueIncrementer today, as attached to =
our JIRA. On the occasion, I've reviewed the incrementer =
implementations: They're too complicated for what they achieve, =
IMO.Thus, I've dropped the inner class NextMaxValueProviders and moved =
the code to the DataFieldMaxValueIncrementer class hierarchy itself.
=20
I've noticed that AbstractDataFieldMaxValueIncrementer's nextDoubleValue =
effectively returns an integer, like nextIntValue/nextLongValue - after =
all, the template method getNextKey returns a long, so there's no chance =
for a true double. Thus, I see no point in keeping the nextDoubleValue =
method in the DataFieldMaxValueIncrementer interface; all current =
implementations do not return doubles here.
=20
Furthermore, why does getNextKey take a type parameter when it returns a =
long anyway? Any JDBC driver will let you read both an int and a long =
via rs.getLong, so there's no point in that type parameter. Simply =
reading the value via getLong should be sufficient.
=20
This leaves a very simple DataFieldMaxValueIncrementer interface with =
nextIntValue, nextLongValue and nextStringValue methods, with =
implementations that achieve their goal in a straightforward fashion. =
AbstractDataFieldMaxValueIncrementer delegates all three to getNextKey =
which returns a long, casting the long to an int respectively converting =
it to a string with optional padding.
=20
This should still cover all current usages and therefore not break =
compatibility, and it should make it as easy as possible to implement an =
AbstractDataFieldMaxValueIncrementer subclass for a specific database. =
Thomas, Dmitrity, what do you think?
=20
Juergen
=20
P.S.:
Obviously, 1.0 RC2 won't be released tonight but rather at the end of =
the week. I believe it's worth it, as I'd also like to wait for feedback =
on the other recent changes.
=20

RE: [Springframework-developer] Suggestion: Generic BeanFactoryPostProcessor for registering custom PropertyEditors

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

That indeed sounds useful. However, specifying the class name is often =
not enough, as you might have to customize the editor instance. Of =
course, you can do that in code, i.e. your own BeanFactoryPostProcessor =
implementation.

A generic CustomEditorConfigurer could take a map with editor instances =
as values to achieve the same for simple enough editors. As the editors =
won't be needed otherwise, it would be convenient to define them as =
inner beans:

<bean id=3D"customEditorConfigurer"
      =
class=3D"org.springframework.beans.factory.config.CustomEditorConfigurer"=
>
  <property name=3D"customEditors">
    <map>
      <entry key=3D"java.util.Date">
        <bean class=3D"com.acme.MyCustomDateEditor"/></bean>
      </entry>
      <entry key=3D"mypackage.MyObject">
        <bean id=3D"myEditor" class=3D"mypackage.MyEditor">
          <property name=3D"myParam"><value>myValue</value></property>
        </bean>
      </entry>
    </map>
  </property>
</bean>

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Daniel Potter
Sent: Wednesday, February 25, 2004 5:01 PM
To: spr...@li...
Subject: [Springframework-developer] Suggestion: Generic
BeanFactoryPostProcessor for registering custom PropertyEditors


I'd like to suggest adding a convenience BeanFactoryPostProcessor
implementation to org.springframework.beans.factory.config to register
custom PropertyEditors.  This seems like a very common need and an easy
addition.  Maybe something like:

<bean id=3D"customEditorConfigurer"
      =
class=3D"org.springframework.beans.factory.config.CustomEditorConfigurer"=
>
  <property name=3D"customEditors">
    <map>
      <entry key=3D"java.util.Date">
        <value>com.acme.MyCustomDateEditor</value>i
      </entry>
    </map>
  </property>
</bean>

The CustomEditorConfigurer bean would just iterate over the map entries
and call beanFactory.registerCustomerEditor() for each using the
specified property class and custom editor.

Seems like a simple and useful addition to the core framework.

Any thoughts?
Daniel


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

[Springframework-developer] Suggestion: Generic BeanFactoryPostProcessor for registering custom PropertyEditors

[Daniel P. <po...@ci...>]

I'd like to suggest adding a convenience BeanFactoryPostProcessor
implementation to org.springframework.beans.factory.config to register
custom PropertyEditors.  This seems like a very common need and an easy
addition.  Maybe something like:

<bean id="customEditorConfigurer"
      class="org.springframework.beans.factory.config.CustomEditorConfigurer">
  <property name="customEditors">
    <map>
      <entry key="java.util.Date">
        <value>com.acme.MyCustomDateEditor</value>i
      </entry>
    </map>
  </property>
</bean>

The CustomEditorConfigurer bean would just iterate over the map entries
and call beanFactory.registerCustomerEditor() for each using the
specified property class and custom editor.

Seems like a simple and useful addition to the core framework.

Any thoughts?
Daniel

Re: [Springframework-developer] JdbcTemplate.update

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

Thomas,

I've checked in those changes to the execute(String) and update(String)
methods of JdbcTemplate.  I also updated the JdbcTemplateTestSuite, since
the change to 'update' caused its mock-behaivior to change.

Keith

----- Original Message -----=20
From: <tri...@tr...>
To: <spr...@li...>
Sent: Wednesday, February 25, 2004 8:11 AM
Subject: Re: [Springframework-developer] JdbcTemplate.update


>
> I can't see any reason for using a prepared stetement rather than a
statement if
> there aren't any bind parameters.  I'm OK with changing this to a
> Statement.executeUpdate(sql).
>
> Thomas
>
>
> Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:
>
> > Thomas, everybody,
> >
> > Any reason why JdbcTemplate's update(sql) method uses a
> > PreparedStatement without bind parameters? To be consistent with the
> > query methods that take static SQL, update(sql) should really use a
> > plain Statement...
> >
> > BTW, Keith and me are currently refining the use of native JDBC
> > extraction in JdbcTemplate: This just makes sense when application co=
de
> > will touch - and potentially cast - JDBC objects like PreparedStateme=
nts
> > or ResultSets. Thus, it isn't necessary for execute(sql) or update(sq=
l).
> >
> > Juergen
> >
> >
> > -------------------------------------------------------
> > 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-develope=
r
> >
>
>
>
>
>
> -------------------------------------------------------
> 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] JdbcTemplate.update

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

I can't see any reason for using a prepared stetement rather than a statement if
there aren't any bind parameters.  I'm OK with changing this to a
Statement.executeUpdate(sql).

Thomas


Quoting "jürgen höller [werk3AT]" <jue...@we...>:

> Thomas, everybody,
> 
> Any reason why JdbcTemplate's update(sql) method uses a 
> PreparedStatement without bind parameters? To be consistent with the 
> query methods that take static SQL, update(sql) should really use a 
> plain Statement...
> 
> BTW, Keith and me are currently refining the use of native JDBC 
> extraction in JdbcTemplate: This just makes sense when application code 
> will touch - and potentially cast - JDBC objects like PreparedStatements 
> or ResultSets. Thus, it isn't necessary for execute(sql) or update(sql).
> 
> Juergen
> 
> 
> -------------------------------------------------------
> 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
> 

Re: [Springframework-developer] MethodInvoker change

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

Colin,
=20
You have a point there. My main intention was consistent naming within =
the framework: the AOP Invocation uses "getArgument" methods too; so =
does MessageSourceResolvable. I guess it's still worth the change; after =
all, there won't be too many users that pass arguments into =
MethodInvokingFactoryBean at this point of time.
=20
I generally believe that consistency within a framework is an underrated =
value. We're certainly far ahead of other frameworks in that respect, =
and also in terms of proper javadoc. I consider this part of Spring's =
value proposition: In all the areas that Spring addresses you'll find =
consistent patterns and consistent naming.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mi 25.02.2004 05:17
An: spr...@li...
Betreff: [Springframework-developer] MethodInvoker change



Juergen,

Further to this, I noticed you changed the 'args' property to =
'arguments'. For me personally this is not that big a deal (I've alrady =
made the change in my configs), but do you think it's really worth =
breaking backwards compatibility for this? Args is a well known and used =
abbreviation for arguments. I wouldn't say the latter is so much better =
than the former that it's worth breaking people's config, now that the =
code already shipped with the name args...

Regards,
Colin



j=FCrgen h=F6ller [werk3AT] wrote:

>Good point - I'll re-add "staticMethod" as convenience setter!
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von Colin Sampaleanu
>Gesendet: Do 19.02.2004 21:54
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Quartz support
>
>
>
>Hey Juergen,
>
>The Quartz stuff looks like good stuff on an initial lookover.
>
>I do have a comment about your refactoring of =
MethodInvokingFactoryBean.
>
>For the static method call case, your refactoring is arguably cleaner
>because the same property is used for specifyng the method name as for
>the non-static case, but on the other hand, static methods are probably
>one of the most common uses of this class, and you've turned a one
>property config into a two property config, i.e.
>  <bean id=3D"qa-util-initProfileImpl"
>class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryB=
ean">
>    <property
>name=3D"staticMethod"><value>com.whatever.qaserver.device.ProfileClasses=
Init.initProfileClasses</value></property>
>  </bean>
>tnow becomes
>  <bean id=3D"qa-util-initProfileImpl"
>class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryB=
ean">
>    <property
>name=3D"targetMethod"><value>initProfileClasses</value></property>
>    <property
>name=3D"targetClass"><value>com.whatever.qaserver.device.ProfileClassesI=
nit</value></property>
>  </bean>
>
>As well, this also breaks backwards compatibility for anybody using it.
>Perhaps you can add back the
>  staticMethod
>property, and on a set, the code inside it would break up the supplied
>string into calls to setTargetMethod and setTargetClass (it would have
>to create the class itself).
>
>This would allow both forms to be used, and keep backwards =
compatibility...
>
>Regards,
>Colin
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
>=20
>
>>The Quartz support is already in CVS, and also in use within the =
werk3AT app it was intended for... feel free to check it out!
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>>Gesendet: Do 19.02.2004 16:54
>>An: spr...@li...
>>Betreff: RE: [Springframework-developer] Quartz support
>>
>>
>>
>>Daniel,
>>
>>As you say, this is most likely caused by the fact that Quartz uses =
its own threads. WebSphere seems to associate the JNDI context =
information with container-managed threads; unfortunately, this does not =
apply to Quartz threads.
>>
>>However, there's a strategy that should work: pre-locate the JNDI =
objects, and pass the objects to Quartz' job data map. This way, the =
Quartz job should receive the pre-located objects when running in its =
own thread, not needing to do a JNDI lookup itself.
>>
>>The Quartz support classes (to be committed within an hour!) provide =
the following:
>>
>>- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to =
register JobDetails, Calendars and Triggers with it
>>
>>- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger =
that allow for easy bean-style usage; the latter allow for implicit =
registration of an associated JobDetail
>>
>>- a FactoryBean for a JobDetail that invokes a method of an existing =
object, to avoid the need for writing one-line Job implementations that =
just delegate to a business method
>>
>>- a convenience implementation of Quartz' Job interface, applying job =
data map entries as bean properties
>>
>>A configuration example:
>>
>>       <bean id=3D"scheduler" =
class=3D"org.springframework.scheduling.quartz.SchedulerFactoryBean">
>>               <property name=3D"triggers">
>>                       <list>
>>                               <ref bean=3D"myTrigger1"/>
>>                               <ref bean=3D"myTrigger2"/>
>>                       </list>
>>               </property>
>>       </bean>
>>
>>       <bean id=3D"myJobDetail1" =
class=3D"org.springframework.scheduling.quartz.JobDetailBean">
>>               <property =
name=3D"jobClass"><value>werk3.example.MyJob</value></property>
>>               <property name=3D"jobDataAsMap">
>>                       <map>
>>                               <entry key=3D"testBean">
>>                                       <bean =
class=3D"org.springframework.beans.TestBean">
>>                                               <property =
name=3D"age"><value>99</value></property>
>>                                       </bean>
>>                               </entry>
>>                       </map>
>>               </property>
>>       </bean>
>>
>>       <bean id=3D"myJobDetail2" =
class=3D"org.springframework.scheduling.quartz.MethodInvokingJobDetailFac=
toryBean">
>>               <property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
>>               <property =
name=3D"targetMethod"><value>doSomething</value></property>
>>       </bean>
>>
>>       <bean id=3D"myTrigger1" =
class=3D"org.springframework.scheduling.quartz.CronTriggerBean">
>>               <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail1"/></property>
>>               <property name=3D"cronExpression"><value>0/5 * * * * =
?</value></property>
>>       </bean>
>>
>>       <bean id=3D"myTrigger2" =
class=3D"org.springframework.scheduling.quartz.SimpleTriggerBean">
>>               <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail2"/></property>
>>               <property =
name=3D"repeatInterval"><value>1000</value></property>
>>       </bean>
>>
>>MyJob (as referenced from "myJobDetail1") can be implemented as =
follows:
>>
>>       public static class MyJob extends QuartzJobBean {
>>
>>               private TestBean testBean;
>>
>>               public void setTestBean(TestBean testBean) {
>>                       this.testBean =3D testBean;
>>               }
>>
>>               protected void executeInternal(JobExecutionContext =
jobExecutionContext) {
>>                       System.out.println("Executing job..." + =
testBean.getAge());
>>               }
>>       }
>>
>>Note that the "testBean" entry in the job data map is automatically =
applied as bean property in MyJob.
>>
>>As a side note, I've refactored Colin's MethodInvokingFactoryBean into =
org.springframework.util.MethodInvoker, with MethodInvokingFactoryBean =
and MethodInvokingJobDetailFactoryBean as subclasses. They provide =
exactly the same invocation capabilities.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On =
Behalf
>>Of Daniel Potter
>>Sent: Thursday, February 19, 2004 4:17 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Quartz support
>>
>>
>>Juergen,
>>I have a question regarding these classes and/or your general =
experience
>>using Quartz with Spring in an J2EE container.  We've run into JNDI
>>lookup issues with jobs that attempt to use Spring beans that contain
>>references to JNDI resources (thru a JndiObjectFactoryBean).  It =
appears
>>the Quartz job doesn't know it's running within the container (even
>>though the scheduler is started in the init() method of a servlet), so =
it's
>>dependencies fail to locate the default JNDI context (and therefore =
fail
>>to locate their JNDI dependencies).  I assume this is because the
>>scheduler is running in its own thread, so it doesn't have any =
implicit
>>knowledge of the container.  To get around this, we've been
>>forced to use a separate Spring config file for the Quartz jobs that
>>overrides the default JNDI settings used by the JndiObjectFactoryBean
>>like this (as if the job had to connect to JNDI remotely):
>>
>> <!-- JNDI connection information -->
>> <bean id=3D"myJndiTemplate"
>>class=3D"org.springframework.jndi.JndiTemplate">
>>   <property name=3D"environment">
>>     <props>
>>       <prop
>>key=3D"java.naming.factory.initial">com.ibm.websphere.naming.WsnInitial=
ContextFactory</prop>
>>       <prop
>>key=3D"java.naming.provider.url">iiop://localhost:9091</prop>
>>       <prop key=3D"java.naming.security.credentials">user</prop>
>>       <prop key=3D"java.naming.security.principal">pw</prop>
>>      </props>
>>    </property>
>> </bean>
>>
>> <!-- QUEUE CONNECTION FACTORY -->
>> <bean id=3D"jmsQueueConnectionFactory"
>>       class=3D"org.springframework.jndi.JndiObjectFactoryBean"
>>       lazy-init=3D"true">
>>   <property name=3D"inContainer">
>>       <value>false</value>
>>   </property>
>>   <property name=3D"jndiTemplate">
>>       <ref local=3D"myJndiTemplate"/>
>>   </property>
>>   <property name=3D"jndiName">
>>     <value>Example/QueueConnectionFactory</value>
>>   </property>
>> </bean>
>>
>>This also requires us to load a separate application context for the
>>Quartz jobs that uses these settings, rather than being able to share
>>the application context used by the rest of the application.
>>
>>Have you ever run into this issue?  Do your support classes get around
>>this somehow?
>>
>>Regards,
>>Daniel
>>
>>On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT] =
wrote:
>>
>>
>>  =20
>>
>>>Everybody,
>>>
>>>I've revived my Quartz support classes for Spring today. They emerged =
from a job scheduling consulting project I did in autumn 2003. We have =
concrete needs for this now at werk3AT, thus the revival: It's about =
quite simple cron-style scheduling of application jobs.
>>>
>>>The basic idea is to set up a Quartz Scheduler via a =
SchedulerFactoryBean, also allowing to register scheduled jobs there via =
a <list> of <refs> to ScheduledJobDefinition beans. A =
ScheduledJobDefinition is just a simple combination of a Quartz =
JobDetail and a Quartz Trigger.
>>>
>>>ScheduledJobDefinition bean implementations include:
>>>- DefaultScheduledJobDefinition, allowing to use any implementation =
of Quartz' Job interface with a declaratively configured job data map =
and cron trigger
>>>- MethodInvokingJobDefinition, allowing to specify a method of a =
Spring-managed bean to execute as job (completely declarative, without =
the need for implementing a custom Job object), with a cron trigger.
>>>
>>>Both job definition beans can link in a separate Quartz Trigger =
instance instead of a cron expression; DefaultScheduledJobDefinition can =
also link in a separate Quartz JobDetail instance instead of a job =
class.
>>>
>>>That's all there is: A simple declarative way of using Quartz within =
Spring. Typically no rescheduling or the like: All schedules are set up =
on context startup, defined as bean definitions. Of course, you can also =
fetch the Scheduler instance and perform any custom scheduling, instead =
of using preconfigured ScheduledJobDefinition beans.
>>>
>>>The typical usage scenario are low-level jobs within an application, =
like data synchronization or storage cleanup - all predefined jobs that =
are just customized by an administrator. Fits nicely into Spring's =
application context model; most jobs will simply delegate to =
Spring-managed business objects.
>>>
>>>I expect to have this polished by the end of the week, as we need it =
at werk3AT quite urgently. I'd like to include this already in Spring =
1.0 final, as it's just 6 pretty simple classes (yes, I know - feature =
freeze - never mind ;-). The main question is where to put it: I suggest =
"org.springframework.scheduling.quartz".
>>>
>>>If there are no general objections, I'll commit it by the end of this =
week, for review within the next week - still plenty of time before 1.0 =
final ;-) Looking forward to your feedback!
>>>
>>>Juergen
>>>=20
>>>    =20
>>>




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

[Springframework-developer] MethodInvoker change

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

Juergen,

Further to this, I noticed you changed the 'args' property to 'arguments'. For me personally this is not that big a deal (I've alrady made the change in my configs), but do you think it's really worth breaking backwards compatibility for this? Args is a well known and used abbreviation for arguments. I wouldn't say the latter is so much better than the former that it's worth breaking people's config, now that the code already shipped with the name args...

Regards,
Colin



jürgen höller [werk3AT] wrote:

>Good point - I'll re-add "staticMethod" as convenience setter!
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Do 19.02.2004 21:54
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Quartz support
>
>
>
>Hey Juergen,
>
>The Quartz stuff looks like good stuff on an initial lookover.
>
>I do have a comment about your refactoring of MethodInvokingFactoryBean.
>
>For the static method call case, your refactoring is arguably cleaner
>because the same property is used for specifyng the method name as for
>the non-static case, but on the other hand, static methods are probably
>one of the most common uses of this class, and you've turned a one
>property config into a two property config, i.e.
>  <bean id="qa-util-initProfileImpl"
>class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
>    <property
>name="staticMethod"><value>com.whatever.qaserver.device.ProfileClassesInit.initProfileClasses</value></property>
>  </bean>
>tnow becomes
>  <bean id="qa-util-initProfileImpl"
>class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
>    <property
>name="targetMethod"><value>initProfileClasses</value></property>
>    <property
>name="targetClass"><value>com.whatever.qaserver.device.ProfileClassesInit</value></property>
>  </bean>
>
>As well, this also breaks backwards compatibility for anybody using it.
>Perhaps you can add back the
>  staticMethod
>property, and on a set, the code inside it would break up the supplied
>string into calls to setTargetMethod and setTargetClass (it would have
>to create the class itself).
>
>This would allow both forms to be used, and keep backwards compatibility...
>
>Regards,
>Colin
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>The Quartz support is already in CVS, and also in use within the werk3AT app it was intended for... feel free to check it out!
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
>>Gesendet: Do 19.02.2004 16:54
>>An: spr...@li...
>>Betreff: RE: [Springframework-developer] Quartz support
>>
>>
>>
>>Daniel,
>>
>>As you say, this is most likely caused by the fact that Quartz uses its own threads. WebSphere seems to associate the JNDI context information with container-managed threads; unfortunately, this does not apply to Quartz threads.
>>
>>However, there's a strategy that should work: pre-locate the JNDI objects, and pass the objects to Quartz' job data map. This way, the Quartz job should receive the pre-located objects when running in its own thread, not needing to do a JNDI lookup itself.
>>
>>The Quartz support classes (to be committed within an hour!) provide the following:
>>
>>- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to register JobDetails, Calendars and Triggers with it
>>
>>- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger that allow for easy bean-style usage; the latter allow for implicit registration of an associated JobDetail
>>
>>- a FactoryBean for a JobDetail that invokes a method of an existing object, to avoid the need for writing one-line Job implementations that just delegate to a business method
>>
>>- a convenience implementation of Quartz' Job interface, applying job data map entries as bean properties
>>
>>A configuration example:
>>
>>       <bean id="scheduler" class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
>>               <property name="triggers">
>>                       <list>
>>                               <ref bean="myTrigger1"/>
>>                               <ref bean="myTrigger2"/>
>>                       </list>
>>               </property>
>>       </bean>
>>
>>       <bean id="myJobDetail1" class="org.springframework.scheduling.quartz.JobDetailBean">
>>               <property name="jobClass"><value>werk3.example.MyJob</value></property>
>>               <property name="jobDataAsMap">
>>                       <map>
>>                               <entry key="testBean">
>>                                       <bean class="org.springframework.beans.TestBean">
>>                                               <property name="age"><value>99</value></property>
>>                                       </bean>
>>                               </entry>
>>                       </map>
>>               </property>
>>       </bean>
>>
>>       <bean id="myJobDetail2" class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean">
>>               <property name="targetObject"><ref bean="exampleService"/></property>
>>               <property name="targetMethod"><value>doSomething</value></property>
>>       </bean>
>>
>>       <bean id="myTrigger1" class="org.springframework.scheduling.quartz.CronTriggerBean">
>>               <property name="jobDetail"><ref bean="myJobDetail1"/></property>
>>               <property name="cronExpression"><value>0/5 * * * * ?</value></property>
>>       </bean>
>>
>>       <bean id="myTrigger2" class="org.springframework.scheduling.quartz.SimpleTriggerBean">
>>               <property name="jobDetail"><ref bean="myJobDetail2"/></property>
>>               <property name="repeatInterval"><value>1000</value></property>
>>       </bean>
>>
>>MyJob (as referenced from "myJobDetail1") can be implemented as follows:
>>
>>       public static class MyJob extends QuartzJobBean {
>>
>>               private TestBean testBean;
>>
>>               public void setTestBean(TestBean testBean) {
>>                       this.testBean = testBean;
>>               }
>>
>>               protected void executeInternal(JobExecutionContext jobExecutionContext) {
>>                       System.out.println("Executing job..." + testBean.getAge());
>>               }
>>       }
>>
>>Note that the "testBean" entry in the job data map is automatically applied as bean property in MyJob.
>>
>>As a side note, I've refactored Colin's MethodInvokingFactoryBean into org.springframework.util.MethodInvoker, with MethodInvokingFactoryBean and MethodInvokingJobDetailFactoryBean as subclasses. They provide exactly the same invocation capabilities.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Daniel Potter
>>Sent: Thursday, February 19, 2004 4:17 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Quartz support
>>
>>
>>Juergen,
>>I have a question regarding these classes and/or your general experience
>>using Quartz with Spring in an J2EE container.  We've run into JNDI
>>lookup issues with jobs that attempt to use Spring beans that contain
>>references to JNDI resources (thru a JndiObjectFactoryBean).  It appears
>>the Quartz job doesn't know it's running within the container (even
>>though the scheduler is started in the init() method of a servlet), so it's
>>dependencies fail to locate the default JNDI context (and therefore fail
>>to locate their JNDI dependencies).  I assume this is because the
>>scheduler is running in its own thread, so it doesn't have any implicit
>>knowledge of the container.  To get around this, we've been
>>forced to use a separate Spring config file for the Quartz jobs that
>>overrides the default JNDI settings used by the JndiObjectFactoryBean
>>like this (as if the job had to connect to JNDI remotely):
>>
>> <!-- JNDI connection information -->
>> <bean id="myJndiTemplate"
>>class="org.springframework.jndi.JndiTemplate">
>>   <property name="environment">
>>     <props>
>>       <prop
>>key="java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialContextFactory</prop>
>>       <prop
>>key="java.naming.provider.url">iiop://localhost:9091</prop>
>>       <prop key="java.naming.security.credentials">user</prop>
>>       <prop key="java.naming.security.principal">pw</prop>
>>      </props>
>>    </property>
>> </bean>
>>
>> <!-- QUEUE CONNECTION FACTORY -->
>> <bean id="jmsQueueConnectionFactory"
>>       class="org.springframework.jndi.JndiObjectFactoryBean"
>>       lazy-init="true">
>>   <property name="inContainer">
>>       <value>false</value>
>>   </property>
>>   <property name="jndiTemplate">
>>       <ref local="myJndiTemplate"/>
>>   </property>
>>   <property name="jndiName">
>>     <value>Example/QueueConnectionFactory</value>
>>   </property>
>> </bean>
>>
>>This also requires us to load a separate application context for the
>>Quartz jobs that uses these settings, rather than being able to share
>>the application context used by the rest of the application.
>>
>>Have you ever run into this issue?  Do your support classes get around
>>this somehow?
>>
>>Regards,
>>Daniel
>>
>>On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT] wrote:
>>
>>
>>    
>>
>>>Everybody,
>>>
>>>I've revived my Quartz support classes for Spring today. They emerged from a job scheduling consulting project I did in autumn 2003. We have concrete needs for this now at werk3AT, thus the revival: It's about quite simple cron-style scheduling of application jobs.
>>>
>>>The basic idea is to set up a Quartz Scheduler via a SchedulerFactoryBean, also allowing to register scheduled jobs there via a <list> of <refs> to ScheduledJobDefinition beans. A ScheduledJobDefinition is just a simple combination of a Quartz JobDetail and a Quartz Trigger.
>>>
>>>ScheduledJobDefinition bean implementations include:
>>>- DefaultScheduledJobDefinition, allowing to use any implementation of Quartz' Job interface with a declaratively configured job data map and cron trigger
>>>- MethodInvokingJobDefinition, allowing to specify a method of a Spring-managed bean to execute as job (completely declarative, without the need for implementing a custom Job object), with a cron trigger.
>>>
>>>Both job definition beans can link in a separate Quartz Trigger instance instead of a cron expression; DefaultScheduledJobDefinition can also link in a separate Quartz JobDetail instance instead of a job class.
>>>
>>>That's all there is: A simple declarative way of using Quartz within Spring. Typically no rescheduling or the like: All schedules are set up on context startup, defined as bean definitions. Of course, you can also fetch the Scheduler instance and perform any custom scheduling, instead of using preconfigured ScheduledJobDefinition beans.
>>>
>>>The typical usage scenario are low-level jobs within an application, like data synchronization or storage cleanup - all predefined jobs that are just customized by an administrator. Fits nicely into Spring's application context model; most jobs will simply delegate to Spring-managed business objects.
>>>
>>>I expect to have this polished by the end of the week, as we need it at werk3AT quite urgently. I'd like to include this already in Spring 1.0 final, as it's just 6 pretty simple classes (yes, I know - feature freeze - never mind ;-). The main question is where to put it: I suggest "org.springframework.scheduling.quartz".
>>>
>>>If there are no general objections, I'll commit it by the end of this week, for review within the next week - still plenty of time before 1.0 final ;-) Looking forward to your feedback!
>>>
>>>Juergen
>>>  
>>>      
>>>

[Springframework-developer] Fw: [springframework - Help] RE: Support for IBATIS SqlMaps 2

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

So we have support for iBATIS SQL Maps 2 now :-)
=20
(was just about 3-4 hours work)
=20
Juergen
=20

________________________________

Von: SourceForge.net [mailto:no...@so...]
Gesendet: Mi 25.02.2004 01:30
An: no...@so...
Betreff: [springframework - Help] RE: Support for IBATIS SqlMaps 2




Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=3D2440421
By: jhoeller

On the occasion, I've just taken the time to add SQL Maps 2 support =
classes
:-) There's SqlMapClientFactoryBean/Template/Callback/Operastions now, =
plus
SqlMapClientDaoSupport.

Note that you can just use either SQL Maps 1.x or SQL Maps 2 in the same =
application.
Simply choose the corresponding Spring support classes when working with =
Spring.

It's already in CVS, and will be part of the upcoming RC2!

Juergen

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=3D250340

[Springframework-developer] JdbcTemplate.update

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

Thomas, everybody,
=20
Any reason why JdbcTemplate's update(sql) method uses a =
PreparedStatement without bind parameters? To be consistent with the =
query methods that take static SQL, update(sql) should really use a =
plain Statement...
=20
BTW, Keith and me are currently refining the use of native JDBC =
extraction in JdbcTemplate: This just makes sense when application code =
will touch - and potentially cast - JDBC objects like PreparedStatements =
or ResultSets. Thus, it isn't necessary for execute(sql) or update(sql).
=20
Juergen

[Springframework-developer] When Spring is going to support indexed property in FORM??????

[Anna C. <ac...@er...>]

WHEN SPRING COULD SUPPORT LIST, MAP IN WEB FORM BY USING SPRING:BIND
TAG??????


If it does, is it possible for someone giving me an example????


Please HELP!

Anna

[Springframework-developer] JMS brainstorming

[Ou, R. <Ro...@sa...>]

Hi all,

We currently have a project that does a lot of JMS messaging, and we =
desperately need an API to simplify the interface layer to JMS. I heard =
rumors that JMS support will be added to Spring 1.1, but we just can't =
wait that long. So I am thinking about doing something in the interim. =
Who knows, if it comes out good, maybe I can contribute the code back.

In Rod's book there is only a couple of pages that briefly touches upon =
JMS. I looked at the interface21 code, the JMS portion is also pretty =
simplistic. I understand Spring has evolved a lot since the interface21 =
days. So to all you experienced Spring'ers, if you were to add JMS =
support today, what would you do? I am still fairly new to Spring, so =
any suggestions and help are welcome.

Thanks,

Rong

[Springframework-developer] <null> tag

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

I've just added a <null> tag to our XML bean definition format, for =
explicitly denoting a Java null value. This is necessary because an =
empty "value" tag	will resolve to an empty String, which will not be =
resolved to a null value unless a special PropertyEditor does so. A =
recent feature request thus asked for such a <null> tag.

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

[Springframework-developer] LocalSessionFactoryBean configuration

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

Was on my todo list. I've just changed LocalSessionFactoryBean's =
configuration properties to org.springframework.core.io.Resource arrays =
as far as possible.
=20
There's still "mappingResources", expecting classpath locations, =
analogous to <mapping resource=3D"xxx"> entries in a Hibernate XML =
config file. But there's also "mappingLocations" now, taking any =
Resource path like "classpath:xxx" or "file:xxx" or =
"WEB-INF/mappings/xxx" in a web application context.
=20
The former "mappingResourceJars" is now called "mappingJarLocations", =
taking a Resource array too. Additionally, there's also =
"mappingDirectoryLocations" now, supporting Hibernate's =
config.addDirectory method, taking a Resource array too.
=20
LocalSessionFactoryBean's "configLocation" is now a Resource too instead =
of classpath String. This is unfortunately incompatible with =
"/hibernate.cfg.xml"-style classpath Strings, but hardly anyone is using =
that AFAIK (as it is preferable to keep the configuration in the Spring =
context), and it's easy to convert: "classpath:/hibernate.cfg.xml".
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag von =
Shishir K. Singh
Gesendet: Di 24.02.2004 07:05
An: spr...@li...
Betreff: RE: [Springframework-user] PropertyPlaceholderConfigurer bug



Can config.addJar(resourcePath) in LocalSessionFactoryBean.java be =
changed to accept File as an input parameter instead of String since the =
Configuration:addJar(String fileName) method in Hibernate 2.1.1 is =
deprecated

Thanks
Shishir=20

-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...] On Behalf Of =
j=FCrgen h=F6ller [werk3AT]
Sent: Monday, February 23, 2004 5:34 PM
To: spr...@li...
Subject: Re: [Springframework-user] PropertyPlaceholderConfigurer bug

It's already fixed in CVS, and even replaced with some new code in the =
meantime. We support a "type" argument for the "constructor-arg" tag =
now, thus that code had to be adapted anyway.

BTW, we're gonna do a quick 1.0 RC2 release this week, including those =
changes.

Juergen


________________________________

Von: spr...@li... im Auftrag von =
Nick Minutello
Gesendet: Fr 20.02.2004 02:42
An: spr...@li...
Betreff: RE: [Springframework-user] PropertyPlaceholderConfigurer bug





Here is a patch if you like.
-Nick



-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of =
nic...@bn...
Sent: 19 February 2004 13:03
To: spr...@li...
Subject: [Springframework-user] PropertyPlaceholderConfigurer bug





Ive found a bit of a buggette in PropertyPlaceholderConfigurer

I am getting a Concurrent modification Exception out of

protected void parseGenericArgumentValues(Properties props, Set gas)

The reason is that we are remove/adding to the collection rather than =
the iterator.

http://opensource.atlassian.com/projects/spring/secure/ViewIssue.jspa?ke
y=3DSPR-41


-Nick





This message and any attachments (the "message") is intended solely for =
the addressees and is confidential.
If you receive this message in error, please delete it and immediately =
notify the sender. Any use not in accord with its purpose, any =
dissemination or disclosure, either whole or partial, is prohibited =
except formal approval. The internet can not guarantee the integrity of =
this message.
BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable =
for the message if modified.

                ---------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses destinataires et =
sont confidentiels. Si vous recevez ce message par erreur, merci de le =
detruire et d'en avertir immediatement l'expediteur. Toute utilisation =
de ce message non conforme a sa destination, toute diffusion ou toute =
publication, totale ou partielle, est interdite, sauf autorisation =
expresse. L'internet ne permettant pas d'assurer l'integrite de ce =
message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce message, dans =
l'hypothese ou il aurait ete modifie.



-------------------------------------------------------
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-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user




-------------------------------------------------------
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_id438&op=3Dick
_______________________________________________
Springframework-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user


-------------------------------------------------------
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_id438&op=3Dick
_______________________________________________
Springframework-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user

Re: [Springframework-developer] Quartz support

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

I've added a demo of scheduling to the imagedb sample app today, =
illustrating how to execute a custom job/task respectively invoke an =
existing method in a scheduled fashion with Quartz or Timer. There are =
alternative "schedulingContext-quartz.xml" and =
"schedulingContext-timer.xml" files, to be activated via the =
"contextConfigLocation" entry in "web.xml".
=20
The custom job respectively task implementation takes a variety of =
parameters to generate a list of image names, write it to the log, and =
send it as email. So imagedb also servers as MailSender example now. In =
total, imagedb illustrates a variety of Spring functionality not covered =
in other sample apps: Velocity, LobHandler, Quartz/Timer, and =
MailSender.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Do 19.02.2004 23:26
An: spr...@li...
Betreff: Re: [Springframework-developer] Quartz support



As a little bonus, I've also added scheduling support classes for =
java.util.Timer :-) It's as similar as possible in concept to the Quartz =
support. Of course, it's quite limited in terms of scheduling options: =
delays and periods, that's all that Timer is capable of.

A configuration example:

 <bean id=3D"timer" =
class=3D"org.springframework.scheduling.timer.TimerFactoryBean">
  <property name=3D"scheduledTimerTasks">
   <list>
    <ref bean=3D"myScheduledTimerTask"/>
   </list>
  </property>
 </bean>

 <bean id=3D"myScheduledTimerTask" =
class=3D"org.springframework.scheduling.timer.ScheduledTimerTask">
  <property name=3D"timerTask"><ref bean=3D"myTimerTask"/></property>
  <property name=3D"delay"><value>1000</value></property>
  <property name=3D"period"><value>2000</value></property>
 </bean>

 <bean id=3D"myTimerTask" =
class=3D"org.springframework.scheduling.timer.MethodInvokingTimerTaskFact=
oryBean">
  <property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
  <property name=3D"targetMethod"><value>doSomething</value></property>
 </bean>

SchedulerTimerTask also supports a "fixedRate" property, deciding on =
Timer's schedule vs scheduleAtFixedRate. There's nothing else: For more =
demanding needs like cron expressions, choose Quartz.

BTW, the whole Timer support just took about two hours of development =
time ;-)

Juergen


________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Do 19.02.2004 22:09
An: spr...@li...
Betreff: Re: [Springframework-developer] Quartz support



Good point - I'll re-add "staticMethod" as convenience setter!


________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Do 19.02.2004 21:54
An: spr...@li...
Betreff: Re: [Springframework-developer] Quartz support



Hey Juergen,

The Quartz stuff looks like good stuff on an initial lookover.

I do have a comment about your refactoring of MethodInvokingFactoryBean.

For the static method call case, your refactoring is arguably cleaner
because the same property is used for specifyng the method name as for
the non-static case, but on the other hand, static methods are probably
one of the most common uses of this class, and you've turned a one
property config into a two property config, i.e.
  <bean id=3D"qa-util-initProfileImpl"
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
    <property
name=3D"staticMethod"><value>com.whatever.qaserver.device.ProfileClassesI=
nit.initProfileClasses</value></property>
  </bean>
tnow becomes
  <bean id=3D"qa-util-initProfileImpl"
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
    <property
name=3D"targetMethod"><value>initProfileClasses</value></property>
    <property
name=3D"targetClass"><value>com.whatever.qaserver.device.ProfileClassesIn=
it</value></property>
  </bean>

As well, this also breaks backwards compatibility for anybody using it.
Perhaps you can add back the
  staticMethod
property, and on a set, the code inside it would break up the supplied
string into calls to setTargetMethod and setTargetClass (it would have
to create the class itself).

This would allow both forms to be used, and keep backwards =
compatibility...

Regards,
Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>The Quartz support is already in CVS, and also in use within the =
werk3AT app it was intended for... feel free to check it out!
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>Gesendet: Do 19.02.2004 16:54
>An: spr...@li...
>Betreff: RE: [Springframework-developer] Quartz support
>
>
>
>Daniel,
>
>As you say, this is most likely caused by the fact that Quartz uses its =
own threads. WebSphere seems to associate the JNDI context information =
with container-managed threads; unfortunately, this does not apply to =
Quartz threads.
>
>However, there's a strategy that should work: pre-locate the JNDI =
objects, and pass the objects to Quartz' job data map. This way, the =
Quartz job should receive the pre-located objects when running in its =
own thread, not needing to do a JNDI lookup itself.
>
>The Quartz support classes (to be committed within an hour!) provide =
the following:
>
>- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to =
register JobDetails, Calendars and Triggers with it
>
>- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger =
that allow for easy bean-style usage; the latter allow for implicit =
registration of an associated JobDetail
>
>- a FactoryBean for a JobDetail that invokes a method of an existing =
object, to avoid the need for writing one-line Job implementations that =
just delegate to a business method
>
>- a convenience implementation of Quartz' Job interface, applying job =
data map entries as bean properties
>
>A configuration example:
>
>        <bean id=3D"scheduler" =
class=3D"org.springframework.scheduling.quartz.SchedulerFactoryBean">
>                <property name=3D"triggers">
>                        <list>
>                                <ref bean=3D"myTrigger1"/>
>                                <ref bean=3D"myTrigger2"/>
>                        </list>
>                </property>
>        </bean>
>
>        <bean id=3D"myJobDetail1" =
class=3D"org.springframework.scheduling.quartz.JobDetailBean">
>                <property =
name=3D"jobClass"><value>werk3.example.MyJob</value></property>
>                <property name=3D"jobDataAsMap">
>                        <map>
>                                <entry key=3D"testBean">
>                                        <bean =
class=3D"org.springframework.beans.TestBean">
>                                                <property =
name=3D"age"><value>99</value></property>
>                                        </bean>
>                                </entry>
>                        </map>
>                </property>
>        </bean>
>
>        <bean id=3D"myJobDetail2" =
class=3D"org.springframework.scheduling.quartz.MethodInvokingJobDetailFac=
toryBean">
>                <property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
>                <property =
name=3D"targetMethod"><value>doSomething</value></property>
>        </bean>
>
>        <bean id=3D"myTrigger1" =
class=3D"org.springframework.scheduling.quartz.CronTriggerBean">
>                <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail1"/></property>
>                <property name=3D"cronExpression"><value>0/5 * * * * =
?</value></property>
>        </bean>
>
>        <bean id=3D"myTrigger2" =
class=3D"org.springframework.scheduling.quartz.SimpleTriggerBean">
>                <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail2"/></property>
>                <property =
name=3D"repeatInterval"><value>1000</value></property>
>        </bean>
>
>MyJob (as referenced from "myJobDetail1") can be implemented as =
follows:
>
>        public static class MyJob extends QuartzJobBean {
>
>                private TestBean testBean;
>
>                public void setTestBean(TestBean testBean) {
>                        this.testBean =3D testBean;
>                }
>
>                protected void executeInternal(JobExecutionContext =
jobExecutionContext) {
>                        System.out.println("Executing job..." + =
testBean.getAge());
>                }
>        }
>
>Note that the "testBean" entry in the job data map is automatically =
applied as bean property in MyJob.
>
>As a side note, I've refactored Colin's MethodInvokingFactoryBean into =
org.springframework.util.MethodInvoker, with MethodInvokingFactoryBean =
and MethodInvokingJobDetailFactoryBean as subclasses. They provide =
exactly the same invocation capabilities.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Daniel Potter
>Sent: Thursday, February 19, 2004 4:17 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Quartz support
>
>
>Juergen,
>I have a question regarding these classes and/or your general =
experience
>using Quartz with Spring in an J2EE container.  We've run into JNDI
>lookup issues with jobs that attempt to use Spring beans that contain
>references to JNDI resources (thru a JndiObjectFactoryBean).  It =
appears
>the Quartz job doesn't know it's running within the container (even
>though the scheduler is started in the init() method of a servlet), so =
it's
>dependencies fail to locate the default JNDI context (and therefore =
fail
>to locate their JNDI dependencies).  I assume this is because the
>scheduler is running in its own thread, so it doesn't have any implicit
>knowledge of the container.  To get around this, we've been
>forced to use a separate Spring config file for the Quartz jobs that
>overrides the default JNDI settings used by the JndiObjectFactoryBean
>like this (as if the job had to connect to JNDI remotely):
>
>  <!-- JNDI connection information -->
>  <bean id=3D"myJndiTemplate"
>class=3D"org.springframework.jndi.JndiTemplate">
>    <property name=3D"environment">
>      <props>
>        <prop
>key=3D"java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialC=
ontextFactory</prop>
>        <prop
>key=3D"java.naming.provider.url">iiop://localhost:9091</prop>
>        <prop key=3D"java.naming.security.credentials">user</prop>
>        <prop key=3D"java.naming.security.principal">pw</prop>
>       </props>
>     </property>
>  </bean>
>
>  <!-- QUEUE CONNECTION FACTORY -->
>  <bean id=3D"jmsQueueConnectionFactory"
>        class=3D"org.springframework.jndi.JndiObjectFactoryBean"
>        lazy-init=3D"true">
>    <property name=3D"inContainer">
>        <value>false</value>
>    </property>
>    <property name=3D"jndiTemplate">
>        <ref local=3D"myJndiTemplate"/>
>    </property>
>    <property name=3D"jndiName">
>      <value>Example/QueueConnectionFactory</value>
>    </property>
>  </bean>
>
>This also requires us to load a separate application context for the
>Quartz jobs that uses these settings, rather than being able to share
>the application context used by the rest of the application.
>
>Have you ever run into this issue?  Do your support classes get around
>this somehow?
>
>Regards,
>Daniel
>
>On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT] =
wrote:
>
>
>>Everybody,
>>
>>I've revived my Quartz support classes for Spring today. They emerged =
from a job scheduling consulting project I did in autumn 2003. We have =
concrete needs for this now at werk3AT, thus the revival: It's about =
quite simple cron-style scheduling of application jobs.
>>
>>The basic idea is to set up a Quartz Scheduler via a =
SchedulerFactoryBean, also allowing to register scheduled jobs there via =
a <list> of <refs> to ScheduledJobDefinition beans. A =
ScheduledJobDefinition is just a simple combination of a Quartz =
JobDetail and a Quartz Trigger.
>>
>>ScheduledJobDefinition bean implementations include:
>>- DefaultScheduledJobDefinition, allowing to use any implementation of =
Quartz' Job interface with a declaratively configured job data map and =
cron trigger
>>- MethodInvokingJobDefinition, allowing to specify a method of a =
Spring-managed bean to execute as job (completely declarative, without =
the need for implementing a custom Job object), with a cron trigger.
>>
>>Both job definition beans can link in a separate Quartz Trigger =
instance instead of a cron expression; DefaultScheduledJobDefinition can =
also link in a separate Quartz JobDetail instance instead of a job =
class.
>>
>>That's all there is: A simple declarative way of using Quartz within =
Spring. Typically no rescheduling or the like: All schedules are set up =
on context startup, defined as bean definitions. Of course, you can also =
fetch the Scheduler instance and perform any custom scheduling, instead =
of using preconfigured ScheduledJobDefinition beans.
>>
>>The typical usage scenario are low-level jobs within an application, =
like data synchronization or storage cleanup - all predefined jobs that =
are just customized by an administrator. Fits nicely into Spring's =
application context model; most jobs will simply delegate to =
Spring-managed business objects.
>>
>>I expect to have this polished by the end of the week, as we need it =
at werk3AT quite urgently. I'd like to include this already in Spring =
1.0 final, as it's just 6 pretty simple classes (yes, I know - feature =
freeze - never mind ;-). The main question is where to put it: I suggest =
"org.springframework.scheduling.quartz".
>>
>>If there are no general objections, I'll commit it by the end of this =
week, for review within the next week - still plenty of time before 1.0 =
final ;-) Looking forward to your feedback!
>>
>>Juergen
>>=20
>>



-------------------------------------------------------
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_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
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_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
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_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Velocity Tools

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

Velocity is not dead (just resting)... Seriously, I just got a reply from
Geir (the rapidity of which indicates how serious he still is about
Velocity).

Basically he was preoccupied with work last year, but is now actively moving
the project forward and looking at enhancements.

Some quotes:

>It's been dull lately because of my time and the fact that it does work
so well, but this month we will do v1.4, which has a bunch of stuff
we've been wanting to get out, 1.5 will follow soon after, which adds
some nice enhancements to VTL, and then we are adding a few major
things, like floating point support, et al immediately following.

>As much as I hate to suggest that it's a valid reason for looking at
it, it's getting more and more use (IDEA uses it...), there is 1 book
out on it, and a second coming, etc.  Yes, there are warts, but I'm
still 100% dedicated to it, although I have other things that dilute my
time, like we all do.

Regards,
Rod


----- Original Message -----
From: "Darren Davison" <da...@da...>
To: <spr...@li...>
Sent: Monday, February 23, 2004 10:52 AM
Subject: Re: [Springframework-developer] Velocity Tools


> In general, I wonder why the Velocity project is moving so slowly. It took
> them over half a year to move from 1.3.1 RC1 to 1.3.1 final. Velocity
> Tools 1.1 final could easily have been released last autumn: After all,
> it's just a couple of straightforward, pretty simple hellper classes. This
> definitely doesn't help in terms of Velocity adoption.

you're right.  In fact it has been remarked upon by less kind people that
Velocity is dead.  The site says they are working on a 1.5 branch but the
CVS repository shows very few changes to any source code in the last year.
 At the end of the day, it's not a major problem for most users.  It's a
stable tool that does a specific job fairly well - most of my tests
suggest it's still ahead of JSP in performance terms and the majority of
graphic designers (IME) prefer it to an xml-based sytax.

I think though that they may have lost some mindshare (if not some
developers) to FreeMarker.  On which note, if no-one else is intending to
do it, I'm planning on looking at a FreeMarker integration along similar
lines to the Velocity integration for Spring 1.1

Regards,

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



-------------------------------------------------------
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_id56&alloc_id438&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] remote invocation

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

Hi Vladimir,
=20
Good point. HTTP-based protocols like Hessian and Burlap can use =
additional HTTP headers here, and already support basic authentication =
out-of-the-box. Our RMI support does not yet support such additional =
parameters, as we haven't focussed on providing full-fledged remoting =
yet. However, this should be easy to incorporate, so I'll consider quick =
adoption of the approach you suggested!
=20
BTW, as of the upcoming 1.0 RC2, RmiServiceExporter supports custom =
socket factories (a recent feature request). This enables SSL-based RMI =
socket factories and the like; we might even provide own pre-built =
socket factories within the Spring 1.1 timeframe.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Vladimir Blagojevic
Gesendet: Mo 23.02.2004 16:31
An: spr...@li...
Betreff: [Springframework-developer] remote invocation



Hi,

I posted this question on help forum but maybe this list is a more
appropriate venue for the discussion.

It seems that there is no current built-in API to specify additional
invocation parameters. Here is why. RemoteInvocationWrapper is an object
that accepts remote calls and tunnels them to a wrapped service object.
RemoteInvocationWrapper is bound to Registry and has a specific =
signature
- public Object invokeRemote(String methodName, Class[] paramTypes,
Object[] params) - that is matched by RemoteInvocationHandler.
RemoteInvocationhandler on a client side is in turn wrapped by
RmiClientInterceptor which directs calls from client intereface to the
RemoteInvocationHandler. Very nice, except that invokeRemote signature.

I remember that in Jboss days the problem of additional invocation
parameters was solved by an abstract Invocation interface that had a
couple of predefined properties (method,paramTypes, params)as well as a
map for custom properties. So instead of the above mentioned method
signature you would pass a more abstract Invocation object from client =
to
server.

Then you can add custom interceptors on both client and server and
customize invocation with additional parameters. For example, a client
interceptor prior to marshalling invocation could strap on user's
Principal and a server interceptor could access that principal in a
matching interceptor on the server?

Any comments?

Regards,
Vladimir


-------------------------------------------------------
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] Velocity Tools

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

I've emailed Geir. But I'm all in favour of FreeMarker integration anyway. I
think it would be very easy.

----- Original Message -----
From: "Darren Davison" <da...@da...>
To: <spr...@li...>
Sent: Monday, February 23, 2004 10:52 AM
Subject: Re: [Springframework-developer] Velocity Tools


> In general, I wonder why the Velocity project is moving so slowly. It took
> them over half a year to move from 1.3.1 RC1 to 1.3.1 final. Velocity
> Tools 1.1 final could easily have been released last autumn: After all,
> it's just a couple of straightforward, pretty simple hellper classes. This
> definitely doesn't help in terms of Velocity adoption.

you're right.  In fact it has been remarked upon by less kind people that
Velocity is dead.  The site says they are working on a 1.5 branch but the
CVS repository shows very few changes to any source code in the last year.
 At the end of the day, it's not a major problem for most users.  It's a
stable tool that does a specific job fairly well - most of my tests
suggest it's still ahead of JSP in performance terms and the majority of
graphic designers (IME) prefer it to an xml-based sytax.

I think though that they may have lost some mindshare (if not some
developers) to FreeMarker.  On which note, if no-one else is intending to
do it, I'm planning on looking at a FreeMarker integration along similar
lines to the Velocity integration for Spring 1.1

Regards,

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



-------------------------------------------------------
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_id56&alloc_id438&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Velocity Tools

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

I know Geir Magnusson, I'll drop him an email asking about the status of
Velocity and let you know what he says.

I thought the issue was that Velocity basically worked...

----- Original Message -----
From: "Darren Davison" <da...@da...>
To: <spr...@li...>
Sent: Monday, February 23, 2004 10:52 AM
Subject: Re: [Springframework-developer] Velocity Tools


> In general, I wonder why the Velocity project is moving so slowly. It took
> them over half a year to move from 1.3.1 RC1 to 1.3.1 final. Velocity
> Tools 1.1 final could easily have been released last autumn: After all,
> it's just a couple of straightforward, pretty simple hellper classes. This
> definitely doesn't help in terms of Velocity adoption.

you're right.  In fact it has been remarked upon by less kind people that
Velocity is dead.  The site says they are working on a 1.5 branch but the
CVS repository shows very few changes to any source code in the last year.
 At the end of the day, it's not a major problem for most users.  It's a
stable tool that does a specific job fairly well - most of my tests
suggest it's still ahead of JSP in performance terms and the majority of
graphic designers (IME) prefer it to an xml-based sytax.

I think though that they may have lost some mindshare (if not some
developers) to FreeMarker.  On which note, if no-one else is intending to
do it, I'm planning on looking at a FreeMarker integration along similar
lines to the Velocity integration for Spring 1.1

Regards,

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



-------------------------------------------------------
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_id56&alloc_id438&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] remote invocation

[Vladimir B. <vla...@cs...>]

Hi,

I posted this question on help forum but maybe this list is a more
appropriate venue for the discussion.

It seems that there is no current built-in API to specify additional
invocation parameters. Here is why. RemoteInvocationWrapper is an object
that accepts remote calls and tunnels them to a wrapped service object.
RemoteInvocationWrapper is bound to Registry and has a specific signature
- public Object invokeRemote(String methodName, Class[] paramTypes,
Object[] params) - that is matched by RemoteInvocationHandler.
RemoteInvocationhandler on a client side is in turn wrapped by
RmiClientInterceptor which directs calls from client intereface to the
RemoteInvocationHandler. Very nice, except that invokeRemote signature.

I remember that in Jboss days the problem of additional invocation
parameters was solved by an abstract Invocation interface that had a
couple of predefined properties (method,paramTypes, params)as well as a
map for custom properties. So instead of the above mentioned method
signature you would pass a more abstract Invocation object from client to
server.

Then you can add custom interceptors on both client and server and
customize invocation with additional parameters. For example, a client
interceptor prior to marshalling invocation could strap on user's
Principal and a server interceptor could access that principal in a
matching interceptor on the server?

Any comments?

Regards,
Vladimir

Re: [Springframework-developer] Velocity Tools

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

Darren Davison wrote:

>>In general, I wonder why the Velocity project is moving so slowly. It took
>>them over half a year to move from 1.3.1 RC1 to 1.3.1 final. Velocity
>>Tools 1.1 final could easily have been released last autumn: After all,
>>it's just a couple of straightforward, pretty simple hellper classes. This
>>definitely doesn't help in terms of Velocity adoption.
>>    
>>
>
>you're right.  In fact it has been remarked upon by less kind people that
>Velocity is dead.  The site says they are working on a 1.5 branch but the
>CVS repository shows very few changes to any source code in the last year.
> At the end of the day, it's not a major problem for most users.  It's a
>stable tool that does a specific job fairly well - most of my tests
>suggest it's still ahead of JSP in performance terms and the majority of
>graphic designers (IME) prefer it to an xml-based sytax.
>
>I think though that they may have lost some mindshare (if not some
>developers) to FreeMarker.  On which note, if no-one else is intending to
>do it, I'm planning on looking at a FreeMarker integration along similar
>lines to the Velocity integration for Spring 1.1
>
>Regards,
>
>  
>
I know of a number of cases of people moving to Freemarker from Velocity.

Not a migration, but the OfBiz project has actually been using Velocity 
very successfully for their 3.0 stream, and has been very happy with it.

Regards,
Colin

RE: [Springframework-developer] Velocity Tools

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

I would be keen for spring to support freemarker in the same way that it
supports velocity.

Currently I been using the webwork2 freemarker servlet, though I would
prefer if it could configure everything from within spring, possibly =
even
creating a webwork2 result type that uses the freemarker integration =
that
spring will provide.

Cameron

> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of Darren Davison
> Sent: Monday, 23 February 2004 8:53 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Velocity Tools
>=20
> > In general, I wonder why the Velocity project is moving so=20
> slowly. It=20
> > took them over half a year to move from 1.3.1 RC1 to 1.3.1 final.=20
> > Velocity Tools 1.1 final could easily have been released=20
> last autumn:=20
> > After all, it's just a couple of straightforward, pretty simple=20
> > hellper classes. This definitely doesn't help in terms of=20
> Velocity adoption.
>=20
> you're right.  In fact it has been remarked upon by less kind=20
> people that Velocity is dead.  The site says they are working=20
> on a 1.5 branch but the CVS repository shows very few changes=20
> to any source code in the last year.
>  At the end of the day, it's not a major problem for most=20
> users.  It's a stable tool that does a specific job fairly=20
> well - most of my tests suggest it's still ahead of JSP in=20
> performance terms and the majority of graphic designers (IME)=20
> prefer it to an xml-based sytax.
>=20
> I think though that they may have lost some mindshare (if not some
> developers) to FreeMarker.  On which note, if no-one else is=20
> intending to do it, I'm planning on looking at a FreeMarker=20
> integration along similar lines to the Velocity integration=20
> for Spring 1.1
>=20
> Regards,
>=20
> --
> Darren Davison
> Public Key: http://www.davison.uk.net/key.jsp
>=20
>=20
>=20
> -------------------------------------------------------
> 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_id438&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20