springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Re: Major Portlet MVC Framework Update

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

I really think it makes complete sense for this to be part of the main 
project, as a separate module alongside the webflow and any other 
modules that are brought out. The common-build stuff I got going in the 
spring-modules module in CVS can easily handle dependencies between 
everything, and allow people to concentrate on the code and not the 
build or dependency handling. It's now been proven in real use too.

Regards,
Colin

John Lewis wrote:

> Donald,
>
> Thansk for the quick feedback -- I agree with all of it.  I think the 
> Portlet MVC framework should be a core product as well, particularly 
> because other areas (such as Spring Web Flow) are already starting to 
> depend on it.  Also, since it so closely mirrors the servlet Web MVC 
> framework, it would be good to keep them together so that their 
> functionality can be kept in sync.  There is a fair amount of 
> rendundant code between the Portlet and Servlet frameworks, and 
> keeping them together will make it possible to refactor a lot of this 
> code.
>
> Let me know what I can do to help.
>
> John Lewis
>
>
> Keith Donald wrote:
>
>> Yes, the sandbox is not the place for code such as Spring Porlet or 
>> Spring
>> Web Flow.  The sandbox should really be only for scratch code that is
>> truly experimental.
>>
>> This weekend Spring Web Flow will move to its own module within the
>> springframework project repository, along with a major upgrade to its
>> build system.  I propose something similiar happen to Spring Portlet.
>>
>> Specifically I could see Spring Portlet as either:
>>
>> - A core module hosted at the main springframework site, maintained by
>> core spring developers, with its own release schedule.
>>
>> OR
>>
>> - A Spring module hosted at the java.net site.
>>
>> In either case all modules should leverage our new common project build
>> system using ivy for automated dependency management.  Colin has put 
>> a lot
>> of effort into a very strong build system essential to managing
>> dependencies between our various products--and Spring Web Flow and 
>> Spring
>> Portlet are both core products.
>>
>> So the question is which home is better for Spring Portlet: here at
>> sourceforge, or over at Spring Modules, right?  We favor hosting Web 
>> Flow
>> here at SF along side springframework as it's a *core product* 
>> maintained
>> by core spring developers.  Spring Portlet seems similiar to me.  And in
>> general, Spring modules seems a better fit for smaller, focused 
>> extension
>> products, e.g commons validator with a wider committer community -- 
>> so my
>> gut tells me Spring Portlet should also be hosted here as well.
>>
>> Thoughts?
>>
>> Keith
>>
>> p.s. great to see the Portlet MVC work moving forward!
>>
>>
>>
>>> Hi John,
>>>
>>> thank you very much for this!
>>>
>>> I am using the framework in production and it works great. Hope there
>>> will be an official home for the portlet MVC soon.
>>>
>>> I beg the spring team to decide soon about the future of the
>>> framework. Either in the core or as a subproject. But the current
>>> situation is not very good. In my opinion the portlet MVC is an
>>> outstanding framework to build portlets.
>>>
>>> Martin
>>>
>>>
>>> 2005/6/9, John Lewis <jl...@ar...>:
>>>
>>>> I just posted a major update to the Spring Portlet MVC Framework.  
>>>> It is
>>>> available here:
>>>>
>>>> http://opensource.atlassian.com/confluence/spring/display/JSR168/Home
>>>>
>>>> This update includes a number of major changes:
>>>> * It is now integrated with (and requires) Spring 1.2. All classes 
>>>> have
>>>> been updated with changes from their equivalent classes from the 
>>>> Servlet
>>>> area.
>>>> * A number of classes have been renamed and/or moved into different
>>>> packages in order to better align it with the Servlet MVC framework.
>>>> * The concept of Handlers is now included, instead of directly mapping
>>>> to Controllers. This will allow other Portlet MVC frameworks to be 
>>>> used
>>>> with a Spring web application.
>>>> * Expanded controller hierarchy that more closely follows the Servlet
>>>> MVC framework.
>>>> * A number of HandlerMappings are now provided, including one for
>>>> PortletMode, one for a request parameter, and one for PortletMode
>>>> combined with a request parameter.
>>>> * OpenSessionInViewInterceptor for both Hibernate 2 and Hibernate 3 
>>>> are
>>>> now included and fully functional.
>>>> * Lots of other minor updates and bug fixes.
>>>>
>>>> Please send me any feedback.
>>>>
>>>> Juergen, what are your current thoughts on getting this integrated 
>>>> into
>>>> the sandbox and into Spring 1.3?
>>>>
>>>> John Lewis
>>>> jl...@ar...
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
>>>> shotput
>>>> a projector? How fast can you ride your desk chair down the office 
>>>> luge
>>>> track?
>>>> If you want to score the big prize, get to know the little guy.
>>>> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
>>>> _______________________________________________
>>>> Springframework-developer mailing list
>>>> Spr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
>>> shotput
>>> a projector? How fast can you ride your desk chair down the office luge
>>> track?
>>> If you want to score the big prize, get to know the little guy.
>>> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office 
> luge track?
> If you want to score the big prize, get to know the little guy.  Play 
> to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: I am getting following error in Sun One Portal. Is this a SunOne Portal issue or should framework set content type automatically?

[John L. <jl...@ar...>]

I think this problem is fixed in the latest update to the Spring Portlet 
MVC framework, but I don't have an environment where I can test this.  
You can get the new download at:

[url]http://opensource.atlassian.com/confluence/spring/display/JSR168/Home[/url]

Let me know if it works.

John Lewis


Boyce, Keith Garry wrote:

>That's the error.. See forum
>http://forum.springframework.org/viewtopic.php?p=23016#23016
>
>Seems the only place to fix this is DispatcherPortlet private method
>since that's the only place that has access to both view and
>RenderResponseImpl. What are your thoughts on possible fix?
>
>Garry
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf
>Of John Lewis
>Sent: Thursday, May 26, 2005 2:22 AM
>To: spr...@li...
>Subject: [Springframework-developer] Re: I am getting following error in
>Sun One Portal. Is this a SunOne Portal issue or should framework set
>content type automatically?
>
>Is that the complete error message, or is there more information?  Any
>additional error data would be helpful.  Thanks!
>
>Boyce, Keith Garry wrote:
>  
>
>>I am getting following error in Sun One Portal. Is this a Sun One
>>    
>>
>
>  
>
>>Portal issue or should framework set content type automatically?
>>
>>    
>>
>
>  
>
>
>  
>
>>ERROR:
>>
>>    
>>
>
>  
>
>>ViewRendererServle: 96 - Could not complete request
>>
>>    
>>
>
>  
>
>>java.lang.IllegalStateException: RenderResponseImpl.getWriter:
>>contentType either contains a wildcard or is not set
>>
>>    
>>
>
>  
>
>>Thanks,
>>Garry
>>
>>    
>>
>
>  
>
>>This message is a PRIVATE communication.
>>If you are not the intended recipient, please do not read, copy, or
>>    
>>
>
>  
>
>>use it, and do not disclose it to others. Please notify the sender of
>>    
>>
>
>  
>
>>the delivery error by replying to this message, and then delete it
>>    
>>
>
>  
>
>>from your system. Thank you.
>>
>>    
>>
>
>  
>
>
>  
>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: GoToMeeting - the easiest way to
>>    
>>
>
>  
>
>>collaborate online with coworkers and clients while avoiding the high
>>    
>>
>
>  
>
>>cost of travel and communications. There is no equipment to buy and
>>    
>>
>
>  
>
>>you can meet as often as you want. Try it
>>    
>>
>
>  
>
>>free.http://ads.osdn.com/?ad_idt02&alloc_id135&op=click
>>    
>>
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: GoToMeeting - the easiest way to
>collaborate online with coworkers and clients while avoiding the high
>cost of travel and communications. There is no equipment to buy and you
>can meet as often as you want. Try it
>free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>This message is a PRIVATE communication.
>If you are not the intended recipient, please do not read, copy,
>or use it, and do not disclose it to others. Please notify the
>sender of the delivery error by replying to this message, and then
>delete it from your system. Thank you.
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
>online with coworkers and clients while avoiding the high cost of travel and
>communications. There is no equipment to buy and you can meet as often as
>you want. Try it free.http://ads.osdn.com/?ad_idt02&alloc_id135&op=click
>  
>

Re: [Springframework-developer] Re: Major Portlet MVC Framework Update

[Erwin V. <erw...@er...>]

> Thansk for the quick feedback -- I agree with all of it.  I think the 
> Portlet MVC framework should be a core product as well, particularly 
> because other areas (such as Spring Web Flow) are already starting to 
> depend on it.  Also, since it so closely mirrors the servlet Web MVC 
> framework, it would be good to keep them together so that their 
> functionality can be kept in sync.  There is a fair amount of rendundant 
> code between the Portlet and Servlet frameworks, and keeping them together 
> will make it possible to refactor a lot of this code.

Great to see this kind of activity with the PortletMVC code. Seems like 
Spring 1.3 preparation are starting up!

Erwin 

Re: [Springframework-developer] Major Portlet MVC Framework Update

[Erwin V. <erw...@er...>]

> So the question is which home is better for Spring Portlet: here at
> sourceforge, or over at Spring Modules, right?  We favor hosting Web Flow
> here at SF along side springframework as it's a *core product* maintained
> by core spring developers.  Spring Portlet seems similiar to me.  And in
> general, Spring modules seems a better fit for smaller, focused extension
> products, e.g commons validator with a wider committer community -- so my
> gut tells me Spring Portlet should also be hosted here as well.

I agree. It would be a bit strange to have a 'core product' like SWF depend 
on an add-on module like Spring PortletMVC, if that's how we would organize 
it. Ofcourse we could also decide to move the Portlet MVC support in SWF 
over to the Portlet module, instead of keeping it with SWF.


Erwin 

[Springframework-developer] Re: Major Portlet MVC Framework Update

[John L. <jl...@ar...>]

Donald,

Thansk for the quick feedback -- I agree with all of it.  I think the 
Portlet MVC framework should be a core product as well, particularly 
because other areas (such as Spring Web Flow) are already starting to 
depend on it.  Also, since it so closely mirrors the servlet Web MVC 
framework, it would be good to keep them together so that their 
functionality can be kept in sync.  There is a fair amount of rendundant 
code between the Portlet and Servlet frameworks, and keeping them 
together will make it possible to refactor a lot of this code.

Let me know what I can do to help.

John Lewis


Keith Donald wrote:
> Yes, the sandbox is not the place for code such as Spring Porlet or Spring
> Web Flow.  The sandbox should really be only for scratch code that is
> truly experimental.
> 
> This weekend Spring Web Flow will move to its own module within the
> springframework project repository, along with a major upgrade to its
> build system.  I propose something similiar happen to Spring Portlet.
> 
> Specifically I could see Spring Portlet as either:
> 
> - A core module hosted at the main springframework site, maintained by
> core spring developers, with its own release schedule.
> 
> OR
> 
> - A Spring module hosted at the java.net site.
> 
> In either case all modules should leverage our new common project build
> system using ivy for automated dependency management.  Colin has put a lot
> of effort into a very strong build system essential to managing
> dependencies between our various products--and Spring Web Flow and Spring
> Portlet are both core products.
> 
> So the question is which home is better for Spring Portlet: here at
> sourceforge, or over at Spring Modules, right?  We favor hosting Web Flow
> here at SF along side springframework as it's a *core product* maintained
> by core spring developers.  Spring Portlet seems similiar to me.  And in
> general, Spring modules seems a better fit for smaller, focused extension
> products, e.g commons validator with a wider committer community -- so my
> gut tells me Spring Portlet should also be hosted here as well.
> 
> Thoughts?
> 
> Keith
> 
> p.s. great to see the Portlet MVC work moving forward!
> 
> 
> 
>>Hi John,
>>
>>thank you very much for this!
>>
>>I am using the framework in production and it works great. Hope there
>>will be an official home for the portlet MVC soon.
>>
>>I beg the spring team to decide soon about the future of the
>>framework. Either in the core or as a subproject. But the current
>>situation is not very good. In my opinion the portlet MVC is an
>>outstanding framework to build portlets.
>>
>>Martin
>>
>>
>>2005/6/9, John Lewis <jl...@ar...>:
>>
>>>I just posted a major update to the Spring Portlet MVC Framework.  It is
>>>available here:
>>>
>>>http://opensource.atlassian.com/confluence/spring/display/JSR168/Home
>>>
>>>This update includes a number of major changes:
>>>* It is now integrated with (and requires) Spring 1.2. All classes have
>>>been updated with changes from their equivalent classes from the Servlet
>>>area.
>>>* A number of classes have been renamed and/or moved into different
>>>packages in order to better align it with the Servlet MVC framework.
>>>* The concept of Handlers is now included, instead of directly mapping
>>>to Controllers. This will allow other Portlet MVC frameworks to be used
>>>with a Spring web application.
>>>* Expanded controller hierarchy that more closely follows the Servlet
>>>MVC framework.
>>>* A number of HandlerMappings are now provided, including one for
>>>PortletMode, one for a request parameter, and one for PortletMode
>>>combined with a request parameter.
>>>* OpenSessionInViewInterceptor for both Hibernate 2 and Hibernate 3 are
>>>now included and fully functional.
>>>* Lots of other minor updates and bug fixes.
>>>
>>>Please send me any feedback.
>>>
>>>Juergen, what are your current thoughts on getting this integrated into
>>>the sandbox and into Spring 1.3?
>>>
>>>John Lewis
>>>jl...@ar...
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
>>>shotput
>>>a projector? How fast can you ride your desk chair down the office luge
>>>track?
>>>If you want to score the big prize, get to know the little guy.
>>>Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
>>shotput
>>a projector? How fast can you ride your desk chair down the office luge
>>track?
>>If you want to score the big prize, get to know the little guy.
>>Play to win an NEC 61" plasma display: http://www.necitguy.com/?r
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
> 
> 
> 

Re: [Springframework-developer] Major Portlet MVC Framework Update

[Keith D. <ke...@in...>]

Yes, the sandbox is not the place for code such as Spring Porlet or Spring
Web Flow.  The sandbox should really be only for scratch code that is
truly experimental.

This weekend Spring Web Flow will move to its own module within the
springframework project repository, along with a major upgrade to its
build system.  I propose something similiar happen to Spring Portlet.

Specifically I could see Spring Portlet as either:

- A core module hosted at the main springframework site, maintained by
core spring developers, with its own release schedule.

OR

- A Spring module hosted at the java.net site.

In either case all modules should leverage our new common project build
system using ivy for automated dependency management.  Colin has put a lot
of effort into a very strong build system essential to managing
dependencies between our various products--and Spring Web Flow and Spring
Portlet are both core products.

So the question is which home is better for Spring Portlet: here at
sourceforge, or over at Spring Modules, right?  We favor hosting Web Flow
here at SF along side springframework as it's a *core product* maintained
by core spring developers.  Spring Portlet seems similiar to me.  And in
general, Spring modules seems a better fit for smaller, focused extension
products, e.g commons validator with a wider committer community -- so my
gut tells me Spring Portlet should also be hosted here as well.

Thoughts?

Keith

p.s. great to see the Portlet MVC work moving forward!


> Hi John,
>
> thank you very much for this!
>
> I am using the framework in production and it works great. Hope there
> will be an official home for the portlet MVC soon.
>
> I beg the spring team to decide soon about the future of the
> framework. Either in the core or as a subproject. But the current
> situation is not very good. In my opinion the portlet MVC is an
> outstanding framework to build portlets.
>
> Martin
>
>
> 2005/6/9, John Lewis <jl...@ar...>:
>> I just posted a major update to the Spring Portlet MVC Framework.  It is
>> available here:
>>
>> http://opensource.atlassian.com/confluence/spring/display/JSR168/Home
>>
>> This update includes a number of major changes:
>> * It is now integrated with (and requires) Spring 1.2. All classes have
>> been updated with changes from their equivalent classes from the Servlet
>> area.
>> * A number of classes have been renamed and/or moved into different
>> packages in order to better align it with the Servlet MVC framework.
>> * The concept of Handlers is now included, instead of directly mapping
>> to Controllers. This will allow other Portlet MVC frameworks to be used
>> with a Spring web application.
>> * Expanded controller hierarchy that more closely follows the Servlet
>> MVC framework.
>> * A number of HandlerMappings are now provided, including one for
>> PortletMode, one for a request parameter, and one for PortletMode
>> combined with a request parameter.
>> * OpenSessionInViewInterceptor for both Hibernate 2 and Hibernate 3 are
>> now included and fully functional.
>> * Lots of other minor updates and bug fixes.
>>
>> Please send me any feedback.
>>
>> Juergen, what are your current thoughts on getting this integrated into
>> the sandbox and into Spring 1.3?
>>
>> John Lewis
>> jl...@ar...
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
>> shotput
>> a projector? How fast can you ride your desk chair down the office luge
>> track?
>> If you want to score the big prize, get to know the little guy.
>> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> shotput
> a projector? How fast can you ride your desk chair down the office luge
> track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>


-- 
Keith Donald
Principal Consultant, Interface21
http://www.springframework.com - Spring Services From the Source

Re: [Springframework-developer] Major Portlet MVC Framework Update

[Martin D. <mdu...@gm...>]

Hi John,

thank you very much for this!

I am using the framework in production and it works great. Hope there
will be an official home for the portlet MVC soon.

I beg the spring team to decide soon about the future of the
framework. Either in the core or as a subproject. But the current
situation is not very good. In my opinion the portlet MVC is an
outstanding framework to build portlets.

Martin


2005/6/9, John Lewis <jl...@ar...>:
> I just posted a major update to the Spring Portlet MVC Framework.  It is
> available here:
>=20
> http://opensource.atlassian.com/confluence/spring/display/JSR168/Home
>=20
> This update includes a number of major changes:
> * It is now integrated with (and requires) Spring 1.2. All classes have
> been updated with changes from their equivalent classes from the Servlet
> area.
> * A number of classes have been renamed and/or moved into different
> packages in order to better align it with the Servlet MVC framework.
> * The concept of Handlers is now included, instead of directly mapping
> to Controllers. This will allow other Portlet MVC frameworks to be used
> with a Spring web application.
> * Expanded controller hierarchy that more closely follows the Servlet
> MVC framework.
> * A number of HandlerMappings are now provided, including one for
> PortletMode, one for a request parameter, and one for PortletMode
> combined with a request parameter.
> * OpenSessionInViewInterceptor for both Hibernate 2 and Hibernate 3 are
> now included and fully functional.
> * Lots of other minor updates and bug fixes.
>=20
> Please send me any feedback.
>=20
> Juergen, what are your current thoughts on getting this integrated into
> the sandbox and into Spring 1.3?
>=20
> John Lewis
> jl...@ar...
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you sho=
tput
> a projector? How fast can you ride your desk chair down the office luge t=
rack?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Major Portlet MVC Framework Update

[John L. <jl...@ar...>]

I just posted a major update to the Spring Portlet MVC Framework.  It is 
available here:

http://opensource.atlassian.com/confluence/spring/display/JSR168/Home

This update includes a number of major changes:
* It is now integrated with (and requires) Spring 1.2. All classes have 
been updated with changes from their equivalent classes from the Servlet 
area.
* A number of classes have been renamed and/or moved into different 
packages in order to better align it with the Servlet MVC framework.
* The concept of Handlers is now included, instead of directly mapping 
to Controllers. This will allow other Portlet MVC frameworks to be used 
with a Spring web application.
* Expanded controller hierarchy that more closely follows the Servlet 
MVC framework.
* A number of HandlerMappings are now provided, including one for 
PortletMode, one for a request parameter, and one for PortletMode 
combined with a request parameter.
* OpenSessionInViewInterceptor for both Hibernate 2 and Hibernate 3 are 
now included and fully functional.
* Lots of other minor updates and bug fixes.

Please send me any feedback.

Juergen, what are your current thoughts on getting this integrated into 
the sandbox and into Spring 1.3?

John Lewis
jl...@ar...

[Springframework-developer] Extensible XML processing in Spring: prototype version available in CVS HEAD

[<jas...@ma...>]

Quite a few folks have wanted some way to extend/enhance Spring's XML  
configuration file mechanism to provide more concise XML with richer  
XML validation (through schemas and XSD extension etc). Here's some  
background ideas...
http://article.gmane.org/gmane.comp.java.springframework.devel/8301/ 
match=neater+xml++xsd

Yet another project I work on, ServiceMix, needed this - and I didn't  
have the heart to go down the XSLT route I've done before (e.g. on  
ActiveMQ) - so I thought I'd experiment actually working on Spring to  
provide an 'XML extension point' for XML configuration files.


Example
=======
First here's the example of what the XML looks like in ServiceMix  
before, using standard Spring - then afterwards with the 'XML  
extensions' so you can see the kind of thing I mean.

regular Spring config.
http://cvs.servicemix.codehaus.org/servicemix/base/src/test/resources/ 
org/servicemix/jbi/config/example-spring.xml?rev=HEAD&view=auto

extended Spring
http://cvs.servicemix.codehaus.org/servicemix/base/src/test/resources/ 
org/servicemix/jbi/config/example.xml?rev=HEAD&view=auto

Now ServiceMix users can use a *much* more concise XML, if they want  
- we can easily add an XSD that can validate the ServiceMix model  
much better - but we can still mix and match all the great Spring XML  
stuff in there too. Its just a couple of trivial, simple macros  
(<components>, <component> and <qname>) to simplify the XML.

 From ServiceMix's perspective, we've implemented these new tags in  
the XML using a couple of pretty-trivial classes.

The neat thing about this is that folks can now start to mix and  
match custom XML languages with the Spring XML. e.g. folks building  
Geronimo's web, JCA and EJB containers can use Spring XML to deal  
with J2EE deployment descriptors, but allow  those files to include  
Spring XML too!


Implementation
============
Now we could use inheritance to add custom XML processing (we did  
this in ActiveMQ) - each library developer would then provide their  
own definition reader / bean factory implementation; the problem with  
that is there are so many kinds of bean factory & application context  
and many ways to make them - having a custom bean factory didn't seem  
a clean solution. Plus I'd like us to mix and match different  
extensions together into the same Spring XML document. So I decided  
to try add a 'META-INF/services/' style of auto-discovery.

The basic idea is that the standard spring configuration mechanism,  
will parse the regular Spring XML elements, but any new ones it  
doesn't recognise, it will see if there is an ElementProcessor class  
registered for the given element name (using namespaces too if need  
be). An ElementProcessor is a trivial little plugin interface  
allowing folks to turn any-old-XML into regular Spring <bean>  
<property> elements.


Using XML extensions
================

So if you parse the this example 'extended' spring XML, with the  
latest CVS HEAD and the ServiceMix jar on your classpath...
http://cvs.servicemix.codehaus.org/servicemix/base/src/test/resources/ 
org/servicemix/jbi/config/example.xml?rev=HEAD&view=auto

it will automatically parse these new XML extensions! (To use the  
ServiceMix example above, since it uses arbitrary XML namespaces, you  
have to turn of XML validation to avoid using the DTD (*))

The neat thing is, different folks can now provide different  
extensions on the classpath. So we could have groovy, activemq,  
servicemix, geronimo-jca and geronimo-ejb, all making their own  
extensions, having their own XSDs and all used freely inside a single  
XML document.


Impact
=====
As it turns out, the impact on the code was surprisingly small and  
the entire thing only took about a day to implement - most of which  
was on the ServiceMix side of things (which is much less than the  
XSLT took to get right on ActiveMQ! :). The impact on the Spring  
codebase is a couple of fairly straightforward small methods added to  
the current parser, 1 new extension interface (ElementProcessor) and  
an optional helper class, ElementProcessorSupport that wraps up a  
bunch of useful helper methods for transforming DOM nodes and adding  
Spring XML elements.

Due to the minimal impact of these changes & ease of backing them out  
again, I've gone ahead and checked them straight in. Please take a  
look and see what you think. I'm using ServiceMix (http:// 
servicemix.org/) as the test case right now; if there's general  
agreement among the team with this approach, I'll add some spring  
specific test cases into CVS to test it out inside the spring unit  
test suite.


Remaining Issues
=============
This whole spike was surprisingly simple to do and had minimal impact  
on Spring. (*) The only gotcha was, Spring uses XML validation by  
default - which forces a DOCTYPE to be specified - and DOCTYPEs don't  
like arbitrary namespaces to be used. So I've added an xmlValidating  
property on AbstractXmlApplicationContext and a new constructor on  
BeanFactory so you can turn off validation if you want to. (There  
could be other places in the code that might need to allow validation  
to be turned off, but that should do for a start).

I guess if we had a Spring XSD, then we could enforce validation all  
the time and folks who wish to extend the XML must specify one more  
more XSD references in the XML?

Thoughts?

James
-------
http://radio.weblogs.com/0112098/

Re: [Springframework-developer] not sure if you guys have seen this

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

Not sure if you've seen this as well - someone blogging about the =20
Core Spring training in Amsterdam:

http://technology.amis.nl/blog/index.php?p=3D608



On Jun 8, 2005, at 11:04 PM, Keith Donald wrote:

> =85it=92s not exactly spanking new news=85 but just in case=85 sf =
stats are =20
> back=85
>
>
>
> http://sourceforge.net/project/stats/detail.php?=20
> group_id=3D73357&ugn=3Dspringframework&type=3Dprdownload&mode=3D12months=
&sl1_c=20
> urrent=3D148517&package_id=3D73406&sl2_current=3D0&release_id=3D0
>
>
>
>

[Springframework-developer] not sure if you guys have seen this

[Keith D. <ke...@in...>]

.it's not exactly spanking new news. but just in case. sf stats are back.

 

http://sourceforge.net/project/stats/detail.php?group_id=73357
<http://sourceforge.net/project/stats/detail.php?group_id=73357&ugn=springfr
amework&type=prdownload&mode=12months&sl1_current=148517&package_id=73406&sl
2_current=0&release_id=0>
&ugn=springframework&type=prdownload&mode=12months&sl1_current=148517&packag
e_id=73406&sl2_current=0&release_id=0

 

[Springframework-developer] Continuous build

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

We're having some problems with our infrastructure at the office so we won't
be able to do the nightly builds for a while. It'll probably be until after
the weekend before we can run a nightly build again.

Apologies!

Rgds,
Alef

[Springframework-developer] FAILED BUILD: sparc-solaris2 (last 30 lines included)

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

1118180253
FAILED
    [junit] Testcase: testAutowireWithDefault took 0.205 sec
    [junit] Testcase: testAutowireByConstructor took 0.092 sec
    [junit] Testcase: testAutowireByConstructorWithSimpleValues took 0.267 sec
    [junit] Testcase: testConstructorArgResolution took 0.364 sec
    [junit] Testcase: testConstructorArgWithSingleMatch took 0.305 sec
    [junit] Testcase: testThrowsExceptionOnTooManyArguments took 0.89 sec
    [junit] Testcase: testThrowsExceptionOnAmbiguousResolution took 0.056 sec
    [junit] Testcase: testFactoryBeanDefinedAsPrototype took 0.035 sec
    [junit] Testcase: testDependsOn took 0.273 sec
    [junit] Testcase: testDependsOnInInnerBean took 0.108 sec
    [junit] Testcase: testDependenciesThroughConstructorArguments took 0.039 sec
    [junit] Testcase: testDependenciesThroughConstructorArgumentAutowiring took 0.07 sec
    [junit] Testcase: testDependenciesThroughConstructorArgumentsInInnerBean took 0.038 sec
    [junit] Testcase: testDependenciesThroughProperties took 0.105 sec
    [junit] Testcase: testDependenciesThroughPropertiesWithInTheMiddle took 0.21 sec
    [junit] Testcase: testDependenciesThroughPropertyAutowiringByName took 0.259 sec
    [junit] Testcase: testDependenciesThroughPropertyAutowiringByType took 0.059 sec
    [junit] Testcase: testDependenciesThroughPropertiesInInnerBean took 0.037 sec
    [junit] Testcase: testClassNotFoundWithDefault took 0.041 sec
    [junit] Testcase: testClassNotFoundWithNoBeanClassLoader took 0.112 sec
    [junit] Testcase: testResourceAndInputStream took 0.362 sec
    [junit] Testcase: testClassPathResourceWithImport took 0.311 sec
    [junit] Testcase: testUrlResourceWithImport took 0.086 sec
    [junit] Testcase: testFileSystemResourceWithImport took 0.242 sec
    [junit] Testcase: testLookupOverrideMethodsWithSetterInjection took 3.016 sec
    [junit] 	FAILED
    [junit] null
    [junit] junit.framework.AssertionFailedError
    [junit] 	at org.springframework.beans.factory.xml.XmlBeanFactoryTests.testLookupOverrideMethodsWithSetterInjection(XmlBeanFactoryTests.java:879)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] spring build.278 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050607001709Lbuild.278

[Springframework-developer] CGLib related startup performance

[Claus I. <cib...@ya...>]

Juozas Baliuka posted this patch to hibernate 3.
http://opensource.atlassian.com/projects/hibernate/browse/HHH-525

I don't know if that could have any relation to Spring's use of CGLib?

/Claus

[Springframework-developer] spring build.277 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050606001638Lbuild.277

[Springframework-developer] FAILED BUILD: sparc-solaris1 (last 30 lines included)

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

1117927522
FAILED
    [junit] Testcase: testAutowireWithDefault took 0.046 sec
    [junit] Testcase: testAutowireByConstructor took 0.067 sec
    [junit] Testcase: testAutowireByConstructorWithSimpleValues took 0.065 sec
    [junit] Testcase: testConstructorArgResolution took 0.123 sec
    [junit] Testcase: testConstructorArgWithSingleMatch took 0.072 sec
    [junit] Testcase: testThrowsExceptionOnTooManyArguments took 0.054 sec
    [junit] Testcase: testThrowsExceptionOnAmbiguousResolution took 0.265 sec
    [junit] Testcase: testFactoryBeanDefinedAsPrototype took 0.033 sec
    [junit] Testcase: testDependsOn took 0.434 sec
    [junit] Testcase: testDependsOnInInnerBean took 0.097 sec
    [junit] Testcase: testDependenciesThroughConstructorArguments took 0.058 sec
    [junit] Testcase: testDependenciesThroughConstructorArgumentAutowiring took 0.24 sec
    [junit] Testcase: testDependenciesThroughConstructorArgumentsInInnerBean took 0.451 sec
    [junit] Testcase: testDependenciesThroughProperties took 0.242 sec
    [junit] Testcase: testDependenciesThroughPropertiesWithInTheMiddle took 0.524 sec
    [junit] Testcase: testDependenciesThroughPropertyAutowiringByName took 0.035 sec
    [junit] Testcase: testDependenciesThroughPropertyAutowiringByType took 0.039 sec
    [junit] Testcase: testDependenciesThroughPropertiesInInnerBean took 0.036 sec
    [junit] Testcase: testClassNotFoundWithDefault took 0.248 sec
    [junit] Testcase: testClassNotFoundWithNoBeanClassLoader took 0.03 sec
    [junit] Testcase: testResourceAndInputStream took 0.351 sec
    [junit] Testcase: testClassPathResourceWithImport took 0.068 sec
    [junit] Testcase: testUrlResourceWithImport took 0.067 sec
    [junit] Testcase: testFileSystemResourceWithImport took 0.278 sec
    [junit] Testcase: testLookupOverrideMethodsWithSetterInjection took 2.265 sec
    [junit] 	FAILED
    [junit] null
    [junit] junit.framework.AssertionFailedError
    [junit] 	at org.springframework.beans.factory.xml.XmlBeanFactoryTests.testLookupOverrideMethodsWithSetterInjection(XmlBeanFactoryTests.java:879)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] applicationContext.xml (maybe dtd) problem

[snpe <sn...@sn...>]

Hello,
This is fragment from rcp project's richclient-application-context.xml :

<bean id="binderSelectionStrategy" 
        class="org.springframework.richclient.samples.petclinic.ui.binder.PetClinicBinderSelectionStrategy">
        <property name="bindersForPropertyTypes">
            <map>
                <entry>
                    <key>
                        <value type="java.lang.Class">java.util.Date</value>
                    </key>
                    <bean 
                        class="org.springframework.richclient.samples.petclinic.ui.binder.CustomDatePickerBinder"/>
                </entry>
                <entry>
                    <key>
                        <value type="java.lang.Class"> 
                            org.springframework.samples.petclinic.PetType</value>
                    </key>
                    <bean 
                        class="org.springframework.richclient.samples.petclinic.ui.binder.PetTypeBinder">
                        <property name="clinic">
                            <ref bean="clinic"/>
                        </property>
                    </bean>
                </entry>
            </map>
        </property>
    </bean>

bindersForPropertyTypes is map and it work fine - spring instantiate bean, but eclipse webtools validation return error :
Attribute "type" must be declared for element type "value".
The content of element type "entry" must match "(bean|ref|idref|list|set|map|props|value|null)".
Attribute "key" is required and must be specified for element type "entry".

Is it dtd problem ?

regards
Peco

[Springframework-developer] FAILED BUILD: ppc-osx2 (last 30 lines included)

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

1117888381
FAILED

This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] spring build.276 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050604001653Lbuild.276

Re: [Springframework-developer] child context lookups

[Juergen H. <ju...@in...>]

I see... it's obviously some unintended recursion.

I guess the fastest way to figuring this out is to set a breakpoint on your
getBean call and see what happens when you step in. The recursion should be
come obvious pretty quickly.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Keith Donald
Sent: Friday, June 03, 2005 9:38 AM
To: spr...@li...
Subject: RE: [Springframework-developer] child context lookups


Juergen,

Hope this helps clarify:

- the delegating bean is hosted in the parent context.  For this app, this
is the context of a dispatcher servlet (so essentially its application
scope.)

- when executed, the delegating bean looks up another context managed in
flow-scope.  That flow-scoped context is a child of the dispatcher servlet's
context.  The delegating bean then asks for the delegate on that child
context by name, and the StackOverflow results.

A picture might help as well:

|-------------|
| dispatcher  |
|  context    |
| * myBean    |
|-------------|
      |
      |
|-------------|
|    flow     |
|  context    |
| * myBean    |
|-------------|

In code of the delegating bean:

execute(RequestContext context) {
  BeanFactory bf =
(BeanFactory)context.getFlowScope().getAttribute("flowContext");
  bf.getBean("myBean"); // STACK OVERFLOW, as instead of getting the
"myBean" from flow context above I get a reference to myself -- why??
}

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Juergen Hoeller
Sent: Friday, June 03, 2005 3:26 AM
To: spr...@li...
Subject: Re: [Springframework-developer] child context lookups

Keith,

Do you I understand correctly that you try to look up the delegate bean -
which resides in the child context - from a delegating bean which resides in
the parent context? That won't work: If the lookup is performed within a
bean in the parent context, all it's gonna see is the parent context and the
beans there.

"Shadowing" beans with the same name does work with bean references, though.
You can for example define a bean in the child context that receives an
explicit reference to a bean of the same name in the parent context, through
a <ref parent="..."> tag which will always perform the lookup in the parent
context, thus linking to the bean there.

What exactly do you want to achieve?

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Keith Donald
Sent: Friday, June 03, 2005 7:37 AM
To: spr...@li...
Subject: [Springframework-developer] child context lookups


I have a question about context hierarchy.

I've run into a situation where I have a "delegating bean" (a singleton) in
a parent context, making a lookup to a delegate instance in a flow-scoped
child context.  For transparency, the delegating bean and the delegate share
the same bean name.

This sounded fine to me, but I was greeted by a StackOverflowError within
the delegating bean implementation when it tried to lookup the delegate.
This happened because instead of getting the delegate, I got a reference
back to the delegating object itself.  In other words, when it queried the
child context, the bean in the parent was returned, not the one in the
child.  I would've thought this to be the other way around - querying the
child context would result in first its registry being checked, and then if
no bean was found a call to the parent?

Another, unreleated issue I am having is the ClasspathXmlApplicationContext
and related implementations are not serializable.  Is there any reason that
this is not supported?  In my case I have transactional state managed in a
flow-scoped context - it'd be nice if I could serialize the entire context
out for reconstruction of that state at a later point to facilitate server
restarts, for example.

Keith



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] child context lookups

[Keith D. <ke...@in...>]

Juergen,

Hope this helps clarify:

- the delegating bean is hosted in the parent context.  For this app, this
is the context of a dispatcher servlet (so essentially its application
scope.)

- when executed, the delegating bean looks up another context managed in
flow-scope.  That flow-scoped context is a child of the dispatcher servlet's
context.  The delegating bean then asks for the delegate on that child
context by name, and the StackOverflow results.

A picture might help as well:

|-------------|
| dispatcher  |
|  context    |
| * myBean    |
|-------------|
      |
      |
|-------------|
|    flow     |
|  context    |
| * myBean    |
|-------------|

In code of the delegating bean:

execute(RequestContext context) {
  BeanFactory bf =
(BeanFactory)context.getFlowScope().getAttribute("flowContext");
  bf.getBean("myBean"); // STACK OVERFLOW, as instead of getting the
"myBean" from flow context above I get a reference to myself -- why??
}

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Juergen Hoeller
Sent: Friday, June 03, 2005 3:26 AM
To: spr...@li...
Subject: Re: [Springframework-developer] child context lookups

Keith,

Do you I understand correctly that you try to look up the delegate bean -
which resides in the child context - from a delegating bean which resides in
the parent context? That won't work: If the lookup is performed within a
bean in the parent context, all it's gonna see is the parent context and the
beans there.

"Shadowing" beans with the same name does work with bean references, though.
You can for example define a bean in the child context that receives an
explicit reference to a bean of the same name in the parent context, through
a <ref parent="..."> tag which will always perform the lookup in the parent
context, thus linking to the bean there.

What exactly do you want to achieve?

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Keith Donald
Sent: Friday, June 03, 2005 7:37 AM
To: spr...@li...
Subject: [Springframework-developer] child context lookups


I have a question about context hierarchy.

I've run into a situation where I have a "delegating bean" (a singleton) in
a parent context, making a lookup to a delegate instance in a flow-scoped
child context.  For transparency, the delegating bean and the delegate share
the same bean name.

This sounded fine to me, but I was greeted by a StackOverflowError within
the delegating bean implementation when it tried to lookup the delegate.
This happened because instead of getting the delegate, I got a reference
back to the delegating object itself.  In other words, when it queried the
child context, the bean in the parent was returned, not the one in the
child.  I would've thought this to be the other way around - querying the
child context would result in first its registry being checked, and then if
no bean was found a call to the parent?

Another, unreleated issue I am having is the ClasspathXmlApplicationContext
and related implementations are not serializable.  Is there any reason that
this is not supported?  In my case I have transactional state managed in a
flow-scoped context - it'd be nice if I could serialize the entire context
out for reconstruction of that state at a later point to facilitate server
restarts, for example.

Keith



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] child context lookups

[Juergen H. <ju...@in...>]

Keith,

Do you I understand correctly that you try to look up the delegate bean -
which resides in the child context - from a delegating bean which resides in
the parent context? That won't work: If the lookup is performed within a
bean in the parent context, all it's gonna see is the parent context and the
beans there.

"Shadowing" beans with the same name does work with bean references, though.
You can for example define a bean in the child context that receives an
explicit reference to a bean of the same name in the parent context, through
a <ref parent="..."> tag which will always perform the lookup in the parent
context, thus linking to the bean there.

What exactly do you want to achieve?

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Keith Donald
Sent: Friday, June 03, 2005 7:37 AM
To: spr...@li...
Subject: [Springframework-developer] child context lookups


I have a question about context hierarchy.

I've run into a situation where I have a "delegating bean" (a singleton) in
a parent context, making a lookup to a delegate instance in a flow-scoped
child context.  For transparency, the delegating bean and the delegate share
the same bean name.

This sounded fine to me, but I was greeted by a StackOverflowError within
the delegating bean implementation when it tried to lookup the delegate.
This happened because instead of getting the delegate, I got a reference
back to the delegating object itself.  In other words, when it queried the
child context, the bean in the parent was returned, not the one in the
child.  I would've thought this to be the other way around - querying the
child context would result in first its registry being checked, and then if
no bean was found a call to the parent?

Another, unreleated issue I am having is the ClasspathXmlApplicationContext
and related implementations are not serializable.  Is there any reason that
this is not supported?  In my case I have transactional state managed in a
flow-scoped context - it'd be nice if I could serialize the entire context
out for reconstruction of that state at a later point to facilitate server
restarts, for example.

Keith

[Springframework-developer] child context lookups

[Keith D. <ke...@in...>]

I have a question about context hierarchy.

 

I've run into a situation where I have a "delegating bean" (a singleton) in
a parent context, making a lookup to a delegate instance in a flow-scoped
child context.  For transparency, the delegating bean and the delegate share
the same bean name.

 

This sounded fine to me, but I was greeted by a StackOverflowError within
the delegating bean implementation when it tried to lookup the delegate.
This happened because instead of getting the delegate, I got a reference
back to the delegating object itself.  In other words, when it queried the
child context, the bean in the parent was returned, not the one in the
child.  I would've thought this to be the other way around - querying the
child context would result in first its registry being checked, and then if
no bean was found a call to the parent?

 

Another, unreleated issue I am having is the ClasspathXmlApplicationContext
and related implementations are not serializable.  Is there any reason that
this is not supported?  In my case I have transactional state managed in a
flow-scoped context - it'd be nice if I could serialize the entire context
out for reconstruction of that state at a later point to facilitate server
restarts, for example.

 

Keith

[Springframework-developer] spring build.275 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050603001643Lbuild.275