Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-03-11 14:40:54
|
Everybody, As we agree to do quick 1.1/1.2/etc releases, we need to prioritize the = feature requests in our Jira now. I suggest to target the following: 1.0 final (March 20th) * AOP Alliance update * FreeMarker support 1.1 RC1 (end of April) * JMS support * JMX support * declarative rules-based validator * minor enhancements to the web framework 1.1 final (late May) 1.2 RC1 (end of June) * OGNL support * JCA support * enhanced RMI support * enhanced PropertiesBeanDefinitionReader 1.2 final (late July) 1.3 RC1 * support for JDK 1.5 metadata? * Prevayler support? * JdoDialects for major JDO implementations? * Spring/JDO sample application? Keith et al, do you think you can finish JMX and declarative validation = in time? Anyone willing to work on OGNL support and give an estimate? Juergen DI J=FCrgen H=F6ller Senior System Architect ______________________________________ werk3ATS - division systementwicklung werk3AT informations- und mediensysteme europaplatz 4 A - 4020 linz t. +43 (0) 732 71 65 29 502 f. +43 (0) 732 71 65 29 3 mailto:jue...@we... http://www.werk3at.com ______________________________________ werk3ATS - WIR ENTWICKELN ERFOLG |
|
From: <jue...@we...> - 2004-03-31 07:01:48
|
Dear Spring developers, =20 I'd like to discuss a refined road map for the next couple of months. My = initial suggestions were a bit too eager, I guess, given that we still = need to refine javadocs and reference docs for 1.0.x, and of course = apply bugfixes respectively appropriate minor enhancements. =20 So I suggest the following time plan now: =20 Spring 1.0.x: doc polishing, bugfixing, minor enhancements - 1.0.1: early April - 1.0.2: late May =20 Spring 1.1.x: JMS support, JMX support, declarative validation - 1.1 RC1: early July - 1.1 final: late August - 1.1.1: late September =20 Spring 1.2.x: OGNL support, JCA support, enhanced RMI support - 1.2 RC1: early November - 1.2 final: late December =20 Further issues are JSF and Portlet support. There is actually quite a = bit of interest in these from various users/integrators; they are also = important for us from a marketing perspective. I'm not keen on providing = official support before 1.2, though. =20 Regards, Juergen =20 |
|
From: Alef A. <al...@jt...> - 2004-03-31 07:26:22
|
> Further issues are JSF and Portlet support. There is actually quite a bit > of interest in these from various users/integrators; they are also > important for us from a marketing perspective. I'm not keen on providing > official support before 1.2, though. JSF and Portlet functionality don't have to be provided in one and the same release. I have been looking a bit into the portlet stuff and it doesn't same all that difficult. I think I'll experiment with it during the next couple of weeks. Major issue is the common supporting functionality (ContextLoader, WebAppCtx, Databinding) between our Web stuff and our future Portlet stuff (and probably also the JSF stuff). Revising the supporting functionality right now (or for 1.1) is not an option imo. I probably can't avoid having to copy-and-paste a lot of code while experimenting and since that's *not* something we want to have in a release, I'm afraid you're right :(. Alef |
|
From: Ben A. <ben...@ac...> - 2004-04-09 06:28:55
|
Hi > JSF and Portlet functionality don't have to be provided in > one and the same release. I have been looking a bit into the > portlet stuff and it doesn't same all that difficult. > > I think I'll experiment with it during the next couple of > weeks. Major issue is the common supporting functionality > (ContextLoader, WebAppCtx, > Databinding) between our Web stuff and our future Portlet > stuff (and probably also the JSF stuff). Revising the > supporting functionality right now (or for 1.1) is not an option imo. > > I probably can't avoid having to copy-and-paste a lot of code > while experimenting and since that's *not* something we want > to have in a release, I'm afraid you're right :(. Several people have previously mentioned portlets and JSF. We are trying to decide whether to implement portlets in our next project, or just stick to include files and/or something like Sitemesh, Tiles etc. Regarding portlets, there is the Pico-based Exo project (http://exo.sourceforge.net/) and Pluto (http://jakarta.apache.org/pluto/). Has anyone done any work on integrating portlets, JSF or projects such as these into Spring? Would anyone be willing and have time to collaborate on this? Best regards Ben |
|
From: William G. T. Jr. <wg...@ru...> - 2004-04-09 13:30:40
|
Ben Alex wrote: > Hi > > >>JSF and Portlet functionality don't have to be provided in >>one and the same release. I have been looking a bit into the >>portlet stuff and it doesn't same all that difficult. >> >>I think I'll experiment with it during the next couple of >>weeks. Major issue is the common supporting functionality >>(ContextLoader, WebAppCtx, >>Databinding) between our Web stuff and our future Portlet >>stuff (and probably also the JSF stuff). Revising the >>supporting functionality right now (or for 1.1) is not an option imo. >> >>I probably can't avoid having to copy-and-paste a lot of code >>while experimenting and since that's *not* something we want >>to have in a release, I'm afraid you're right :(. > > > Several people have previously mentioned portlets and JSF. We are trying to > decide whether to implement portlets in our next project, or just stick to > include files and/or something like Sitemesh, Tiles etc. > > Regarding portlets, there is the Pico-based Exo project > (http://exo.sourceforge.net/) and Pluto (http://jakarta.apache.org/pluto/). > Has anyone done any work on integrating portlets, JSF or projects such as > these into Spring? Would anyone be willing and have time to collaborate on > this? Rutgers is very interested in Spring support for the Portlet API in the form of a PortletDispatcher as it were. We run the uPortal[1] platform and the latest release embeds Pluto. We are just now embarking on dev cycle for new porlets that takes us thru september, if possible these new portlets would live behind a Spring PortletDispatcher. We have had some preliminary dicussions with Alef about what it might look like, and should be in a better positition to try out some ideas/code in a few weeks. later. Bill [1] http://www.uportal.org/ |
|
From: Rod J. <rod...@in...> - 2004-03-31 12:40:31
|
Some comments: Spring 1.0.x: doc polishing, bugfixing, minor enhancements - 1.0.1: early April - 1.0.2: late May Spring 1.1.x: JMS support, JMX support, declarative validation [RJ: pointcut expression language (AOP), JSR-175 preview? ] - 1.1 RC1: early July - 1.1 final: late August - 1.1.1: late September [RJ: why are we _scheduling_ a 1.1.1?] Spring 1.2.x: OGNL support, JCA support, enhanced RMI support - 1.2 RC1: early November - 1.2 final: late December Further issues are JSF and Portlet support. There is actually quite a bit of interest in these from various users/integrators; they are also important for us from a marketing perspective. I'm not keen on providing official support before 1.2, though. [RJ: depends on what's involved. I'd be keen to have JSF support sooner rather than later if it's straightforward. I'm going to be looking at that soon. Portlets I think are more of a niche interest. ] Regards, Juergen ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=ick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: William G. T. Jr. <wg...@ru...> - 2004-03-31 13:20:35
|
Rod Johnson wrote: > Some comments: > > Spring 1.0.x: doc polishing, bugfixing, minor enhancements > - 1.0.1: early April > - 1.0.2: late May > > Spring 1.1.x: JMS support, JMX support, declarative validation > [RJ: pointcut expression language (AOP), JSR-175 preview? ] > - 1.1 RC1: early July > - 1.1 final: late August > - 1.1.1: late September > [RJ: why are we _scheduling_ a 1.1.1?] > > Spring 1.2.x: OGNL support, JCA support, enhanced RMI support > - 1.2 RC1: early November > - 1.2 final: late December > > Further issues are JSF and Portlet support. There is actually quite a bit of > interest in these from various users/integrators; they are also important > for us from a marketing perspective. I'm not keen on providing official > support before 1.2, though. > > [RJ: depends on what's involved. I'd be keen to have JSF support sooner > rather than later if it's straightforward. I'm going to be looking at that > soon. Portlets I think are more of a niche interest. ] Not sure if we constitute the niche or not, but I tell you that we are very interested in having Spring support for the Portlet API similar to the Spring WebMVC. If things continue to go the way they are around here the portal will be the primary service delivery mechanism...meaning all of our Spring apps will live behind the Portlet API not the Servlet API. Cheers, Bill -- William G. Thompson, Jr. Associate Director of New Technologies Administrative Computing Services, Rutgers University voice: 732 445-5428 | fax: 732 445-5493 | wg...@ru... |
|
From: Colin S. <col...@ex...> - 2004-03-31 14:17:25
|
This is fine with me. It seems like JMX and validation are in fairly=20 capable hands, and JMS is on it's way at least, so as OGNL scratches an=20 itch for a lot of people (including me), I think I will be working on it=20 before this timeframe, hopefully for inclusion in 1.1... j=FCrgen h=F6ller [werk3AT] wrote: >Dear Spring developers, >=20 >I'd like to discuss a refined road map for the next couple of months. My= initial suggestions were a bit too eager, I guess, given that we still n= eed to refine javadocs and reference docs for 1.0.x, and of course apply = bugfixes respectively appropriate minor enhancements. >=20 >So I suggest the following time plan now: >=20 >Spring 1.0.x: doc polishing, bugfixing, minor enhancements >- 1.0.1: early April >- 1.0.2: late May >=20 >Spring 1.1.x: JMS support, JMX support, declarative validation >- 1.1 RC1: early July >- 1.1 final: late August >- 1.1.1: late September >=20 >Spring 1.2.x: OGNL support, JCA support, enhanced RMI support >- 1.2 RC1: early November >- 1.2 final: late December >=20 >Further issues are JSF and Portlet support. There is actually quite a bi= t of interest in these from various users/integrators; they are also impo= rtant for us from a marketing perspective. I'm not keen on providing offi= cial support before 1.2, though. >=20 >Regards, >Juergen >=20 > |
|
From: Colin S. <col...@ex...> - 2004-03-11 15:03:06
|
j=FCrgen h=F6ller [werk3AT] wrote: >Everybody, > >As we agree to do quick 1.1/1.2/etc releases, we need to prioritize the = feature requests in our Jira now. I suggest to target the following: > >1.0 final (March 20th) >* AOP Alliance update >* FreeMarker support > >1.1 RC1 (end of April) >* JMS support >* JMX support >* declarative rules-based validator >* minor enhancements to the web framework > >1.1 final (late May) > >1.2 RC1 (end of June) >* OGNL support >* JCA support >* enhanced RMI support >* enhanced PropertiesBeanDefinitionReader > >1.2 final (late July) > >1.3 RC1 >* support for JDK 1.5 metadata? >* Prevayler support? >* JdoDialects for major JDO implementations? >* Spring/JDO sample application? > >Keith et al, do you think you can finish JMX and declarative validation = in time? Anyone willing to work on OGNL support and give an estimate? > >Juergen > =20 > I should be able to do the OGNL support in that timeframe. The last 6=20 weeks or so have been really bad for me, with basically no free time at=20 all, and this will continue for another couple of weeks, but there=20 should be no problem working on it in the timeframe above... Regards, Colin |
|
From: Keith D. <kd...@cs...> - 2004-03-11 15:36:24
|
The end of April sounds reasonable for JMX support and the declarative validation. Most of the validation design/coding is already complete (though we = still need more rules, more tests/feedback, and better docs.) The JMX stuff is obviously more work and presents more issues to = consider, but I still think the end of April works for base JMX support = (jmx-enabling spring beans.) Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of j=FCrgen h=F6ller [werk3AT] Sent: Thursday, March 11, 2004 9:24 AM To: spr...@li... Subject: [Springframework-developer] Road map Everybody, As we agree to do quick 1.1/1.2/etc releases, we need to prioritize the feature requests in our Jira now. I suggest to target the following: 1.0 final (March 20th) * AOP Alliance update * FreeMarker support 1.1 RC1 (end of April) * JMS support * JMX support * declarative rules-based validator * minor enhancements to the web framework 1.1 final (late May) 1.2 RC1 (end of June) * OGNL support * JCA support * enhanced RMI support * enhanced PropertiesBeanDefinitionReader 1.2 final (late July) 1.3 RC1 * support for JDK 1.5 metadata? * Prevayler support? * JdoDialects for major JDO implementations? * Spring/JDO sample application? Keith et al, do you think you can finish JMX and declarative validation = in time? Anyone willing to work on OGNL support and give an estimate? Juergen DI J=FCrgen H=F6ller Senior System Architect ______________________________________ werk3ATS - division systementwicklung werk3AT informations- und mediensysteme europaplatz 4 A - 4020 linz t. +43 (0) 732 71 65 29 502 f. +43 (0) 732 71 65 29 3 mailto:jue...@we... http://www.werk3at.com ______________________________________ werk3ATS - WIR ENTWICKELN ERFOLG ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of = GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Alef A. <al...@jt...> - 2004-03-11 16:35:01
|
How about declarative security, should somehow also be mentioned in the roadmap. Any ideas so far about how to go about it? Alef > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On = Behalf > Of j=FCrgen h=F6ller [werk3AT] > Sent: Thursday, March 11, 2004 3:24 PM > To: spr...@li... > Subject: [Springframework-developer] Road map >=20 > Everybody, >=20 > As we agree to do quick 1.1/1.2/etc releases, we need to prioritize = the > feature requests in our Jira now. I suggest to target the following: >=20 > 1.0 final (March 20th) > * AOP Alliance update > * FreeMarker support >=20 > 1.1 RC1 (end of April) > * JMS support > * JMX support > * declarative rules-based validator > * minor enhancements to the web framework >=20 > 1.1 final (late May) >=20 > 1.2 RC1 (end of June) > * OGNL support > * JCA support > * enhanced RMI support > * enhanced PropertiesBeanDefinitionReader >=20 > 1.2 final (late July) >=20 > 1.3 RC1 > * support for JDK 1.5 metadata? > * Prevayler support? > * JdoDialects for major JDO implementations? > * Spring/JDO sample application? >=20 > Keith et al, do you think you can finish JMX and declarative = validation in > time? Anyone willing to work on OGNL support and give an estimate? >=20 > Juergen >=20 >=20 > DI J=FCrgen H=F6ller > Senior System Architect > ______________________________________ >=20 > werk3ATS - division systementwicklung > werk3AT informations- und mediensysteme >=20 > europaplatz 4 > A - 4020 linz >=20 > t. +43 (0) 732 71 65 29 502 > f. +43 (0) 732 71 65 29 3 > mailto:jue...@we... > http://www.werk3at.com > ______________________________________ > werk3ATS - WIR ENTWICKELN ERFOLG >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Ben A. <ben...@ac...> - 2004-03-11 20:59:02
|
> How about declarative security, should somehow also be > mentioned in the roadmap. Any ideas so far about how to go about it? Thought I'd jump in here. The Acegi Security System for Spring project now has a home at SoureForge. I'm currently writing automated container integration unit tests (ie unzip a stock standard container release, install the security module to it, and run unit tests). CVS and a new ZIP release will be at SourceForge in a day or two, and anyone interested is welcome to participate in development. Whilst I initially wrote the above project with a view to inclusion in Spring, I also recognise there are no Spring-specific dependencies apart from standard bean context and interceptor services. As such, from a technical perspective security could be effectively developed in a separate project, or as a separate module under Spring CVS. There is no technical requirement in having it in Spring core. The real issue is whether from a marketing perspective the Spring Framework needs its very own security capability/project, an "official" separate security project that users are pointed towards, or a list of external (untested) security projects that claim to support Spring. It would be nice to avoid duplication of efforts on security, particularly given most of it involves writing adapters between the project security and the container's native security. Maximising the user and developer base of a single security project will also have obvious benefits in terms of testing, issue identification, support and improvement. Ben |
|
From: Colin S. <col...@ex...> - 2004-03-11 21:55:47
|
Ben Alex wrote: >>How about declarative security, should somehow also be >>mentioned in the roadmap. Any ideas so far about how to go about it? >> >> > >Thought I'd jump in here. The Acegi Security System for Spring project now >has a home at SoureForge. I'm currently writing automated container >integration unit tests (ie unzip a stock standard container release, install >the security module to it, and run unit tests). CVS and a new ZIP release >will be at SourceForge in a day or two, and anyone interested is welcome to >participate in development. > >Whilst I initially wrote the above project with a view to inclusion in >Spring, I also recognise there are no Spring-specific dependencies apart >from standard bean context and interceptor services. As such, from a >technical perspective security could be effectively developed in a separate >project, or as a separate module under Spring CVS. There is no technical >requirement in having it in Spring core. The real issue is whether from a >marketing perspective the Spring Framework needs its very own security >capability/project, an "official" separate security project that users are >pointed towards, or a list of external (untested) security projects that >claim to support Spring. > >It would be nice to avoid duplication of efforts on security, particularly >given most of it involves writing adapters between the project security and >the container's native security. Maximising the user and developer base of a >single security project will also have obvious benefits in terms of testing, >issue identification, support and improvement. > >Ben > > Ben, Your stuff looks great. I'm probably going to try using it in our main app in the relatively near-term (a month or so). I _really_ appreciate the work you've put into it. At the same time, due to the fact the people's security needs are so varied, it might be a bit preliminary to bake it into Spring itself without letting people use it for a while, hopefully with the idea that any relevant comments or issues would be raised in the process. Once something is part of Spring itself it's going to be much harder to make backwards incompatible changes, whereas with an external add-on, there could simply be two versions. Just IMHO... Regards, Colin |
|
From: Alef A. <al...@jt...> - 2004-03-11 22:21:09
|
First of all I must say I forget about you Ben and I really have to take a look at your code soon! I just downloaded it... Our proposition is: easier J2EE. Actually, at the moment we're not doing everything that's out there. One of those things is declarative security. I really think it should be addressed in some way. Some people just don't see Spring as suitable for enterprise apps, because of lack of security infrastructure (this is the main reason for some applications we're still using EJBs, arggghhhh, I hate it!). Colin, you're right about varying requirements. The question is: are role-based security and method-level restrictions enough. Well, I have been able to build decent apps with that, so I would say: yes. Unfortunately there are no decent common grounds on which all servlet containers base their security (like JTA), so that I guess, is the real problem. Alef > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On Behalf > Of Colin Sampaleanu > Sent: Thursday, March 11, 2004 10:36 PM > To: spr...@li... > Subject: Re: [Springframework-developer] Road map (security) > > Ben Alex wrote: > > >>How about declarative security, should somehow also be > >>mentioned in the roadmap. Any ideas so far about how to go about it? > >> > >> > > > >Thought I'd jump in here. The Acegi Security System for Spring project > now > >has a home at SoureForge. I'm currently writing automated container > >integration unit tests (ie unzip a stock standard container release, > install > >the security module to it, and run unit tests). CVS and a new ZIP release > >will be at SourceForge in a day or two, and anyone interested is welcome > to > >participate in development. > > > >Whilst I initially wrote the above project with a view to inclusion in > >Spring, I also recognise there are no Spring-specific dependencies apart > >from standard bean context and interceptor services. As such, from a > >technical perspective security could be effectively developed in a > separate > >project, or as a separate module under Spring CVS. There is no technical > >requirement in having it in Spring core. The real issue is whether from a > >marketing perspective the Spring Framework needs its very own security > >capability/project, an "official" separate security project that users > are > >pointed towards, or a list of external (untested) security projects that > >claim to support Spring. > > > >It would be nice to avoid duplication of efforts on security, > particularly > >given most of it involves writing adapters between the project security > and > >the container's native security. Maximising the user and developer base > of a > >single security project will also have obvious benefits in terms of > testing, > >issue identification, support and improvement. > > > >Ben > > > > > Ben, > > Your stuff looks great. I'm probably going to try using it in our main > app in the relatively near-term (a month or so). I _really_ appreciate > the work you've put into it. > > At the same time, due to the fact the people's security needs are so > varied, it might be a bit preliminary to bake it into Spring itself > without letting people use it for a while, hopefully with the idea that > any relevant comments or issues would be raised in the process. Once > something is part of Spring itself it's going to be much harder to make > backwards incompatible changes, whereas with an external add-on, there > could simply be two versions. Just IMHO... > > Regards, > Colin > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Ben A. <ben...@ac...> - 2004-03-11 23:33:43
|
I agree there is value in allowing the Acegi security project to develop and see where it leads for now. One question: should I establish a separate SF mailing list or is there any objection in using springframework-developer and spring-user for now? I doubt there will be much traffic and it will be easier to solicit feedback from those not actively using it. At this time I'm really focusing on Spring. Thus the project name has "for Spring" at the end. It wouldn't be too hard to get the Acegi security project supporting non-Spring containers, but doing so at this early stage would dilute the focus of the project. I'm not even sure what the status is of other IoC containers and security - do they already have it? If so, we wouldn't bother. If not, security could be a differentiation factor for Spring. I'd welcome other views on this. > Actually, at the moment we're not doing everything that's out > there. One of those things is declarative security. I really > think it should be addressed in some way. Some people just > don't see Spring as suitable for enterprise apps, because of > lack of security infrastructure (this is the main reason for > some applications we're still using EJBs, arggghhhh, I hate it!). The only argument I can think of against Spring's security support today is the low installed base of the Acegi security project. Conversely, the code is simple, with reasonable test coverage and easily reviewed. The Acegi security project certainly provides plenty of features and plug-in points. A major benefit is that it complements the existing container security capabilities via the included "container adapters". This has a number of benefits: * Appeals to users who want to build on their understanding of J2EE declarative security * Your container obtains the authentication credentials from the user (form, basic auth etc) * Normal declarative security can be used to secure EJB, Servlets, JSPs, static content etc * The Acegi security approach complements future security enhancement of J2EE specs * It immediately works out-of-the-box, which is always encouraging to new users * You can still use the "alternative approach" (discussed below) The "alternative approach" is to ignore container adapters. That is, you populate your Authentication object in a Session (probably via a form), and write your own handler for securing static content etc (like a HttpRequestPathAuthorizationFilter). The price of this is ignoring container capabilities and the J2EE specs. Still, you can easily do that using the Acegi approach. Or you can do it the recommended way via container adapters. Cheers Ben |
|
From: Darren D. <da...@da...> - 2004-03-11 16:38:46
|
> 1.0 final (March 20th) > * FreeMarker support that's fine. --=20 Darren Davison Public Key: http://www.davison.uk.net/key.jsp |
