springframework-developer — Spring Framework developers list

Re: [lists] Re: [Springframework-developer] java.util.Map fields and commons validator

[Peter d. H. <pe...@de...>]

Colin Sampaleanu wrote:

> The existing spring approach is also similar to OGNL. In OGNL, '(' is
> used for an actual method call [...] It would make the validation usage
> a bit more similar to commons-validator/struts, but would muddy the
> water for general expression syntax.

Indeed; at some point we might want to support OGNL-like method invocations
and we would have made the expression language a lot more difficult to
parse, implement and also to read. Of course the JSP EL also supports
function invocations, using the foo:bar() syntax. Supporting a property(foo)
syntax might end up being a liability rather than an asset.

 - Peter

Re: [Springframework-developer] Has our JIRA moved?

[Mike Cannon-B. <mi...@at...>]

Apologies - it seems in getting the Confluence instance up we 
accidentally changed a wrong rewrite rule (say that 10 times in a 
hurry). Should be back again now.

M
--
ATLASSIAN - http://www.atlassian.com/

Confluence - the professional J2EE wiki - tried it yet?
http://www.atlassian.com/confluence/

On 15/04/2004, at 10:10 PM, Colin Sampaleanu wrote:

> Same here. Ditto for the Confluence instance.
>
> Darren Davison wrote:
>
>> I get 404 for all JIRA bookmarks and links I have (including the one 
>> on
>> the Spring website).  Has it moved, or is there a temporary glitch?
>>
>>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Re: new jms development, request for comments.

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

Some thoughts--and I've copied this to the dev list.

----- Original Message -----
From: "Mark Pollack"
Sent: Friday, April 09, 2004 6:00 PM
Subject: new jms development, request for comments.


> Hi everyone,
>
>
> I wanted to get some feedback on the spring JMS support I was planning to
> implement and put in the sandbox.  If you feel this should get send to the
> dev mailing list just let me know. It is a long emai....
>
> At the high level send and recieve functionality are handled seprately, as
> they are currently in the sandbox code.  This makes sence especially in
> the case of J2EE usage since all J2EE users are interested in doing in
> client code is sending since the container creates the receiving
> infrastructure.
>
> JmsTemplate
> -----------
>
> I was thinking that the JmsTemplate class/classes should be changed to an
> interface.
+1.

>The main motivation for this right now is because of the
> changes between JMS 1.0.2 and 1.1. Not only has the api changed, which in
> itself maybe isn't so important, but the new API adds news functionality
> such as the ability to mix sending on topics and queues using the same
> session and within the same transaction.  Other reasons relate to more
> advanced usage of how we might handle session management - more on that
> later.
>
> I was also thinking of a name change, to JmsSender or JmsProducer, to have
> commonality with the existing spring mail package and it seems to express
> better what functionality the class offers.  This interface would offer
> methods much like those in the JMS 1.1 MessageProducer interface, various
> send methods and also provide methods for use with a MessageCreator and
> do perform a sync request/reply.  The reason a Destination object should
> be in the signatures is in the case of sending to a destination defined in
> an incoming messages Message.getJMSReplyTo() It will also be possible to
> send to a destination specifying the jndi string of the destinaton,
> proably the most common usage.  There should also be some accomdation to
> allow transactional sending of multiple messages.
I like JmsSender.
>

> MDB Helper Classes
> ------------------
> The most basic of which would make it easy to get at the spring app
context.
There is an existing superclass for MDBs in the ejb.support package. Might
be best to improve that if necessary, or add a new subclass with whatever
extra functionality you want. It allows access to the context.

I guess there are 2 cases we need to support for message consumers: making
MDBs easier to use (via easy access to IoC etc.) and providing some level of
convenient JMS consumption ability without EJB.


> Connection and Session management.
> ----------------------------------
> Just like in the case of jdbc, you really don't want to actually create
> and close a connection for each send operation, so a JMS connection pool
> is necessary.  One straightforward way to do this is to provide
> implementations of the ConnectionFactory interface that perform the
> pooling, much like how connection pooling is done is jdbc using the
> Datasource interface.
> There is definetly value for us to provide implementations of the
> ConnectionFactory that will perform connection/session pooling for any
> vendors JMS impl.  The Weblogic JMS impl provides JMS connections/session
> pooling features as do others.  However, some don't and support varies in
> the details.  I need to look into this more.
So long as we don't make it hard to use efficient application server pooling
I think having our own ConnectionFactory implementations makes sense.

> Session pooling is more significantly more complicated and I need to look
> into it more. Unlike JDBC, JMS connections are thread safe and not the
> focal point of JMS functionality. JMS sessions are where all the action
> occurs are not thread safe.  Sessions are considered to be 'lightweight'
> objects, as mentioned in the JMS spec, but Weblogic considers them to
> be 'heavyweight', and so they are reused.  Other reasons to reuse the same
> session over and over again is to ensure message ordering and to group
> multiple sends in the same transaction. The JMS spec states that ordering
> is only done if sending from the same session. This is where some other
> JmsTemplate/JmsProducer implementation might be necessary.  This case
> could also potentially be handled by a SessionFactory or strategy pattern
> inside
> an existing impl.  Session pooling would then be on a per thread and
> destination basis.
+1 for a strategy approach

>
> Exceptions
> ----------
> I guess it is a spring mandate to use runtime exceptions, though the
> existing exception heirarchy is much better than in the case of jdbc.
> There is a vendor code, but I've really seen it used much to classify
> errors.  The work here would be to preserve the existing heirarchy but
> switch them all to runtime.... this gives me a wierd feeling..

Interesting problem. Indeed, the JMS hierarchy is much better than
SQLException (not too hard). With JDBC we add value in 2 ways: making the
exceptions unchecked, and providing a meaningful hierarchy. If there is a
meaningful hierarchy the value proposition is reduced. Clearly having JMS
related exceptions unchecked is consistent with the rest of Spring however,
which is important.

>
> Stand-alone Usage
> -----------------
> This relates to the creation of message listeners and also the
> 'mini-container' or JmsService that would be used to set it all up.  More
> on this another time.
>
> Client Side Selector
> --------------------
> Use the client side selector in a MDB or stand-alone message listener to
> aid in message routing/processing.
>
>
> JMS Marshalling
> ----------------
> I have robust JMS<->Bean converter which we have found to be incredibly
> useful.  Might add some send methods to the JmsProducer in order to
> automatically convert....
>
>
> Misc
> ----
> A pretty printer for messges, always nice for debugging purposes.
>
>
>
> Why not to use commons-messenger.
> ---------------------------------
>
> I reviewed the commons-messenger API and while it does offer 'domain
> unfication' it falls short in other areas.
>
> 1) The approach they took in managing/caching the connections/sessions
> does not use the approach of using a different implementation of the
> ConnectionFactory interface. Instead is done inside each 'messenger'
> instance with their own custom classes. This means that people could not
> leverage advanced features offered by weblogic and other vendors
> since that use the ConnectionFactory approach to pooling resources.
>
> However, for advanced usage, we might need to do something similar, though
> I'd like to see how far we can go with the ConnectionFactory approach.
>
> 2) Use of checked exceptions.
>
> 3) Combines in one class the send and receive stuff, which I think is more
> naturally done in seperate clasess/interfaces.

Regards,
Rod

[Springframework-developer] Re: Spring IDE - Eclipse Plugin: Migration of SpringUI finished; Version 1.0.0 ready

[Rob M. <Rob...@pe...>]

FYI, I'm seeing the following exception when I try to use the plug-in on M8:

!ENTRY org.eclipse.ui 4 4 Apr 15, 2004 11:26:29.821
!MESSAGE Unhandled event loop exception
!ENTRY org.eclipse.ui 4 0 Apr 15, 2004 11:26:29.853
!MESSAGE Provider org.apache.xerces.parsers.XIncludeParserConfiguration 
not found
!STACK 0
org.apache.xerces.util.ObjectFactory$ConfigurationError: Provider 
org.apache.xerces.parsers.XIncludeParserConfiguration not found
	at org.apache.xerces.util.ObjectFactory.newInstance(ObjectFactory.java:252)
	at 
org.apache.xerces.util.ObjectFactory.createObject(ObjectFactory.java:163)
	at 
org.apache.xerces.util.ObjectFactory.createObject(ObjectFactory.java:123)
	at org.apache.xerces.parsers.SAXParser.<init>(SAXParser.java:95)
	at 
org.springframework.ide.eclipse.beans.core.project.ProjectDescriptionReader.read(ProjectDescriptionReader.java:78)
	at 
org.springframework.ide.eclipse.beans.core.project.ProjectDescriptionReader.read(ProjectDescriptionReader.java:58)
	at 
org.springframework.ide.eclipse.beans.core.project.ProjectDescriptionReader.read(ProjectDescriptionReader.java:43)
	at 
org.springframework.ide.eclipse.beans.core.project.BeansProject.getDescription(BeansProject.java:52)
	at 
org.springframework.ide.eclipse.beans.ui.model.RootNode.reloadConfigs(RootNode.java:75)
	at 
org.springframework.ide.eclipse.beans.ui.views.BeansView.createViewer(BeansView.java:76)
	at 
org.springframework.ide.eclipse.beans.ui.views.BeansView.createPartControl(BeansView.java:70)
	at org.eclipse.ui.internal.PartPane$1.run(PartPane.java:94)

Re: [Springframework-developer] Preparing for 1.0.1

[Les A. H. <le...@ha...>]

I'd like to jump in on this discussion since it is related to a question I'v=
e
been meaning to ask....

I tried asking a question about BMT vs. CMT declarations when coding Spring
EJB's on the user list, but apparently nobody wanted to touch that :)  So, I
figured I'd ask here and realized this thread may have something to do with =
my
subject...

I have some EJB's that are POJO backed (i.e. the common case where all the E=
JB
method does is just directly call the pojo method with the same method
signature...nothing more).  These POJO's are of course Spring configured and
use a TransactionProxyFactoryBean to allow me to declaritively control
transaction/isolation levels for the pojos.

Since I use the TransactionProxyFactoryBean to configure transactional behav=
ior
on the pojos, should I tell XDoclect when it generates by EJB deployment
descriptors that I'm using BMT instead of the default CMT?

Also, related to this thread, I noticed Colin's response about the Hibernate=
 JTA
stuff with CMT.  I am using Hibernate as well and I have a couple of EJB's t=
hat
haven't yet been POJO-ified and use XDoclet CMT declarations.  Does the newl=
y
added functionality Colin references help me in any way?  If so, how?  Of
course, I intend to fully "POJO-ify" my other EJB's and use Springs declarit=
ive
transaction management, but this may not happen as soon as I like due to
potentially disrupting my development schedule.

I should note that I'm using Hibernate as a JCA configured JBoss MBean as
described on Hibernate's website.  The mbean configuration uses the
net.sf.hibernate.transaction.JBossTransactionManagerLookup lookup strategy a=
nd
the userTransactionName ("java:/UserTransaction" for JBoss).  How does this
affect how I use Spring?  Currently I just get the Hibernate SessionFactory
using a JndiObjectFactoryBean since its already bound to JNDI via the JCA
configuration.  I also declare the JtaTransactionManager as a Spring bean
definition as described in the Spring documentation.  Do I even need to do t=
his
if I've already configured Hibernate as described above?  I mean, if I alrea=
dy
supply a transaction lookup strategy and the user transaction name in the mb=
ean
configuration, why would I need to declare a Spring JtaTransactionManager be=
an?


Your comments and insight are always gratefully received,

Les



Quoting Colin Sampaleanu <col...@ex...>:

> I've been using the CVS version without issues; actually it's even in
> production...    I have on my todo list to create a test case for
> testing the new Hibernate JTA stuff with CMT; I've been busy, but will
> make sure this is done by the weekend...
>
> Regards,
> Colin
>
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
> >Everybody,
> >
> >As we're about to release Spring 1.0.1 by the beginning of next week, we
> need to re-test the current CVS contents thoroughly. The most important ar=
ea
> is Hibernate/JTA integration: Flushing failures should now be handled
> properly; and ThreadLocal Sessions should work without JtaTransactionManag=
er
> too, as long as there's a Hibernate TransactionManagerLookup configured.
> >
> >As a side note: Hibernate's TransactionManagerLookup can be configured vi=
a
> Spring too, passing a javax.transaction.TransactionManager into
> LocalSessionFactoryBean's "jtaTransactionManager" property. Normally, this
> will be a JndiObjectFactoryBean reference, possibly shared with
> JtaTransactionManager (i.e. passed into the latter's "transactionManager"
> property too).
> >
> >If anyone finds some further areas in the documentation that need complet=
ion
> or polishing, please address them this week rather than next one :-)
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag von
> j=FCrgen h=F6ller [werk3AT]
> >Gesendet: Fr 09.04.2004 07:57
> >An: spr...@li...
> >Betreff: Re: [Springframework-developer] Preparing for 1.0.1
> >
> >
> >
> >"AbstractPrototypeBasedTargetSource" may be a bit wordy, but I like it, a=
s
> it hits the nail: "prototype-based" is what it is. I've got a new favourit=
e
> :-)
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag von
> Rod Johnson
> >Gesendet: Do 08.04.2004 20:21
> >An: spr...@li...
> >Betreff: Re: [Springframework-developer] Preparing for 1.0.1
> >
> >
> >
> >AbstractDynamicTargetSource is OK by me, although I'm not in love with it=
.
> >Technically of course a dynamic target source need not use the bean facto=
ry
> >at all. But AbstractPrototypeBasedTargetSource is a bit wordy...
> >
> >----- Original Message -----
> >From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> >To: <spr...@li...>
> >Sent: Thursday, April 08, 2004 5:27 PM
> >Subject: Re: [Springframework-developer] Preparing for 1.0.1
> >
> >
> >Final decision here? I still vote for "AbstractDynamicTargetSource"; at
> >least against "AbstractPrototypeTargetSource".
> >
> >Juergen
> >
> >
> >-----Original Message-----
> >From: spr...@li...
> >[mailto:spr...@li...]On Behalf
> >Of j=FCrgen h=F6ller [werk3AT]
> >Sent: Monday, April 05, 2004 9:51 AM
> >To: spr...@li...
> >Subject: Re: [Springframework-developer] Preparing for 1.0.1
> >
> >
> >Actually, I still prefer "AbstractDynamicTargetSource": Target beans bein=
g
> >defined as prototypes is a requirement for any meaningful dynamic target
> >source strategy (no matter if one-shot, ThreadLocal or pooled), therefore=
 I
> >consider it fine that AbstractDynamicTargetSource implicitly works with
> >prototype target beans. But just PrototypeTargetSource delivers actual
> >one-instance-per-method-invocation semantics, rather than pooling instanc=
es
> >or the like.
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag von
> >j=FCrgen h=F6ller [werk3AT]
> >Gesendet: So 04.04.2004 16:25
> >An: spr...@li...
> >Betreff: Re: [Springframework-developer] Preparing for 1.0.1
> >
> >
> >
> >That's what I meant with the different meaning of the term "prototype":
> >AbstractPrototypeTargetSource just assumes that the bean that it referenc=
es
> >is a prototype, allowing to expose targets with ThreadLocal or pooling
> >semantics. On the other hand, PrototypeTargetSource actually exposes a
> >"prototype" target, i.e. a new target object on each method invocation
> >(analogous to the term "prototype" used in bean definitions).
> >
> >I agree that the term "prototype" isn't wrong in
> >AbstractPrototypeTargetSource, but it's used with somewhat different mean=
ing
> >than in PrototypeTargetSource. To avoid confusion for people that dig int=
o
> >Spring's javadoc or even implementation, we should use different terms he=
re,
> >i.e. use the term "prototype" for a more specific meaning (preferably the
> >one analogous to bean definitions).
> >
> >I'm open for other suggestions, of course!
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag von
> >Rod Johnson
> >Gesendet: So 04.04.2004 16:08
> >An: spr...@li...
> >Betreff: Re: [Springframework-developer] Preparing for 1.0.1
> >
> >
> >
> >I guess AbstractDynamicTargetSource is an improvement. I agree the naming
> >pattern isn't great, but the abstract base class _does_ work with prototy=
pe
> >definitions, so having Prototype in its name does make sense. It's not a
> >generic "Dynamic" TargetSource because it works with bean names and
> >getBeans() assuming a prototype.
> >
> >Any other suggestions? If this is renamed, I'd rather that it was
> >undebatably right.
> >
> >R
> >
> >
> >----- Original Message -----
> >From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> >To: <spr...@li...>
> >Sent: Saturday, April 03, 2004 6:46 PM
> >Subject: Re: [Springframework-developer] Preparing for 1.0.1
> >
> >
> >A minor naming issue that I've noticed: We have an
> >AbstractPrototypeTargetSource, which serves as base class for
> >PrototypeTargetSource, ThreadLocalTargetSource and
> >AbstractPoolingTargetSource. We don't have the AbstractXxx/Xxx naming
> >pattern anywhere else in the framework. (I've actually removed a similar
> >naming pattern in the AbstractAutoProxyCreator area before 1.0 final.)
> >
> >Furthermore, "AbstractPrototypeTargetSource" is actually a bit misleading=
,
> >as we're using a broader meaning of the word prototype here than found in
> >bean definitions. "PrototypeTargetSource" matches the bean definition ter=
m
> >exactly, but the base class is more generic: So what about renaming it to
> >"AbstractDynamicTargetSource" or the like, indicating that it serves as b=
ase
> >class for all non-singleton TargetSources?
> >
> >Like the AopUtils move, this should be fine in terms of compatibility lev=
el,
> >as the base class is not part of the public API but rather an internal
> >implementation detail. PrototypeTargetSource and co will still be fully
> >backward compatible after that change, and I doubt that anyone has
> >implemented custom TargetSources yet (and even if, it's trivial to adapt)=
.
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag von
> >Rod Johnson
> >Gesendet: Fr 02.04.2004 16:53
> >An: spr...@li...
> >Betreff: Re: [Springframework-developer] Preparing for 1.0.1
> >
> >
> >
> >I suggest that we sit on this code for at least a week until we release i=
t,
> >so we can catch anything else. How about we target Monday week for releas=
e?
> >
> >A 1.0.1 release should be driven by stability, not date, so we should see=
 if
> >any more issues come out of the woodwork.
> >
> >----- Original Message -----
> >From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> >To: <spr...@li...>
> >Sent: Friday, April 02, 2004 10:57 AM
> >Subject: [Springframework-developer] Preparing for 1.0.1
> >
> >
> >Hi everybody,
> >
> >From my point of view, the code is ready for release 1.0.1. There were a
> >couple of bug fixes and minor enhancements since 1.0 final. The most
> >important fix is proper Hibernate/JTA resource management when flush fail=
s.
> >Enhancements include the introduction of the MessageCodesResolver interfa=
ce
> >in the validation package, and a more efficient internal implementation o=
f
> >AbstractMessageSource. See the changelog for details.
> >
> >Please give the current CVS snapshot a try. There shouldn't be any issues=
,
> >as changes are minor and just affect specific functionality. I'd like to
> >target mid next week for the release, i.e. two weeks after 1.0 final. In =
the
> >meantime, the only thing I plan to address is the lack of remoting covera=
ge
> >in the reference docs. If anyone feels the need to improve other parts of
> >the docs, please do so till mid next week!
> >
> >Juergen
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] BeanWrapper and anonymous class overrides

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

I have a case for failure with getPropertyValue() on BeanWrapper and was
wondering if anyone could shed some light...

Here's the situation -

- In my test suite, I have a static inner class called "TestBean" with
several properties that return dummy values.
- In one of my test cases, I create a new instance of TestBean, =
anonymously
overriding several of the public getters to return different values.

On the BeanWrapper getPropertyValue() call I get this exception:

org.springframework.beans.FatalBeanException: Illegal attempt to get
property 'test' threw exception; nested exception is

java.lang.IllegalAccessException:
	java.lang.IllegalAccessException: Class
org.springframework.beans.BeanWrapperImpl can not access a member of =
class
org.springframework.rules.RulesTestSuite$1 with modifiers "public"
	at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57)
	at java.lang.reflect.Method.invoke(Method.java:317)
	at
org.springframework.beans.BeanWrapperImpl.getPropertyValue(BeanWrapperImp=
l.j
ava:459)
	at
org.springframework.beans.BeanWrapperImpl.getPropertyValue(BeanWrapperImp=
l.j
ava:446)
	at
org.springframework.rules.functions.GetProperty.evaluate(GetProperty.java=
:41
)
	at
org.springframework.rules.predicates.BeanPropertiesExpression.test(BeanPr=
ope
rtiesExpression.java:70)
	at
org.springframework.rules.predicates.UnaryOr.test(UnaryOr.java:66)
	at
org.springframework.rules.predicates.CompoundBeanPropertyExpression.test(=
Com
poundBeanPropertyExpression.java:68)
	at org.springframework.rules.Rules.test(Rules.java:154)
	at
org.springframework.rules.RulesTestSuite.testCompoundRules(RulesTestSuite=
.ja
va:246)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39
)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl
.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTes=
tRu
nner.java:410)
	at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunn=
er.
java:294)
	at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRun=
ner
.java:182)

Is this just not supported?  I guess I was expecting it to work.

Keith

RE: [Springframework-developer] Portlet and JSFs

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

Interesting approach they're taking. However, there are a couple of real
nasty things going on there as far as I can see.

In their bridges/adapters intro (using underlying controllers/actions =
for
both portlet- and servlet-based apps) they're mentioning two approaches;
either modifying the underlying framework in some way or modifying /
rewriting the HTML coming from the Servlet (which in this case would be =
the
Spring dispatcher servlet). I really don't like the last approach and
certainly do not think it should be part of a solution Spring is =
offering.
The first solution would be the way to go but that means we'll have to
modify/rewrite the current MVC package, or at least, the infrastructural
code. This is a non-option of course.

To be honest I can't think of a way to get our current controller
infrastructure to work with portlets, except for manually forwarding an
incoming ActionRequest to a Servlet using the PortletRequestDispatcher. =
This
is only allowed when executing the render method of the Portlet =
interface.
Forcing users to only use the render method is not really a good thing =
to do
IMHO.

Getting the applicationcontext available through a FrameworkPortlet is =
the
first step I think and this is one thing that should be available in =
Spring
core (it's only a couple of classes). How to go on after that is still
unclear for me.

Opinions?

Alef






> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of William G. Thompson, Jr.
> Sent: Wednesday, April 14, 2004 3:16 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet and JSFs
>=20
> this also might help...
> =
http://exo.sourceforge.net/multiproject/exo-portlet-framework/index.html
>=20
> Dmitriy Kopylenko wrote:
> > Here what the eXo platform did with Bridges/Adapters approach:
> > http://exo.sourceforge.net/bridges-intro.html (the source code is
> available)
> >
> > Regards,
> > Dmitriy.
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On =
Behalf
> Of
> > Alef Arendsen
> > Sent: Wednesday, April 14, 2004 5:40 AM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] Portlet and JSFs
> >
> >
> > Ok, back in town ;-).
> >
> > I think an approach of making the context available is a good first
> step.
> > From there later on we could possibly extend things to include =
mappings
> > based on portal mode, window state and maybe other criteria. But =
since
> I'm
> > seeing a lot of code getting duplicated if we go ahead there, I want =
to
> take
> > things slowly to see what the other options are.
> >
> > To get the context available, I think it's best to create something =
like
> a
> > FrameworkPortlet (similar to the FrameworkServlet). This allows for
> further
> > extension later on (possibly the creation of a DispatcherPortlet if =
we
> need
> > it).
> >
> > So: FrameworkPortlet extends PortletBean extends GenericPortlet,
> > offering the same functionality as the FrameworkServlet. I think
> extending
> > ApplicationContext to get a PortletApplicationContext is needed as =
well,
> to
> > allow for access to the PortletContext (instead of the =
ServletContext).
> >
> > This is the approach I've been taking last time I spent time on it. =
If
> we
> > can continue this discussion a bit to see what everybody thinks, =
then
> I'll
> > probably be able to implement something tomorrow, Friday and over =
the
> > weekend (got some stuff lying around already so it shouldn't be that
> hard).
> >
> > Regards,
> > Alef
> >
> >
> >
> >>-----Original Message-----
> >>From: spr...@li...
> >>[mailto:spr...@li...] On
> >>Behalf Of William G. Thompson, Jr.
> >>Sent: Wednesday, April 14, 2004 1:30 AM
> >>To: spr...@li...
> >>Subject: Re: [Springframework-developer] Portlet and JSFs
> >>
> >>j=FCrgen h=F6ller [werk3AT] wrote:
> >>
> >>>But what criteria do you base your dispatching on when there's no
> >>>URL?
> >>
> >>Request parameters?
> >>
> >>yes, plus perhaps the Portal Mode (edit,view,help,...) and maybe =
some
> >>state...
> >>
> >>and of course the other tricky bit is the two step
> >>call...ActionRequest/Response and then some time later the
> >>RenderRequest/Response.
> >>
> >>
> >>>Juergen
> >>>
> >>>
> >>>________________________________
> >>>
> >>>Von: spr...@li... im
> >>>Auftrag
> >>
> >>von Eduardo Issao Ito
> >>
> >>>Gesendet: Di 13.04.2004 22:15
> >>>An: spr...@li...
> >>>Betreff: Re: [Springframework-developer] Portlet and JSFs
> >>>
> >>>
> >>>
> >>>j=FCrgen h=F6ller [werk3AT] wrote:
> >>>
> >>>
> >>>>>Portlets can not access the URL that the client used to initiate
> >>>>>the
> >>
> >>request on the portal.
> >>
> >>>>
> >>>>While that makes sense, it effectively makes me wonder whether we
> >>>>need a
> >>
> >>Portlet dispatcher: With Servlets, dispatching is all about flexible
> >>URL mapping. AFAIK, Portlets have doView, doEdit etc callbacks,
> >>similar to doGet, doPost, etc from the Servlet API.
> >>
> >>>>So for typical Portlets, it's probably most important to allow for
> >>>>easy
> >>
> >>access to Spring facilities from those methods, rather than dispatch
> >>to some other components from a Portlet doView method. Portlet =
support
> >>classes similar to the ones I just added for Struts come to my mind.
> >>
> >>>>This doesn't seem to be much effort at all. Am I on the wrong =
track
> >>
> >>here?
> >>
> >>>>Juergen
> >>>
> >>>
> >>>While in most cases a Portlet should be simple (just display some
> >>>info), sometimes one portlet can be a complete web application in
> >>>itself. In
> >>
> >>this case,
> >>
> >>>having an MVC framework can make a huge difference. Imagine
> >>>implementing
> >>
> >>a whole
> >>
> >>>web application inside a servlet doPost(), and no framework
> >>>underneath.
> >>
> >>With
> >>
> >>>portlets you only have doView() to do the same thing...
> >>>
> >>>A PortletDispatcher should be very similar to ServletDispatcher and
> >>
> >>reuse
> >>
> >>>everything that is possible from the actual mvc framework. Ideally,
> >>
> >>implementing
> >>
> >>>a portlet with Spring should be the same as implementing a servlet.
> >>>
> >>>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by: IBM Linux Tutorials
> >>Free Linux tutorial presented by Daniel Robbins, President and CEO =
of
> >>GenToo technologies. Learn everything from fundamentals to system
> =
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> =
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO =
of
> GenToo
> > technologies. Learn everything from fundamentals to system
> > =
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO =
of
> > GenToo technologies. Learn everything from fundamentals to system
> > =
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring IDE - Eclipse Plugin: Migration of SpringUI finished; Version 1.0.0 ready

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

Torsten Juergeleit wrote:

>J=FCrgen,
>
> =20
>
>>So if you encounter any issues till Sunday, feel
>>free to address them and send me a new zip.
>>   =20
>>
>
>I am fine with the version 1.0.0 available from
>http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/.
>
>Btw. is this address for the Eclipse plugin's
>"official" update site ok
>(http://springframework.sourceforge.net/... instead of
>http://www.springframework.org/...)?
>
> =20
>
>>Has anyone else already tried this plugin release?
>>   =20
>>
>
>Two SpringUI users which complained about the missing
>support for inner beans are already using this plugin
>release (via update from
>http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/).
>In the company I am working for some developers are
>using this plugin release (with Eclipse 2.1.2) too.
>
>Colin, are you using this plugin release with Eclipse
>3.0 too?
> =20
>
Yes, it's been working great for me in 3.0M7 and M8...

Re: [Springframework-developer] Has our JIRA moved?

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

Same here. Ditto for the Confluence instance.

Darren Davison wrote:

>I get 404 for all JIRA bookmarks and links I have (including the one on
>the Spring website).  Has it moved, or is there a temporary glitch?
>
>  
>

Re: [Springframework-developer] Spring IDE - Eclipse Plugin: Migration of SpringUI finished; Version 1.0.0 ready

[Torsten J. <tju...@ya...>]

Jürgen,

> So if you encounter any issues till Sunday, feel
> free to address them and send me a new zip.

I am fine with the version 1.0.0 available from
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/.

Btw. is this address for the Eclipse plugin's
"official" update site ok
(http://springframework.sourceforge.net/... instead of
http://www.springframework.org/...)?

> Has anyone else already tried this plugin release?

Two SpringUI users which complained about the missing
support for inner beans are already using this plugin
release (via update from
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/).
In the company I am working for some developers are
using this plugin release (with Eclipse 2.1.2) too.

Colin, are you using this plugin release with Eclipse
3.0 too?


I am busy working on an update of the plugin. This
will contain spring-core.jar 1.0.1, some minor bug
fixes and a few preparations for an additional editor
plugin.

This update release 1.0.1 will be ready next week.

The new editor plugin will use GEF to display a
directed graph of Spring beans from a selected config
file or config set in the Beans Config view. Later I
will add a Spring-aware XML editor with
auto-completion for bean classes and bean properties.

A first preview of the graph view will be ready end of
this month.

Torsten

--- jürgen_höller_[werk3AT]
<jue...@we...> wrote:
> Torsten,
>  
> Sorry for the late reply - I think I finally got it
> ;-)
>  
> Regarding the version number, it's OK to stay with
> 1.0.0 if that is recommended for Eclipse plugins. (I
> noticed this with FreeMarker's Eclipse plugin too.)
> I'll also leave the file name as-is if you say it is
> viable :-)
>  
> I'll do the actual upload to SourceForge together
> with Spring 1.0.1 on Sunday. I'd also like to
> announce the plugin release in the Spring 1.0.1
> announcement mail.
>  
> So if you encounter any issues till Sunday, feel
> free to address them and send me a new zip. Has
> anyone else already tried this plugin release?
>  
> Juergen
>  
> 
> ________________________________
> 
> Von:
>
spr...@li...
> im Auftrag von Torsten Juergeleit
> Gesendet: Mi 07.04.2004 18:01
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Spring IDE
> - Eclipse Plugin: Migration of SpringUI finished;
> Version 1.0.0 ready
> 
> 
> 
> Jürgen,
> 
> some infos regarding "Eclipse for Runaways" ;-)
> 
> > Ehm, (Eclipse newbie here), you want me to upload
> > the updatesite zip as file release? Shouldn't it
> > rather be some installation zip a la
> > "spring-ide-eclipse.zip"?
> 
> The file
>
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/updatesite_1.0.0.zip
> is not a "normal" archive with Eclipse plugins which
> you can unzip in the Eclipse plugins folder. Instead
> it's a copy of the whole update site
>
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/
> which you can download (and use locally) if you are
> sitting behind a restrictive proxy / firewall (like
> me
> :-( ) which does not allow your Eclipse update
> manager
> to install Eclipse plugins via an internet
> connection.
> 
> Distributing Eclipse plugins via the Eclipse update
> manager mechanism is the way recommended by the
> Eclipse team. The update site (which allows to
> install
> the plugins via Eclipse update manager) should be
> IMHO
> our preferred distribution channel. The additional
> file release is only a goody for corporate admins
> supporting a network installation of multiple
> Eclipse
> users or Eclipse users behind a restricted proxy.
> 
> With the update site we have no information about
> the
> download / usage count. But who cares about numbers
> ;-)
> 
> 
> IMHO using the prefix "spring-ide-" for the file
> release of the update site is redundant. This prefix
> is the same as the package name of the corresponding
> file release. So we will have (in addition to the
> already existing file release package
> "springframework") a new package named "spring-ide /
> eclipse" or "spring-ide-eclipse".
> 
> For an example please refer to the old SpringUI file
> releases
>
http://sourceforge.net/project/showfiles.php?group_id=99715
> 
> 
> > Regarding the version number, we use "1.0" rather
> > than "1.0.0" with the Spring distribution itself,
> so
> > it's probably advisable to use the same numbering
> > scheme with the Eclipse plugin.
> 
> Hhmm, the versioning schema for Eclipse plugins /
> features / fragments is <major>.<minor>.<service>.
> 
> Quote from
>
http://www.eclipse.org/documentation/html/plugins/org.eclipse.platform.doc.isv/doc/reference/misc/eclipse_install.html
> :
> 
> "...
> The version identifier follows the format defined by
> Eclipse for plug-in version identifiers (see javadoc
> for PluginVersionIdentifier class). It is a 3-part
> numeric identifier consisting of major, minor and
> service components (eg. 2.4.11)
> ..."
> 
> No problem with an initial release 1.0 but how about
> maintenance releases?
> 
> 
> Btw. where should the Eclipse update site be hosted?
> Is
>
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/
> ok?
> 
> If we are hosting it on
> http://www.springframework.org/ then we need a place
> to upload new versions ready to be transfered to our
> website. IMHO sending new versions via mail is no
> viable option.
> 
> Torsten
> 
> --- jürgen_höller_[werk3AT]
> <jue...@we...> wrote:
> > Torsten,
> >
> > Ehm, (Eclipse newbie here), you want me to upload
> > the updatesite zip as file release? Shouldn't it
> > rather be some installation zip a la
> > "spring-ide-eclipse.zip"? I guess I have to learn
> > something about how Eclipse plugins are
> distributed
> > :-)
> >
> > Regarding the version number, we use "1.0" rather
> > than "1.0.0" with the Spring distribution itself,
> so
> > it's probably advisable to use the same numbering
> > scheme with the Eclipse plugin.
> >
> > As we're about to release Spring 1.0.1 next week,
> > I'd like to do the Eclipse plugin 1.0 release in
> the
> > same SourceForge upload session, and annouce both
> in
> > the same mail. So there's still time to educate me
> > in terms of Eclipse plugin distributions ;-)
> >
> > Juergen
> >
> >
> > -----Original Message-----
> > From:
> >
>
spr...@li...
> >
>
[mailto:spr...@li...]On
> > Behalf
> > Of Torsten Juergeleit
> > Sent: Monday, April 05, 2004 10:43 PM
> > To:
> spr...@li...
> > Subject: [Springframework-developer] Spring IDE -
> > Eclipse Plugin:
> > Migration of SpringUI finished; Version 1.0.0
> ready
> >
> >
> > I finished migrating the SpringUI Eclipse plugin
> > into
> > the Spring CVS (new module 'spring-ide/eclipse/').
> >
> > Now I am looking for a place to host the Eclipse
> > plugin's update site (web site with a config XML
> > file
> > and two folders holding the plugin data). The
> update
> > site is used by Eclipse's update manager to
> download
> > different versions of the plugin directly from
> with
> > the IDE. Also an HTML file and a few screen copies
> > (with some infos about the plugin and it's update
> > site) has to be hosted somewhere.
> >
> > To give an example I have stored the stuff in
> > Spring's
> > (unused) webspace on SF.NET. The installation
> infos
> > can be found on
> >
>
http://springframework.sourceforge.net/spring-ide/eclipse/
> > and the update site is available from
> >
>
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/.
> 
=== message truncated ===



	
		
__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html

[Springframework-developer] Has our JIRA moved?

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

I get 404 for all JIRA bookmarks and links I have (including the one on
the Spring website).  Has it moved, or is there a temporary glitch?

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

Re: [Springframework-developer] Confluence & Docs

[Hans D. <co...@po...>]

Only thing to consider is how to maintain the moved documentation.

Hans

> +1
>
> Also a wiki is often more informal... some stuff in the wiki is cool right
> where it is and never needs to be moved elsewhere.
>
> ----- Original Message -----
> From: "Keith Donald" <kd...@cs...>
> To: <spr...@li...>
> Sent: Wednesday, April 14, 2004 7:33 PM
> Subject: RE: [Springframework-developer] Confluence & Docs
>
>
> I agree with that.  I've always intended on using it to write
> documentation
> on new, still-to-be-released features which shouldn't be part of the main
> reference manual yet.  The agile format of a wiki allows for those docs to
> get posted, reviewed, edited quickly (perfect forum I think for flushing
> out
> the docs...) then after they're more mature and the features they cover
> are
> released and supported, move it to the more formal docbook/pdf format.
>
>>I don't think that keeping the documentation in two places (docbook and
> wiki)
> are a good idea... The wiki should be considered as a scrapbook where
> documentation is developed and when mature enough moved to the official
> reference document.
>
>
>
>
>

[Springframework-developer] RE: default error message

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

Karl,

Good point. That is a problem with the createMessage() function. I took your
suggestion and removed all of the "???" delimiters from the default
messages. I also changed the implementation of the getArgs() function to
observe the resource="false" so the argument fields will not try to resolve
a message when resource="false" is specified.

Oddly enough, the implementation of the Msg class in the Commons-Validator
(from what I can tell) totally ignores the resource="false" attribute in the
<msg> tag. Consequently, there is no way to detect if the message associated
with a Field is actually a message resource or a literal value. On the
brighter side, I don't know how I would implement this differently anyway.
It doesn't look like there is a way to invoke the Spring
Errors.rejectValue() function without an "errorCode" parameter (although it
may be possible to mangle the errorCode parameter in some way to ensure that
a message resource would never be resolved, but that sounds a bit too
hackish to me). The only possible disadvantage here is the possibility that
a message resource with a key that matches the literal message to be
displayed would override the value. For example the following configuration:

  messages.properties
    Required=Value

  validation.xml
    ...
    <msg name="required" key="Required" resource="false" />
    ...

would render the message as "Value" even if you wanted it to be "Required"
because the "Required" property in the messages.properties file would
override the literal value. Luckily this will not be a problem most of the
time because most message resources use a naming convention that is not very
user friendly and therefore most likely would not overlap with the actual
error messages that you would want to show to a user.

I have attached the updated Resources.java file. Let me know if it doesn't
solve the problem.

Thanks,
Daniel

P.S.
You can feel free to send any questions you have directly to the Dev list
and just CC me.

P.P.S.
Keith, please replace the old resources file with this new one. Thanks.

-----Original Message-----
From: Baum, Karl [mailto:Kar...@Ta...]
Sent: Tuesday, April 13, 2004 8:31 PM
To: 'Daniel Miller'
Subject: default error message


Hi Daniel.  I am having some trouble displaying a string literal error
message.  Basically I am supplying the error message from the formset
element and not using the message resource bundle.  My msg element looks
like:

<msg name="validwhen" key="Are you currently working in the aquisition
field?" resource="false"/>

The error message when displayed however looks like:

???Are you currently working in the aquisition field????

I think the "???" are getting appended in the class
org.springframework.validation.commons.Resources in the method:

      public static MessageSourceResolvable createMessage(Object obj) {
            String[] codes = new String[] { String.valueOf(obj) };
            String defaultMsg = "???" + codes[0] + "???";
            MessageSourceResolvable msg =
                        new DefaultMessageSourceResolvable(codes, null,
defaultMsg);
            return msg;
      }

I think these "???" can be removed but I am unsure.  Thanks aging for your
help.  Talk to you soon.


Karl Baum
Work (212) 213-5199 X3408
Cell (917) 439-1791

Re: [Springframework-developer] Spring wiki

[Mike Cannon-B. <mi...@at...>]

Darren,

Damn - seems to be a bug. Thanks for the report!

I've filed it online, and will be fixed in the next patch release=20
(1.0.3):

    http://jira.atlassian.com/browse/CONF-1101

For now subscribe to the individual space feeds as a workaround.

Cheers,
Mike

--
ATLASSIAN - http://www.atlassian.com/

Confluence - the professional J2EE wiki - tried it yet?
http://www.atlassian.com/confluence/

On 15/04/2004, at 10:15 AM, Darren Davison wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 14 April 2004 07:19, Mike Cannon-Brookes wrote:
>
>> Seriously - any questions about setup etc, please ask me (either on=20=

>> the
>> list or via any possible contact means -
>> http://conflence.atlassian.com/display/~mi...@at... for
>> details).
>
> Hi Mike,
>
> The global RSS feed seems to have a rogue closing parenthesis ")" at =20=

> the
> end of each link..
> http://opensource.atlassian.com/confluence/spring/globalrss.action
>
> Obviously clicking on such a link in an RSS aggregator throws up a
> confluence application error.  Doesn't seem to affect any other RSS=20
> link
> from what I can see.
>
> Regards,
>
>
> - --
>
> Darren Davison
> Public Key: http://www.davison.uk.net/key.jsp
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFAfdQvKLMLAN01aw0RAgUyAJwPjaC9rnMSa1PHpRhg9c/HtlnivgCeNogU
> dw6EJSzXeBtAdWCzYxsJ2RU=3D
> =3DJTBA
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Spring wiki

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

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

On Wednesday 14 April 2004 07:19, Mike Cannon-Brookes wrote:

> Seriously - any questions about setup etc, please ask me (either on the
> list or via any possible contact means -
> http://conflence.atlassian.com/display/~mi...@at... for
> details).

Hi Mike,

The global RSS feed seems to have a rogue closing parenthesis ")" at  the=20
end of each link..
http://opensource.atlassian.com/confluence/spring/globalrss.action

Obviously clicking on such a link in an RSS aggregator throws up a=20
confluence application error.  Doesn't seem to affect any other RSS link=20
from what I can see.

Regards,


=2D --=20

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

iD8DBQFAfdQvKLMLAN01aw0RAgUyAJwPjaC9rnMSa1PHpRhg9c/HtlnivgCeNogU
dw6EJSzXeBtAdWCzYxsJ2RU=3D
=3DJTBA
=2D----END PGP SIGNATURE-----

Re: [Springframework-developer] Confluence & Docs

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

+1

Also a wiki is often more informal... some stuff in the wiki is cool right
where it is and never needs to be moved elsewhere.

----- Original Message -----
From: "Keith Donald" <kd...@cs...>
To: <spr...@li...>
Sent: Wednesday, April 14, 2004 7:33 PM
Subject: RE: [Springframework-developer] Confluence & Docs


I agree with that.  I've always intended on using it to write documentation
on new, still-to-be-released features which shouldn't be part of the main
reference manual yet.  The agile format of a wiki allows for those docs to
get posted, reviewed, edited quickly (perfect forum I think for flushing out
the docs...) then after they're more mature and the features they cover are
released and supported, move it to the more formal docbook/pdf format.

>I don't think that keeping the documentation in two places (docbook and
wiki)
are a good idea... The wiki should be considered as a scrapbook where
documentation is developed and when mature enough moved to the official
reference document.

[Springframework-developer] Javablogs 1.2 powered by spring

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

pretty cool...

http://confluence.atlassian.com/display/JAVABLOGS/2004/04/13/Javablogs+1.2

Keith
 
 

[Springframework-developer] Typos in reference docs

[Eduardo I. I. <zi...@su...>]

I've found some minor errors in the MVC chapter of reference docs:

jsut
focussing
webapplication
webapplicationcontext
oject
Rseolver
that is knows to which servlet

Section 2:
"The WebApplicationContext is bound in the ServletContext, and using 
RequestContextUtils you can always lookup the WebApplicationContext in case you 
need it."
WebApplicationContextUtils would be a more natural choice.

Re: [Springframework-developer] java.util.Map fields and commons validator

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

Baum, Karl wrote:
> There is one other slight issue I noticed with mapped properties.  In
> addition to supporting get/set methods that work with a Map object,
> Struts suports methods that take key value pairs.  For example:
> 
> 	public void setValue(String key, String value);
> 
> 	public String getValue(String key);
> 
> This feature allows the developer to abstract the underlying
> implementation.  It also guards against external code overwriting your
> Map.  Spring does not support this because it only uses java bean
> introspection to find all properties in a bean.  These Map methods are
> not properties to Java.  

Just MHO, but I never liked that above Struts idiom.  It's easy to think 
about objects as object graphs and beans.  To me, the above breaks that 
simple object graph notation.  If what I'm trying to say is "object foo 
has a Map called bar" then the above way doesn't say that very clearly.

Here's where I think Spring does a better job than Struts in mapping 
properties and objects together.  Also, I'm -1 on adding then '(' 
support.  While I am sympathetic (I, too, am migrating Struts apps to 
Spring MVC) I'd like to take steps forward, not just simply port.  I 
think the more standard '[' makes more sense.

Seth

RE: [Springframework-developer] Confluence & Docs

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

I agree with that.  I've always intended on using it to write =
documentation
on new, still-to-be-released features which shouldn't be part of the =
main
reference manual yet.  The agile format of a wiki allows for those docs =
to
get posted, reviewed, edited quickly (perfect forum I think for flushing =
out
the docs...) then after they're more mature and the features they cover =
are
released and supported, move it to the more formal docbook/pdf format.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Eduardo Issao Ito
Sent: Wednesday, April 14, 2004 12:27 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Confluence & Docs


Alef Arendsen wrote:
> Then something else. What's the plan with the reference documentation? =

> I'd like to keep something like a PDF in place, since a lot of people=20
> like to have something offline. When we've got everything in=20
> confluence, I don't think moving it to dockbook again makes sense;=20
> that is, if a reasonable export to PDF is possible that resembles a=20
> bit...

I don't think that keeping the documentation in two places (docbook and
wiki)=20
are a good idea... The wiki should be considered as a scrapbook where=20
documentation is developed and when mature enough moved to the official=20
reference document.

Comments?


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

Re: [Springframework-developer] Confluence & Docs

[Eduardo I. I. <zi...@su...>]

Alef Arendsen wrote:
> Then something else. What's the plan with the reference documentation? I'd
> like to keep something like a PDF in place, since a lot of people like to
> have something offline. When we've got everything in confluence, I don't
> think moving it to dockbook again makes sense; that is, if a reasonable
> export to PDF is possible that resembles a bit...

I don't think that keeping the documentation in two places (docbook and wiki) 
are a good idea... The wiki should be considered as a scrapbook where 
documentation is developed and when mature enough moved to the official 
reference document.

Comments?

Fw: [Springframework-developer] Portlet and JSFs

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

Thanks Dmitriy...I created two spaces:

Spring Documentation Sandbox (DOC)  (is this a decent name? for future
release preliminary docs/discussions.)

    and

Spring Rich Client Platform (RCP)

Feel free to polish names of the spaces or the description, as organizati=
on
is paramount obviously when using any wiki.

----- Original Message -----=20
From: "Keith Donald" <kd...@cs...>
To: "Dmitriy Kopylenko" <dko...@ru...>
Sent: Wednesday, April 14, 2004 11:27 AM
Subject: Re: [Springframework-developer] Portlet and JSFs


> Got it. Thanks...
>
> ----- Original Message -----=20
> From: "Dmitriy Kopylenko" <dko...@ru...>
> To: "'Keith Donald'" <kd...@cs...>
> Sent: Wednesday, April 14, 2004 11:22 AM
> Subject: RE: [Springframework-developer] Portlet and JSFs
>
>
> > Keith,
> >
> > I believe it's available only to jira-administrators. I'll see if I
could
> > change that, hold on...
> >
> > -----Original Message-----
> > From: Keith Donald [mailto:kd...@cs...]
> > Sent: Wednesday, April 14, 2004 11:16 AM
> > To: dko...@su...
> > Subject: Re: [Springframework-developer] Portlet and JSFs
> >
> >
> > Dmitry,
> >
> > How did you create the new space? I can't find a "new space" action
> > anywhere!
> >
> > I am in jira-developers...
> > thanks
> > ----- Original Message -----=20
> > From: "Kopylenko, Dmitry" <dko...@su...>
> > To: <spr...@li...>
> > Sent: Wednesday, April 14, 2004 9:33 AM
> > Subject: RE: [Springframework-developer] Portlet and JSFs
> >
> >
> > > BTW I've creataed "Portlet support" space in Confluence...
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: William G. Thompson, Jr. [mailto:wg...@ru...]
> > > Sent: Wednesday, April 14, 2004 9:16 AM
> > > To: spr...@li...
> > > Subject: Re: [Springframework-developer] Portlet and JSFs
> > >
> > >
> > > this also might help...
> > > http://exo.sourceforge.net/multiproject/exo-portlet-framework/index=
.ht
> > > ml
> > >
> > > Dmitriy Kopylenko wrote:
> > > > Here what the eXo platform did with Bridges/Adapters approach:
> > > > http://exo.sourceforge.net/bridges-intro.html (the source code is
> > > > available)
> > > >
> > > > Regards,
> > > > Dmitriy.
> > > >
> > > > -----Original Message-----
> > > > From: spr...@li...
> > > > [mailto:spr...@li...] On
> > > > Behalf Of Alef Arendsen
> > > > Sent: Wednesday, April 14, 2004 5:40 AM
> > > > To: spr...@li...
> > > > Subject: RE: [Springframework-developer] Portlet and JSFs
> > > >
> > > >
> > > > Ok, back in town ;-).
> > > >
> > > > I think an approach of making the context available is a good fir=
st
> > > > step. From there later on we could possibly extend things to incl=
ude
> > > > mappings based on portal mode, window state and maybe other
> > > > criteria. But since I'm seeing a lot of code getting duplicated i=
f
> > > > we go ahead there, I want to take things slowly to see what the
> > > > other options are.
> > > >
> > > > To get the context available, I think it's best to create somethi=
ng
> > > > like a FrameworkPortlet (similar to the FrameworkServlet). This
> > > > allows for further extension later on (possibly the creation of a
> > > > DispatcherPortlet if we need it).
> > > >
> > > > So: FrameworkPortlet extends PortletBean extends GenericPortlet,
> > > > offering the same functionality as the FrameworkServlet. I think
> > extending
> > > > ApplicationContext to get a PortletApplicationContext is needed a=
s
> > > > well,
> > > to
> > > > allow for access to the PortletContext (instead of the
> > > > ServletContext).
> > > >
> > > > This is the approach I've been taking last time I spent time on i=
t.
> > > > If we can continue this discussion a bit to see what everybody
> > > > thinks, then I'll probably be able to implement something tomorro=
w,
> > > > Friday and over the weekend (got some stuff lying around already =
so
> > > > it shouldn't be that hard).
> > > >
> > > > Regards,
> > > > Alef
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: spr...@li...
> > > >>[mailto:spr...@li...] On
> > > >>Behalf Of William G. Thompson, Jr.
> > > >>Sent: Wednesday, April 14, 2004 1:30 AM
> > > >>To: spr...@li...
> > > >>Subject: Re: [Springframework-developer] Portlet and JSFs
> > > >>
> > > >>j=FCrgen h=F6ller [werk3AT] wrote:
> > > >>
> > > >>>But what criteria do you base your dispatching on when there's n=
o
> > > >>>URL?
> > > >>
> > > >>Request parameters?
> > > >>
> > > >>yes, plus perhaps the Portal Mode (edit,view,help,...) and maybe
> > > >>some state...
> > > >>
> > > >>and of course the other tricky bit is the two step
> > > >>call...ActionRequest/Response and then some time later the
> > > >>RenderRequest/Response.
> > > >>
> > > >>
> > > >>>Juergen
> > > >>>
> > > >>>
> > > >>>________________________________
> > > >>>
> > > >>>Von: spr...@li... im
> > > >>>Auftrag
> > > >>
> > > >>von Eduardo Issao Ito
> > > >>
> > > >>>Gesendet: Di 13.04.2004 22:15
> > > >>>An: spr...@li...
> > > >>>Betreff: Re: [Springframework-developer] Portlet and JSFs
> > > >>>
> > > >>>
> > > >>>
> > > >>>j=FCrgen h=F6ller [werk3AT] wrote:
> > > >>>
> > > >>>
> > > >>>>>Portlets can not access the URL that the client used to initia=
te
> > > >>>>>the
> > > >>
> > > >>request on the portal.
> > > >>
> > > >>>>
> > > >>>>While that makes sense, it effectively makes me wonder whether =
we
> > > >>>>need a
> > > >>
> > > >>Portlet dispatcher: With Servlets, dispatching is all about flexi=
ble
> > > >>URL mapping. AFAIK, Portlets have doView, doEdit etc callbacks,
> > > >>similar to doGet, doPost, etc from the Servlet API.
> > > >>
> > > >>>>So for typical Portlets, it's probably most important to allow =
for
> > > >>>>easy
> > > >>
> > > >>access to Spring facilities from those methods, rather than dispa=
tch
> > > >>to some other components from a Portlet doView method. Portlet
> > > >>support classes similar to the ones I just added for Struts come =
to
> > > >>my mind.
> > > >>
> > > >>>>This doesn't seem to be much effort at all. Am I on the wrong
> > > >>>>track
> > > >>
> > > >>here?
> > > >>
> > > >>>>Juergen
> > > >>>
> > > >>>
> > > >>>While in most cases a Portlet should be simple (just display som=
e
> > > >>>info), sometimes one portlet can be a complete web application i=
n
> > > >>>itself. In
> > > >>
> > > >>this case,
> > > >>
> > > >>>having an MVC framework can make a huge difference. Imagine
> > > >>>implementing
> > > >>
> > > >>a whole
> > > >>
> > > >>>web application inside a servlet doPost(), and no framework
> > > >>>underneath.
> > > >>
> > > >>With
> > > >>
> > > >>>portlets you only have doView() to do the same thing...
> > > >>>
> > > >>>A PortletDispatcher should be very similar to ServletDispatcher =
and
> > > >>
> > > >>reuse
> > > >>
> > > >>>everything that is possible from the actual mvc framework. Ideal=
ly,
> > > >>
> > > >>implementing
> > > >>
> > > >>>a portlet with Spring should be the same as implementing a servl=
et.
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >>-------------------------------------------------------
> > > >>This SF.Net email is sponsored by: IBM Linux Tutorials
> > > >>Free Linux tutorial presented by Daniel Robbins, President and CE=
O
> > > >>of GenToo technologies. Learn everything from fundamentals to sys=
tem
> > > >>administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dc=
lick
> > > >>_______________________________________________
> > > >>Springframework-developer mailing list
> > > >>Spr...@li...
> > > >>https://lists.sourceforge.net/lists/listinfo/springframework-deve=
lop
> > > >>er
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email is sponsored by: IBM Linux Tutorials
> > > > Free Linux tutorial presented by Daniel Robbins, President and CE=
O
> > > > of GenToo technologies. Learn everything from fundamentals to sys=
tem
> > > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dc=
lick
> > > > _______________________________________________
> > > > Springframework-developer mailing list
> > > > Spr...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/springframework-deve=
lop
> > > > er
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email is sponsored by: IBM Linux Tutorials
> > > > Free Linux tutorial presented by Daniel Robbins, President and CE=
O
> > > > of GenToo technologies. Learn everything from fundamentals to sys=
tem
> > > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dc=
lick
> > > > _______________________________________________
> > > > Springframework-developer mailing list
> > > > Spr...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/springframework-deve=
lop
> > > > er
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: IBM Linux Tutorials
> > > Free Linux tutorial presented by Daniel Robbins, President and CEO =
of
> > GenToo
> > > technologies. Learn everything from fundamentals to system
> > > administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=
=3Dclick
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-develo=
per
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: IBM Linux Tutorials
> > > Free Linux tutorial presented by Daniel Robbins, President and CEO =
of
> > > GenToo technologies. Learn everything from fundamentals to system
> > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-develo=
per
> >
>

RE: [Springframework-developer] Portlet and JSFs

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

I've added jira-developers to be able to create spaces...

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Keith Donald
Sent: Wednesday, April 14, 2004 11:21 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Portlet and JSFs


I can't seem to find the action to create a new space--I am in JIRA
developers though.

Keith

----- Original Message -----=20
From: "Kopylenko, Dmitry" <dko...@su...>
To: <spr...@li...>
Sent: Wednesday, April 14, 2004 9:33 AM
Subject: RE: [Springframework-developer] Portlet and JSFs


> BTW I've creataed "Portlet support" space in Confluence...
>
>
>
> -----Original Message-----
> From: William G. Thompson, Jr. [mailto:wg...@ru...]
> Sent: Wednesday, April 14, 2004 9:16 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet and JSFs
>
>
> this also might help...=20
> http://exo.sourceforge.net/multiproject/exo-portlet-framework/index.ht
> ml
>
> Dmitriy Kopylenko wrote:
> > Here what the eXo platform did with Bridges/Adapters approach:=20
> > http://exo.sourceforge.net/bridges-intro.html (the source code is
> > available)
> >
> > Regards,
> > Dmitriy.
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On=20
> > Behalf Of Alef Arendsen
> > Sent: Wednesday, April 14, 2004 5:40 AM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] Portlet and JSFs
> >
> >
> > Ok, back in town ;-).
> >
> > I think an approach of making the context available is a good first=20
> > step. From there later on we could possibly extend things to include =

> > mappings based on portal mode, window state and maybe other=20
> > criteria. But since I'm seeing a lot of code getting duplicated if=20
> > we go ahead there, I want to take things slowly to see what the=20
> > other options are.
> >
> > To get the context available, I think it's best to create something=20
> > like a FrameworkPortlet (similar to the FrameworkServlet). This=20
> > allows for further extension later on (possibly the creation of a=20
> > DispatcherPortlet if we need it).
> >
> > So: FrameworkPortlet extends PortletBean extends GenericPortlet,=20
> > offering the same functionality as the FrameworkServlet. I think
extending
> > ApplicationContext to get a PortletApplicationContext is needed as=20
> > well,
> to
> > allow for access to the PortletContext (instead of the=20
> > ServletContext).
> >
> > This is the approach I've been taking last time I spent time on it.=20
> > If we can continue this discussion a bit to see what everybody=20
> > thinks, then I'll probably be able to implement something tomorrow,=20
> > Friday and over the weekend (got some stuff lying around already so=20
> > it shouldn't be that hard).
> >
> > Regards,
> > Alef
> >
> >
> >
> >>-----Original Message-----
> >>From: spr...@li...
> >>[mailto:spr...@li...] On=20
> >>Behalf Of William G. Thompson, Jr.
> >>Sent: Wednesday, April 14, 2004 1:30 AM
> >>To: spr...@li...
> >>Subject: Re: [Springframework-developer] Portlet and JSFs
> >>
> >>j=FCrgen h=F6ller [werk3AT] wrote:
> >>
> >>>But what criteria do you base your dispatching on when there's no=20
> >>>URL?
> >>
> >>Request parameters?
> >>
> >>yes, plus perhaps the Portal Mode (edit,view,help,...) and maybe=20
> >>some state...
> >>
> >>and of course the other tricky bit is the two step=20
> >>call...ActionRequest/Response and then some time later the=20
> >>RenderRequest/Response.
> >>
> >>
> >>>Juergen
> >>>
> >>>
> >>>________________________________
> >>>
> >>>Von: spr...@li... im=20
> >>>Auftrag
> >>
> >>von Eduardo Issao Ito
> >>
> >>>Gesendet: Di 13.04.2004 22:15
> >>>An: spr...@li...
> >>>Betreff: Re: [Springframework-developer] Portlet and JSFs
> >>>
> >>>
> >>>
> >>>j=FCrgen h=F6ller [werk3AT] wrote:
> >>>
> >>>
> >>>>>Portlets can not access the URL that the client used to initiate=20
> >>>>>the
> >>
> >>request on the portal.
> >>
> >>>>
> >>>>While that makes sense, it effectively makes me wonder whether we=20
> >>>>need a
> >>
> >>Portlet dispatcher: With Servlets, dispatching is all about flexible =

> >>URL mapping. AFAIK, Portlets have doView, doEdit etc callbacks,=20
> >>similar to doGet, doPost, etc from the Servlet API.
> >>
> >>>>So for typical Portlets, it's probably most important to allow for =

> >>>>easy
> >>
> >>access to Spring facilities from those methods, rather than dispatch =

> >>to some other components from a Portlet doView method. Portlet=20
> >>support classes similar to the ones I just added for Struts come to=20
> >>my mind.
> >>
> >>>>This doesn't seem to be much effort at all. Am I on the wrong=20
> >>>>track
> >>
> >>here?
> >>
> >>>>Juergen
> >>>
> >>>
> >>>While in most cases a Portlet should be simple (just display some=20
> >>>info), sometimes one portlet can be a complete web application in=20
> >>>itself. In
> >>
> >>this case,
> >>
> >>>having an MVC framework can make a huge difference. Imagine=20
> >>>implementing
> >>
> >>a whole
> >>
> >>>web application inside a servlet doPost(), and no framework=20
> >>>underneath.
> >>
> >>With
> >>
> >>>portlets you only have doView() to do the same thing...
> >>>
> >>>A PortletDispatcher should be very similar to ServletDispatcher and
> >>
> >>reuse
> >>
> >>>everything that is possible from the actual mvc framework. Ideally,
> >>
> >>implementing
> >>
> >>>a portlet with Spring should be the same as implementing a servlet.
> >>>
> >>>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by: IBM Linux Tutorials
> >>Free Linux tutorial presented by Daniel Robbins, President and CEO=20
> >>of GenToo technologies. Learn everything from fundamentals to system =

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

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

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



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

Re: [Springframework-developer] Portlet and JSFs

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

I can't seem to find the action to create a new space--I am in JIRA
developers though.

Keith

----- Original Message -----=20
From: "Kopylenko, Dmitry" <dko...@su...>
To: <spr...@li...>
Sent: Wednesday, April 14, 2004 9:33 AM
Subject: RE: [Springframework-developer] Portlet and JSFs


> BTW I've creataed "Portlet support" space in Confluence...
>
>
>
> -----Original Message-----
> From: William G. Thompson, Jr. [mailto:wg...@ru...]
> Sent: Wednesday, April 14, 2004 9:16 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Portlet and JSFs
>
>
> this also might help...
> http://exo.sourceforge.net/multiproject/exo-portlet-framework/index.htm=
l
>
> Dmitriy Kopylenko wrote:
> > Here what the eXo platform did with Bridges/Adapters approach:
> > http://exo.sourceforge.net/bridges-intro.html (the source code is
> > available)
> >
> > Regards,
> > Dmitriy.
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On
> > Behalf Of Alef Arendsen
> > Sent: Wednesday, April 14, 2004 5:40 AM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] Portlet and JSFs
> >
> >
> > Ok, back in town ;-).
> >
> > I think an approach of making the context available is a good first
> > step. From there later on we could possibly extend things to include
> > mappings based on portal mode, window state and maybe other criteria.
> > But since I'm seeing a lot of code getting duplicated if we go ahead
> > there, I want to take things slowly to see what the other options are=
.
> >
> > To get the context available, I think it's best to create something
> > like a FrameworkPortlet (similar to the FrameworkServlet). This allow=
s
> > for further extension later on (possibly the creation of a
> > DispatcherPortlet if we need it).
> >
> > So: FrameworkPortlet extends PortletBean extends GenericPortlet,
> > offering the same functionality as the FrameworkServlet. I think
extending
> > ApplicationContext to get a PortletApplicationContext is needed as we=
ll,
> to
> > allow for access to the PortletContext (instead of the ServletContext=
).
> >
> > This is the approach I've been taking last time I spent time on it. I=
f
> > we can continue this discussion a bit to see what everybody thinks,
> > then I'll probably be able to implement something tomorrow, Friday an=
d
> > over the weekend (got some stuff lying around already so it shouldn't
> > be that hard).
> >
> > Regards,
> > Alef
> >
> >
> >
> >>-----Original Message-----
> >>From: spr...@li...
> >>[mailto:spr...@li...] On
> >>Behalf Of William G. Thompson, Jr.
> >>Sent: Wednesday, April 14, 2004 1:30 AM
> >>To: spr...@li...
> >>Subject: Re: [Springframework-developer] Portlet and JSFs
> >>
> >>j=FCrgen h=F6ller [werk3AT] wrote:
> >>
> >>>But what criteria do you base your dispatching on when there's no
> >>>URL?
> >>
> >>Request parameters?
> >>
> >>yes, plus perhaps the Portal Mode (edit,view,help,...) and maybe some
> >>state...
> >>
> >>and of course the other tricky bit is the two step
> >>call...ActionRequest/Response and then some time later the
> >>RenderRequest/Response.
> >>
> >>
> >>>Juergen
> >>>
> >>>
> >>>________________________________
> >>>
> >>>Von: spr...@li... im
> >>>Auftrag
> >>
> >>von Eduardo Issao Ito
> >>
> >>>Gesendet: Di 13.04.2004 22:15
> >>>An: spr...@li...
> >>>Betreff: Re: [Springframework-developer] Portlet and JSFs
> >>>
> >>>
> >>>
> >>>j=FCrgen h=F6ller [werk3AT] wrote:
> >>>
> >>>
> >>>>>Portlets can not access the URL that the client used to initiate
> >>>>>the
> >>
> >>request on the portal.
> >>
> >>>>
> >>>>While that makes sense, it effectively makes me wonder whether we
> >>>>need a
> >>
> >>Portlet dispatcher: With Servlets, dispatching is all about flexible
> >>URL mapping. AFAIK, Portlets have doView, doEdit etc callbacks,
> >>similar to doGet, doPost, etc from the Servlet API.
> >>
> >>>>So for typical Portlets, it's probably most important to allow for
> >>>>easy
> >>
> >>access to Spring facilities from those methods, rather than dispatch
> >>to some other components from a Portlet doView method. Portlet suppor=
t
> >>classes similar to the ones I just added for Struts come to my mind.
> >>
> >>>>This doesn't seem to be much effort at all. Am I on the wrong track
> >>
> >>here?
> >>
> >>>>Juergen
> >>>
> >>>
> >>>While in most cases a Portlet should be simple (just display some
> >>>info), sometimes one portlet can be a complete web application in
> >>>itself. In
> >>
> >>this case,
> >>
> >>>having an MVC framework can make a huge difference. Imagine
> >>>implementing
> >>
> >>a whole
> >>
> >>>web application inside a servlet doPost(), and no framework
> >>>underneath.
> >>
> >>With
> >>
> >>>portlets you only have doView() to do the same thing...
> >>>
> >>>A PortletDispatcher should be very similar to ServletDispatcher and
> >>
> >>reuse
> >>
> >>>everything that is possible from the actual mvc framework. Ideally,
> >>
> >>implementing
> >>
> >>>a portlet with Spring should be the same as implementing a servlet.
> >>>
> >>>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by: IBM Linux Tutorials
> >>Free Linux tutorial presented by Daniel Robbins, President and CEO of
> >>GenToo technologies. Learn everything from fundamentals to system
> >>administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-develope=
r
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-develope=
r
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-develope=
r
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo
> technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] java.util.Map fields and commons validator

[Baum, K. <Kar...@Ta...>]

My issue is more with compatibility between commons validator and
spring.  Currently today, to denote a mapped property in spring we use
the '[' character.  However when this is sent to commons validator, it
will not be able to find this property in the bean as it will be =
looking
for an indexed property as opposed to a mapped property.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On =
Behalf
Of Colin Sampaleanu
Sent: Wednesday, April 14, 2004 7:57 AM
To: spr...@li...
Subject: Re: [Springframework-developer] java.util.Map fields and
commons validator

The existing spring approach is also similar to OGNL. In OGNL, '(' is=20
used for an actual method call, since you can also call methods, not=20
just navigate graphs.

I'm a bit of mixed feelings about adding '(' support in the =
BeanWrapper.

It would make the validation usage a bit more similar to=20
commons-validator/struts, but would muddy the water for general=20
expression syntax.

Karl, your issue with the setup right now is that people can't take=20
their existing definitions exactly as-is?


j=FCrgen h=F6ller [werk3AT] wrote:

>Karl,
>=20
>Agreed, it makes sense to be consistent with Commons BeanUtils /
Commons Validator / Struts here, while still supporting the current
syntax. Our current syntax is somewhat analogous to JSTL EL, but I =
don't
mind supporting further syntactic options, as long as they don't
introduce parsing problems.
>=20
>This should be pretty trivial to add, so I'll look into it this
weekend.
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag
von Baum, Karl
>Gesendet: Mi 14.04.2004 04:19
>An: spr...@li...
>Betreff: [Springframework-developer] java.util.Map fields and commons
validator
>
>
>
>I have encountered an issue in regards to validating beans backed by a
>Map object while using the spring commons validator component.  My =
form
>is made to work with key value pairsbacked as a map.  It has a field:
>
>     /**
>      * @return
>      */
>     public Map getValue() {
>         return valueMap;
>     }
>
>     /**
>      * @param map
>      */
>     public void setValue(Map map) {
>         valueMap =3D map;
>     }
>
>The problem isn't specific to the validator adapter.  The problem has
to
>do with the way Spring symbolizes a mapped property in the
>BeanwrapperImpl class.  Spring uses a '[' where as commons validator
and
>struts use '('.  Another words a mapped property of firstName would
look
>like this in Spring:
>
> value[firstName]
>
>and this in commons validator:
>
> value(firstName)
>
>Commons validator uses '[' for indexed properties.  Spring uses '[' =
for
>both indexed and Mapped properties.  I think the best place to fix =
this
>problem is on the Spring side in the BeanWrapperImpl.  We might as =
well
>be consistent with struts and commons validator in regards to our
>indexed and mapped property sytax.  Perhaps we can support both
>syntaxes.=20
>
>Any thoughts?
>
>Karl
> =20
>




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