Menu
▾
▴
webmacro-user — List for WebMacro users, developers, competitors, and friends.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(68) |
Dec
(77) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(75) |
Feb
(84) |
Mar
(89) |
Apr
(96) |
May
(52) |
Jun
(73) |
Jul
(99) |
Aug
(46) |
Sep
(40) |
Oct
(46) |
Nov
(45) |
Dec
(25) |
| 2004 |
Jan
(13) |
Feb
(74) |
Mar
(40) |
Apr
(18) |
May
(31) |
Jun
(1) |
Jul
(16) |
Aug
(1) |
Sep
(21) |
Oct
(19) |
Nov
(10) |
Dec
(16) |
| 2005 |
Jan
(4) |
Feb
(12) |
Mar
(46) |
Apr
(33) |
May
(64) |
Jun
(1) |
Jul
(60) |
Aug
(31) |
Sep
(26) |
Oct
(24) |
Nov
(37) |
Dec
(10) |
| 2006 |
Jan
(3) |
Feb
(31) |
Mar
(122) |
Apr
(22) |
May
(4) |
Jun
|
Jul
|
Aug
(2) |
Sep
(4) |
Oct
(8) |
Nov
(3) |
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(8) |
|
From: Mike W. - de B. <M.W...@tr...> - 2005-06-05 10:51:36
|
Hi Keats,
I know that you are all very busy, I have the same problem?
[But it's nice to have work nowadays ;-) ]
JUnit tests? Sorry, I haven't used it... maybe it is a good testing tool for
me also... Ill look into it when I have the time.
However, the files are tested in a live environment by me and Marcel H.
I hope that we can make WM stronger and more appreciated by a larger
community... with all kinds of improvements... even the small ones :-)
Greetings,
Mike
Ps. I have forgotten to thank you for adjusting #eval (to evaluate Strings)
it's precisely what I needed...
-----Oorspronkelijk bericht-----
Van: Keats Kirsch [mailto:ke...@xa...]
Verzonden: vrijdag 3 juni 2005 21:16
Aan: Mike Weerdenburg - de Bruin
Onderwerp: Re: FW: [WebMacro-user] WebMacro 2.0 release? / Items that are
modified or added by Mike W / Marcel H
Hey Mike,
Sorry, I don't mean to ignore you. I think your additions are cool and
I will try to incorporate them into the code base before our final 2.0
release. If you happen to have any JUnit tests that would help.
Keats
Mike Weerdenburg - de Bruin wrote:
>Hello Keats,
>
>I think it is super that there is action in the WM community at this
>moment...
>
>Maybe my question is not so interresting for you guys, but I wouldt like to
>see some updates in the following files.
>
>I have put them a while ago into the mailing list, but nothing hapend with
>it?
>
>It would be verry nice if you want to adjust/add the files into the source.
>
>---
>
>1) adjusted DefaultDirective (see attachment).
>
>Made #default pre wm2 compatible.
>#default $myVar to "value" has been deprecated, but NOW it still works!
>Verry usefull for migration to WM 2
>
>It generates a warning if LogLevel.directive: NOTICE
>This is a neat trick to log all the occurences and replace them!
>Log-example: ../my.wmt:34.2 uses #default $border to "default", please use:
>#default $border = "default"
>
>
>2) adjusted LogFile (see attachment)
>
>ChangeLog:
>
>14-01-2005 (Mike Weerdenburg)
>LogFilePerDay
>It was :
>exampl. c:/logs/wm.log -> c:/logs/wm.log_20050105
>
>Now it is (this is more logical):
>exampl. c:/logs/wm.log -> c:/logs/wm_20050105.log
>
>Write a message to the 'old' logfile when switching to a 'new' one.
>
>17-07-2002 (Marcel Huijkman)
>setting for WebMacro.properties added
>LogFilePerDay
>usage:
>LogFilePerDay=FALSE or TRUE
>
>LogFileAutoFlush
>usage:
>LogFileAutoFlush=FALSE or TRUE
>(Notice: Only handy when developing on a Operating system, that buffers
>file-writing, not recommended for production, since it obviously slows down
>the machine.)
>
>??? OPTIONAL ???
>
>3) new WhileDirective (see attachment)
>
>Just have fun with it...
>
>Syntax: #while (condition) [limit (int)] { block } WhileDirective
implements
>a WebMacro directive for an while control structure. If you use it without
>the limit option than it stops after 1000000 loops! Use a limit value < 0
to
>create a loop without a limit, this could hang your template!
>
>---
>
>Greetings
>Mike Weerdenburg
|
|
From: Keats K. <ke...@xa...> - 2005-05-31 02:18:14
|
One more bit of code ... I extended your JSPAttributes class a bit. Attached for your review. Keats Marc Palmer wrote: > Lane Sharman wrote: > >> Hi Keats, >> >> this is good news. >> >> I will take into account some of the other posts; clean up the >> contrib; and post an rc2 shortly. > > > Hold off that RC2 at the moment, I need to get the JSP + Tablig stuff > done, hopefully tomorrow. > > Cheers > |
|
From: Lane S. <la...@op...> - 2005-05-30 20:53:27
|
> > Hold off that RC2 at the moment, I need to get the JSP + Tablig stuff > done, hopefully tomorrow. ok. |
|
From: Lane S. <la...@op...> - 2005-05-30 20:50:15
|
Endre St=F8lsvik wrote: >On Fri, 27 May 2005, Marc Palmer wrote: > > >I think JSP and Spring is very useful, and people will probably use it, >given that it has some amount of documentation. But is should pretty muc= h >-never- enter core, as this isn't anything that WM needs to work. > =20 > amazing. endre and I agree. |
|
From: Lane S. <la...@op...> - 2005-05-30 20:50:08
|
Endre St=F8lsvik wrote: >On Fri, 27 May 2005, Marc Palmer wrote: > > >I think JSP and Spring is very useful, and people will probably use it, >given that it has some amount of documentation. But is should pretty muc= h >-never- enter core, as this isn't anything that WM needs to work. > =20 > amazing. endre and I agree. |
|
From: Lane S. <la...@op...> - 2005-05-30 20:49:09
|
Keats Kirsch wrote: > I think the JSP tag lib needs to have its own jar, which we can mark > as beta code. We can do the same for the Spring stuff. This way we > won't hold up the final release of 2.0 or add more dependencies to the > core. > > I agree that sticking stuff in the contrib branch is kind of like > sending them into the great bit bucket in the sky -- although Lane's > clean up plan should help a lot. I'd like to give the Taglib a > different status -- more like a subproject. I agree with Marc that > this is a way to give WM wider adoption, now that so many of us are > stuck in JSP shops. Maybe the Spring adapter could be a subproject as > well -- I haven't delved into that yet. > Maybe a general "WM Adapters" subproject could incorporate JSP, > Spring, and Struts integration along with any other framework that > folks want to support. We could kick off the subproject in > conjunction with the WM 2.0 release. > > Thoughts? Just as there is a wiki sub-project for WM, there could easily be a spring/ or jsp/ subproject that stands on its own and is dependent on WM but in no way is WM dependent on them except for modest changes. Thusly, you will have the baby and the bath water. OK? -Lane > > Keats > > Marc Palmer wrote: > >>> the jsp and spring integration projects would be desireable to >>> include in contrib/ >>> >> >> >> Well Keats said to me he thinks it should go in the main tree. I don't >> think this stuff should go in contrib because it will languish in >> obscurity there. >> >> However if we introduce new packages: >> >> org.webmacro.views.jsp >> org.webmacro.views.spring >> >> ...the core becomes dependent on some new JARs which -must- be shipped >> with the src distro of WM so that you can build it. However the binary >> distro probably shouldn't include the JSP API and Spring JARs. >> >> I am pretty convinced that the JSP and Spring views will widen usage >> of WM >> significantly provided that they (a) are promoted as a new feature >> and (b) >> work well ;-) >> >> It may be that we want to hold off on these new components until 2.1 as >> nobody else has (apart from Keats with JSP taglib) used them. >> >> However maybe we could include them as experimental in 2.0? The great >> thing about Spring is that I can write some unit tests for the Spring >> view >> as part of the WM src tests :) >> >> I've also got ServletXXBroker patches to submit which add support for >> ServletContext + ClassLoder init, required for the JSP and Spring impls. >> >> Keats volunteered to do the final JavaCC tweaks so that we can boast 2.0 >> also has: >> >> * JSP Taglib support >> * Spring View support * JDK 1.5 compatibility >> >> ...all I've got left to do is commit this stuff once there is a decision >> on branch 2.1 or fold into 2.0, and some minor changes to JSP taglib to >> incorporate some suggestions from Keats. >> >> And I just have to say, you guys -have- to get into Spring, it really >> rocks in some areas. ESPECIALLY unit testing of your "servlet" >> controllers >> and testing that the WM context has the vars in it that your webapp >> should >> be supplying etc. >> >> > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Webmacro-user mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-user > -- Lane Sharman Providing Private and SPAM-Free Email http://www.opendoors.com 858-755-2868 |
|
From: Lane S. <la...@op...> - 2005-05-30 20:43:48
|
Thanks, Marc. My view is to energize contrib/ and not impose a lot of dependencies on webmacro the basic package. In fact, contrib/ could and should become a point of leverage against WM, showing all that is possible with WM and it should become the driver for WM. WM is a power tool that is proven. I have some long term goals for WM, services, and talent. I would rather see WM remain a solid anchor and not some moving target. Of course, if there is a clear improvement to WM to support for example Spring or JSP cooperation, let's make it happen. Right now, WM stands on its own. It is loosely coupled and cohesive. Let's keep it that way. Lane Marc Palmer wrote: >>Greetings, >> >>For the 2.0 release, I am planning the following with respect to >>webmacro/contrib: >> >> > >Great work Lane. > > > >>the jsp and spring integration projects would be desireable to include >>in contrib/ >> >> > >Well Keats said to me he thinks it should go in the main tree. I don't >think this stuff should go in contrib because it will languish in >obscurity there. > >However if we introduce new packages: > >org.webmacro.views.jsp >org.webmacro.views.spring > >...the core becomes dependent on some new JARs which -must- be shipped >with the src distro of WM so that you can build it. However the binary >distro probably shouldn't include the JSP API and Spring JARs. > >I am pretty convinced that the JSP and Spring views will widen usage of WM >significantly provided that they (a) are promoted as a new feature and (b) >work well ;-) > >It may be that we want to hold off on these new components until 2.1 as >nobody else has (apart from Keats with JSP taglib) used them. > >However maybe we could include them as experimental in 2.0? The great >thing about Spring is that I can write some unit tests for the Spring view >as part of the WM src tests :) > >I've also got ServletXXBroker patches to submit which add support for >ServletContext + ClassLoder init, required for the JSP and Spring impls. > >Keats volunteered to do the final JavaCC tweaks so that we can boast 2.0 >also has: > >* JSP Taglib support >* Spring View support >* JDK 1.5 compatibility > >...all I've got left to do is commit this stuff once there is a decision >on branch 2.1 or fold into 2.0, and some minor changes to JSP taglib to >incorporate some suggestions from Keats. > >And I just have to say, you guys -have- to get into Spring, it really >rocks in some areas. ESPECIALLY unit testing of your "servlet" controllers >and testing that the WM context has the vars in it that your webapp should >be supplying etc. > > > > -- Lane Sharman Providing Private and SPAM-Free Email http://www.opendoors.com 858-755-2868 |
|
From: Marc P. <ma...@an...> - 2005-05-30 16:55:14
|
Lane Sharman wrote: > Hi Keats, > > this is good news. > > I will take into account some of the other posts; clean up the contrib; > and post an rc2 shortly. Hold off that RC2 at the moment, I need to get the JSP + Tablig stuff done, hopefully tomorrow. Cheers -- Marc Palmer wj...@wa... Wangjammers - Java, J2ME and Web Consultants ~ http://www.wangjammers.org/ |
|
From: Lane S. <la...@op...> - 2005-05-30 15:12:02
|
Hi Keats, this is good news. I will take into account some of the other posts; clean up the contrib; and post an rc2 shortly. Lane Keats Kirsch wrote: > I have updated the sources to compile cleanly with JDK1.5 (with the > exception of one warning which is not significant). > > I regenerated the parser using the latest stable version of JavaCC. > > I have compiled it on Windows using the following standard Sun JDKs: > 1.3.1, 1.4.2, and 1.5.0. > > Please test and let me know if you find any problems. > > Keats > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Webmacro-user mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-user > -- Lane Sharman Providing Private and SPAM-Free Email http://www.opendoors.com 858-755-2868 |
|
From: <Web...@St...> - 2005-05-29 14:24:53
|
| | That way we can (a) pump it out now, (b) shout about new support for JS= P | and Spring in 2.0 release, even if it is experimental, and (c) not | bother anybody who just wants raw WM. Eeeexcellent! | | I think it should be sort of the other way around for wm - webmacro.jar | =3D webmacro, nothing else. webmacro-views.jar =3D the new view code. | webmacro-tools.jar =3D some top-grade documented context tools. So you even suggest removing the default tools from the webmacro.jar? Radical, but I wholeheartedly agree. That way one could also move them tools to the correct location (at least last time I looked, lots of "generic" tools (Text etc?) was up in some servlet dir?), and simply clea= n up the thing quite a bit. | | When the Spring view becomes mature we might be able to get it put out | in the core Spring distro - they already do this for JSP, Velocity and | FreeMarker. Just great. Really! --=20 Endre St=F8lsvik - Endre@CoreTrek.[no|com] Work[+47 23100271] Mobile[+47 93054050] Fax[+47 23100299] |
|
From: Marc P. <ma...@an...> - 2005-05-27 21:48:50
|
Keats Kirsch wrote: > I have updated the sources to compile cleanly with JDK1.5 (with the > exception of one warning which is not significant). > > I regenerated the parser using the latest stable version of JavaCC. > > I have compiled it on Windows using the following standard Sun JDKs: > 1.3.1, 1.4.2, and 1.5.0. > > Please test and let me know if you find any problems. Great work Keats - I will try to look at it this weekend, and will commit my ServletXXBroker improvements too. Cheers |
|
From: Keats K. <ke...@xa...> - 2005-05-27 20:09:21
|
I have updated the sources to compile cleanly with JDK1.5 (with the exception of one warning which is not significant). I regenerated the parser using the latest stable version of JavaCC. I have compiled it on Windows using the following standard Sun JDKs: 1.3.1, 1.4.2, and 1.5.0. Please test and let me know if you find any problems. Keats |
|
From: Marc P. <ma...@an...> - 2005-05-27 18:39:16
|
> I feel it has nothing to do in the main tree. At all. I am inclined to agree with you, but I think it is important enough to WM's adoption that it must be a major part of the WM availability. Most people these days take templating as just a small part of a bigger whole, and use templating technologies that already work with their application framework. I really think that very few new people are going to use WM on its own, because you have to learn how to setup a WM instance etc, write templates out etc. > | Maybe a general "WM Adapters" subproject could incorporate JSP, Spring, > | and Struts integration along with any other framework that folks want to > | support. We could kick off the subproject in conjunction with the WM > | 2.0 release. > > This I find interesting, but what about just sticking it into a jar inside > the WM distro? Like a contrib, but with a purpose? > > Note that you anywhichway can't change package names and such, if > compatiblity is an issue at all. > > Remeber that WM is pretty much dying, and that someone mentioned that the > 2.0 probably will be one of the final releases ever. DOn't have too many > grand plans going along with it. The 2.0 -might- kick off new revived > interest in the project, but please don't get your hopes and visions up > too much before this actually happens. It is exactly the taglib plus Spring view etc that have a chance of reviving the project. WM is stable, and doesn't need much added. Velocity is a successful project only because it has all these extra things that WM does not. (because it was fast-tracked by having lots more active developers because of the Apache background). I think that a single org.webmacro source tree with a build.xml that builds core WM without any "views" in it (i.e. what we have now) plus a separate ANT target which builds a "webmacro-views" JAR with just the views code in it is a good solution. That way we can (a) pump it out now, (b) shout about new support for JSP and Spring in 2.0 release, even if it is experimental, and (c) not bother anybody who just wants raw WM. Take a look at Spring, MX4J et al to see how projects with these external dependencies are put out now. Typically they have one main jar with everything in, and then a bunch of smaller jars with subsets. I think it should be sort of the other way around for wm - webmacro.jar = webmacro, nothing else. webmacro-views.jar = the new view code. webmacro-tools.jar = some top-grade documented context tools. When the Spring view becomes mature we might be able to get it put out in the core Spring distro - they already do this for JSP, Velocity and FreeMarker. Cheers -- Marc Palmer wj...@wa... Wangjammers - Java, J2ME and Web Consultants ~ http://www.wangjammers.org/ |
|
From: <Web...@St...> - 2005-05-27 17:21:41
|
On Fri, 27 May 2005, Marc Palmer wrote: | > Greetings, | > | > For the 2.0 release, I am planning the following with respect to | > webmacro/contrib: | | Great work Lane. | | > the jsp and spring integration projects would be desireable to include | > in contrib/ | | Well Keats said to me he thinks it should go in the main tree. I don't | think this stuff should go in contrib because it will languish in | obscurity there. I feel it has nothing to do in the main tree. At all. If it languishes into obscurity in the contrib section, then so be it. WM "proper"/"core" should be a thight templating language, not a bunch of nice-to-haves. I think JSP and Spring is very useful, and people will probably use it, given that it has some amount of documentation. But is should pretty much -never- enter core, as this isn't anything that WM needs to work. Keats said: | Maybe a general "WM Adapters" subproject could incorporate JSP, Spring, | and Struts integration along with any other framework that folks want to | support. We could kick off the subproject in conjunction with the WM | 2.0 release. This I find interesting, but what about just sticking it into a jar inside the WM distro? Like a contrib, but with a purpose? Note that you anywhichway can't change package names and such, if compatiblity is an issue at all. Remeber that WM is pretty much dying, and that someone mentioned that the 2.0 probably will be one of the final releases ever. DOn't have too many grand plans going along with it. The 2.0 -might- kick off new revived interest in the project, but please don't get your hopes and visions up too much before this actually happens. E |
|
From: Keats K. <ke...@xa...> - 2005-05-27 14:04:56
|
I think the JSP tag lib needs to have its own jar, which we can mark as beta code. We can do the same for the Spring stuff. This way we won't hold up the final release of 2.0 or add more dependencies to the core. I agree that sticking stuff in the contrib branch is kind of like sending them into the great bit bucket in the sky -- although Lane's clean up plan should help a lot. I'd like to give the Taglib a different status -- more like a subproject. I agree with Marc that this is a way to give WM wider adoption, now that so many of us are stuck in JSP shops. Maybe the Spring adapter could be a subproject as well -- I haven't delved into that yet. Maybe a general "WM Adapters" subproject could incorporate JSP, Spring, and Struts integration along with any other framework that folks want to support. We could kick off the subproject in conjunction with the WM 2.0 release. Thoughts? Keats Marc Palmer wrote: >>the jsp and spring integration projects would be desireable to include >>in contrib/ >> >> > >Well Keats said to me he thinks it should go in the main tree. I don't >think this stuff should go in contrib because it will languish in >obscurity there. > >However if we introduce new packages: > >org.webmacro.views.jsp >org.webmacro.views.spring > >...the core becomes dependent on some new JARs which -must- be shipped >with the src distro of WM so that you can build it. However the binary >distro probably shouldn't include the JSP API and Spring JARs. > >I am pretty convinced that the JSP and Spring views will widen usage of WM >significantly provided that they (a) are promoted as a new feature and (b) >work well ;-) > >It may be that we want to hold off on these new components until 2.1 as >nobody else has (apart from Keats with JSP taglib) used them. > >However maybe we could include them as experimental in 2.0? The great >thing about Spring is that I can write some unit tests for the Spring view >as part of the WM src tests :) > >I've also got ServletXXBroker patches to submit which add support for >ServletContext + ClassLoder init, required for the JSP and Spring impls. > >Keats volunteered to do the final JavaCC tweaks so that we can boast 2.0 >also has: > >* JSP Taglib support >* Spring View support >* JDK 1.5 compatibility > >...all I've got left to do is commit this stuff once there is a decision >on branch 2.1 or fold into 2.0, and some minor changes to JSP taglib to >incorporate some suggestions from Keats. > >And I just have to say, you guys -have- to get into Spring, it really >rocks in some areas. ESPECIALLY unit testing of your "servlet" controllers >and testing that the WM context has the vars in it that your webapp should >be supplying etc. > > |
|
From: Marc P. <ma...@an...> - 2005-05-27 08:59:47
|
> Greetings, > > For the 2.0 release, I am planning the following with respect to > webmacro/contrib: Great work Lane. > the jsp and spring integration projects would be desireable to include > in contrib/ Well Keats said to me he thinks it should go in the main tree. I don't think this stuff should go in contrib because it will languish in obscurity there. However if we introduce new packages: org.webmacro.views.jsp org.webmacro.views.spring ...the core becomes dependent on some new JARs which -must- be shipped with the src distro of WM so that you can build it. However the binary distro probably shouldn't include the JSP API and Spring JARs. I am pretty convinced that the JSP and Spring views will widen usage of WM significantly provided that they (a) are promoted as a new feature and (b) work well ;-) It may be that we want to hold off on these new components until 2.1 as nobody else has (apart from Keats with JSP taglib) used them. However maybe we could include them as experimental in 2.0? The great thing about Spring is that I can write some unit tests for the Spring view as part of the WM src tests :) I've also got ServletXXBroker patches to submit which add support for ServletContext + ClassLoder init, required for the JSP and Spring impls. Keats volunteered to do the final JavaCC tweaks so that we can boast 2.0 also has: * JSP Taglib support * Spring View support * JDK 1.5 compatibility ...all I've got left to do is commit this stuff once there is a decision on branch 2.1 or fold into 2.0, and some minor changes to JSP taglib to incorporate some suggestions from Keats. And I just have to say, you guys -have- to get into Spring, it really rocks in some areas. ESPECIALLY unit testing of your "servlet" controllers and testing that the WM context has the vars in it that your webapp should be supplying etc. |
|
From: Lane S. <la...@sa...> - 2005-05-27 04:55:11
|
Greetings,
For the 2.0 release, I am planning the following with respect to
webmacro/contrib:
1) a contrib section will be released iff
it compiles; has a readme.html; has some useful test cases; the
author supports it.
2) if not (1), it will be removed or moved out of contrib to unsupported/
This action will be taken by me and will be completed by June 10.
New contrib packages can only be submitted conforming to (1) above.
the jsp and spring integration projects would be desireable to include
in contrib/
thanks,
Lane
|
|
From: Keats K. <ke...@xa...> - 2005-05-25 04:55:01
|
Rab Wallace wrote: >Keats >I tried your example and it works ok! But, my simple >test bean still refused to cooperate when >scope=session. I've got logging in the constructor and >the test bean is getting instantiated *every* time the >page loads (I don't think this is correct behaviour >for session scope). How can it be instantiated, but my >template not 'see' any methods on the bean? > > This is curious. For session scope, the BeanDirective tests if an attribute exists in the session, and if not it instantiates the object and sets the attribute. If your class is getting instantiated on each request then it is either not getting into the session, or it is getting removed, or the session is getting recreated. Here are some suggestions: - Make sure you have your logging level set to Debug. The #bean directive should log each time it runs. - You could make your class implement HttpSessionBindingListener and then log each time it is bound or unbound to the session (in the valueBound/valueUnbound methods). - You might also try referencing the attribute directly through the $Session tool before and after the #bean statement. E.g., Session $Session.Id, created $Session.CreationTime<br> Before bean directive: [test=$Session.test]<br> #bean $test="com.myteststuff.Test" scope=session After bean directive: [test=$Session.test]<br> If you can send me a small example that exhibits the problem, I'll be glad to try and debug it. There can be some confusion here due the fact that the session-scoped #bean objects share the same namespace as any other session object. So if an attribute with the same name is placed in the session before the #bean is evaluated, the statement will have no effect. I've considered using a separate namespace for #bean session objects, but I'm not convinced this is the right way to go. (I hope to address this in the future along with the concept of scoped variables in the context.) >I'm curious about your comment about my BeanDirective >security, are you referring to something in >webmacro.properties? > > Yes. You can restrict what packages classes can be instantiated from by the #bean directive, e.g., BeanDirective.AllowedPackages: com.mystuff, com.mystuff.extra This helps alleviate some of the dangerous things that people might try to do with the #bean directive. Good luck. Keats >Many thanks. > >Rab Wallace > >--- Keats Kirsch <ke...@xa...> wrote: > > > >>I spent a couple of hours setting up Tomcat 5.5.9 >>and cooking up some >>test cases and I can't reproduce your problem. >> >>I put the following into a sandbox template, with no >>problem. I'm using >>Win2K with Sun JRE 1.5.0_02. I also tested with >>Tomcat 4.1 and 5.0 with >>JDK 1.4.2. >> >>Your error indicates that your class wasn't >>instantiated. You might try >>putting some logging into the constructor to see >>what's going on. Also >>check your BeanDirective security settings. Good >>luck. >> >>Keats >> >>Sample WMScript: >> >>#bean $testbean = "com.xaltus.wm.Test" scope=session >>onNew >> #set $testbean.Num = 2 >>#end >>#set $testbean.Num = $testbean.Num * 2 >>testbean.Num = $testbean.Num<br><br> >> >>#bean $counts = "java.util.HashMap" scope=session >>onNew >> #set $counts.Hits = 0 >>#end >>#set $counts.Hits = $counts.Hits + 1 >>Number of visits to this page in this session: >>$counts.Hits<br><br> >> >> >> >>Rab Wallace wrote: >> >> >> >>>I recently upgraded to Tomcat 5.5.9 and noticed all my >>> >>> >>>pages with a #bean...scope=session no longer works >>>(scope=page works fine), anyone else seen this? >>> >>>I tried a simple example: >>>A simple bean 'com.myteststuff.Test' has a single long >>> >>> >>>attribute 'value' and a getter & setter. In my >>>template, I've got: >>> >>>#bean $test="com.myteststuff.Test" scope=session >>>$test.setValue(123) >>> >>>results in the exception below. If I switch to >>>scope=page, everything works fine. Earlier version >>> >>> >>of >> >> >>>Tomcat also ok. Thanks for any advice. >>> >>>Rab Wallace >>> >>>ps. this problem exists on both the latest Webmacro >>>(2.0rc1) and at least the previous version (2.0b1). >>> >>> >>> >>> >>org.webmacro.PropertyException$NoSuchMethodException: >> >> >>>No public method setValue(123) on variable $test of >>>class org.webmacro.engine.UndefinedMacro at >>> >>> >>jndi:/localhost/metridium_jboss/skins/kelpforest/kelpforest_DefaultMainPage.wm:229.1 >> >> >>> at >>> >>> >>org.webmacro.engine.PropertyOperator.getProperty(PropertyOperatorCache.java:716) >> >> >>> at >>> >>> >>org.webmacro.engine.PropertyOperatorCache.getProperty(PropertyOperatorCache.java:163) >> >> >>> at >>> >>> >>org.webmacro.Context.internalGet(Context.java:383) >> >> >>> at >>> >>> >>org.webmacro.Context.getProperty(Context.java:443) >> >> >>> at >>> >>> >>org.webmacro.engine.PropertyVariable.getValue(PropertyVariable.java:52) >> >> >>> at >>> >>> >>org.webmacro.engine.Variable.write(Variable.java:211) >> >> >>> at org.webmacro.engine.Block.write(Block.java:133) >>> at >>> >>> >>org.webmacro.directive.IfDirective.write(IfDirective.java:210) >> >> >>> at org.webmacro.engine.Block.write(Block.java:184) >>> at >>> >>> >>org.webmacro.directive.ForeachDirective.write(ForeachDirective.java:177) >> >> >>> at org.webmacro.engine.Block.write(Block.java:145) >>> at >>> >>> >>org.webmacro.directive.IfDirective.write(IfDirective.java:210) >> >> >>> at org.webmacro.engine.Block.write(Block.java:199) >>> at >>> >>> >>org.webmacro.engine.WMTemplate.write(WMTemplate.java:324) >> >> >>> at >>> >>> >>org.webmacro.engine.WMTemplate.evaluateAsString(WMTemplate.java:253) >> >> >>> at >>> >>> >>com.metridia.metridium.servlets.MetridiumServlet.renderPageAlias(MetridiumServlet.java:743) >> >> >>> at >>> >>> >>com.metridia.metridium.servlets.MetridiumServlet.doGet(MetridiumServlet.java:598) >> >> >>> at >>> >>> >>javax.servlet.http.HttpServlet.service(HttpServlet.java:689) >> >> >>> at >>> >>> >>javax.servlet.http.HttpServlet.service(HttpServlet.java:802) >> >> >>> at >>> >>> >>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) >> >> >>> at >>> >>> >>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) >> >> >>> at >>> >>> >>org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) >> >> >>> at >>> >>> >>org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) >> >> >>> at >>> >>> >>org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:407) >> >> >>> at >>> >>> >>org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) >> >> >>> at >>> >>> >>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) >> >> >>> at >>> >>> >>org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) >> >> >>> at >>> >>> >>org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) >> >> >>> at >>> >>> >>org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307) >> >> >>> at >>> >>> >>org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385) >> >> >>> at >>> >>> >>org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) >> >> >>> at >>> >>> >>org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) >> >> >>> at >>> >>> >>org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) >> >> >>> at >>> >>> >>org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) >> >> >>> at java.lang.Thread.run(Unknown Source) >>> >>> >>> >>> |
|
From: Rab W. <ja...@ya...> - 2005-05-24 17:56:04
|
Keats I tried your example and it works ok! But, my simple test bean still refused to cooperate when scope=session. I've got logging in the constructor and the test bean is getting instantiated *every* time the page loads (I don't think this is correct behaviour for session scope). How can it be instantiated, but my template not 'see' any methods on the bean? I'm curious about your comment about my BeanDirective security, are you referring to something in webmacro.properties? Many thanks. Rab Wallace --- Keats Kirsch <ke...@xa...> wrote: > I spent a couple of hours setting up Tomcat 5.5.9 > and cooking up some > test cases and I can't reproduce your problem. > > I put the following into a sandbox template, with no > problem. I'm using > Win2K with Sun JRE 1.5.0_02. I also tested with > Tomcat 4.1 and 5.0 with > JDK 1.4.2. > > Your error indicates that your class wasn't > instantiated. You might try > putting some logging into the constructor to see > what's going on. Also > check your BeanDirective security settings. Good > luck. > > Keats > > Sample WMScript: > > #bean $testbean = "com.xaltus.wm.Test" scope=session > onNew > #set $testbean.Num = 2 > #end > #set $testbean.Num = $testbean.Num * 2 > testbean.Num = $testbean.Num<br><br> > > #bean $counts = "java.util.HashMap" scope=session > onNew > #set $counts.Hits = 0 > #end > #set $counts.Hits = $counts.Hits + 1 > Number of visits to this page in this session: > $counts.Hits<br><br> > > > > Rab Wallace wrote: > > >I recently upgraded to Tomcat 5.5.9 and noticed all > my > >pages with a #bean...scope=session no longer works > >(scope=page works fine), anyone else seen this? > > > >I tried a simple example: > >A simple bean 'com.myteststuff.Test' has a single > long > >attribute 'value' and a getter & setter. In my > >template, I've got: > > > >#bean $test="com.myteststuff.Test" scope=session > >$test.setValue(123) > > > >results in the exception below. If I switch to > >scope=page, everything works fine. Earlier version > of > >Tomcat also ok. Thanks for any advice. > > > >Rab Wallace > > > >ps. this problem exists on both the latest Webmacro > >(2.0rc1) and at least the previous version (2.0b1). > > > > > >org.webmacro.PropertyException$NoSuchMethodException: > >No public method setValue(123) on variable $test of > >class org.webmacro.engine.UndefinedMacro at > >jndi:/localhost/metridium_jboss/skins/kelpforest/kelpforest_DefaultMainPage.wm:229.1 > > at > >org.webmacro.engine.PropertyOperator.getProperty(PropertyOperatorCache.java:716) > > at > >org.webmacro.engine.PropertyOperatorCache.getProperty(PropertyOperatorCache.java:163) > > at > org.webmacro.Context.internalGet(Context.java:383) > > at > org.webmacro.Context.getProperty(Context.java:443) > > at > >org.webmacro.engine.PropertyVariable.getValue(PropertyVariable.java:52) > > at > >org.webmacro.engine.Variable.write(Variable.java:211) > > at org.webmacro.engine.Block.write(Block.java:133) > > at > >org.webmacro.directive.IfDirective.write(IfDirective.java:210) > > at org.webmacro.engine.Block.write(Block.java:184) > > at > >org.webmacro.directive.ForeachDirective.write(ForeachDirective.java:177) > > at org.webmacro.engine.Block.write(Block.java:145) > > at > >org.webmacro.directive.IfDirective.write(IfDirective.java:210) > > at org.webmacro.engine.Block.write(Block.java:199) > > at > >org.webmacro.engine.WMTemplate.write(WMTemplate.java:324) > > at > >org.webmacro.engine.WMTemplate.evaluateAsString(WMTemplate.java:253) > > at > >com.metridia.metridium.servlets.MetridiumServlet.renderPageAlias(MetridiumServlet.java:743) > > at > >com.metridia.metridium.servlets.MetridiumServlet.doGet(MetridiumServlet.java:598) > > at > >javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > > at > >javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > > at > >org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > > at > >org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > > at > >org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > > at > >org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > > at > >org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:407) > > at > >org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > > at > >org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > > at > >org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > > at > >org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > > at > >org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307) > > at > >org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385) > > at > >org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) > > at > >org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) > > at > >org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) > > at > >org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) > > at java.lang.Thread.run(Unknown Source) > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space > Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Webmacro-user mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-user > ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com |
|
From: <Web...@St...> - 2005-05-24 09:17:40
|
subject. Endre |
|
From: Tim P. <ti...@pa...> - 2005-05-22 13:09:11
|
Hi all, On Monday 16 May 2005 16:14, Lane Sharman wrote: > Greetings, > > Keats and I posted RC1 of Release 2.0 on SF. Here is the plan: > > Community to start using this release immediately and if no major > > bugs, it becomes 2.0. > > > I will prepare a press release and when 2.0 is posted, I will send > > this out. > > > Any special uses/examples/plans/projects for WebMacro should be > > posted on the web site and i will cite these in the Press Release. > > Kindest, Cool, good work. I have tested 2.0.RC1 with Melati and all seems to work with no problems. I have been using 2.0b1 since early in 2004 Has much changed since then? Shouldn't this be 2.1RC1 ? http://www.webmacro.org/DownloadWebMacro needs updating, I would do it myself but can't see a 'mail me my password' link on login page. What do you guys think of Maven? cheers Tim |
|
From: <Web...@St...> - 2005-05-22 12:08:47
|
On Sat, 21 May 2005, Marc Palmer wrote: | Keats Kirsch wrote: | > It needs the servletContext *and* the classloader for the | > servletContext. WM can get both from the Servlet, which is why it wa= s | > done that way. I don't think there is a guaranteed way to get the | > servlet classloader from the servletContext. | > | > Let's not break all the old WM servlet code. However if you want to = be | > explicitly pass in both arguments, I don't see any problem with that. | | Precisely what I was talking of doing. Breaking stuff is not going to | happen :) Good. | | However I am interested in any ideas for getting a reference to the web | application's own ClassLoader from within a class that has no reference | to the Serlvet, only the ServletContext. Let at least, in any case, the Broker be highly extendable. I am not completely happy with the "magic-ness" of template loading right now at any rate, and would like this to be very pluggable. Also, the logging wil= l need to be changed at my code, because I want it to go to log4j. Last tim= e I was over this, I realized that I'd have to extend / replace Broker, and a whole bunch of classes, to get this done. That was when I postponed thi= s to the 2.0 - and everybody knows where that have left me! ;) Drop -every- final-modifyers. Let the javadoc tell any system developer what is meant to be extended, and what is not - let it be a "contract" which isn't enforced by final-nessing. The point is that no-one may foresee which needs will arise in such frameworks. I've -always- regretted at some point making a method final. Suddenly you'd love to "hack just a little" at some method, and then call super.method, or something similar. If it is final, the ONLY way you may get around the problem, is to copy LARGE swathes of code, just becase someone tried to outguess you on what you probably will and won't ever do= . (This might already be the case, though - I just remember that at some point things were way to final around WM) Note that I don't mean that this goes for everything: APIs should be thight to force users to use it in a proper way. However, the framework itself shouldn't have much limits in what a systems developer are allowed to do / extend. | | I suppose in theory you could use the (most/all deprecated) methods on | ServletContext to iterate over the servlets and just grab any one and | call getClass().getClassLoader() on it. | | Doesn't feel good though... Drop the thought right away! They're -so- deprecated! I even believe they return null now, and have done quite a while. Don't deprecate the good-ol servlet-constructor either - I guess they have their place (although they're unusable in Sun ONE thingy by default, due to the default SecMgr settings in that thing). But, at ANY RATE: DO GET THE 2.0 OUT, now!! I'd rather have it out -now- than having any ServletContextBroker OR WHATEVER extra fixups. Pliz pliz pliz, don't let it boil away (again) this time!! See, I even believe that this might be beneficial to WM: one may releas= e 2.0.z's or 2.y's or whatnot - as long as there -is- a base that is out an= d readily available. --=20 Endre St=F8lsvik - Endre@CoreTrek.[no|com] Work[+47 23100271] Mobile[+47 93054050] Fax[+47 23100299] |
|
From: Keats K. <ke...@xa...> - 2005-05-21 19:55:45
|
Marc Palmer wrote: > Keats Kirsch wrote: > >> I don't have a problem with adding this constructor to WM and adding >> a corresponding getBroker method to the ServletBroker. In fact the >> other constructors could delegate to this one so we don't have >> duplicate code paths. >> >> However, I don't see any need to make the Broker constructor >> non-private. Maybe you can explain. Also I don't understand why you >> think the classloader will not work if WM is in a shared path. A >> webapp classloader should delegate to it's parent if it can't find a >> resource. > > > 1. Making Broker constructor protected: Rationale is that I needed to > create a new broker to workaround WM's lack of > getBroker(ServletContext, ClassLoader, ...) method and this was not > possible without a major copy and paste from existing Broker > implementations. I should have been able to just extend > ServletXXBroker but I couldn't call the inherited constructor because > it is private. It's pointless. ;I see your point. I was thinking about just modifying the existing class. The class hierarchy was designed to allow new broker implementations, so I suppose it ought to allow for extending the ServletBroker implementations as well. > 2. Classloader stuff. As I understand it there is the following issue: > > If webmacro.jar is in a shared lib directory of the application > server, and not in WEB-INF/lib isn't it the case that some application > servers will load that lib on a different classloader to the webapp? > My memory and gut tells me this is why the ServletXXBroker > implementations jump through hoops to get the Servlet instance so they > can get the ClassLoader for the servlet (== the WEBAPP classloader) as > doing somehing like WebMacro.getClass() is typically != > MyServlet.getClass() in this situaiton. > > If webmacro.jar is in WEB-INF/lib there is no such problem. > > What this then means is that if we want to be able to load webapp > specific templates from WEB-INF/xxx etc we -must- have a reference to > the Servlet (== webapp) ClassLoader instance if webmacro.jar is in a > shared location... otherwise it just will not work. > > The ServletContext is no good to us here because it is loaded on one > of the main application server classloaders as part of the API, and as > such will not find resources in the webapp's tree. > > See what I mean? This is why ServletXXBroker take a reference to > Servlet and note ServletContext. I see what you mean. It sounds like a new Broker implementation that relies on ServletContext's resource loading capabilities would be useful. I think that's what Endre is getting at. We might even eventually deprecate the Servlet22Broker in favor of the this ServletContextBroker. Keats > It's problematic. > > Cheers > > |
|
From: Marc P. <ma...@an...> - 2005-05-21 18:49:35
|
Keats Kirsch wrote: > It needs the servletContext *and* the classloader for the > servletContext. WM can get both from the Servlet, which is why it was > done that way. I don't think there is a guaranteed way to get the > servlet classloader from the servletContext. > > Let's not break all the old WM servlet code. However if you want to be > explicitly pass in both arguments, I don't see any problem with that. Precisely what I was talking of doing. Breaking stuff is not going to happen :) However I am interested in any ideas for getting a reference to the web application's own ClassLoader from within a class that has no reference to the Serlvet, only the ServletContext. I suppose in theory you could use the (most/all deprecated) methods on ServletContext to iterate over the servlets and just grab any one and call getClass().getClassLoader() on it. Doesn't feel good though... -- Marc Palmer wj...@wa... Wangjammers - Java, J2ME and Web Consultants ~ http://www.wangjammers.org/ |
|
From: Marc P. <ma...@an...> - 2005-05-21 18:47:04
|
Keats Kirsch wrote: > I don't have a problem with adding this constructor to WM and adding a > corresponding getBroker method to the ServletBroker. In fact the other > constructors could delegate to this one so we don't have duplicate code > paths. > > However, I don't see any need to make the Broker constructor > non-private. Maybe you can explain. Also I don't understand why you > think the classloader will not work if WM is in a shared path. A webapp > classloader should delegate to it's parent if it can't find a resource. 1. Making Broker constructor protected: Rationale is that I needed to create a new broker to workaround WM's lack of getBroker(ServletContext, ClassLoader, ...) method and this was not possible without a major copy and paste from existing Broker implementations. I should have been able to just extend ServletXXBroker but I couldn't call the inherited constructor because it is private. It's pointless. 2. Classloader stuff. As I understand it there is the following issue: If webmacro.jar is in a shared lib directory of the application server, and not in WEB-INF/lib isn't it the case that some application servers will load that lib on a different classloader to the webapp? My memory and gut tells me this is why the ServletXXBroker implementations jump through hoops to get the Servlet instance so they can get the ClassLoader for the servlet (== the WEBAPP classloader) as doing somehing like WebMacro.getClass() is typically != MyServlet.getClass() in this situaiton. If webmacro.jar is in WEB-INF/lib there is no such problem. What this then means is that if we want to be able to load webapp specific templates from WEB-INF/xxx etc we -must- have a reference to the Servlet (== webapp) ClassLoader instance if webmacro.jar is in a shared location... otherwise it just will not work. The ServletContext is no good to us here because it is loaded on one of the main application server classloaders as part of the API, and as such will not find resources in the webapp's tree. See what I mean? This is why ServletXXBroker take a reference to Servlet and note ServletContext. It's problematic. Cheers |
24 messages has been excluded from this view by a project administrator.
