springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Final preparations for 1.1 RC1

[Seth L. <set...@gm...>]

> I'm a bit unsure how copying macro definitions to app resource locations
> works in practice: presumably we can only do this once to avoid
> overwriting customizations made by the user?  How would we manage updates
> made to the macros inside spring.jar in future releases?  It just sounds a
> bit kludgy to me, but I'm probably missing an obvious benefit.
> 
> In my experience, the standard macros briefly outlined would be more
> useful - I guess if a  user really wanted to completely customize the
> macro set, s/he could manually take a copy from the Spring source and do
> so, but I'm definitely open to opinions here.

Some guidance here would be helpful.  I'm also unsure how this is
supposed to work.  I agree with Darren that if the user needs
something unconventional, it should be easy to generate their own
tags.  These convenience tags are so simple and so straight forward
that they should work for most people (especially if they allow XHTML
or HTML rendering).

Now that the nestedPath tag exists, I can submit our JSP 2.0 tagfiles
for the form elements.  I will also try to submit tag classes, for
those not using JSP 2.0.  Again, since the BindTag still exists, we're
not forcing people to use these tags just to get at variables.

Seth

RES: [Springframework-developer] Web services integration with Spring

[Rodrigo U. F. J. <rod...@us...>]

You can already do this,

Just copy the AxisServlet declaration to your web.xml

=20

And declare the services you want to export as following:

<service name=3D"OrderService" provider=3D"java:RPC">

  <parameter name=3D"allowedMethods" value=3D"*"/>

  <parameter name=3D"className"
value=3D"org.springframework.samples.jpetstore.service.server.JaxRpcOrder=
Servi
ce"/>

      <beanMapping qname=3D"jpetstore:Order" =
xmlns:jpetstore=3D"urn:JPetStore"
languageSpecificType=3D"java:org.springframework.samples.jpetstore.domain=
.Orde
r"/>

      <beanMapping qname=3D"jpetstore:LineItem"
xmlns:jpetstore=3D"urn:JPetStore"
languageSpecificType=3D"java:org.springframework.samples.jpetstore.domain=
.Line
Item"/>

      <beanMapping qname=3D"jpetstore:Item" =
xmlns:jpetstore=3D"urn:JPetStore"
languageSpecificType=3D"java:org.springframework.samples.jpetstore.domain=
.Item
"/>

      <beanMapping qname=3D"jpetstore:Product" =
xmlns:jpetstore=3D"urn:JPetStore"
languageSpecificType=3D"java:org.springframework.samples.jpetstore.domain=
.Prod
uct"/>

 </service>

=20

=20

where JaxRpcOrderService is a class that extends ServletEndpointSupport,

this is not like spring is exposing your beans automatically, but you =
have
access to your ApplicationContext from inside your Web Service what is =
cool
enough for me :-)

=20

=20

I hope that this help you

=20

-----Mensagem original-----
De: spr...@li...
[mailto:spr...@li...] Em nome =
de
Nimish Pachapurkar
Enviada em: segunda-feira, 19 de julho de 2004 14:24
Para: spr...@li...
Assunto: [Springframework-developer] Web services integration with =
Spring

=20

Hello,

=20

We have been using Spring for some projects for past 3 months

successfully. We are very impressed with the ease of use and

flexibility that Spring provides. Our current requirement is to have a

web service implemented through Spring. We feel that this would be a

better solution than using something like Axis directly. This way, we

can actually choose a different implementation without touching

majority of the code.

=20

Is web services one of the near future additions in Spring's road map?

If not, we would like to help design a set of web service interfaces

and at least one support package - possibly using Axis. I felt it is

better to get some input from the contributors before we actually

start work in this direction.

=20

Best regards,

--=20

Nimish

=20

=20

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

This SF.Net email is sponsored by BEA Weblogic Workshop

FREE Java Enterprise J2EE developer tools!

Get your free copy of BEA WebLogic Workshop 8.1 today.

http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick

_______________________________________________

Springframework-developer mailing list

Spr...@li...

https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Web services integration with Spring

[Tim C. <tc...@ta...>]

I'm kind of curious about this because I've implemented a webservice 
using Spring.
I'm not sure what that actually means though since the way that I've 
done it (using JBoss.net/Axis)
Is to just deploy a Session Bean along with a WSR that has the 
webservice definition.

So when I said that I am using webservice with Spring it's just that my 
Session bean is using Spring to Dependency Inject the stuff it needs. 
(DAOs etc)
Not really using Spring specifically for Web Services. After all, Axis 
does not require you're bean to have any webservice methods in it.

Now if you're talking about the client side code, It would be nice for 
Spring to allow dependency injection of a Web Service.
Which I don't know if it currently does. I am doing it in a different 
way (which is bad if Spring DOES have a way to handle web services 
already ;)

I have a Bean that is using a static implementation method that returns 
back the actual Web Service.
Example is:

    <bean id="nppDelegate" 
class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
        <property 
name="targetClass"><value>com.xxx.whatever.MyWebServiceFactory</value></property>
        <property 
name="targetMethod"><value>getWebServiceInstanceOrWhatever</value></property>
    </bean>

That allows me to still use Spring's dependency injection with a 
WebService bean.
-Tim

Nimish Pachapurkar wrote:

>Hello,
>
>We have been using Spring for some projects for past 3 months
>successfully. We are very impressed with the ease of use and
>flexibility that Spring provides. Our current requirement is to have a
>web service implemented through Spring. We feel that this would be a
>better solution than using something like Axis directly. This way, we
>can actually choose a different implementation without touching
>majority of the code.
>
>Is web services one of the near future additions in Spring's road map?
>If not, we would like to help design a set of web service interfaces
>and at least one support package - possibly using Axis. I felt it is
>better to get some input from the contributors before we actually
>start work in this direction.
>
>Best regards,
>  
>

Re: [Springframework-developer] Web services integration with Spring

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

Nimish,

Spring currently provides web-services type of remote access with 
support for several different protocols e.g. Caucho's Hessian and 
Burlap, RMI, JAX-RPC (Axis).

http://www.springframework.org/docs/reference/remoting.html

Regards,
Dmitriy.


Nimish Pachapurkar wrote:

>Hello,
>
>We have been using Spring for some projects for past 3 months
>successfully. We are very impressed with the ease of use and
>flexibility that Spring provides. Our current requirement is to have a
>web service implemented through Spring. We feel that this would be a
>better solution than using something like Axis directly. This way, we
>can actually choose a different implementation without touching
>majority of the code.
>
>Is web services one of the near future additions in Spring's road map?
>If not, we would like to help design a set of web service interfaces
>and at least one support package - possibly using Axis. I felt it is
>better to get some input from the contributors before we actually
>start work in this direction.
>
>Best regards,
>  
>

[Springframework-developer] Web services integration with Spring

[Nimish P. <ni...@gm...>]

Hello,

We have been using Spring for some projects for past 3 months
successfully. We are very impressed with the ease of use and
flexibility that Spring provides. Our current requirement is to have a
web service implemented through Spring. We feel that this would be a
better solution than using something like Axis directly. This way, we
can actually choose a different implementation without touching
majority of the code.

Is web services one of the near future additions in Spring's road map?
If not, we would like to help design a set of web service interfaces
and at least one support package - possibly using Axis. I felt it is
better to get some input from the contributors before we actually
start work in this direction.

Best regards,
-- 
Nimish

Re: Re: [Springframework-developer] Portlet support status?

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

No problem.  It is already pretty far along...things you can do right now are package up a deployable Portlet in a .war file with a standard
Spring application context.  You can configure a PortletDispatcher and dispatch to Controllers and JSTL Views.

There is simple proof a concept app pacakged up at:
http://www.tnt-web.com/springportlet/

JSR-168 is still a bit too fresh...the portal frameworks are still working it in which has slowed us a down a bit...having to attend to production deployments in the very near term with legacy APIs.  I am hopeful we can start to bring more focus to Spring PortletMVC in the near term.

Cheers,
Bill


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

> Date: Mon Jul 19 07:39:30 EDT 2004
> From: "Rainer Schmitz" <Rai...@ab...>
> Reply-To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet support status?
> To: spr...@li...
>
> Thanks for the information, Bill. With my still somewhat limited 
> experience with portlets it seems best to wait until at least some 
> example code is published.
> 
> Rainer
> 
> William G Thompson Jr wrote:
> 
> > we are mostly at the same stage...which is a good base but still needs polish and good sample useage.  
> > 
> > with what is in the sandbox and the sample springportlet you can route portet modes to controllers and render via jstl using portlet tag lib all configured in a standard spring application context.
> > 
> > things remaining include:
> >   * convenience controllers
> >   * data binding
> >   * javadoc clean up
> >   * sample app
> > 
> > later.
> > Bill
> 
> 

Re: [Springframework-developer] Final preparations for 1.1 RC1

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

CVS will convert end of lines properly on checkin and checkout, 
appropriate to the platform being checked out on.

However, it is unable to handle the case where somebody creates or 
modifies a file on Windows (which has CR/LF at the end of lines), then 
mails it (or whtever) to somebody who then checks it in from a unix 
system. It will then appear in CVS with the CR still there since that 
system will not strip out the CR. Then when you subsequently check it 
out on the windows system, CVS will add another CR, so you end up with 
CRCRLF.

Colin

Darren Davison wrote:

>>Hi,
>>
>>    
>>
>>>- We need to adapt the source code formatting of the JMS
>>>support: I still see nasty empty lines after each code line
>>>on Windows: maybe Unix/Windows line feed differences?
>>>      
>>>
>>I'm not seeing this, if you show me how you are detecting this I can clean
>>it up.
>>    
>>
>
>The JMS files are using windows EOL markers (0A 0D) the other files use
>the Unix convention (0A).  You can verify by opening the files with any
>binary viewer (TextPad on Windows will do it, any Hex viewer on Unix/Linux
>will show it too).  I thought the CVS server should automatically convert
>to the Unix format..?
>
>I downloaded AbstractJmsTemplate.java and checked it with both TextPad on
>'doze and the nano editor (pico clone) on Linux; they formatted OK on both
>for me.  Emacs would probably show the JMS source as having ^M at the end
>of each line.
>
>
>  
>

Re: [Springframework-developer] Final preparations for 1.1 RC1

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

IntelliJ IDEA shows those extra lines. I checked the actual file =
contents with UltraEdit's hex editor: This clearly indicates 0D 0D 0A. =
I've told UltraEdit to convert to DOS format to get rid of those.

I've also applied my IDEA code style template for Spring and polished =
some javadocs, so I guess I'll simply commit the files as they are now. =
Let's check whether everyone sees appropriate line feeds then.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Darren Davison
Sent: Monday, July 19, 2004 5:18 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Final preparations for 1.1 RC1



> I've just checked that too: Actually, the JMS source files use 0D 0D =
0A -
> i.e. double carriage return. I've just converted them to 0D 0A, just =
like
> our other files have. I'll commit them in a second.

hmm.  That's odd - here's the first binary word from the
AbstractJmsTemplate file as I see it here (windows line-feed sequence
underlined):

2F 2A 0D 0A 20 2A 20 43 6F 70 79 72 69 67 68 74
      ^^^^^

which equates to the fragment:

/*
 * Copyright

Which editor are you using as it sounds like the problem may be there?  =
Is
it perhaps assuming a Unix file format without actually checking it?  If
so, it would automatically add 0D before each 0A it encountered - that
would certainly explain your 0D 0D 0A sequence!

--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Final preparations for 1.1 RC1

[<tho...@tr...>]

We had the same problem way back when we moved the codebase from com.interface12
to org.springframework.  That time it was because I moved Rod's Windows files
to a Linux box and did create the new project with these files without
stripping the '0D' character. The CVS client built into Eclipse seemed to mask
this problem but anybody using a regular CVS client did notice it.

Thomas


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

> I've just checked that too: Actually, the JMS source files use 0D 0D 0A =
> - i.e. double carriage return. I've just converted them to 0D 0A, just =
> like our other files have. I'll commit them in a second.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Darren Davison
> Sent: Monday, July 19, 2004 4:46 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Final preparations for 1.1 RC1
>
>
>
> > Hi,
> >
> >> - We need to adapt the source code formatting of the JMS
> >> support: I still see nasty empty lines after each code line
> >> on Windows: maybe Unix/Windows line feed differences?
> >
> > I'm not seeing this, if you show me how you are detecting this I can =
> clean
> > it up.
>
> The JMS files are using windows EOL markers (0A 0D) the other files use
> the Unix convention (0A).  You can verify by opening the files with any
> binary viewer (TextPad on Windows will do it, any Hex viewer on =
> Unix/Linux
> will show it too).  I thought the CVS server should automatically =
> convert
> to the Unix format..?
>
> I downloaded AbstractJmsTemplate.java and checked it with both TextPad =
> on
> 'doze and the nano editor (pico clone) on Linux; they formatted OK on =
> both
> for me.  Emacs would probably show the JMS source as having ^M at the =
> end
> of each line.
>
>
> --=20
> Darren Davison
> Public Key: http://www.davison.uk.net/pages/key.htm
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

RE: [Springframework-developer] Final preparations for 1.1 RC1

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

> I've just checked that too: Actually, the JMS source files use 0D 0D 0A=
 -
> i.e. double carriage return. I've just converted them to 0D 0A, just li=
ke
> our other files have. I'll commit them in a second.

hmm.  That's odd - here's the first binary word from the
AbstractJmsTemplate file as I see it here (windows line-feed sequence
underlined):

2F 2A 0D 0A 20 2A 20 43 6F 70 79 72 69 67 68 74
      ^^^^^

which equates to the fragment:

/*
 * Copyright

Which editor are you using as it sounds like the problem may be there?  I=
s
it perhaps assuming a Unix file format without actually checking it?  If
so, it would automatically add 0D before each 0A it encountered - that
would certainly explain your 0D 0D 0A sequence!

--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm

RE: [Springframework-developer] Final preparations for 1.1 RC1

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

I've just checked that too: Actually, the JMS source files use 0D 0D 0A =
- i.e. double carriage return. I've just converted them to 0D 0A, just =
like our other files have. I'll commit them in a second.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Darren Davison
Sent: Monday, July 19, 2004 4:46 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Final preparations for 1.1 RC1



> Hi,
>
>> - We need to adapt the source code formatting of the JMS
>> support: I still see nasty empty lines after each code line
>> on Windows: maybe Unix/Windows line feed differences?
>
> I'm not seeing this, if you show me how you are detecting this I can =
clean
> it up.

The JMS files are using windows EOL markers (0A 0D) the other files use
the Unix convention (0A).  You can verify by opening the files with any
binary viewer (TextPad on Windows will do it, any Hex viewer on =
Unix/Linux
will show it too).  I thought the CVS server should automatically =
convert
to the Unix format..?

I downloaded AbstractJmsTemplate.java and checked it with both TextPad =
on
'doze and the nano editor (pico clone) on Linux; they formatted OK on =
both
for me.  Emacs would probably show the JMS source as having ^M at the =
end
of each line.


--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Final preparations for 1.1 RC1

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

> Hi,
>
>> - We need to adapt the source code formatting of the JMS
>> support: I still see nasty empty lines after each code line
>> on Windows: maybe Unix/Windows line feed differences?
>
> I'm not seeing this, if you show me how you are detecting this I can cl=
ean
> it up.

The JMS files are using windows EOL markers (0A 0D) the other files use
the Unix convention (0A).  You can verify by opening the files with any
binary viewer (TextPad on Windows will do it, any Hex viewer on Unix/Linu=
x
will show it too).  I thought the CVS server should automatically convert
to the Unix format..?

I downloaded AbstractJmsTemplate.java and checked it with both TextPad on
'doze and the nano editor (pico clone) on Linux; they formatted OK on bot=
h
for me.  Emacs would probably show the JMS source as having ^M at the end
of each line.


--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm

Re: [Springframework-developer] Final preparations for 1.1 RC1

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

> No problem - let's add those for 1.1 final or even 1.1.1, whenever they
> are ready. Do you in principle envisage copying Velocity/FreeMarker mac=
ros
> to the user's resource loader path, to allow for easy customization?

it hadn't been my original intention, but then again I havn't really spen=
t
time thinking about it either :)  Originally I'd expected to make all the
macros standard but parameterisable, building on the binding ability just
added.  The html output would work without modification and a parameter
could be passed to the macro to customize the html.  Something like;

#macro (springTextInput $htmlAttributes)
  ## assume bind already performed
  <input
    type=3D"text"
    name=3D"${status.expression}"
    value=3D"$!status.value"
    $htmlAttributes
  #if ($xhtmlCompliant) "/>" #else ">" #end
#end


The following VTL;

#springTextInput('style=3D"border: 1px solid silver" maxlength=3D"30"')

would output (if binding to a 'name' field);

<input
    type=3D"text"
    name=3D"name"
    value=3D"Darren Davison"
    style=3D"border: 1px solid silver" maxlength=3D"30"
>

Further conveniences like allowing default htmlAttributes (defined by the
user, not Spring) would clearly be simple to implement too.

The Struts guys have gone to the trouble of duplicating almost all of the
HTML 4.0.1 attribute set in their custom tags, which sounds to me like an
awful lot of copy/paste just to get a nice IDE integration!

If the convenience macros fail to meet some unusual requirement in the
html form, the user can always fall back to using the springBind macro an=
d
completely handcoding individual fields - or the entire html form - as
required (like you would have to do now with what's in CVS).

I'm a bit unsure how copying macro definitions to app resource locations
works in practice: presumably we can only do this once to avoid
overwriting customizations made by the user?  How would we manage updates
made to the macros inside spring.jar in future releases?  It just sounds =
a
bit kludgy to me, but I'm probably missing an obvious benefit.

In my experience, the standard macros briefly outlined would be more
useful - I guess if a  user really wanted to completely customize the
macro set, s/he could manually take a copy from the Spring source and do
so, but I'm definitely open to opinions here.

Regards,

--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm

RE: [Springframework-developer] Final preparations for 1.1 RC1

[Mark P. <mar...@co...>]

Hi,

> - We need to adapt the source code formatting of the JMS 
> support: I still see nasty empty lines after each code line 
> on Windows: maybe Unix/Windows line feed differences?

I'm not seeing this, if you show me how you are detecting this I can clean
it up.


I am comfortable with the end of the week timeframe for JMS.


Cheers,
Mark

Re: [Springframework-developer] Final preparations for 1.1 RC1

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

I personally don't like using the name interceptor for something that 
can be more than an interceptor. It can confuse people, and/or make them 
think it can't do something it can. On the other hand, given the legacy 
issues and lack of any clear solution, I agree that it's probably best 
to leave it as-is, maybe with more emphasis in the JavaDocs and regular 
documentation...

jürgen höller [werk3AT] wrote:

>As we just discussed on IM, I tend to agree :-) There is no convincing term for bean properties - "aspect" is not really perfect either -, so it's probably best to keep "interceptor".
>
>The remaining question is: Do we need to deprecate "addInterceptor" on AdvisedSupport? Quite a lot of people might just have a superficial grip on AOP at the MethodInterceptor level: For those, "addInterceptor" might be more natural, as they're not aware of the term "advice" or the superinterface Advice in the first place.
>
>We could also move "addInterceptor" down to ProxyFactory, as a convenience, rather than deprecating it in AdvisedSupport. Essentially, we need to find a good compromise, making stuff as easy to comprehend as possible from the user's perspective. Allowing users to just think about "interceptors" for working with MethodInterceptors might be part of that.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rod Johnson
>Sent: Monday, July 19, 2004 1:40 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1
>
>
>I'm not convinced that it's worth changing, especially as the change would
>obviously have quite an impact in the long term. The present use of
>"interceptor" in properties--e.g. "interceptorNames", is a bit misleading,
>as Interceptors, other Advices or Advisors can be used. However, such
>methods are *not* parallel to the addInterceptor/addAdvice methods on
>AdvisedSupport. addAdvice is more general than addInterceptor--e.g. you can
>add ThrowsAdvice as well as interceptors--but it doesn't support adding
>Advisors. The "interceptorNames" style properties support Advices (including
>Interceptors) and Advisors.
>
>It's hard to find a convincing name for the latter combination. It's
>essentially Object-typed. Thus the "interceptor" concept, while an
>implementation feature rather than AOP essential, seems as good as any.
>
>Rgds
>Rod
>
>----- Original Message -----
>From: "jürgen höller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Monday, July 19, 2004 11:36 AM
>Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1
>
>
>I forgot:
>
>- We need to get "advice" vs "interceptor" naming right, possibly using the
>term "aspect" if also covering advisors: in ProxyFactory, ProxyFactoryBean,
>TransactionProxyFactoryBean.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von
>jürgen höller [werk3AT]
>Gesendet: Mo 19.07.2004 11:29
>An: spr...@li...
>Betreff: [Springframework-developer] Final preparations for 1.1 RC1
>
>
>
>Everybody,
>
>Seems like we're finally ready for 1.1 RC1, already with full 1.1 scope:
>
>- Mark has provided a refined version of the JMS support
>- Thomas has already added support for JDBC-generated keys
>- Darren has committed bind support for Velocity and FreeMarker
>- Seth has contributed some tag refinements for JSP views.
>
>The remaining tasks that I see are:
>
>- We need to adapt the source code formatting of the JMS support: I still
>see nasty empty lines after each code line on Windows: maybe Unix/Windows
>line feed differences?
>
>- I'd like to review the source code of the final version of JMS support.
>Just about polishing and javadoc, as always before a release :-)
>
>- Thomas is already working on using a single API approach for
>JDBC-generated keys, including moving the classes to a different package.
>
>- I'd like to move BindStatus and the new BindStatusHelper class from
>servlet.tags to servlet.support. JSPs using the BindTag should still work,
>provided that they get freshly compiled. Any objections to this?
>
>- I'd like to refine resource loading in VelocityFormView and
>FreeMarkerFormView: This is not entirely clean when combined with custom
>resource paths yet, from a superficial glance.
>
>- We need to add Seth's NestedPathTag and include his BindTag refinements.
>I'll do this myself during the course of the week.
>
>All things considered, this means a release by the end of the week: Any
>earlier date would require dropping one of those tasks, which I don't think
>would be worth it. Thoughts?
>
>Finally, regarding form simplification macros, i.e. Struts-style HTML input
>tag wrappers: Do we already have something here, for either JSP 2.0,
>Velocity or FreeMarker?
>
>Juergen
>  
>

Re: [Springframework-developer] CachedIntrospectionResults

[Claudio D'A. <cla...@ob...>]

I understend.
But how can I save the application server from OutOfMemory or memory leak?
My first problem is that after 20 redeploy the sever must be restarted.

At 11.50 16/07/2004 -0400, you wrote:
>Claudio,
>
>I'm not completely sure to understand correctly your question, but I will 
>try to answer as best as I can.
>
>WeakHashMap is implemented with WeakReference for keys, and strong 
>reference for values.  That means if the value has a strong reference on 
>the key, then the key cannot be garbage collected until the WeakHashMap is 
>ready for collection.  However, if the value has no strong reference on 
>its key, then being in the WeakHashMap won't prevent the key and value 
>from being garbage collected if it is otherwise ready.  The WeakHashMap 
>knows when to remove the key (and the value with it) by using the 
>notification provided by the java.lang.ref package.  For more information 
>on this, see: 
><http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/package-summary.html>http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/package-summary.html
>
>So the problem here with the CachedIntrospectionResults is that it uses 
>BeanInfo and PropertyDescriptor that both have strong reference to the 
>class (indirectly by a reference on Methods of the class).  That will be 
>solved with JDK 1.5 that uses a combinaison of Weak and Soft Reference to 
>the Class and Method objects, but for 1.4.2, there's not really any better 
>solution than to flush the Introspector's cache and/or use WeakReference 
>on CachedIntrospectionResults. Using WeakReference on the 
>CachedIntrospectionResults is safer, but decrease performance, and in such 
>case a manual Instrospector.flushFromCaches(Class) must be used, so that 
>the Instrospector does not keep a strong reference on the BeanInfo.
>
>When a webapp is hot-redeployed, a new ClassLoader is created to load the 
>webapp, and the old one is thrown away, expected to be garbage 
>collected.  For the collection to happen, the server must clear any strong 
>reference to the ClassLoader or its classes, and also the webapp must make 
>sure that any code in parent ClassLoaders (or siblings) clear any 
>reference it might have to any of the webapp's class.
>
>Hopefully this answers your question, but if it does not (or if it's not 
>clear enough), please give me more details of what information you need.
>
>Regards,
>Guillaume
>
>
>Claudio D'Angelo wrote:
>>Thank's Guillaume.
>>I'm studing about the WeakHashMap and I've seen that WeakHashMap build a 
>>weak reference on the key (it's right??), when the key hasn't any 
>>reference the entity is removed by map.
>>
>>Spring use a class type to save the key. When the class object haven't 
>>any reference? When the Classloader is shutdown?
>>
>>Can you explain to me (or advise to me if exists an article or tutorial) 
>>about?
>>
>>Thanks,
>>  Claudio
>>
>>
>>At 10.05 15/07/2004 -0400, you wrote:
>>>As Juergen pointed out, if you find a static member hasn't been garbage 
>>>collected, it just means its ClassLoader cannot be garbage collected 
>>>yet, the static member is not necessarly at fault there.  For an 
>>>explanation of the current behavior, see below.
>>>
>>>For the solution, you can use a ServletContextListener to call 
>>>java.beans.Introspector.flushCaches() when the ServletContext is detroy 
>>>(which causes the ClassLoader to be thrown away).
>>>
>>>>                 if (results == null) {
>>>>                         // can throw BeansException
>>>>                         results = new CachedIntrospectionResults(clazz);
>>>>                         boolean cacheSafe = isCacheSafe(clazz);
>>>>                         if (logger.isDebugEnabled()) {
>>>>                                 logger.debug("Class [" + 
>>>> clazz.getName() + "] is " + (!cacheSafe ? "not " : "") + "cache-safe");
>>>>                         }
>>>>                         classCache.put(clazz, new WeakReference(results));
>>>>                 }
>>>Since Spring 1.0.2, the current code of this method is the following :
>>>
>>>         if (results == null) {
>>>             // can throw BeansException
>>>             results = new CachedIntrospectionResults(clazz);
>>>             boolean cacheSafe = isCacheSafe(clazz);
>>>             if (logger.isDebugEnabled()) {
>>>                 logger.debug("Class [" + clazz.getName() + "] is " + 
>>> (!cacheSafe ? "not " : "") + "cache-safe");
>>>             }
>>>             if (cacheSafe) {
>>>                 classCache.put(clazz, results);
>>>             }
>>>             else {
>>>                 classCache.put(clazz, new WeakReference(results));
>>>             }
>>>         }
>>>
>>>What the isCacheSafe(Class) method does is check if the clazz's 
>>>ClassLoader is the
>>>same as CachedIntrospectionResults, or a parent of it.  Because what 
>>>prevent garbage
>>>collection of a ClassLoader A is if a class of a ClassLoader B that is 
>>>not for garbage
>>>collection has a reference on a class (or instance) of the ClassLoader 
>>>A.  However, if
>>>A is a parent of B (or B == A), then A cannot be collected 
>>>anyway.  Which is why if clazz
>>>is considered "cacheSafe", no WeakReference is necessary, and in such 
>>>case it improve
>>>performance.  For example, if the class introspected is a JDK class, or 
>>>a Spring class, its
>>>ClassLoader can never be collected before the CachedIntrospectionResults 
>>>class.
>>>
>>>>I don't understand about memory leak, weark or soft referance but I've 
>>>>see that CachedIntrospectionResults is referenced 
>>>>by  CachedIntrospectionResults.classCache and there are 2 instances 
>>>>(org.springframework.context.support.ResourceBundleMessageSource and 
>>>>org.springframework.web.servlet.DispatcherServlet)
>>>I don't know what causes the ClassLoader to be retained, but you cannot 
>>>easily know what is the cause, just knowning that singletons instances 
>>>are still in the JVM only proves that the ClassLoader has not been 
>>>garbage collected.  The problem is that something in a parent (or 
>>>sibling) ClassLoader still has a reference on a Class of your webapp's 
>>>ClassLoader.  The trick is to find what is.
>>>
>>>Guillaume
>>>
>>>Claudio D'Angelo wrote:
>>>>I've deployed the minimal application (see the spring's sample). There 
>>>>isn't Quarts, ibatis or hibernate. There is a controller with a test.jsp only.
>>>>
>>>>I don't understand about memory leak, weark or soft referance but I've 
>>>>see that CachedIntrospectionResults is referenced 
>>>>by  CachedIntrospectionResults.classCache and there are 2 instances 
>>>>(org.springframework.context.support.ResourceBundleMessageSource and 
>>>>org.springframework.web.servlet.DispatcherServlet)
>>>>
>>>>
>>>>Where I can call the java.beans.Introspector.flushCaches()?
>>>>
>>>>Please help. After 20 redeploy Tomcat goes in OutOfMemory and ELS craches
>>>>
>>>>At 15.17 15/07/2004 +0200, you wrote:
>>>>>If this happens with Spring 1.0.2, it is typically caused by *other* 
>>>>>code that causes a leak. The ClassLoader is then still around, also 
>>>>>showing Spring classes like CachedIntrospectionResults. This is not 
>>>>>Spring's fault: Spring classes just keep hanging around as a side effect.
>>>>>
>>>>>Try calling "java.beans.Introspector.flushCaches()" on application 
>>>>>shutdown. This is a typical source of such leaks: The JavaBeans 
>>>>>Introspector might still refer to application classes. This is not 
>>>>>caused by Spring: It's rather other libraries that use the 
>>>>>Introspector, for example Quartz.
>>>>>
>>>>>Juergen
>>>>>
>>>>>
>>>>>________________________________
>>>>>
>>>>>Von: 
>>>>><mailto:spr...@li...>spr...@li... 
>>>>>im Auftrag von Rod Johnson
>>>>>Gesendet: Do 15.07.2004 14:38
>>>>>An: 
>>>>><mailto:spr...@li...>spr...@li...
>>>>>Betreff: Re: [Springframework-developer] CachedIntrospectionResults 
>>>>>classCache leak
>>>>>
>>>>>
>>>>>
>>>>>Claudio
>>>>>
>>>>>What version of Spring is your analysis against?
>>>>>
>>>>>R
>>>>>
>>>>>----- Original Message -----
>>>>>From: "Claudio D'Angelo" 
>>>>><mailto:cla...@ob...><cla...@ob...>
>>>>>To: 
>>>>><mailto:spr...@li...><spr...@li...>
>>>>>Sent: Thursday, July 15, 2004 10:26 AM
>>>>>Subject: [Springframework-developer] CachedIntrospectionResults classCache
>>>>>leak
>>>>>
>>>>>
>>>>> > Hi,
>>>>> > I'm analyzing with OptimizeIt my web application:
>>>>> > when I redeploy the application I note that instances of
>>>>> > CachedIntrospectionResults still in memory and for any redeploy the
>>>>> > instances raise.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>>>>FREE Java Enterprise J2EE developer tools!
>>>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>>>>_______________________________________________
>>>>>Springframework-developer mailing list
>>>>><mailto:Spr...@li...>Spr...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>>>>FREE Java Enterprise J2EE developer tools!
>>>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>>>_______________________________________________
>>>>>Springframework-developer mailing list
>>>>><mailto:Spr...@li...>Spr...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>
>>>>Grazie e buon lavoro
>>>>
>>>>----------
>>>>Claudio D'Angelo
>>>>Software Consultant
>>>>ObjectWay S.p.A.
>>>>Via G.A. Boltraffio 7
>>>>20159 Milano (MI)
>>>>http://www.objectway.it
>>>>
>>>>
>>>>--
>>>>La presente comunicazione potrebbe contenere informazioni riservate e/o 
>>>>protette
>>>>da segreto professionale ed e' indirizzata esclusivamente ai 
>>>>destinatari della
>>>>medesima qui indicati. Se avete ricevuto per errore la presente 
>>>>comunicazione,
>>>>siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo di 
>>>>e-mail,
>>>>e a cancellare il presente messaggio dal Vostro sistema. E' 
>>>>strettamente proibito
>>>>e potrebbe essere fonte di violazione di legge qualsiasi uso, 
>>>>comunicazione, copia
>>>>o diffusione dei contenuti di questa comunicazione da parte di chi la 
>>>>abbia
>>>>ricevuta per errore o in violazione degli scopi della presente.
>>>>Il messaggio e' stato analizzato alla ricerca di virus o contenuti 
>>>>pericolosi ed
>>>>e' risultato NON infetto.
>>
>>Grazie e buon lavoro
>>
>>----------
>>Claudio D'Angelo
>>Software Consultant
>>ObjectWay S.p.A.
>>Via G.A. Boltraffio 7
>>20159 Milano (MI)
>>http://www.objectway.it
>>
>>
>>--
>>La presente comunicazione potrebbe contenere informazioni riservate e/o 
>>protette
>>da segreto professionale ed e' indirizzata esclusivamente ai destinatari 
>>della
>>medesima qui indicati. Se avete ricevuto per errore la presente 
>>comunicazione,
>>siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo di 
>>e-mail,
>>e a cancellare il presente messaggio dal Vostro sistema. E' strettamente 
>>proibito
>>e potrebbe essere fonte di violazione di legge qualsiasi uso, 
>>comunicazione, copia
>>o diffusione dei contenuti di questa comunicazione da parte di chi la abbia
>>ricevuta per errore o in violazione degli scopi della presente.
>>Il messaggio e' stato analizzato alla ricerca di virus o contenuti 
>>pericolosi ed
>>e' risultato NON infetto.

Grazie e buon lavoro

----------
Claudio D'Angelo
Software Consultant
ObjectWay S.p.A.
Via G.A. Boltraffio 7
20159 Milano (MI)
http://www.objectway.it


-- 
La presente comunicazione potrebbe contenere informazioni riservate e/o
protette
da segreto professionale ed e' indirizzata esclusivamente ai destinatari della
medesima qui indicati. Se avete ricevuto per errore la presente comunicazione,
siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo di
e-mail,
e a cancellare il presente messaggio dal Vostro sistema. E' strettamente
proibito
e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione,
copia
o diffusione dei contenuti di questa comunicazione da parte di chi la abbia
ricevuta per errore o in violazione degli scopi della presente.
Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi
ed
e' risultato NON infetto.

Re: [Springframework-developer] Final preparations for 1.1 RC1

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

I forgot to say, as I said to Juergen in our chat, that I want to reserve
"aspect" for a high-level construct if necessary: possibly multiple Advis=
ors
working together to address a single aspect.

I vote to keep addInterceptor deprecated on Advised/dvisedSupport. I thin=
k
this gives an education and migration path. Moving it down might break
code--e.g. people cast to Advised and addInterceptor() doesn't work any
more. That would have broken some of my test code.

Rgds
Rod

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Monday, July 19, 2004 1:17 PM
Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1


As we just discussed on IM, I tend to agree :-) There is no convincing te=
rm
for bean properties - "aspect" is not really perfect either -, so it's
probably best to keep "interceptor".

The remaining question is: Do we need to deprecate "addInterceptor" on
AdvisedSupport? Quite a lot of people might just have a superficial grip =
on
AOP at the MethodInterceptor level: For those, "addInterceptor" might be
more natural, as they're not aware of the term "advice" or the
superinterface Advice in the first place.

We could also move "addInterceptor" down to ProxyFactory, as a convenienc=
e,
rather than deprecating it in AdvisedSupport. Essentially, we need to fin=
d a
good compromise, making stuff as easy to comprehend as possible from the
user's perspective. Allowing users to just think about "interceptors" for
working with MethodInterceptors might be part of that.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Monday, July 19, 2004 1:40 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1


I'm not convinced that it's worth changing, especially as the change woul=
d
obviously have quite an impact in the long term. The present use of
"interceptor" in properties--e.g. "interceptorNames", is a bit misleading=
,
as Interceptors, other Advices or Advisors can be used. However, such
methods are *not* parallel to the addInterceptor/addAdvice methods on
AdvisedSupport. addAdvice is more general than addInterceptor--e.g. you c=
an
add ThrowsAdvice as well as interceptors--but it doesn't support adding
Advisors. The "interceptorNames" style properties support Advices (includ=
ing
Interceptors) and Advisors.

It's hard to find a convincing name for the latter combination. It's
essentially Object-typed. Thus the "interceptor" concept, while an
implementation feature rather than AOP essential, seems as good as any.

Rgds
Rod

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Monday, July 19, 2004 11:36 AM
Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1


I forgot:

- We need to get "advice" vs "interceptor" naming right, possibly using t=
he
term "aspect" if also covering advisors: in ProxyFactory, ProxyFactoryBea=
n,
TransactionProxyFactoryBean.

Juergen


________________________________

Von: spr...@li... im Auftrag von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Mo 19.07.2004 11:29
An: spr...@li...
Betreff: [Springframework-developer] Final preparations for 1.1 RC1



Everybody,

Seems like we're finally ready for 1.1 RC1, already with full 1.1 scope:

- Mark has provided a refined version of the JMS support
- Thomas has already added support for JDBC-generated keys
- Darren has committed bind support for Velocity and FreeMarker
- Seth has contributed some tag refinements for JSP views.

The remaining tasks that I see are:

- We need to adapt the source code formatting of the JMS support: I still
see nasty empty lines after each code line on Windows: maybe Unix/Windows
line feed differences?

- I'd like to review the source code of the final version of JMS support.
Just about polishing and javadoc, as always before a release :-)

- Thomas is already working on using a single API approach for
JDBC-generated keys, including moving the classes to a different package.

- I'd like to move BindStatus and the new BindStatusHelper class from
servlet.tags to servlet.support. JSPs using the BindTag should still work=
,
provided that they get freshly compiled. Any objections to this?

- I'd like to refine resource loading in VelocityFormView and
FreeMarkerFormView: This is not entirely clean when combined with custom
resource paths yet, from a superficial glance.

- We need to add Seth's NestedPathTag and include his BindTag refinements.
I'll do this myself during the course of the week.

All things considered, this means a release by the end of the week: Any
earlier date would require dropping one of those tasks, which I don't thi=
nk
would be worth it. Thoughts?

Finally, regarding form simplification macros, i.e. Struts-style HTML inp=
ut
tag wrappers: Do we already have something here, for either JSP 2.0,
Velocity or FreeMarker?

Juergen



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Final preparations for 1.1 RC1

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

> I meant to raise this when I generalised the behaviour of them but it
> slipped my mind.  They should be moved to a non-tag specific package =
now.

OK, I'll move them to "servlet.support" tonight, alongside =
RequestContext. I'll also check whether Tomcat and Resin recompile JSPs =
if a TLD has changed; else, the working directory needs to be scratched =
to force a recompile.

> VelocityConfigurer (and respective FreeMarkerConfigurer) ensure a
> SpringResourceLoader is available for use, possibly in addition to any
> other resource loading strategy in the case of FreeMarker.  Does this =
not
> cover requirements?  I'm a little unclear on what's missing here..

I've gone through the code Tuesday night last week; I need to recheck =
what I actually noticed there. I'll do so when I'm back at home. (I'm =
currently at the werk3 office.)

> I'd intended contacting Seth again to catch up on this and ensure a
> consistent approach for the three technologies.  My feeling is that it
> should be fairly quick to add given the basic framework code is OK for
> resource loading, but I've not really looked closely at it yet.

No problem - let's add those for 1.1 final or even 1.1.1, whenever they =
are ready. Do you in principle envisage copying Velocity/FreeMarker =
macros to the user's resource loader path, to allow for easy =
customization?

Juergne

Re: [Springframework-developer] Final preparations for 1.1 RC1

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

As we just discussed on IM, I tend to agree :-) There is no convincing =
term for bean properties - "aspect" is not really perfect either -, so =
it's probably best to keep "interceptor".

The remaining question is: Do we need to deprecate "addInterceptor" on =
AdvisedSupport? Quite a lot of people might just have a superficial grip =
on AOP at the MethodInterceptor level: For those, "addInterceptor" might =
be more natural, as they're not aware of the term "advice" or the =
superinterface Advice in the first place.

We could also move "addInterceptor" down to ProxyFactory, as a =
convenience, rather than deprecating it in AdvisedSupport. Essentially, =
we need to find a good compromise, making stuff as easy to comprehend as =
possible from the user's perspective. Allowing users to just think about =
"interceptors" for working with MethodInterceptors might be part of =
that.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Monday, July 19, 2004 1:40 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1


I'm not convinced that it's worth changing, especially as the change =
would
obviously have quite an impact in the long term. The present use of
"interceptor" in properties--e.g. "interceptorNames", is a bit =
misleading,
as Interceptors, other Advices or Advisors can be used. However, such
methods are *not* parallel to the addInterceptor/addAdvice methods on
AdvisedSupport. addAdvice is more general than addInterceptor--e.g. you =
can
add ThrowsAdvice as well as interceptors--but it doesn't support adding
Advisors. The "interceptorNames" style properties support Advices =
(including
Interceptors) and Advisors.

It's hard to find a convincing name for the latter combination. It's
essentially Object-typed. Thus the "interceptor" concept, while an
implementation feature rather than AOP essential, seems as good as any.

Rgds
Rod

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Monday, July 19, 2004 11:36 AM
Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1


I forgot:

- We need to get "advice" vs "interceptor" naming right, possibly using =
the
term "aspect" if also covering advisors: in ProxyFactory, =
ProxyFactoryBean,
TransactionProxyFactoryBean.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Mo 19.07.2004 11:29
An: spr...@li...
Betreff: [Springframework-developer] Final preparations for 1.1 RC1



Everybody,

Seems like we're finally ready for 1.1 RC1, already with full 1.1 scope:

- Mark has provided a refined version of the JMS support
- Thomas has already added support for JDBC-generated keys
- Darren has committed bind support for Velocity and FreeMarker
- Seth has contributed some tag refinements for JSP views.

The remaining tasks that I see are:

- We need to adapt the source code formatting of the JMS support: I =
still
see nasty empty lines after each code line on Windows: maybe =
Unix/Windows
line feed differences?

- I'd like to review the source code of the final version of JMS =
support.
Just about polishing and javadoc, as always before a release :-)

- Thomas is already working on using a single API approach for
JDBC-generated keys, including moving the classes to a different =
package.

- I'd like to move BindStatus and the new BindStatusHelper class from
servlet.tags to servlet.support. JSPs using the BindTag should still =
work,
provided that they get freshly compiled. Any objections to this?

- I'd like to refine resource loading in VelocityFormView and
FreeMarkerFormView: This is not entirely clean when combined with custom
resource paths yet, from a superficial glance.

- We need to add Seth's NestedPathTag and include his BindTag =
refinements.
I'll do this myself during the course of the week.

All things considered, this means a release by the end of the week: Any
earlier date would require dropping one of those tasks, which I don't =
think
would be worth it. Thoughts?

Finally, regarding form simplification macros, i.e. Struts-style HTML =
input
tag wrappers: Do we already have something here, for either JSP 2.0,
Velocity or FreeMarker?

Juergen



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Final preparations for 1.1 RC1

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

I'm not convinced that it's worth changing, especially as the change woul=
d
obviously have quite an impact in the long term. The present use of
"interceptor" in properties--e.g. "interceptorNames", is a bit misleading=
,
as Interceptors, other Advices or Advisors can be used. However, such
methods are *not* parallel to the addInterceptor/addAdvice methods on
AdvisedSupport. addAdvice is more general than addInterceptor--e.g. you c=
an
add ThrowsAdvice as well as interceptors--but it doesn't support adding
Advisors. The "interceptorNames" style properties support Advices (includ=
ing
Interceptors) and Advisors.

It's hard to find a convincing name for the latter combination. It's
essentially Object-typed. Thus the "interceptor" concept, while an
implementation feature rather than AOP essential, seems as good as any.

Rgds
Rod

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Monday, July 19, 2004 11:36 AM
Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1


I forgot:

- We need to get "advice" vs "interceptor" naming right, possibly using t=
he
term "aspect" if also covering advisors: in ProxyFactory, ProxyFactoryBea=
n,
TransactionProxyFactoryBean.

Juergen


________________________________

Von: spr...@li... im Auftrag von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Mo 19.07.2004 11:29
An: spr...@li...
Betreff: [Springframework-developer] Final preparations for 1.1 RC1



Everybody,

Seems like we're finally ready for 1.1 RC1, already with full 1.1 scope:

- Mark has provided a refined version of the JMS support
- Thomas has already added support for JDBC-generated keys
- Darren has committed bind support for Velocity and FreeMarker
- Seth has contributed some tag refinements for JSP views.

The remaining tasks that I see are:

- We need to adapt the source code formatting of the JMS support: I still
see nasty empty lines after each code line on Windows: maybe Unix/Windows
line feed differences?

- I'd like to review the source code of the final version of JMS support.
Just about polishing and javadoc, as always before a release :-)

- Thomas is already working on using a single API approach for
JDBC-generated keys, including moving the classes to a different package.

- I'd like to move BindStatus and the new BindStatusHelper class from
servlet.tags to servlet.support. JSPs using the BindTag should still work=
,
provided that they get freshly compiled. Any objections to this?

- I'd like to refine resource loading in VelocityFormView and
FreeMarkerFormView: This is not entirely clean when combined with custom
resource paths yet, from a superficial glance.

- We need to add Seth's NestedPathTag and include his BindTag refinements.
I'll do this myself during the course of the week.

All things considered, this means a release by the end of the week: Any
earlier date would require dropping one of those tasks, which I don't thi=
nk
would be worth it. Thoughts?

Finally, regarding form simplification macros, i.e. Struts-style HTML inp=
ut
tag wrappers: Do we already have something here, for either JSP 2.0,
Velocity or FreeMarker?

Juergen



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Portlet support status?

[Rainer S. <Rai...@ab...>]

Thanks for the information, Bill. With my still somewhat limited 
experience with portlets it seems best to wait until at least some 
example code is published.

Rainer

William G Thompson Jr wrote:

> we are mostly at the same stage...which is a good base but still needs polish and good sample useage.  
> 
> with what is in the sandbox and the sample springportlet you can route portet modes to controllers and render via jstl using portlet tag lib all configured in a standard spring application context.
> 
> things remaining include:
>   * convenience controllers
>   * data binding
>   * javadoc clean up
>   * sample app
> 
> later.
> Bill

Re: [Springframework-developer] Portlet support status?

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

we are mostly at the same stage...which is a good base but still needs polish and good sample useage.  

with what is in the sandbox and the sample springportlet you can route portet modes to controllers and render via jstl using portlet tag lib all configured in a standard spring application context.

things remaining include:
  * convenience controllers
  * data binding
  * javadoc clean up
  * sample app

later.
Bill








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

> Date: Sat Jul 17 16:01:05 EDT 2004
> From: "Rainer Schmitz" <Rai...@ab...>
> Reply-To: spr...@li...
> Subject: [Springframework-developer] Portlet support status?
> To: spr...@li...
>
> After some distractions I'm dealing with portlets again.
> 
> What is the current status of spring support for portlet programming? In 
>   the mailing lists the topic wasn't discussed since early May.
> 
> Regards,
> Rainer
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Final preparations for 1.1 RC1

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

I forgot:
=20
- We need to get "advice" vs "interceptor" naming right, possibly using =
the term "aspect" if also covering advisors: in ProxyFactory, =
ProxyFactoryBean, TransactionProxyFactoryBean.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Mo 19.07.2004 11:29
An: spr...@li...
Betreff: [Springframework-developer] Final preparations for 1.1 RC1



Everybody,

Seems like we're finally ready for 1.1 RC1, already with full 1.1 scope:

- Mark has provided a refined version of the JMS support
- Thomas has already added support for JDBC-generated keys
- Darren has committed bind support for Velocity and FreeMarker
- Seth has contributed some tag refinements for JSP views.

The remaining tasks that I see are:

- We need to adapt the source code formatting of the JMS support: I =
still see nasty empty lines after each code line on Windows: maybe =
Unix/Windows line feed differences?

- I'd like to review the source code of the final version of JMS =
support. Just about polishing and javadoc, as always before a release =
:-)

- Thomas is already working on using a single API approach for =
JDBC-generated keys, including moving the classes to a different =
package.

- I'd like to move BindStatus and the new BindStatusHelper class from =
servlet.tags to servlet.support. JSPs using the BindTag should still =
work, provided that they get freshly compiled. Any objections to this?

- I'd like to refine resource loading in VelocityFormView and =
FreeMarkerFormView: This is not entirely clean when combined with custom =
resource paths yet, from a superficial glance.

- We need to add Seth's NestedPathTag and include his BindTag =
refinements. I'll do this myself during the course of the week.

All things considered, this means a release by the end of the week: Any =
earlier date would require dropping one of those tasks, which I don't =
think would be worth it. Thoughts?

Finally, regarding form simplification macros, i.e. Struts-style HTML =
input tag wrappers: Do we already have something here, for either JSP =
2.0, Velocity or FreeMarker?

Juergen



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Final preparations for 1.1 RC1

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

> - I'd like to move BindStatus and the new BindStatusHelper class from
> servlet.tags to servlet.support. JSPs using the BindTag should still wo=
rk,
> provided that they get freshly compiled. Any objections to this?

I meant to raise this when I generalised the behaviour of them but it
slipped my mind.  They should be moved to a non-tag specific package now.

> - I'd like to refine resource loading in VelocityFormView and
> FreeMarkerFormView: This is not entirely clean when combined with custo=
m
> resource paths yet, from a superficial glance.

VelocityConfigurer (and respective FreeMarkerConfigurer) ensure a
SpringResourceLoader is available for use, possibly in addition to any
other resource loading strategy in the case of FreeMarker.  Does this not
cover requirements?  I'm a little unclear on what's missing here..

> Finally, regarding form simplification macros, i.e. Struts-style HTML
> input tag wrappers: Do we already have something here, for either JSP 2=
.0,
> Velocity or FreeMarker?

not from my side - personal events have overtaken me a little recently.=20
I'd intended contacting Seth again to catch up on this and ensure a
consistent approach for the three technologies.  My feeling is that it
should be fairly quick to add given the basic framework code is OK for
resource loading, but I've not really looked closely at it yet.

Regards,
--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm

[Springframework-developer] Final preparations for 1.1 RC1

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

Everybody,
=20
Seems like we're finally ready for 1.1 RC1, already with full 1.1 scope:
=20
- Mark has provided a refined version of the JMS support
- Thomas has already added support for JDBC-generated keys
- Darren has committed bind support for Velocity and FreeMarker
- Seth has contributed some tag refinements for JSP views.
=20
The remaining tasks that I see are:
=20
- We need to adapt the source code formatting of the JMS support: I =
still see nasty empty lines after each code line on Windows: maybe =
Unix/Windows line feed differences?
=20
- I'd like to review the source code of the final version of JMS =
support. Just about polishing and javadoc, as always before a release =
:-)
=20
- Thomas is already working on using a single API approach for =
JDBC-generated keys, including moving the classes to a different =
package.
=20
- I'd like to move BindStatus and the new BindStatusHelper class from =
servlet.tags to servlet.support. JSPs using the BindTag should still =
work, provided that they get freshly compiled. Any objections to this?
=20
- I'd like to refine resource loading in VelocityFormView and =
FreeMarkerFormView: This is not entirely clean when combined with custom =
resource paths yet, from a superficial glance.
=20
- We need to add Seth's NestedPathTag and include his BindTag =
refinements. I'll do this myself during the course of the week.
=20
All things considered, this means a release by the end of the week: Any =
earlier date would require dropping one of those tasks, which I don't =
think would be worth it. Thoughts?
=20
Finally, regarding form simplification macros, i.e. Struts-style HTML =
input tag wrappers: Do we already have something here, for either JSP =
2.0, Velocity or FreeMarker?
=20
Juergen
=20