Menu
▾
▴
springframework-developer — Spring Framework developers list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: snpe <sn...@sn...> - 2005-04-14 13:24:06
|
Hello I try eclipse 3.1m6, gef,emf and ve for 3.1m6 and current cvs spring ide (1.2.0) - I build it on 3.1m6 (it need little changes for example, change enum field in XMLWriter class) builder work for me, graph editor work and I haven't tried xml editor (I want webtools but it be out april 22) I think that you have problem with config file - Does it work with old spring ide and eclipse 3.0 ? regards Haris Peco On Wednesday 13 April 2005 05:54 pm, Eugene Kuleshov wrote: > Hi Torsten, > > It is a good news and long awaited update. > > I've installed plugin on my Eclipse 3.1 and I'm getting a error from > builder. > > ---------- > An error occurred while traversing resources. > java.lang.IllegalStateException: Bean can only have a parent of type > IBeansConfig, IBean or (in case of an inner bean) IBeanProperty > at > org.springframework.ide.eclipse.beans.core.internal.model.Bean.getConfig(Bean.java:75) > at > org.springframework.ide.eclipse.beans.core.internal.model.BeansConfigValidator.validateBean(BeansConfigValidator.java:214) > at > org.springframework.ide.eclipse.beans.core.internal.model.BeansConfigValidator.validateConfig(BeansConfigValidator.java:148) > at > org.springframework.ide.eclipse.beans.core.internal.model.BeansConfigValidator.validate(BeansConfigValidator.java:110) > at > org.springframework.ide.eclipse.beans.core.internal.project.BeansProjectValidator.buildFile(BeansProjectValidator.java:70) > at > org.springframework.ide.eclipse.beans.core.internal.project.BeansProjectBuilder$Visitor.visit(BeansProjectBuilder.java:62) > at org.eclipse.core.internal.resources.Resource$2.visit(Resource.java:103) > at > org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:50) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:81) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) > at > org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:126) > at org.eclipse.core.internal.resources.Resource.accept(Resource.java:60) > at org.eclipse.core.internal.resources.Resource.accept(Resource.java:101) > at org.eclipse.core.internal.resources.Resource.accept(Resource.java:80) > at > org.springframework.ide.eclipse.beans.core.internal.project.BeansProjectBuilder.build(BeansProjectBuilder.java:42) > at > org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:581) > at > org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1021) > at org.eclipse.core.runtime.Platform.run(Platform.java:757) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:160) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:198) > at > org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:227) > at > org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1021) > at org.eclipse.core.runtime.Platform.run(Platform.java:757) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:230) > at > org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:249) > at > org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:278) > at > org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:139) > at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:200) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:67) > > > > Torsten Juergeleit wrote: > > After a few month of sleep Spring IDE is alive again. > > > > We have moved the project from SF to a new site > > (http://springide.org/) which provides a Subversion > > repository and a Trac-based project management tool. > > > > A maintainance release (with spring-core.jar v1.1.5) > > is available too. The corresponding Eclipse updatesite > > is http://springide.org/updatesite/. A list of > > bugfixes can be found here > > http://springide.org/project/milestone/Release%201.1.1 > > . > > > > Christian is busy working on a graphical editor for > > Spring Webflow > > (http://springide.org/project/wiki/WebFlowEditor). > > > > Thomas, Colin, please update the links on > > www.springframework.org (home page and download page) > > with the new Spring IDE project site and update site. > > > > Keith, maybe you can ask Nikki for creating a logo for > > Spring IDE too ;-) > > > > Thanx. > > > > Cheers, > > Torsten > > > > > > > > __________________________________ > > Yahoo! Mail Mobile > > Take Yahoo! Mail with you! Check email on your mobile phone. > > http://mobile.yahoo.com/learn/mail > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: <jas...@ma...> - 2005-04-14 07:24:54
|
Hi Steve If it helps at all, we've developed a Spring based JCA container with support for endpoint, connection and thread pooling and local & XA transaction support. By all means reuse as much or little code as you like... http://activemq.codehaus.org/JCA+Container Echoing what Juergen just said; its not really a 'container' as such - Spring is the container (the thing which creates everything, wires things together). The JCA container just deals with the managed connections, resource adapters, endpoint management and transactions and provides the JCA thread pool implementation. On 14 Apr 2005, at 02:54, Steve Lewis wrote: > "So for a Spring environment, we don't actually need a > JCA *container* > in the > sense that it manages the setup of the connectors. All > we need is a JCA > ConnectionManager implementation that is XA-capable > and able to > interact > with a given javax.transaction.TransactionManager > instance." > > So it sounds sort of like running an XA resource in > non-managed mode? As in, no pooling, no security > injection, but participate/coordinate the XA directly > to the ManagedConnectionFactory? > > I am planning on putting an interceptor stack in, so > basically it would be using it without the pool > interceptor. To be honest, the XA stuff is the stuff > I'm least familiar with, so I may need some guidance > as I was originally intending on tackling that last. > But I was planning on delegating all the transaction > stuff to JOTM or any other XA manager. > > I know I'm sort of reinventing the wheel, but the hard > parts (like JOTM and HOWL, etc) I want to delegate as > much as possible. Make it JavaBean-ish as much as > possible, while still being standard JCA where it is > required. > > Thanks, > Steve > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > James ------- http://radio.weblogs.com/0112098/ |
|
From: Will B. <wil...@ra...> - 2005-04-14 06:50:26
|
All, When there are errors in the model, status.value is obtained from errors.getFieldValue(expression), which executes a custom property editor for the field if one exists. When there aren't errors in the model, status.value is obtained from the bean wrapper, and custom property editors are not invoked. Why not? Thanks, Will |
|
From: Matt R. <li...@ra...> - 2005-04-14 04:40:24
|
I tried it and the springmodules-validator-dev-20050413.jar seems to be
missing the taglib.tld in the META-INF directory. I built the project
using "ant alljars".
0 Wed Apr 13 22:12:46 MDT 2005 META-INF/
217 Wed Apr 13 22:12:44 MDT 2005 META-INF/MANIFEST.MF
0 Wed Apr 13 22:12:44 MDT 2005 org/
0 Wed Apr 13 22:12:44 MDT 2005 org/springmodules/
0 Wed Apr 13 22:12:44 MDT 2005 org/springmodules/commons/
0 Wed Apr 13 22:12:44 MDT 2005 org/springmodules/commons/validator/
0 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/taglib/
2392 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/BeanValidator.class
4596 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/DefaultValidatorFactory.class
11261 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/FieldChecks.class
3404 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/NamedBeanValidator.class
4625 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/Resources.class
2974 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/ValidatorAdaptor.class
446 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/ValidatorFactory.class
1305 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/taglib/
JavascriptValidatorTag$1.class
13579 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/taglib/JavascriptValidatorTag.class
This results in the following error:
org.apache.jasper.JasperException: /index.jsp(1,1) The absolute uri:
http://www.springmodules.org/tags/spring-commons-validator cannot be
resolved in either web.xml or the jar files deployed with this
application
at
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHand
ler.java:39)
BTW, is there any way to have a shorter URI - something like
http://www.springmodules.org/tags/validator?
Thanks,
Matt
On Apr 13, 2005, at 8:46 PM, Thomas Risberg wrote:
> I have moved the Commons Validator support over to springmodules. I
> did not make any changes other than the package names and
> copyright/license notices. There are quite a few deprecated methods -
> I guess some of the code is for an older version.
>
> The new package name is org.springmodules.commons.validator
> and the new uri for the taglib is
> http://www.springmodules.org/tags/spring-commons-validator
>
> Matt, since you seem to be the primary user of this support, could you
> check the new code out and test it?
>
> Thomas
>
>
> On Apr 13, 2005, at 5:40 PM, Rob Harrop wrote:
>
>> Thomas,
>>
>> If you are willing to work on it, I am happy for you to move it to
>> Spring Modules now. I don't see any harm in including what is there
>> in a 0.1 release if you are happy with it.
>>
>> Rob
>> On 13 Apr 2005, at 20:52, tho...@tr... wrote:
>>
>>> Rob,
>>>
>>> I'm currently working on a project where I will use Commons
>>> Validator outside of
>>> a Web MVC environment. I still would like to be able to wire it up
>>> using Spring
>>> and I have been playing around with what's in the sandbox. I have
>>> already
>>> changed the package names, so let me know when/if it is a good time
>>> to move
>>> this to springmodules CVS.
>>>
>>> I moved most of it to org.springmodules.validation.commons package
>>> except for
>>> the tag library which I put in
>>> org.springmodules.web.servlet.tags.validation.commons. I guess it
>>> makes sense
>>> to keep the package structure in org.springmodules the same as
>>> org.springframework so it's easier to move code between the projects.
>>>
>>> Thomas
>>>
>>>
>>> Quoting Rob Harrop <rob...@in...>:
>>>
>>>> Well, I'll spend some time going through the sandbox and see what I
>>>> think is
>>>> a candidate for Spring Modules. I'll post the suggestions here and
>>>> if
>>>> everyone is happy I'll do the move. We have about 6 active
>>>> developers on SM
>>>> who are not core Spring devs, plus there is me so we may be able to
>>>> breath
>>>> some live back into the stuff in the sandbox.
>>>>
>>>> Rob
>>>>
>>>> --
>>>> Rob Harrop
>>>> Interface21 - Spring Services from the Source
>>>> http://www.springframework.com
>>>>
>>>> -----Original Message-----
>>>> From: spr...@li...
>>>> [mailto:spr...@li...] On
>>>> Behalf Of
>>>> Juergen Hoeller
>>>> Sent: 12 April 2005 22:17
>>>> To: spr...@li...
>>>> Subject: Re: [Springframework-developer] Where does webflow live?
>>>>
>>>> Ah, our favorite topic once again ;-)
>>>>
>>>> I'm not entirely sure whether Web Flow will get its own module;
>>>> could be too
>>>> fine-granular. The binding framework quite certainly shouldn't,
>>>> which would
>>>> already cause a problem with Web Flow's current status if we had
>>>> modules.
>>>>
>>>> To give some numbers: If we want to have the binding framework, JCA
>>>> support,
>>>> Hibernate support, Web Flow, etc as separate modules (which would be
>>>> necessary to get your desired effect of not putting any
>>>> early-access stuff
>>>> in the sandbox), we would end up with at least 35 modules (that's
>>>> our
>>>> top-level packages plus some subpackages of relevant size).
>>>> Frankly, I
>>>> consider that a horror scenario in terms of management and would
>>>> strongly
>>>> vote against it.
>>>>
>>>> I guess what I'm saying is that modules only *look* convincingly
>>>> easy, but
>>>> won't be a general solution for the early access problem in
>>>> practice. Keith,
>>>> please try to imagine this in detail and don't just consider it as
>>>> solution
>>>> upfront. This is absolutely non-trivial when looking at the details.
>>>>
>>>> Before we continue to spread the word on modules, I'd like to see
>>>> concrete
>>>> suggestions for module separation, respecting the interdependencies
>>>> outlined
>>>> in section 3 of our readme. I have already tried multiple times to
>>>> nail down
>>>> some options, and have always failed to find a convincing
>>>> separation.
>>>>
>>>> The current jar files (12) might be a starting point, but I'm not
>>>> sure that
>>>> they can serve as module granularity too... Some packages are joined
>>>> together there rather arbitrarily (from a source module
>>>> perspective), for
>>>> example the ones in spring-support.jar, or the separation between
>>>> spring-orm.jar (which includes the entire ORM support except for
>>>> Hibernate)
>>>> and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1
>>>> to source
>>>> modules.
>>>>
>>>> So in total, it's unclear to me how a concrete module separation
>>>> could look
>>>> like (the more I look at it, the harder it seems). I doubt that we
>>>> can
>>>> resolve this within the 1.3 timeframe, given that we have such an
>>>> aggressive
>>>> schedule there, with just two months for multiple major new
>>>> features.
>>>>
>>>> Anyway, the real problem here is the sandbox, IMO. There's too much
>>>> stuff in
>>>> there, both dead and somewhat alive. Noone should have to rely on
>>>> spring-sandbox.jar!! Everything that's of some use in there should
>>>> move,
>>>> either to the core or to Spring Modules.
>>>>
>>>> Juergen
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: spr...@li...
>>>> [mailto:spr...@li...]On
>>>> Behalf
>>>> Of Keith Donald
>>>> Sent: Tuesday, April 12, 2005 9:24 PM
>>>> To: spr...@li...
>>>> Subject: RE: [Springframework-developer] Where does webflow live?
>>>>
>>>>
>>>> Aye, this is exactly why we need a modular CVS structure and a
>>>> smarter
>>>> build, which Colin is leading up in the post 1.2 timeframe.
>>>>
>>>> Web flow is currently maintained in the sandbox, yes. This means
>>>> it is also
>>>> included in spring-sandbox.jar when the 'sandboxjar' target is run.
>>>>
>>>> Independent of that fact, the webflow.release target ships
>>>> spring-webflow.jar and spring-webflow-support.jar, pulling in
>>>> _just_ the
>>>> required code from the sandbox needed to run spring webflow.
>>>>
>>>> So, I guess you can say we've taken the stance that people aren't
>>>> developing
>>>> apps with spring-sandbox.jar in their classpath. Hmm...
>>>>
>>>> In any case, in the future spring-webflow will be in its own module
>>>> with its
>>>> own distributable, along side other well-defined core modules, and
>>>> the
>>>> sandbox will die the death it deserves (or be only used for true
>>>> 'scratch'
>>>> stuff)
>>>>
>>>> Keith
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: spr...@li...
>>>> [mailto:spr...@li...] On
>>>> Behalf Of
>>>> Matt Raible
>>>> Sent: Tuesday, April 12, 2005 3:04 PM
>>>> To: spr...@li...
>>>> Subject: [Springframework-developer] Where does webflow live?
>>>>
>>>> I ran into some issues last night with spring-sandbox.jar from
>>>> Spring
>>>> 1.2 RC1 and Spring Web Flow PR2. The problem turned out to be that
>>>> many of the flow classes where already in my spring-sandbox.jar.
>>>> Once
>>>> I deleted them from spring-sandbox.jar, everything worked fine.
>>>> How do
>>>> I eliminate this duplication in the future? Is the web flow stuff
>>>> in
>>>> spring-sandbox.jar? The main reason I'm using the sandbox JAR is
>>>> for
>>>> Commons Validator.
>>>>
>>>> Thanks,
>>>>
>>>> Matt
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF email is sponsored by - The IT Product Guide
>>>> Read honest & candid reviews on hundreds of IT Products from real
>>>> users.
>>>> Discover which products truly live up to the hype. Start reading
>>>> now.
>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>> _______________________________________________
>>>> Springframework-developer mailing list
>>>> Spr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/springframework-
>>>> developer
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF email is sponsored by - The IT Product Guide
>>>> Read honest & candid reviews on hundreds of IT Products from real
>>>> users.
>>>> Discover which products truly live up to the hype. Start reading
>>>> now.
>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>> _______________________________________________
>>>> Springframework-developer mailing list
>>>> Spr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/springframework-
>>>> developer
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF email is sponsored by - The IT Product Guide
>>>> Read honest & candid reviews on hundreds of IT Products from real
>>>> users.
>>>> Discover which products truly live up to the hype. Start reading
>>>> now.
>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>> _______________________________________________
>>>> Springframework-developer mailing list
>>>> Spr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/springframework-
>>>> developer
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF email is sponsored by - The IT Product Guide
>>>> Read honest & candid reviews on hundreds of IT Products from real
>>>> users.
>>>> Discover which products truly live up to the hype. Start reading
>>>> now.
>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>> _______________________________________________
>>>> Springframework-developer mailing list
>>>> Spr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/springframework-
>>>> developer
>>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real
>>> users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-
>>> developer
>>>
>> --
>> Rob Harrop
>> Interface21 - Spring Services from the Source
>> http://www.springframework.com
>>
>> Lead Developer - AOP & JMX, Spring Framework:
>> http://www.springframework.org
>>
>> Author, "Pro Spring"
>> (February 2005, with Jan Machacek).
>> http://www.amazon.com/exec/obidos/ASIN/1590594614/
>>
>> Author, "Pro Jakarta Velocity"
>> (August 2004).
>> http://www.amazon.com/exec/obidos/ASIN/159059410X/
>>
>> Author, "Pro Jakarta Struts"
>> (March 2004, with John Carnell).
>> http://www.amazon.com/exec/obidos/ASIN/159059228X/
>>
>>
>> ____________________________________________________
>> Interface21 Limited
>> Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent
>> DA1 2JY
>> Registered in England and Wales No. 5187766
>> ____________________________________________________
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real
>> users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Thomas R. <tho...@tr...> - 2005-04-14 02:46:18
|
I have moved the Commons Validator support over to springmodules. I did not make any changes other than the package names and copyright/license notices. There are quite a few deprecated methods - I guess some of the code is for an older version. The new package name is org.springmodules.commons.validator and the new uri for the taglib is http://www.springmodules.org/tags/spring-commons-validator Matt, since you seem to be the primary user of this support, could you check the new code out and test it? Thomas On Apr 13, 2005, at 5:40 PM, Rob Harrop wrote: > Thomas, > > If you are willing to work on it, I am happy for you to move it to > Spring Modules now. I don't see any harm in including what is there in > a 0.1 release if you are happy with it. > > Rob > On 13 Apr 2005, at 20:52, tho...@tr... wrote: > >> Rob, >> >> I'm currently working on a project where I will use Commons Validator >> outside of >> a Web MVC environment. I still would like to be able to wire it up >> using Spring >> and I have been playing around with what's in the sandbox. I have >> already >> changed the package names, so let me know when/if it is a good time >> to move >> this to springmodules CVS. >> >> I moved most of it to org.springmodules.validation.commons package >> except for >> the tag library which I put in >> org.springmodules.web.servlet.tags.validation.commons. I guess it >> makes sense >> to keep the package structure in org.springmodules the same as >> org.springframework so it's easier to move code between the projects. >> >> Thomas >> >> >> Quoting Rob Harrop <rob...@in...>: >> >>> Well, I'll spend some time going through the sandbox and see what I >>> think is >>> a candidate for Spring Modules. I'll post the suggestions here and if >>> everyone is happy I'll do the move. We have about 6 active >>> developers on SM >>> who are not core Spring devs, plus there is me so we may be able to >>> breath >>> some live back into the stuff in the sandbox. >>> >>> Rob >>> >>> -- >>> Rob Harrop >>> Interface21 - Spring Services from the Source >>> http://www.springframework.com >>> >>> -----Original Message----- >>> From: spr...@li... >>> [mailto:spr...@li...] On >>> Behalf Of >>> Juergen Hoeller >>> Sent: 12 April 2005 22:17 >>> To: spr...@li... >>> Subject: Re: [Springframework-developer] Where does webflow live? >>> >>> Ah, our favorite topic once again ;-) >>> >>> I'm not entirely sure whether Web Flow will get its own module; >>> could be too >>> fine-granular. The binding framework quite certainly shouldn't, >>> which would >>> already cause a problem with Web Flow's current status if we had >>> modules. >>> >>> To give some numbers: If we want to have the binding framework, JCA >>> support, >>> Hibernate support, Web Flow, etc as separate modules (which would be >>> necessary to get your desired effect of not putting any early-access >>> stuff >>> in the sandbox), we would end up with at least 35 modules (that's our >>> top-level packages plus some subpackages of relevant size). Frankly, >>> I >>> consider that a horror scenario in terms of management and would >>> strongly >>> vote against it. >>> >>> I guess what I'm saying is that modules only *look* convincingly >>> easy, but >>> won't be a general solution for the early access problem in >>> practice. Keith, >>> please try to imagine this in detail and don't just consider it as >>> solution >>> upfront. This is absolutely non-trivial when looking at the details. >>> >>> Before we continue to spread the word on modules, I'd like to see >>> concrete >>> suggestions for module separation, respecting the interdependencies >>> outlined >>> in section 3 of our readme. I have already tried multiple times to >>> nail down >>> some options, and have always failed to find a convincing separation. >>> >>> The current jar files (12) might be a starting point, but I'm not >>> sure that >>> they can serve as module granularity too... Some packages are joined >>> together there rather arbitrarily (from a source module >>> perspective), for >>> example the ones in spring-support.jar, or the separation between >>> spring-orm.jar (which includes the entire ORM support except for >>> Hibernate) >>> and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1 to >>> source >>> modules. >>> >>> So in total, it's unclear to me how a concrete module separation >>> could look >>> like (the more I look at it, the harder it seems). I doubt that we >>> can >>> resolve this within the 1.3 timeframe, given that we have such an >>> aggressive >>> schedule there, with just two months for multiple major new features. >>> >>> Anyway, the real problem here is the sandbox, IMO. There's too much >>> stuff in >>> there, both dead and somewhat alive. Noone should have to rely on >>> spring-sandbox.jar!! Everything that's of some use in there should >>> move, >>> either to the core or to Spring Modules. >>> >>> Juergen >>> >>> >>> -----Original Message----- >>> From: spr...@li... >>> [mailto:spr...@li...]On >>> Behalf >>> Of Keith Donald >>> Sent: Tuesday, April 12, 2005 9:24 PM >>> To: spr...@li... >>> Subject: RE: [Springframework-developer] Where does webflow live? >>> >>> >>> Aye, this is exactly why we need a modular CVS structure and a >>> smarter >>> build, which Colin is leading up in the post 1.2 timeframe. >>> >>> Web flow is currently maintained in the sandbox, yes. This means it >>> is also >>> included in spring-sandbox.jar when the 'sandboxjar' target is run. >>> >>> Independent of that fact, the webflow.release target ships >>> spring-webflow.jar and spring-webflow-support.jar, pulling in _just_ >>> the >>> required code from the sandbox needed to run spring webflow. >>> >>> So, I guess you can say we've taken the stance that people aren't >>> developing >>> apps with spring-sandbox.jar in their classpath. Hmm... >>> >>> In any case, in the future spring-webflow will be in its own module >>> with its >>> own distributable, along side other well-defined core modules, and >>> the >>> sandbox will die the death it deserves (or be only used for true >>> 'scratch' >>> stuff) >>> >>> Keith >>> >>> >>> >>> >>> -----Original Message----- >>> From: spr...@li... >>> [mailto:spr...@li...] On >>> Behalf Of >>> Matt Raible >>> Sent: Tuesday, April 12, 2005 3:04 PM >>> To: spr...@li... >>> Subject: [Springframework-developer] Where does webflow live? >>> >>> I ran into some issues last night with spring-sandbox.jar from Spring >>> 1.2 RC1 and Spring Web Flow PR2. The problem turned out to be that >>> many of the flow classes where already in my spring-sandbox.jar. >>> Once >>> I deleted them from spring-sandbox.jar, everything worked fine. How >>> do >>> I eliminate this duplication in the future? Is the web flow stuff in >>> spring-sandbox.jar? The main reason I'm using the sandbox JAR is for >>> Commons Validator. >>> >>> Thanks, >>> >>> Matt >>> >>> >>> >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real >>> users. >>> Discover which products truly live up to the hype. Start reading now. >>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> https://lists.sourceforge.net/lists/listinfo/springframework- >>> developer >>> >>> >>> >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real >>> users. >>> Discover which products truly live up to the hype. Start reading now. >>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> https://lists.sourceforge.net/lists/listinfo/springframework- >>> developer >>> >>> >>> >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real >>> users. >>> Discover which products truly live up to the hype. Start reading now. >>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> https://lists.sourceforge.net/lists/listinfo/springframework- >>> developer >>> >>> >>> >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real >>> users. >>> Discover which products truly live up to the hype. Start reading now. >>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> https://lists.sourceforge.net/lists/listinfo/springframework- >>> developer >>> >> >> >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> > -- > Rob Harrop > Interface21 - Spring Services from the Source > http://www.springframework.com > > Lead Developer - AOP & JMX, Spring Framework: > http://www.springframework.org > > Author, "Pro Spring" > (February 2005, with Jan Machacek). > http://www.amazon.com/exec/obidos/ASIN/1590594614/ > > Author, "Pro Jakarta Velocity" > (August 2004). > http://www.amazon.com/exec/obidos/ASIN/159059410X/ > > Author, "Pro Jakarta Struts" > (March 2004, with John Carnell). > http://www.amazon.com/exec/obidos/ASIN/159059228X/ > > > ____________________________________________________ > Interface21 Limited > Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent > DA1 2JY > Registered in England and Wales No. 5187766 > ____________________________________________________ > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Steve L. <spi...@ya...> - 2005-04-14 01:54:32
|
"So for a Spring environment, we don't actually need a JCA *container* in the sense that it manages the setup of the connectors. All we need is a JCA ConnectionManager implementation that is XA-capable and able to interact with a given javax.transaction.TransactionManager instance." So it sounds sort of like running an XA resource in non-managed mode? As in, no pooling, no security injection, but participate/coordinate the XA directly to the ManagedConnectionFactory? I am planning on putting an interceptor stack in, so basically it would be using it without the pool interceptor. To be honest, the XA stuff is the stuff I'm least familiar with, so I may need some guidance as I was originally intending on tackling that last. But I was planning on delegating all the transaction stuff to JOTM or any other XA manager. I know I'm sort of reinventing the wheel, but the hard parts (like JOTM and HOWL, etc) I want to delegate as much as possible. Make it JavaBean-ish as much as possible, while still being standard JCA where it is required. Thanks, Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: <al...@jt...> - 2005-04-13 22:13:07
|
View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050414001642 |
|
From: Rob H. <rob...@in...> - 2005-04-13 21:41:00
|
Thomas, If you are willing to work on it, I am happy for you to move it to Spring Modules now. I don't see any harm in including what is there in a 0.1 release if you are happy with it. Rob On 13 Apr 2005, at 20:52, tho...@tr... wrote: > Rob, > > I'm currently working on a project where I will use Commons Validator > outside of > a Web MVC environment. I still would like to be able to wire it up > using Spring > and I have been playing around with what's in the sandbox. I have > already > changed the package names, so let me know when/if it is a good time to > move > this to springmodules CVS. > > I moved most of it to org.springmodules.validation.commons package > except for > the tag library which I put in > org.springmodules.web.servlet.tags.validation.commons. I guess it > makes sense > to keep the package structure in org.springmodules the same as > org.springframework so it's easier to move code between the projects. > > Thomas > > > Quoting Rob Harrop <rob...@in...>: > >> Well, I'll spend some time going through the sandbox and see what I >> think is >> a candidate for Spring Modules. I'll post the suggestions here and if >> everyone is happy I'll do the move. We have about 6 active developers >> on SM >> who are not core Spring devs, plus there is me so we may be able to >> breath >> some live back into the stuff in the sandbox. >> >> Rob >> >> -- >> Rob Harrop >> Interface21 - Spring Services from the Source >> http://www.springframework.com >> >> -----Original Message----- >> From: spr...@li... >> [mailto:spr...@li...] On >> Behalf Of >> Juergen Hoeller >> Sent: 12 April 2005 22:17 >> To: spr...@li... >> Subject: Re: [Springframework-developer] Where does webflow live? >> >> Ah, our favorite topic once again ;-) >> >> I'm not entirely sure whether Web Flow will get its own module; could >> be too >> fine-granular. The binding framework quite certainly shouldn't, which >> would >> already cause a problem with Web Flow's current status if we had >> modules. >> >> To give some numbers: If we want to have the binding framework, JCA >> support, >> Hibernate support, Web Flow, etc as separate modules (which would be >> necessary to get your desired effect of not putting any early-access >> stuff >> in the sandbox), we would end up with at least 35 modules (that's our >> top-level packages plus some subpackages of relevant size). Frankly, I >> consider that a horror scenario in terms of management and would >> strongly >> vote against it. >> >> I guess what I'm saying is that modules only *look* convincingly >> easy, but >> won't be a general solution for the early access problem in practice. >> Keith, >> please try to imagine this in detail and don't just consider it as >> solution >> upfront. This is absolutely non-trivial when looking at the details. >> >> Before we continue to spread the word on modules, I'd like to see >> concrete >> suggestions for module separation, respecting the interdependencies >> outlined >> in section 3 of our readme. I have already tried multiple times to >> nail down >> some options, and have always failed to find a convincing separation. >> >> The current jar files (12) might be a starting point, but I'm not >> sure that >> they can serve as module granularity too... Some packages are joined >> together there rather arbitrarily (from a source module perspective), >> for >> example the ones in spring-support.jar, or the separation between >> spring-orm.jar (which includes the entire ORM support except for >> Hibernate) >> and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1 to >> source >> modules. >> >> So in total, it's unclear to me how a concrete module separation >> could look >> like (the more I look at it, the harder it seems). I doubt that we can >> resolve this within the 1.3 timeframe, given that we have such an >> aggressive >> schedule there, with just two months for multiple major new features. >> >> Anyway, the real problem here is the sandbox, IMO. There's too much >> stuff in >> there, both dead and somewhat alive. Noone should have to rely on >> spring-sandbox.jar!! Everything that's of some use in there should >> move, >> either to the core or to Spring Modules. >> >> Juergen >> >> >> -----Original Message----- >> From: spr...@li... >> [mailto:spr...@li...]On >> Behalf >> Of Keith Donald >> Sent: Tuesday, April 12, 2005 9:24 PM >> To: spr...@li... >> Subject: RE: [Springframework-developer] Where does webflow live? >> >> >> Aye, this is exactly why we need a modular CVS structure and a smarter >> build, which Colin is leading up in the post 1.2 timeframe. >> >> Web flow is currently maintained in the sandbox, yes. This means it >> is also >> included in spring-sandbox.jar when the 'sandboxjar' target is run. >> >> Independent of that fact, the webflow.release target ships >> spring-webflow.jar and spring-webflow-support.jar, pulling in _just_ >> the >> required code from the sandbox needed to run spring webflow. >> >> So, I guess you can say we've taken the stance that people aren't >> developing >> apps with spring-sandbox.jar in their classpath. Hmm... >> >> In any case, in the future spring-webflow will be in its own module >> with its >> own distributable, along side other well-defined core modules, and the >> sandbox will die the death it deserves (or be only used for true >> 'scratch' >> stuff) >> >> Keith >> >> >> >> >> -----Original Message----- >> From: spr...@li... >> [mailto:spr...@li...] On >> Behalf Of >> Matt Raible >> Sent: Tuesday, April 12, 2005 3:04 PM >> To: spr...@li... >> Subject: [Springframework-developer] Where does webflow live? >> >> I ran into some issues last night with spring-sandbox.jar from Spring >> 1.2 RC1 and Spring Web Flow PR2. The problem turned out to be that >> many of the flow classes where already in my spring-sandbox.jar. Once >> I deleted them from spring-sandbox.jar, everything worked fine. How >> do >> I eliminate this duplication in the future? Is the web flow stuff in >> spring-sandbox.jar? The main reason I'm using the sandbox JAR is for >> Commons Validator. >> >> Thanks, >> >> Matt >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > -- Rob Harrop Interface21 - Spring Services from the Source http://www.springframework.com Lead Developer - AOP & JMX, Spring Framework: http://www.springframework.org Author, "Pro Spring" (February 2005, with Jan Machacek). http://www.amazon.com/exec/obidos/ASIN/1590594614/ Author, "Pro Jakarta Velocity" (August 2004). http://www.amazon.com/exec/obidos/ASIN/159059410X/ Author, "Pro Jakarta Struts" (March 2004, with John Carnell). http://www.amazon.com/exec/obidos/ASIN/159059228X/ ____________________________________________________ Interface21 Limited Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY Registered in England and Wales No. 5187766 ____________________________________________________ |
|
From: <tho...@tr...> - 2005-04-13 19:52:20
|
Rob, I'm currently working on a project where I will use Commons Validator outside of a Web MVC environment. I still would like to be able to wire it up using Spring and I have been playing around with what's in the sandbox. I have already changed the package names, so let me know when/if it is a good time to move this to springmodules CVS. I moved most of it to org.springmodules.validation.commons package except for the tag library which I put in org.springmodules.web.servlet.tags.validation.commons. I guess it makes sense to keep the package structure in org.springmodules the same as org.springframework so it's easier to move code between the projects. Thomas Quoting Rob Harrop <rob...@in...>: > Well, I'll spend some time going through the sandbox and see what I think is > a candidate for Spring Modules. I'll post the suggestions here and if > everyone is happy I'll do the move. We have about 6 active developers on SM > who are not core Spring devs, plus there is me so we may be able to breath > some live back into the stuff in the sandbox. > > Rob > > -- > Rob Harrop > Interface21 - Spring Services from the Source > http://www.springframework.com > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On Behalf Of > Juergen Hoeller > Sent: 12 April 2005 22:17 > To: spr...@li... > Subject: Re: [Springframework-developer] Where does webflow live? > > Ah, our favorite topic once again ;-) > > I'm not entirely sure whether Web Flow will get its own module; could be too > fine-granular. The binding framework quite certainly shouldn't, which would > already cause a problem with Web Flow's current status if we had modules. > > To give some numbers: If we want to have the binding framework, JCA support, > Hibernate support, Web Flow, etc as separate modules (which would be > necessary to get your desired effect of not putting any early-access stuff > in the sandbox), we would end up with at least 35 modules (that's our > top-level packages plus some subpackages of relevant size). Frankly, I > consider that a horror scenario in terms of management and would strongly > vote against it. > > I guess what I'm saying is that modules only *look* convincingly easy, but > won't be a general solution for the early access problem in practice. Keith, > please try to imagine this in detail and don't just consider it as solution > upfront. This is absolutely non-trivial when looking at the details. > > Before we continue to spread the word on modules, I'd like to see concrete > suggestions for module separation, respecting the interdependencies outlined > in section 3 of our readme. I have already tried multiple times to nail down > some options, and have always failed to find a convincing separation. > > The current jar files (12) might be a starting point, but I'm not sure that > they can serve as module granularity too... Some packages are joined > together there rather arbitrarily (from a source module perspective), for > example the ones in spring-support.jar, or the separation between > spring-orm.jar (which includes the entire ORM support except for Hibernate) > and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1 to source > modules. > > So in total, it's unclear to me how a concrete module separation could look > like (the more I look at it, the harder it seems). I doubt that we can > resolve this within the 1.3 timeframe, given that we have such an aggressive > schedule there, with just two months for multiple major new features. > > Anyway, the real problem here is the sandbox, IMO. There's too much stuff in > there, both dead and somewhat alive. Noone should have to rely on > spring-sandbox.jar!! Everything that's of some use in there should move, > either to the core or to Spring Modules. > > Juergen > > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...]On Behalf > Of Keith Donald > Sent: Tuesday, April 12, 2005 9:24 PM > To: spr...@li... > Subject: RE: [Springframework-developer] Where does webflow live? > > > Aye, this is exactly why we need a modular CVS structure and a smarter > build, which Colin is leading up in the post 1.2 timeframe. > > Web flow is currently maintained in the sandbox, yes. This means it is also > included in spring-sandbox.jar when the 'sandboxjar' target is run. > > Independent of that fact, the webflow.release target ships > spring-webflow.jar and spring-webflow-support.jar, pulling in _just_ the > required code from the sandbox needed to run spring webflow. > > So, I guess you can say we've taken the stance that people aren't developing > apps with spring-sandbox.jar in their classpath. Hmm... > > In any case, in the future spring-webflow will be in its own module with its > own distributable, along side other well-defined core modules, and the > sandbox will die the death it deserves (or be only used for true 'scratch' > stuff) > > Keith > > > > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On Behalf Of > Matt Raible > Sent: Tuesday, April 12, 2005 3:04 PM > To: spr...@li... > Subject: [Springframework-developer] Where does webflow live? > > I ran into some issues last night with spring-sandbox.jar from Spring > 1.2 RC1 and Spring Web Flow PR2. The problem turned out to be that > many of the flow classes where already in my spring-sandbox.jar. Once > I deleted them from spring-sandbox.jar, everything worked fine. How do > I eliminate this duplication in the future? Is the web flow stuff in > spring-sandbox.jar? The main reason I'm using the sandbox JAR is for > Commons Validator. > > Thanks, > > Matt > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: <tho...@tr...> - 2005-04-13 19:44:36
|
I have updated the links. Thomas Quoting Torsten Juergeleit <tju...@ya...>: > After a few month of sleep Spring IDE is alive again. > > We have moved the project from SF to a new site > (http://springide.org/) which provides a Subversion > repository and a Trac-based project management tool. > > A maintainance release (with spring-core.jar v1.1.5) > is available too. The corresponding Eclipse updatesite > is http://springide.org/updatesite/. A list of > bugfixes can be found here > http://springide.org/project/milestone/Release%201.1.1 > . > > Christian is busy working on a graphical editor for > Spring Webflow > (http://springide.org/project/wiki/WebFlowEditor). > > Thomas, Colin, please update the links on > www.springframework.org (home page and download page) > with the new Spring IDE project site and update site. > > Keith, maybe you can ask Nikki for creating a logo for > Spring IDE too ;-) > > Thanx. > > Cheers, > Torsten > > > > __________________________________ > Yahoo! Mail Mobile > Take Yahoo! Mail with you! Check email on your mobile phone. > http://mobile.yahoo.com/learn/mail > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Torsten J. <tju...@ya...> - 2005-04-13 19:15:41
|
Eugene, I didn't tested Spring IDE with Eclipse 3.1 yet. I created a ticket for this issue (http://springide.org/project/ticket/26 ). Cheers, Torsten --- Eugene Kuleshov <eu...@md...> wrote: > Hi Torsten, > > It is a good news and long awaited update. > > I've installed plugin on my Eclipse 3.1 and I'm > getting a error from > builder. > > ---------- > An error occurred while traversing resources. > java.lang.IllegalStateException: Bean can only have > a parent of type > IBeansConfig, IBean or (in case of an inner bean) > IBeanProperty > at > org.springframework.ide.eclipse.beans.core.internal.model.Bean.getConfig(Bean.java:75) > at > org.springframework.ide.eclipse.beans.core.internal.model.BeansConfigValidator.validateBean(BeansConfigValidator.java:214) > at > org.springframework.ide.eclipse.beans.core.internal.model.BeansConfigValidator.validateConfig(BeansConfigValidator.java:148) > at > org.springframework.ide.eclipse.beans.core.internal.model.BeansConfigValidator.validate(BeansConfigValidator.java:110) > at > org.springframework.ide.eclipse.beans.core.internal.project.BeansProjectValidator.buildFile(BeansProjectValidator.java:70) > at > org.springframework.ide.eclipse.beans.core.internal.project.BeansProjectBuilder$Visitor.visit(BeansProjectBuilder.java:62) > at > org.eclipse.core.internal.resources.Resource$2.visit(Resource.java:103) > at > org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:50) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:81) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) > at > org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) > at > org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:126) > at > org.eclipse.core.internal.resources.Resource.accept(Resource.java:60) > at > org.eclipse.core.internal.resources.Resource.accept(Resource.java:101) > at > org.eclipse.core.internal.resources.Resource.accept(Resource.java:80) > at > org.springframework.ide.eclipse.beans.core.internal.project.BeansProjectBuilder.build(BeansProjectBuilder.java:42) > at > org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:581) > at > org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1021) > at > org.eclipse.core.runtime.Platform.run(Platform.java:757) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:160) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:198) > at > org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:227) > at > org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1021) > at > org.eclipse.core.runtime.Platform.run(Platform.java:757) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:230) > at > org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:249) > at > org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:278) > at > org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:139) > at > org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:200) > at > org.eclipse.core.internal.jobs.Worker.run(Worker.java:67) > > > > Torsten Juergeleit wrote: > > After a few month of sleep Spring IDE is alive > again. > > > > We have moved the project from SF to a new site > > (http://springide.org/) which provides a > Subversion > > repository and a Trac-based project management > tool. > > > > A maintainance release (with spring-core.jar > v1.1.5) > > is available too. The corresponding Eclipse > updatesite > > is http://springide.org/updatesite/. A list of > > bugfixes can be found here > > > http://springide.org/project/milestone/Release%201.1.1 > > . > > > > Christian is busy working on a graphical editor > for > > Spring Webflow > > (http://springide.org/project/wiki/WebFlowEditor). > > > > Thomas, Colin, please update the links on > > www.springframework.org (home page and download > page) > > with the new Spring IDE project site and update > site. > > > > Keith, maybe you can ask Nikki for creating a logo > for > > Spring IDE too ;-) > > > > Thanx. > > > > Cheers, > > Torsten > > > > > > > > __________________________________ > > Yahoo! Mail Mobile > > Take Yahoo! Mail with you! Check email on your > mobile phone. > > http://mobile.yahoo.com/learn/mail > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT > Products from real users. > > Discover which products truly live up to the hype. > Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the hype. > Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 |
|
From: Eugene K. <eu...@md...> - 2005-04-13 17:55:23
|
Hi Torsten, It is a good news and long awaited update. I've installed plugin on my Eclipse 3.1 and I'm getting a error from builder. ---------- An error occurred while traversing resources. java.lang.IllegalStateException: Bean can only have a parent of type IBeansConfig, IBean or (in case of an inner bean) IBeanProperty at org.springframework.ide.eclipse.beans.core.internal.model.Bean.getConfig(Bean.java:75) at org.springframework.ide.eclipse.beans.core.internal.model.BeansConfigValidator.validateBean(BeansConfigValidator.java:214) at org.springframework.ide.eclipse.beans.core.internal.model.BeansConfigValidator.validateConfig(BeansConfigValidator.java:148) at org.springframework.ide.eclipse.beans.core.internal.model.BeansConfigValidator.validate(BeansConfigValidator.java:110) at org.springframework.ide.eclipse.beans.core.internal.project.BeansProjectValidator.buildFile(BeansProjectValidator.java:70) at org.springframework.ide.eclipse.beans.core.internal.project.BeansProjectBuilder$Visitor.visit(BeansProjectBuilder.java:62) at org.eclipse.core.internal.resources.Resource$2.visit(Resource.java:103) at org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:50) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:81) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:126) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:60) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:101) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:80) at org.springframework.ide.eclipse.beans.core.internal.project.BeansProjectBuilder.build(BeansProjectBuilder.java:42) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:581) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1021) at org.eclipse.core.runtime.Platform.run(Platform.java:757) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:160) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:198) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:227) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1021) at org.eclipse.core.runtime.Platform.run(Platform.java:757) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:230) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:249) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:278) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:139) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:200) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:67) Torsten Juergeleit wrote: > After a few month of sleep Spring IDE is alive again. > > We have moved the project from SF to a new site > (http://springide.org/) which provides a Subversion > repository and a Trac-based project management tool. > > A maintainance release (with spring-core.jar v1.1.5) > is available too. The corresponding Eclipse updatesite > is http://springide.org/updatesite/. A list of > bugfixes can be found here > http://springide.org/project/milestone/Release%201.1.1 > . > > Christian is busy working on a graphical editor for > Spring Webflow > (http://springide.org/project/wiki/WebFlowEditor). > > Thomas, Colin, please update the links on > www.springframework.org (home page and download page) > with the new Spring IDE project site and update site. > > Keith, maybe you can ask Nikki for creating a logo for > Spring IDE too ;-) > > Thanx. > > Cheers, > Torsten > > > > __________________________________ > Yahoo! Mail Mobile > Take Yahoo! Mail with you! Check email on your mobile phone. > http://mobile.yahoo.com/learn/mail > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: March, A. <am...@so...> - 2005-04-13 17:03:59
|
I have probably said this before but I am interested in a controller that can handle all simple GET requests dispatching them to one or more service layer methods and sticking the results into the model under specified keys. =20 Just wanted to let you know that I opened a JIRA issue for this and attached some code I'm playing with. SPR-871 <http://opensource.atlassian.com/projects/spring/browse/SPR-871> has a summary of my thoughts on this issue. =20 ----------------------------------------- Andres March Platform - Apps Engineering Sony Online Entertainment desk: 858.577.3373 cell: 619.519.1519 =20 |
|
From: Juergen H. <ju...@in...> - 2005-04-13 16:51:09
|
Hi over here too, Steve! I've already briefly responded on the user list. I'll go a bit further here... The core of a JCA container is the implementation of the javax.resource.spi.ConnectionManager interface. This is what the ManagedConnectionFactory of a concrete JCA connector needs to receive to be able to work in a managed fashion. Everything else essentially comes with the connector itself. This ConnectionManager implementation can either be a simple connection pool (for JCA's non-managed mode) or a full-fledged manager of the overall JCA service contracts (for JCA's managed mode, in particular including XA transaction management). For the latter mode, it has to collaborate with a javax.transaction.TransactionManager. In a Spring context, such a ConnectionManager would simply be defined as bean. Each JCA connector would then be set up with Spring's existing LocalConnectionFactoryBean, taking a ManagerConnectionFactory instance and a ConnectionManager instance and exposing the connector's native ConnectionFactory (e.g. a JDBC DataSource or CCI ConnectionFactory). So for a Spring environment, we don't actually need a JCA *container* in the sense that it manages the setup of the connectors. All we need is a JCA ConnectionManager implementation that is XA-capable and able to interact with a given javax.transaction.TransactionManager instance. If the ConnectionManager is defined as bean, it could simply receive the JTA TransactionManager as bean reference. This would allow us to define all involved components as Spring beans: the TransactionManager, the ConnectionManager, the ManagedConnectionFactory of each connector, and the native ConnectionFactory for each connector. Note that in the above configuration model, it's all objects: no static accessors or static state anywhere, it's all in instances. A ConnectionManager like the above would be completely generic in that it could work with any JCA connector and with any JTA implementation. Furthermore, it doesn't require any Spring dependencies: as long as the ConnectionManager follows JavaBean conventions, it can easily be used in a Spring environment despite being a completely separate component. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Steve Lewis Sent: Wednesday, April 13, 2005 6:07 PM To: Spr...@li... Subject: [Springframework-developer] Re: JCA support Hello Juergen, I've recently begun a project (not hosted anywhere yet) for a JCA container. It's in the very early stages, but it uses Commons Pool for the pooling. I've begun to talk with Thierry so maybe we can throw something together that's useful. Currently I am in the early stages of testing my container against the local transaction JBoss JDBC adapter. But basically I'd like to say something like: Container.registerAdapter(AdapterInfo); Then once it's registered, call Container.getDataSource() or Container.getConnectionFactory() Something very simple that hides all that complexity, as much as possible. Thanks, Steve __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Steve L. <spi...@ya...> - 2005-04-13 16:06:52
|
Hello Juergen, I've recently begun a project (not hosted anywhere yet) for a JCA container. It's in the very early stages, but it uses Commons Pool for the pooling. I've begun to talk with Thierry so maybe we can throw something together that's useful. Currently I am in the early stages of testing my container against the local transaction JBoss JDBC adapter. But basically I'd like to say something like: Container.registerAdapter(AdapterInfo); Then once it's registered, call Container.getDataSource() or Container.getConnectionFactory() Something very simple that hides all that complexity, as much as possible. Thanks, Steve __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail |
|
From: Juergen H. <ju...@in...> - 2005-04-13 15:57:38
|
Well, in general, I wouldn't mind Web Flow getting its own module, for example following our current jar file structure (where spring-webflow.jar will be the 13th jar file). However, as I said, I'm not sure our jar files really provide a good basis for a source module structure... they are separated by jar size / deployment combo rules, not necessarily by logical modules. Data binding is quite definitely too small for a module. If we give data binding its own module, we'll consequently *have* to give JNDI support, JMS support, JCA support, Hibernate support, etc all their own modules as well - and then we'll end up with ~35 modules. There is no point in giving data binding a special status here, IMO... A smart build system is also able to generate all sorts of deployables from a *single* source tree, without separation into multiple separate source trees. Even subpackage interdependencies could be checked through selective compilation. The advantage would be that we can keep refining the granularity of the deployables, like we can do now. With multiple source trees, we'd have to move packages between source directories for this, and thus lose our version history etc. I'm not saying that we shouldn't go down the module route in general. I'm just saying that it's too early to promise anything in that area, as the final word has not been spoken yet, not even on *whether* we go down the module route within our now very aggressive 1.3 schedule. Before we continue to assume anything here, I'd like to see a concrete proposal for module separation, taking our entire codebase into account in a detailed and balanced fashion, not just reiterating that modules for data binding and web flow would be nice. I guess I'm just sick of the argument that we wouldn't have a problem with Web Flow's (or other sandbox stuff's) current residence if we had source modules. That's simply not true if you look at it a bit closer: There will always be extensions that have to go into an existing module - and have to reside in some sort of sandbox until they get moved over to the main sources. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Keith Donald Sent: Wednesday, April 13, 2005 5:22 PM To: spr...@li... Subject: RE: [Springframework-developer] Where does webflow live? I don't see why Web Flow should not be its own module. It's 135K as is, probably around 115 classes. I also think data binding could nicely be its own module as well, upon which web flow would depend. A smart build system would make things manageable. Look at how the eclipse project does it -- they have lots of different modules for the different parts of Eclipse, and they're successful at it. I'm not saying Hibernate and OJB and iBatis should each be their own, for example, that's probably a bit xtreme -- but ORM might well be. We probably shouldn't get distracted by this now given 1.2. Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Juergen Hoeller Sent: Tuesday, April 12, 2005 5:17 PM To: spr...@li... Subject: Re: [Springframework-developer] Where does webflow live? Ah, our favorite topic once again ;-) I'm not entirely sure whether Web Flow will get its own module; could be too fine-granular. The binding framework quite certainly shouldn't, which would already cause a problem with Web Flow's current status if we had modules. To give some numbers: If we want to have the binding framework, JCA support, Hibernate support, Web Flow, etc as separate modules (which would be necessary to get your desired effect of not putting any early-access stuff in the sandbox), we would end up with at least 35 modules (that's our top-level packages plus some subpackages of relevant size). Frankly, I consider that a horror scenario in terms of management and would strongly vote against it. I guess what I'm saying is that modules only *look* convincingly easy, but won't be a general solution for the early access problem in practice. Keith, please try to imagine this in detail and don't just consider it as solution upfront. This is absolutely non-trivial when looking at the details. Before we continue to spread the word on modules, I'd like to see concrete suggestions for module separation, respecting the interdependencies outlined in section 3 of our readme. I have already tried multiple times to nail down some options, and have always failed to find a convincing separation. The current jar files (12) might be a starting point, but I'm not sure that they can serve as module granularity too... Some packages are joined together there rather arbitrarily (from a source module perspective), for example the ones in spring-support.jar, or the separation between spring-orm.jar (which includes the entire ORM support except for Hibernate) and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1 to source modules. So in total, it's unclear to me how a concrete module separation could look like (the more I look at it, the harder it seems). I doubt that we can resolve this within the 1.3 timeframe, given that we have such an aggressive schedule there, with just two months for multiple major new features. Anyway, the real problem here is the sandbox, IMO. There's too much stuff in there, both dead and somewhat alive. Noone should have to rely on spring-sandbox.jar!! Everything that's of some use in there should move, either to the core or to Spring Modules. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Keith Donald Sent: Tuesday, April 12, 2005 9:24 PM To: spr...@li... Subject: RE: [Springframework-developer] Where does webflow live? Aye, this is exactly why we need a modular CVS structure and a smarter build, which Colin is leading up in the post 1.2 timeframe. Web flow is currently maintained in the sandbox, yes. This means it is also included in spring-sandbox.jar when the 'sandboxjar' target is run. Independent of that fact, the webflow.release target ships spring-webflow.jar and spring-webflow-support.jar, pulling in _just_ the required code from the sandbox needed to run spring webflow. So, I guess you can say we've taken the stance that people aren't developing apps with spring-sandbox.jar in their classpath. Hmm... In any case, in the future spring-webflow will be in its own module with its own distributable, along side other well-defined core modules, and the sandbox will die the death it deserves (or be only used for true 'scratch' stuff) Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Matt Raible Sent: Tuesday, April 12, 2005 3:04 PM To: spr...@li... Subject: [Springframework-developer] Where does webflow live? I ran into some issues last night with spring-sandbox.jar from Spring 1.2 RC1 and Spring Web Flow PR2. The problem turned out to be that many of the flow classes where already in my spring-sandbox.jar. Once I deleted them from spring-sandbox.jar, everything worked fine. How do I eliminate this duplication in the future? Is the web flow stuff in spring-sandbox.jar? The main reason I'm using the sandbox JAR is for Commons Validator. Thanks, Matt ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Keith D. <ke...@in...> - 2005-04-13 15:22:34
|
I don't see why Web Flow should not be its own module. It's 135K as is, probably around 115 classes. I also think data binding could nicely be its own module as well, upon which web flow would depend. A smart build system would make things manageable. Look at how the eclipse project does it -- they have lots of different modules for the different parts of Eclipse, and they're successful at it. I'm not saying Hibernate and OJB and iBatis should each be their own, for example, that's probably a bit xtreme -- but ORM might well be. We probably shouldn't get distracted by this now given 1.2. Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Juergen Hoeller Sent: Tuesday, April 12, 2005 5:17 PM To: spr...@li... Subject: Re: [Springframework-developer] Where does webflow live? Ah, our favorite topic once again ;-) I'm not entirely sure whether Web Flow will get its own module; could be too fine-granular. The binding framework quite certainly shouldn't, which would already cause a problem with Web Flow's current status if we had modules. To give some numbers: If we want to have the binding framework, JCA support, Hibernate support, Web Flow, etc as separate modules (which would be necessary to get your desired effect of not putting any early-access stuff in the sandbox), we would end up with at least 35 modules (that's our top-level packages plus some subpackages of relevant size). Frankly, I consider that a horror scenario in terms of management and would strongly vote against it. I guess what I'm saying is that modules only *look* convincingly easy, but won't be a general solution for the early access problem in practice. Keith, please try to imagine this in detail and don't just consider it as solution upfront. This is absolutely non-trivial when looking at the details. Before we continue to spread the word on modules, I'd like to see concrete suggestions for module separation, respecting the interdependencies outlined in section 3 of our readme. I have already tried multiple times to nail down some options, and have always failed to find a convincing separation. The current jar files (12) might be a starting point, but I'm not sure that they can serve as module granularity too... Some packages are joined together there rather arbitrarily (from a source module perspective), for example the ones in spring-support.jar, or the separation between spring-orm.jar (which includes the entire ORM support except for Hibernate) and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1 to source modules. So in total, it's unclear to me how a concrete module separation could look like (the more I look at it, the harder it seems). I doubt that we can resolve this within the 1.3 timeframe, given that we have such an aggressive schedule there, with just two months for multiple major new features. Anyway, the real problem here is the sandbox, IMO. There's too much stuff in there, both dead and somewhat alive. Noone should have to rely on spring-sandbox.jar!! Everything that's of some use in there should move, either to the core or to Spring Modules. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Keith Donald Sent: Tuesday, April 12, 2005 9:24 PM To: spr...@li... Subject: RE: [Springframework-developer] Where does webflow live? Aye, this is exactly why we need a modular CVS structure and a smarter build, which Colin is leading up in the post 1.2 timeframe. Web flow is currently maintained in the sandbox, yes. This means it is also included in spring-sandbox.jar when the 'sandboxjar' target is run. Independent of that fact, the webflow.release target ships spring-webflow.jar and spring-webflow-support.jar, pulling in _just_ the required code from the sandbox needed to run spring webflow. So, I guess you can say we've taken the stance that people aren't developing apps with spring-sandbox.jar in their classpath. Hmm... In any case, in the future spring-webflow will be in its own module with its own distributable, along side other well-defined core modules, and the sandbox will die the death it deserves (or be only used for true 'scratch' stuff) Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Matt Raible Sent: Tuesday, April 12, 2005 3:04 PM To: spr...@li... Subject: [Springframework-developer] Where does webflow live? I ran into some issues last night with spring-sandbox.jar from Spring 1.2 RC1 and Spring Web Flow PR2. The problem turned out to be that many of the flow classes where already in my spring-sandbox.jar. Once I deleted them from spring-sandbox.jar, everything worked fine. How do I eliminate this duplication in the future? Is the web flow stuff in spring-sandbox.jar? The main reason I'm using the sandbox JAR is for Commons Validator. Thanks, Matt ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Juergen H. <ju...@in...> - 2005-04-13 14:43:30
|
I'm not sure whether it is feasible for the Spring core to provide support for the JCA connection and transaction management contracts. This is beyond what Spring does in related areas: for example, we don't provide support for XA-enlistment of JDBC Connections from a local DataSource. This is where XAPool comes in: it includes an XA-aware pool facade that auto-enlists JDBC Connections with a given JTA TransactionManager and handles Connection state accordingly. Of course, XAPool is not a particularly exciting piece of software ;-) I would argue that there is a quite strong need for a better standalone XA-capable JDBC DataSource. While we're at it, JOTM isn't exactly perfect either; but compared to XAPool, it's still quite decent. For true 2-Phase-Commit, the resource needs to support the XAResource interface; in the case of JCA, via ManagedConnection.getXAResource(). So what's needed for JCA here is a generic XA-aware connection pool that provides auto-enlistment of connections, accessing the XAResource interface of the connector. I'm afraid that such XA-handling code is non-trivial to write. Essentially, we'd need to implement a javax.resource.spi.ConnectionManager that handles all of this for an arbitrary ManagedConnectionFactory: both the pooling of connections and the XA enlistment. Such a ConnectionManager would delegate to the javax.transaction.TransactionManager for the actual transactional management of XA resources, but it still needs to do a lot of quite tricky work. And it needs to do the entire connection pooling! I would argue that this outside of the scope of Spring. One of the nice things about the JTA/JCA spec combo is that they allow to separate the transaction manager from the connection pool completely, even in case of an XA-aware pool. So there could be independent transaction manager implementations and XA connection pool implementations, collaborating with each other through standard interfaces. JOTM and XAPool are good example for this separation. But there should be a better and more general pool than XAPool: one working with the JCA contracts, thus being able to handle any kind of resource rather than just JDBC Connections. I would love to see such a project emerge, maybe at Jakarta Commons or as independent SourceForge project. BTW, Tyrex (http://tyrex.sourceforge.net) offers a transaction manager plus a generic JCA-based connection pool in a combo. Unfortunately, it's virtually dead. But it could be an inspiration for an implementation of such a generic connection pool. Actually, there is a need for such a generic pool in Geronimo, where (as far as I know) JOTM will be used as transaction manager. They can't just use XAPool there, because they need to be JCA-compliant too. I wonder which pool they are gonna use there... third-party or Geronimo-specific? In any case, it should be a reusable component, so it's probably worth checking out. Juergen -----Original Message----- From: Thierry TEMPLIER [mailto:te...@ya...] Sent: Wednesday, April 13, 2005 12:59 PM To: Dmitriy Kopylenko; Juergen Hoeller Cc: Thierry TEMPLIER Subject: Re: [Springframework-developer] JCA support Hi Dmitriy and Juerguen, I think that it's feasible but it's not simple... We must support JCA 1.0 / 1.5 and the version 1.5 brings some important improvments in the SPI side! and manage the interactions with JCA SPI... In any case, I'm interesting to look at this and send you my code like for JCA CCI ;-) So we will see at this moment if it's in the scope of Spring JCA. Are you interested with this idea? Firstly, Dmitriy, I will debug and improve the beginned project around JOTM and take you up to date with my work... I have looked at the code you put in the Spring Main, Juerguen and congratulations it really improves and simplifies my work ;-) I will update the JCA sample and the documentation. Do you a date planned for the version 1.2 RC2 of Spring (when the documentation must be ready...)? Nevertheless, I have a remark about the record management. I see in the book "J2EE Connector Architecture and Enterprise Application Integration" a "strange" use of record with the JCA SAP connector. I have never used this connector but I will work on JCO the native (non JCA compliant) connector of SAP. Here is an extract of the code of the book: "Connection connection=...; Interaction interaction=...; MappedRecord inputRecord=recordFactory.createMappedRecord("BAPI_BANK_CREATE"); ResultSet input=(ResultSet)inputRecord.get("import"); //some works on the input record to put datas //for example input.updateString("BANK_CTRY",someValue); interaction.execute(null,inputRecord); ResultSet output=(ResultSet)inputRecord.get("export"); ..." That was the aim of my second flag (useInputAsOutput) for the two execute methods of CCI. If you work directly on records, there is no problem but it isn't possible if you use RecordCreator/RecordExtractor because records are managed by the Ccitemplate class. Perhaps I'm wrong. If not, a flag could be added on the CciTemplate for this case... Cheers, Thierry > It would be very desirable to see the JCA SPIs > implemented to allow > deploy and use of resource adapter in say a > standalone Servlet container > + standalone transaction coordinator (JOTM) and have > a full XA support > with 2PC (for example doing an IMS transaction + > Oracle operation in one > global TX context)! Is it really feasible? > > Dmitriy. Take a look at my blog: http://templth.blogspot.com/ ____________________________________________________________________________ _______________________ Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com |
|
From: Paul B. <PB...@ct...> - 2005-04-13 14:28:56
|
=20 Hi all,=20 =20 I'm presenting Spring at the internal Delivery Meeting at Cambridge = Technology Partners and Novell in Amsterdam on monday next week (April = 18th, 16.00 at the Novell office).=20 =20 This will be a high level presentation about the benefits of Spring and = why it matters to a consulting practice, but will also contain an overview = interesting enough for the consultants present that work on J2EE projects = (i.e. that write Java for a living :-)).=20 =20 Does anyone have some material I could use or copy/paste from?=20 =20 Thanks a lot in advance,=20 Paul.=20 =20 Paul Buying Senior Consultant pb...@no... M: +31 (0)6 30439836 Cambridge Technology Partners A Novell Company Arena Boulevard 129-133 1101 DM Amsterdam South-East The Netherlands http://www.ctp.com T: +31 (0)20-5750575 F: +31 (0)20-5750500 |
|
From: Juergen H. <ju...@in...> - 2005-04-13 12:42:05
|
Both approaches have advantages. If the overall size is rather small, I would lean towards a single springmodules.jar. If it starts getting bigger, offer both a full springmodules.jar and some finer-grained jar files (but not necessarily one for each piece of code, rather one for each high-level package). This is essentially what we're doing in core Spring too. The other question is how to organize the springmodules source tree. As I've already argued, jar file separation does not have to match source tree separation. A single source tree can be used to generate multiple jar files, just like we currently do for core Spring. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Dmitriy Kopylenko Sent: Wednesday, April 13, 2005 2:29 PM To: spr...@li... Subject: Re: [Springframework-developer] Where does webflow live? Thomas Risberg wrote: > Rob, > > So what is the plan for the springmodules - is this going to be one > monolithic collection of modules or do you plan to split it up into > specific subprojects? I have a couple of small modules that could > live there but I'm not sure of how to coordinate adding them and > creating a distributable jar file. Do you see each module as an > independent piece that will have its own jar file or do you envision a > single springmodules.jar? > I guess that springmodules.jar would be too coarse grained. I would lean towards a separate jar per module. What do others think? Dmitriy. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Dmitriy K. <dko...@ru...> - 2005-04-13 12:29:44
|
Thomas Risberg wrote: > Rob, > > So what is the plan for the springmodules - is this going to be one > monolithic collection of modules or do you plan to split it up into > specific subprojects? I have a couple of small modules that could > live there but I'm not sure of how to coordinate adding them and > creating a distributable jar file. Do you see each module as an > independent piece that will have its own jar file or do you envision a > single springmodules.jar? > I guess that springmodules.jar would be too coarse grained. I would lean towards a separate jar per module. What do others think? Dmitriy. |
|
From: Thomas R. <tho...@tr...> - 2005-04-13 12:06:20
|
Rob, So what is the plan for the springmodules - is this going to be one monolithic collection of modules or do you plan to split it up into specific subprojects? I have a couple of small modules that could live there but I'm not sure of how to coordinate adding them and creating a distributable jar file. Do you see each module as an independent piece that will have its own jar file or do you envision a single springmodules.jar? Thomas On Apr 13, 2005, at 7:34 AM, Rob Harrop wrote: > Well, I'll spend some time going through the sandbox and see what I > think is > a candidate for Spring Modules. I'll post the suggestions here and if > everyone is happy I'll do the move. We have about 6 active developers > on SM > who are not core Spring devs, plus there is me so we may be able to > breath > some live back into the stuff in the sandbox. > > Rob > > -- > Rob Harrop > Interface21 - Spring Services from the Source > http://www.springframework.com > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On > Behalf Of > Juergen Hoeller > Sent: 12 April 2005 22:17 > To: spr...@li... > Subject: Re: [Springframework-developer] Where does webflow live? > > Ah, our favorite topic once again ;-) > > I'm not entirely sure whether Web Flow will get its own module; could > be too > fine-granular. The binding framework quite certainly shouldn't, which > would > already cause a problem with Web Flow's current status if we had > modules. > > To give some numbers: If we want to have the binding framework, JCA > support, > Hibernate support, Web Flow, etc as separate modules (which would be > necessary to get your desired effect of not putting any early-access > stuff > in the sandbox), we would end up with at least 35 modules (that's our > top-level packages plus some subpackages of relevant size). Frankly, I > consider that a horror scenario in terms of management and would > strongly > vote against it. > > I guess what I'm saying is that modules only *look* convincingly easy, > but > won't be a general solution for the early access problem in practice. > Keith, > please try to imagine this in detail and don't just consider it as > solution > upfront. This is absolutely non-trivial when looking at the details. > > Before we continue to spread the word on modules, I'd like to see > concrete > suggestions for module separation, respecting the interdependencies > outlined > in section 3 of our readme. I have already tried multiple times to > nail down > some options, and have always failed to find a convincing separation. > > The current jar files (12) might be a starting point, but I'm not sure > that > they can serve as module granularity too... Some packages are joined > together there rather arbitrarily (from a source module perspective), > for > example the ones in spring-support.jar, or the separation between > spring-orm.jar (which includes the entire ORM support except for > Hibernate) > and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1 to > source > modules. > > So in total, it's unclear to me how a concrete module separation could > look > like (the more I look at it, the harder it seems). I doubt that we can > resolve this within the 1.3 timeframe, given that we have such an > aggressive > schedule there, with just two months for multiple major new features. > > Anyway, the real problem here is the sandbox, IMO. There's too much > stuff in > there, both dead and somewhat alive. Noone should have to rely on > spring-sandbox.jar!! Everything that's of some use in there should > move, > either to the core or to Spring Modules. > > Juergen > > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...]On Behalf > Of Keith Donald > Sent: Tuesday, April 12, 2005 9:24 PM > To: spr...@li... > Subject: RE: [Springframework-developer] Where does webflow live? > > > Aye, this is exactly why we need a modular CVS structure and a smarter > build, which Colin is leading up in the post 1.2 timeframe. > > Web flow is currently maintained in the sandbox, yes. This means it > is also > included in spring-sandbox.jar when the 'sandboxjar' target is run. > > Independent of that fact, the webflow.release target ships > spring-webflow.jar and spring-webflow-support.jar, pulling in _just_ > the > required code from the sandbox needed to run spring webflow. > > So, I guess you can say we've taken the stance that people aren't > developing > apps with spring-sandbox.jar in their classpath. Hmm... > > In any case, in the future spring-webflow will be in its own module > with its > own distributable, along side other well-defined core modules, and the > sandbox will die the death it deserves (or be only used for true > 'scratch' > stuff) > > Keith > > > > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On > Behalf Of > Matt Raible > Sent: Tuesday, April 12, 2005 3:04 PM > To: spr...@li... > Subject: [Springframework-developer] Where does webflow live? > > I ran into some issues last night with spring-sandbox.jar from Spring > 1.2 RC1 and Spring Web Flow PR2. The problem turned out to be that > many of the flow classes where already in my spring-sandbox.jar. Once > I deleted them from spring-sandbox.jar, everything worked fine. How do > I eliminate this duplication in the future? Is the web flow stuff in > spring-sandbox.jar? The main reason I'm using the sandbox JAR is for > Commons Validator. > > Thanks, > > Matt > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Rob H. <rob...@in...> - 2005-04-13 11:34:13
|
Well, I'll spend some time going through the sandbox and see what I think is a candidate for Spring Modules. I'll post the suggestions here and if everyone is happy I'll do the move. We have about 6 active developers on SM who are not core Spring devs, plus there is me so we may be able to breath some live back into the stuff in the sandbox. Rob -- Rob Harrop Interface21 - Spring Services from the Source http://www.springframework.com -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Juergen Hoeller Sent: 12 April 2005 22:17 To: spr...@li... Subject: Re: [Springframework-developer] Where does webflow live? Ah, our favorite topic once again ;-) I'm not entirely sure whether Web Flow will get its own module; could be too fine-granular. The binding framework quite certainly shouldn't, which would already cause a problem with Web Flow's current status if we had modules. To give some numbers: If we want to have the binding framework, JCA support, Hibernate support, Web Flow, etc as separate modules (which would be necessary to get your desired effect of not putting any early-access stuff in the sandbox), we would end up with at least 35 modules (that's our top-level packages plus some subpackages of relevant size). Frankly, I consider that a horror scenario in terms of management and would strongly vote against it. I guess what I'm saying is that modules only *look* convincingly easy, but won't be a general solution for the early access problem in practice. Keith, please try to imagine this in detail and don't just consider it as solution upfront. This is absolutely non-trivial when looking at the details. Before we continue to spread the word on modules, I'd like to see concrete suggestions for module separation, respecting the interdependencies outlined in section 3 of our readme. I have already tried multiple times to nail down some options, and have always failed to find a convincing separation. The current jar files (12) might be a starting point, but I'm not sure that they can serve as module granularity too... Some packages are joined together there rather arbitrarily (from a source module perspective), for example the ones in spring-support.jar, or the separation between spring-orm.jar (which includes the entire ORM support except for Hibernate) and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1 to source modules. So in total, it's unclear to me how a concrete module separation could look like (the more I look at it, the harder it seems). I doubt that we can resolve this within the 1.3 timeframe, given that we have such an aggressive schedule there, with just two months for multiple major new features. Anyway, the real problem here is the sandbox, IMO. There's too much stuff in there, both dead and somewhat alive. Noone should have to rely on spring-sandbox.jar!! Everything that's of some use in there should move, either to the core or to Spring Modules. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Keith Donald Sent: Tuesday, April 12, 2005 9:24 PM To: spr...@li... Subject: RE: [Springframework-developer] Where does webflow live? Aye, this is exactly why we need a modular CVS structure and a smarter build, which Colin is leading up in the post 1.2 timeframe. Web flow is currently maintained in the sandbox, yes. This means it is also included in spring-sandbox.jar when the 'sandboxjar' target is run. Independent of that fact, the webflow.release target ships spring-webflow.jar and spring-webflow-support.jar, pulling in _just_ the required code from the sandbox needed to run spring webflow. So, I guess you can say we've taken the stance that people aren't developing apps with spring-sandbox.jar in their classpath. Hmm... In any case, in the future spring-webflow will be in its own module with its own distributable, along side other well-defined core modules, and the sandbox will die the death it deserves (or be only used for true 'scratch' stuff) Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Matt Raible Sent: Tuesday, April 12, 2005 3:04 PM To: spr...@li... Subject: [Springframework-developer] Where does webflow live? I ran into some issues last night with spring-sandbox.jar from Spring 1.2 RC1 and Spring Web Flow PR2. The problem turned out to be that many of the flow classes where already in my spring-sandbox.jar. Once I deleted them from spring-sandbox.jar, everything worked fine. How do I eliminate this duplication in the future? Is the web flow stuff in spring-sandbox.jar? The main reason I'm using the sandbox JAR is for Commons Validator. Thanks, Matt ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Juergen H. <ju...@in...> - 2005-04-13 11:28:05
|
Wow, that came in late... that's a rant from last night, actually ;-) Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Juergen Hoeller Sent: Tuesday, April 12, 2005 11:17 PM To: spr...@li... Subject: Re: [Springframework-developer] Where does webflow live? Ah, our favorite topic once again ;-) I'm not entirely sure whether Web Flow will get its own module; could be too fine-granular. The binding framework quite certainly shouldn't, which would already cause a problem with Web Flow's current status if we had modules. To give some numbers: If we want to have the binding framework, JCA support, Hibernate support, Web Flow, etc as separate modules (which would be necessary to get your desired effect of not putting any early-access stuff in the sandbox), we would end up with at least 35 modules (that's our top-level packages plus some subpackages of relevant size). Frankly, I consider that a horror scenario in terms of management and would strongly vote against it. I guess what I'm saying is that modules only *look* convincingly easy, but won't be a general solution for the early access problem in practice. Keith, please try to imagine this in detail and don't just consider it as solution upfront. This is absolutely non-trivial when looking at the details. Before we continue to spread the word on modules, I'd like to see concrete suggestions for module separation, respecting the interdependencies outlined in section 3 of our readme. I have already tried multiple times to nail down some options, and have always failed to find a convincing separation. The current jar files (12) might be a starting point, but I'm not sure that they can serve as module granularity too... Some packages are joined together there rather arbitrarily (from a source module perspective), for example the ones in spring-support.jar, or the separation between spring-orm.jar (which includes the entire ORM support except for Hibernate) and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1 to source modules. So in total, it's unclear to me how a concrete module separation could look like (the more I look at it, the harder it seems). I doubt that we can resolve this within the 1.3 timeframe, given that we have such an aggressive schedule there, with just two months for multiple major new features. Anyway, the real problem here is the sandbox, IMO. There's too much stuff in there, both dead and somewhat alive. Noone should have to rely on spring-sandbox.jar!! Everything that's of some use in there should move, either to the core or to Spring Modules. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Keith Donald Sent: Tuesday, April 12, 2005 9:24 PM To: spr...@li... Subject: RE: [Springframework-developer] Where does webflow live? Aye, this is exactly why we need a modular CVS structure and a smarter build, which Colin is leading up in the post 1.2 timeframe. Web flow is currently maintained in the sandbox, yes. This means it is also included in spring-sandbox.jar when the 'sandboxjar' target is run. Independent of that fact, the webflow.release target ships spring-webflow.jar and spring-webflow-support.jar, pulling in _just_ the required code from the sandbox needed to run spring webflow. So, I guess you can say we've taken the stance that people aren't developing apps with spring-sandbox.jar in their classpath. Hmm... In any case, in the future spring-webflow will be in its own module with its own distributable, along side other well-defined core modules, and the sandbox will die the death it deserves (or be only used for true 'scratch' stuff) Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Matt Raible Sent: Tuesday, April 12, 2005 3:04 PM To: spr...@li... Subject: [Springframework-developer] Where does webflow live? I ran into some issues last night with spring-sandbox.jar from Spring 1.2 RC1 and Spring Web Flow PR2. The problem turned out to be that many of the flow classes where already in my spring-sandbox.jar. Once I deleted them from spring-sandbox.jar, everything worked fine. How do I eliminate this duplication in the future? Is the web flow stuff in spring-sandbox.jar? The main reason I'm using the sandbox JAR is for Commons Validator. Thanks, Matt ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Juergen H. <ju...@in...> - 2005-04-13 10:37:39
|
Hi everybody, I've spent some time yesterday and today to improve our JDK 1.3 compatibility: * The classic VM of Sun's JDK 1.3 breaks when an abstract implementation of an interface refers to an interface method that it doesn't redeclare itself. I've refined our AbstractResource class accordingly. (http://opensource.atlassian.com/projects/spring/browse/SPR-852) * Our entire test suite runs (and passes) on JDK 1.3 now! It needs to be built on JDK 1.4+, but it can run on JDK 1.3. That is, "buildtests" needs to be executed on JDK 1.4+, but the "tests" target can run on JDK 1.3. In the course of making the test suite work, I've refined various implementation classes to be more JDK-1.3-friendly: * Our CodebaseAwareObjectInputStream explicitly resolves primitive class names, which is necessary on JDK 1.3 (where the standard ObjectInputStream doesn't do this). HTTP invoker uses CodebaseAwareObjectInputStream even with no codebase specified now, to deserialize primitives on JDK 1.3. * Our UrlPathHelper supports URL-decoding with the VM platform default encoding on JDK 1.3 now. Previously, it just worked on JDK 1.4, because it insisted to decode with the request encoding explicitly specified. This is used by AbstractUrlHandlerMapping and other web MVC classes. I also had to refine various test cases which insisted on JDK 1.4+ semantics before. This was pretty straightforward, but affected numerous places. Furthermore, I had to downgrade the EJB and JCA jars that we ship to EJB 2.0 and JCA 1.0, respectively. EJB 2.1 and JCA 1.5 are unfortunately built with JDK 1.4 as target, which makes our test suite break. EJB 2.0 and JCA 1.0 are fine for us anyway, though, so that downgrade should be acceptable. It would be great if we could include a run of the entire test suite on JDK 1.3 into our automated build. There are essentially 3 combinations for the test suite now: * building on JDK 1.5, running on JDK 1.5 * building on JDK 1.4, running on JDK 1.4 * building on JDK 1.4, runnong on JDK 1.3 This should eliminate the potential for any accidental breakages on JDK 1.3, such as the one we had in autumn (with StringBuffer.indexOf usage). Juergen |
1239 messages has been excluded from this view by a project administrator.
