Menu
▾
▴
webmacro-devel — Discuss development issues related to the core of WebMacro
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(28) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(103) |
Feb
(44) |
Mar
(65) |
Apr
(140) |
May
(72) |
Jun
(233) |
Jul
(466) |
Aug
(51) |
Sep
(2) |
Oct
(17) |
Nov
(1) |
Dec
(7) |
| 2004 |
Jan
(8) |
Feb
(5) |
Mar
(28) |
Apr
(9) |
May
(7) |
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
(3) |
May
(24) |
Jun
(7) |
Jul
(2) |
Aug
|
Sep
|
Oct
(4) |
Nov
(3) |
Dec
(12) |
| 2006 |
Jan
|
Feb
(3) |
Mar
(8) |
Apr
(59) |
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(3) |
| 2008 |
Jan
|
Feb
(1) |
Mar
(16) |
Apr
(2) |
May
(2) |
Jun
|
Jul
(11) |
Aug
(3) |
Sep
(9) |
Oct
(9) |
Nov
(44) |
Dec
(34) |
| 2009 |
Jan
(12) |
Feb
(14) |
Mar
(11) |
Apr
(16) |
May
(41) |
Jun
(19) |
Jul
(33) |
Aug
(8) |
Sep
(3) |
Oct
|
Nov
|
Dec
(7) |
| 2010 |
Jan
(8) |
Feb
(50) |
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Marc P. <ma...@an...> - 2003-06-19 15:58:49
|
Do we call the SF tracker vote "closed" now we have had 5 "in favours"? Also, I've added another vote in a (vain?) attempt to get you guys to download Ignition and try it out. Remember it's a binary, it works, there are lots of docs. This isn't thrown together rubbish :) "Shall Marc's "Ignition" Web App be Part of the WebMacro Project from 2.0" http://www.webmacro.org/DeveloperVotes -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Lane S. <la...@op...> - 2003-06-19 15:11:54
|
My rebellion like so many of the sixties has been crushed by the arms of conventionalism. Bah! Brian Goetz wrote: >>>Also, unless there is a huge cry, I would drop the org in front of >>>webmacro as a convention. Without it our packages and docs will be a lot >>>easier to document. >>> >>> > >Nope, nope, nope. > >This will brand us as "not playing by the rules." Sure, its annoying, >but that's Java Life. > > > >------------------------------------------------------- >This SF.Net email is sponsored by: INetU >Attention Web Developers & Consultants: Become An INetU Hosting Partner. >Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! >INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >_______________________________________________ >Webmacro-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webmacro-devel > > > |
|
From: <web...@st...> - 2003-06-19 08:42:52
|
On Wed, 18 Jun 2003, Eric B.Ridge wrote: | On Wednesday, June 18, 2003, at 01:38 AM, Lane Sharman wrote: | | > ebr, | > | > i read your reorg work. looks good. | > | > I can go anyway the group wants to go on the following: | > | > org.opendoors.cache shows that you can plug an optional cache manager. | > But, if you want to do cosmetic work on this and change the name to | > org.webmacro.cache.generational.* as a specific impl, that is ok with | > me. | | I'm not convinced we really need an "org.webmacro.cache" package | anyways. Couldn't this stuff go in "org.webmacro.resource" or | "org.webmacro.provider" | | The caching stuff, although central to WM, doesn't seem like something | we should expose as a top-level package. It is a separate "thing", ergo a separate package. org.webmacro.provider.cache MAY be a solution. But do not bundle it along with other stuff.. -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ |
|
From: Brian G. <br...@qu...> - 2003-06-19 07:46:40
|
> > Also, unless there is a huge cry, I would drop the org in front of > > webmacro as a convention. Without it our packages and docs will be a lot > > easier to document. Nope, nope, nope. This will brand us as "not playing by the rules." Sure, its annoying, but that's Java Life. |
|
From: Marc P. <ma...@an...> - 2003-06-19 07:42:01
|
On Wed, 18 Jun 2003 22:22:52 -0700, Lane Sharman <la...@op...> wrote: > there would be nothing wrong with starting out a class: > > package cool.web.app; > import webmacro.ignition.modules.*; > import webmacro.service.cache.generational.*; > > Also, unless there is a huge cry, I would drop the org in front of > webmacro as a convention. Without it our packages and docs will be a lot > easier to document. True, we could but the JLS does advise use of domain names: http://java.sun.com/docs/books/jls/second_edition/html/packages.doc.html#40169 ...and is is really worth departing from this convention for the sake of 4 characters? Marc -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Lane S. <la...@op...> - 2003-06-19 05:32:05
|
I voted :). Marc Palmer wrote: > > http://www.webmacro.org/DeveloperVotes > > I took the liberty of putting Brian in for his own bug category list. > |
|
From: Lane S. <la...@op...> - 2003-06-19 05:29:33
|
Eric B. Ridge wrote: > On Wednesday, June 18, 2003, at 10:58 AM, Marc Palmer wrote: > >>> The caching stuff, although central to WM, doesn't seem like >>> something we should expose as a top-level package. >> >> >> Why not? Caching is a separate function from resource provision, and >> could be reused for other things (i.e. Ignition stuff). > there would be nothing wrong with starting out a class: package cool.web.app; import webmacro.ignition.modules.*; import webmacro.service.cache.generational.*; Also, unless there is a huge cry, I would drop the org in front of webmacro as a convention. Without it our packages and docs will be a lot easier to document. -Lane > > It is separate, but it seems, like Lane said, to be more of an > implementation detail than something we really want outside users > (including Ignition) to use. That's my view anyways. > > eric > >> >> It's not a huge deal either way. >> >> >> >> -- >> Marc Palmer >> Contract Java Consultant/Developer >> >> http://www.anyware.co.uk/marc/ >> http://www.wangjammers.org >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: INetU >> Attention Web Developers & Consultants: Become An INetU Hosting Partner. >> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! >> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >> _______________________________________________ >> Webmacro-devel mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/webmacro-devel > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel > |
|
From: Marc P. <ma...@an...> - 2003-06-18 17:46:50
|
OK Eric has filed a vote now on the votes page (http://www.webmacro.org/DeveloperVotes). Seeing as there are only 10 people listed as core developers who have created Wiki pages for themselves, many of which do not seem to be active contributors any more, I propose the following "dodgy" democratic scheme to avoid us stalling development: 1. A vote can be considered over when 50% or more of the core developers who have Wiki pages have cast their vote. 2. The outcome is the majority, whether for or against. The observant among you may have realised that 50% equals 5 out of the 10 developers listed, and there just so happen to be 5 recently active developers... Keats, Brian, Lane, Eric and me. :) Do we need to vote on the voting rules, and if so what rules do we use for that, and will we vote on those? GOTO 10. -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-06-18 16:16:41
|
http://www.webmacro.org/DeveloperVotes I took the liberty of putting Brian in for his own bug category list. -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-06-18 15:43:18
|
On Wed, 18 Jun 2003 11:34:21 -0400, Eric B. Ridge <eb...@tc...> wrote: > On Wednesday, June 18, 2003, at 11:06 AM, Lane Sharman wrote: > >> Caching is an implementation detail and so, yes, I would agree that it >> would be an improvement on the package layout to subordinate it to a >> provider or resource status. It is actually a service. > > That's a very good way to look at it, I think. +1 for me... o.w.service sounds good. >> My vote would be to think about org.webmacro.service instead of >> o.w.resource. I prefer the term service to resource. Marc |
|
From: Eric B. R. <eb...@tc...> - 2003-06-18 15:35:35
|
On Wednesday, June 18, 2003, at 10:58 AM, Marc Palmer wrote: >> The caching stuff, although central to WM, doesn't seem like >> something we should expose as a top-level package. > > Why not? Caching is a separate function from resource provision, and > could be reused for other things (i.e. Ignition stuff). It is separate, but it seems, like Lane said, to be more of an implementation detail than something we really want outside users (including Ignition) to use. That's my view anyways. eric > > It's not a huge deal either way. > > > > -- > Marc Palmer > Contract Java Consultant/Developer > > http://www.anyware.co.uk/marc/ > http://www.wangjammers.org > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting > Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly > Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: Eric B. R. <eb...@tc...> - 2003-06-18 15:34:30
|
On Wednesday, June 18, 2003, at 11:06 AM, Lane Sharman wrote: > Caching is an implementation detail and so, yes, I would agree that it > would be an improvement on the package layout to subordinate it to a > provider or resource status. It is actually a service. That's a very good way to look at it, I think. > My vote would be to think about org.webmacro.service instead of > o.w.resource. I prefer the term service to resource. I kinda like that. eric > > -Lane > > Eric B.Ridge wrote: > >> On Wednesday, June 18, 2003, at 01:38 AM, Lane Sharman wrote: >> >>> ebr, >>> >>> i read your reorg work. looks good. >>> >>> I can go anyway the group wants to go on the following: >>> >>> org.opendoors.cache shows that you can plug an optional cache >>> manager. But, if you want to do cosmetic work on this and change the >>> name to org.webmacro.cache.generational.* as a specific impl, that >>> is ok with me. >> >> >> I'm not convinced we really need an "org.webmacro.cache" package >> anyways. Couldn't this stuff go in "org.webmacro.resource" or >> "org.webmacro.provider" >> >> The caching stuff, although central to WM, doesn't seem like >> something we should expose as a top-level package. >> >> Other thoughts? >> >> eric >> >>> >>> -Lane >>> >>> >>> >>> Eric B. Ridge wrote: >>> >>>> I've modified the NextRelease page on the website include what we >>>> want our new package structure to be. This is based on the (little >>>> bit of) discussion we've had here on this list. >>>> >>>> If you have comments please add them to the page, or discuss them >>>> here. >>>> >>>> http://www.webmacro.org/NextRelease >>>> >>>> eric >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.Net email is sponsored by: INetU >>>> Attention Web Developers & Consultants: Become An INetU Hosting >>>> Partner. >>>> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly >>>> Commission! >>>> INetU Dedicated Managed Hosting >>>> http://www.inetu.net/partner/index.php >>>> _______________________________________________ >>>> Webmacro-devel mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel >>>> >>> >>> >> >> > > |
|
From: Lane S. <la...@op...> - 2003-06-18 15:12:53
|
Caching is an implementation detail and so, yes, I would agree that it would be an improvement on the package layout to subordinate it to a provider or resource status. It is actually a service. My vote would be to think about org.webmacro.service instead of o.w.resource. I prefer the term service to resource. -Lane Eric B.Ridge wrote: > On Wednesday, June 18, 2003, at 01:38 AM, Lane Sharman wrote: > >> ebr, >> >> i read your reorg work. looks good. >> >> I can go anyway the group wants to go on the following: >> >> org.opendoors.cache shows that you can plug an optional cache >> manager. But, if you want to do cosmetic work on this and change the >> name to org.webmacro.cache.generational.* as a specific impl, that is >> ok with me. > > > I'm not convinced we really need an "org.webmacro.cache" package > anyways. Couldn't this stuff go in "org.webmacro.resource" or > "org.webmacro.provider" > > The caching stuff, although central to WM, doesn't seem like something > we should expose as a top-level package. > > Other thoughts? > > eric > >> >> -Lane >> >> >> >> Eric B. Ridge wrote: >> >>> I've modified the NextRelease page on the website include what we >>> want our new package structure to be. This is based on the (little >>> bit of) discussion we've had here on this list. >>> >>> If you have comments please add them to the page, or discuss them here. >>> >>> http://www.webmacro.org/NextRelease >>> >>> eric >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: INetU >>> Attention Web Developers & Consultants: Become An INetU Hosting >>> Partner. >>> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly >>> Commission! >>> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >>> _______________________________________________ >>> Webmacro-devel mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel >>> >> >> > > |
|
From: Lane S. <la...@op...> - 2003-06-18 15:07:54
|
Marc Palmer wrote:
> On Tue, 17 Jun 2003 23:16:41 -0700, Lane Sharman <la...@op...>
> wrote:
>
>>
>>
>> Keats wrote:
>
>
> The solution to this I believe is to specify the VLH settings through
> the VisitorTrackerRequestPlugin's config properties, so these
> properties are brought under ignition.properties / module config file,
> and can thus be edited when the user first installs the app. One place
> to config is much better.
>
> I'll have a look at the Visitor -> VLH code to see if I can do this
> with the current code base.
Yes. This is a workable approach. The signature in VLHProvider takes a
base path and forwards it on to the implementing proxy. You effectively
override the VLHDefaults.properties. Line 77 in VLHProvider:
public Hashtable getDefaultStore(
String storageRootDir,
String partitionKey) throws Exception {
...
Set the first parameter with a property defined in ignition.properties.
When it is not null, the property defined in VLHDefaults will not be used.
-Lane
>
>
> Marc
>
|
|
From: Marc P. <ma...@an...> - 2003-06-18 14:59:28
|
On Wed, 18 Jun 2003 10:47:59 -0400, Eric B. Ridge <eb...@tc...> wrote: > On Wednesday, June 18, 2003, at 01:38 AM, Lane Sharman wrote: > >> ebr, >> >> i read your reorg work. looks good. >> >> I can go anyway the group wants to go on the following: >> >> org.opendoors.cache shows that you can plug an optional cache manager. >> But, if you want to do cosmetic work on this and change the name to >> org.webmacro.cache.generational.* as a specific impl, that is ok with >> me. > > I'm not convinced we really need an "org.webmacro.cache" package anyways. > Couldn't this stuff go in "org.webmacro.resource" or > "org.webmacro.provider" > > The caching stuff, although central to WM, doesn't seem like something we > should expose as a top-level package. Why not? Caching is a separate function from resource provision, and could be reused for other things (i.e. Ignition stuff). It's not a huge deal either way. -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Eric B. R. <eb...@tc...> - 2003-06-18 14:48:09
|
On Wednesday, June 18, 2003, at 01:38 AM, Lane Sharman wrote: > ebr, > > i read your reorg work. looks good. > > I can go anyway the group wants to go on the following: > > org.opendoors.cache shows that you can plug an optional cache manager. > But, if you want to do cosmetic work on this and change the name to > org.webmacro.cache.generational.* as a specific impl, that is ok with > me. I'm not convinced we really need an "org.webmacro.cache" package anyways. Couldn't this stuff go in "org.webmacro.resource" or "org.webmacro.provider" The caching stuff, although central to WM, doesn't seem like something we should expose as a top-level package. Other thoughts? eric > > -Lane > > > > Eric B. Ridge wrote: > >> I've modified the NextRelease page on the website include what we >> want our new package structure to be. This is based on the (little >> bit of) discussion we've had here on this list. >> >> If you have comments please add them to the page, or discuss them >> here. >> >> http://www.webmacro.org/NextRelease >> >> eric >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: INetU >> Attention Web Developers & Consultants: Become An INetU Hosting >> Partner. >> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly >> Commission! >> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >> _______________________________________________ >> Webmacro-devel mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/webmacro-devel >> > > |
|
From: Eric B. R. <eb...@tc...> - 2003-06-18 14:39:34
|
On Wednesday, June 18, 2003, at 05:38 AM, Marc Palmer wrote: > On Tue, 17 Jun 2003 22:32:32 -0700, Lane Sharman <la...@op...> > wrote: > >> Macro Processing? > > Actually Brian mailed me direct an alternative list: <snip> > Any Agreement? +1 > As a separate though related note, we seem to have problems getting > "concensus" on things from WM core developers these days. I know this > is purely down to time constraints that various people have (for a > long time I was unable to contribute to this kind of discussion in the > past). I'm just waiting around for other people to make the decisions. :) <snip> > Be nice if Wiki could show who wrote what in the current document! damn, it just doesn't stop, does it! *grin* eric |
|
From: Keats <ke...@ea...> - 2003-06-18 13:47:46
|
In the past we've voted by having developers reply with +1/-1/0. Using Wiki might improve the process. Certainly a Wiki page to allow folks to discuss different options prior to a vote would be helpful. I think Brian's categories look good, except for "template engine". I imagine it may not be clear to most users what that means. How about "template evaluation" instead? If we start getting lot's of bug reports we may need more categories, but I don't expect that to happen. Keats ----- Original Message ----- From: "Marc Palmer" <ma...@an...> To: <web...@li...> Sent: Wednesday, June 18, 2003 5:38 AM Subject: Re: [Webmacro-devel] Setting up SF tracker > On Tue, 17 Jun 2003 22:32:32 -0700, Lane Sharman <la...@op...> > wrote: > > > Macro Processing? > > Actually Brian mailed me direct an alternative list: > > - template engine > - configuration > - servlet integration > - other > > I actually think this is probably the best way to go. In my experience with > a local SF system at a client of mine, staff were constantly putting > bugs/rfes in the wrong category (and project!) all the time, because they > don't understand it as well as the programmers do. > > So the fewer and more vague categories we have, the more likely they will > be in the right area. > > Any Agreement? > > As a separate though related note, we seem to have problems getting > "concensus" on things from WM core developers these days. I know this is > purely down to time constraints that various people have (for a long time I > was unable to contribute to this kind of discussion in the past). > > Anyone got any ideas for improving our response rate? > > We could start a DeveloperVotes page on Wiki and list current issues we > want feedback on, and list each developers' initials by them, with a "x" > for a vote and a "?" for no vote cast, i.e: > > Use brian's list of categories > ? ebr > ? mp > x ls > x bg > ? sk > x kk > > Then each developer just needs to visit the page and edit their line. Or > someone like me goes in and puts "x" by all of them ;-) > > Be nice if Wiki could show who wrote what in the current document! > > Marc > > -- > Marc Palmer > Contract Java Consultant/Developer > > http://www.anyware.co.uk/marc/ > http://www.wangjammers.org > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: Marc P. <ma...@an...> - 2003-06-18 09:40:01
|
On Tue, 17 Jun 2003 22:32:32 -0700, Lane Sharman <la...@op...> wrote: > Macro Processing? Actually Brian mailed me direct an alternative list: - template engine - configuration - servlet integration - other I actually think this is probably the best way to go. In my experience with a local SF system at a client of mine, staff were constantly putting bugs/rfes in the wrong category (and project!) all the time, because they don't understand it as well as the programmers do. So the fewer and more vague categories we have, the more likely they will be in the right area. Any Agreement? As a separate though related note, we seem to have problems getting "concensus" on things from WM core developers these days. I know this is purely down to time constraints that various people have (for a long time I was unable to contribute to this kind of discussion in the past). Anyone got any ideas for improving our response rate? We could start a DeveloperVotes page on Wiki and list current issues we want feedback on, and list each developers' initials by them, with a "x" for a vote and a "?" for no vote cast, i.e: Use brian's list of categories ? ebr ? mp x ls x bg ? sk x kk Then each developer just needs to visit the page and edit their line. Or someone like me goes in and puts "x" by all of them ;-) Be nice if Wiki could show who wrote what in the current document! Marc -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-06-18 08:35:16
|
On Tue, 17 Jun 2003 23:16:41 -0700, Lane Sharman <la...@op...> wrote: > > > Keats wrote: > >> Hmmm. Strangely after a couple of restarts it is working again. The >> filese >> apparently existed all along, as they are dated from Friday. Perhaps >> this >> is a Windoze drive letter thing, like if I start the server from a >> different >> drive it can't find the files? I'll try to experiement. >> > Please let me know if you find a pattern. This is part of VLH as Marc > mentioned. The base directory path to the store may, as you suggest, need > to be rewritten to allow a start from drives other than the one that > started the app. I'm sure it's just because the default VLHDefaults.properties has a unix path (/deploy/....) and as a result it can be a lottery as to which drive it will look on. The solution to this I believe is to specify the VLH settings through the VisitorTrackerRequestPlugin's config properties, so these properties are brought under ignition.properties / module config file, and can thus be edited when the user first installs the app. One place to config is much better. I'll have a look at the Visitor -> VLH code to see if I can do this with the current code base. Marc -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Lane S. <la...@op...> - 2003-06-18 06:23:16
|
Keats wrote: >Hmmm. Strangely after a couple of restarts it is working again. The filese >apparently existed all along, as they are dated from Friday. Perhaps this >is a Windoze drive letter thing, like if I start the server from a different >drive it can't find the files? I'll try to experiement. > Please let me know if you find a pattern. This is part of VLH as Marc mentioned. The base directory path to the store may, as you suggest, need to be rewritten to allow a start from drives other than the one that started the app. -Lane > >Another little bug is with the anchor tags in the documentation. I think >they need to be URL encoded. For example: > ><a name="sec_Example 2. A cleaner "Hello, World!""> > >This obviously won't work because of the double quotes. I'm not sure about >the blanks and other special characters, but $URLEncode($link) should fix >the problem. > >Keats > >----- Original Message ----- >From: "Marc Palmer" <ma...@an...> >To: "Keats" <ke...@ea...>; <web...@li...> >Sent: Monday, June 16, 2003 1:10 PM >Subject: Re: [Webmacro-devel] Please don't forget... > > > > >>>Marc, >>> >>>I'm not able to access the Ignition app on my box anymore. I'm getting >>>the >>>following: >>> >>>java.lang.Exception: Partition does not exist=Anonymous in >>>/deploy/projects/visitors/storage_1983 >>> >>>I don't see a directory structure like this anywhere. >>> >>> >>This is (passing buck) Lane's code :-) >> >>It's the filesystem-based VLH. It sounds like you did have the files (or >> >> >it > > >>would never have worked) and you have deleted them while Ignition is >>running. They are auto-generated if they do not exist, but I suspect only >>at startup. >> >>So, if you deleted/moved a directory (or your mounts/drive names changed) >>called /deploy then that would explain it. >> >>Try restarting your servlet container. >> >>Let me know how it goes. If you need any more help you can reach me on >>Yahoo as marcp_uk, AIM as HateAiOiL or ICQ 2930802. >> >>Cheers >> >>-- >>Marc Palmer >>Contract Java Consultant/Developer >> >>http://www.anyware.co.uk/marc/ >>http://www.wangjammers.org >> >> >> > > > >------------------------------------------------------- >This SF.NET email is sponsored by: eBay >Great deals on office technology -- on eBay now! Click here: >http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 >_______________________________________________ >Webmacro-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webmacro-devel > > > |
|
From: Lane S. <la...@op...> - 2003-06-18 06:14:33
|
Brian Goetz wrote: >>This sounds good to me, but we should monitor the performance to see >>if it really doesn't degrade. After all, we don't add optimisations >>without knowing they are really necessary, so we shouldn't take them >>away unless we know they are unnecessary :-) >> >> > >Truly excellent, useful, and widely applicable advice. I'd pushed for >this for quite a while earlier, but we never came up with a good >performance test harness. Anyway, in this case, I am inclined to >summarily ignore this advice. > The harness is in place: TestSyntheticTemplate.java and its associated reporting and member emplates provide an excellent baseline reporting vehicle before you start. Out of the box, you can run wm-home>ant test-tst and it will produce a baseline report in your current directory: LoadReport.html. The above runs exclusively the synthetic report. You recall that I wrote an OS kernel in assembler while you were a tot, right? Lots of benchmarking and tuning for the dispatcher. I invested heavily in TestSyntheticTemplate. It tests a spectrum of all the wm features and language set. During your refactoring efforts which I wholeheartedly support, you can get a big score or make a mistake. Yes, even you, Brian :). This test will give you an easy way to get the feedback while you refresh your coffee. Hopefully, the above will give you pause to summarily ignore the investment made in our WM development infrastructure. -Lane |
|
From: Lane S. <la...@op...> - 2003-06-18 05:55:08
|
There is a complete Performance Benchmark in the unit tests. Any project start like Brian proposes has to do the following: a) start the project on a stable machine. Do not alter the metrics of the maching over time by adding any background tasks. b) run the WM unit test benchmark and get consistent results. Save the html report as a baseline. c) iterate over the development tasks running often the benchmark to identify wins / losses. The nice thing about the Benchmark is it produces a clean report with a comparable capability. Edit the template to place the baseline values so you can always see your baseline in the dynamic report. -Lane Marc Palmer wrote: > On Fri, 13 Jun 2003 08:58:04 -0700, Brian Goetz <br...@qu...> > wrote: > >> One of the things I want to do for 2.0 is to get rid of all of the >> performance hacks that were introduced in the early days. They might >> or might not have been helpful then, but they are almost certainly >> counterproductive now. This will probably get rid of a lot of code. >> >> Now, I know we've existed thus far without any JAR dependencies, but >> one JAR we really should be using is Doug Lea's util.concurrent >> library, which contains some excellent building blocks for concurrent >> apps. > > > This sounds good to me, but we should monitor the performance to see > if it really doesn't degrade. After all, we don't add optimisations > without knowing they are really necessary, so we shouldn't take them > away unless we know they are unnecessary :-) > |
|
From: Lane S. <la...@op...> - 2003-06-18 05:47:45
|
I have no objection to an additional jar in the distro. Can you get started on this, Brian? -Lane Brian Goetz wrote: >One of the things I want to do for 2.0 is to get rid of all of the >performance hacks that were introduced in the early days. They might >or might not have been helpful then, but they are almost certainly >counterproductive now. This will probably get rid of a lot of code. > >Now, I know we've existed thus far without any JAR dependencies, but >one JAR we really should be using is Doug Lea's util.concurrent >library, which contains some excellent building blocks for concurrent >apps. > > > >------------------------------------------------------- >This SF.NET email is sponsored by: eBay >Great deals on office technology -- on eBay now! Click here: >http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 >_______________________________________________ >Webmacro-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webmacro-devel > > > |
|
From: Lane S. <la...@op...> - 2003-06-18 05:44:54
|
ebr, i read your reorg work. looks good. I can go anyway the group wants to go on the following: org.opendoors.cache shows that you can plug an optional cache manager. But, if you want to do cosmetic work on this and change the name to org.webmacro.cache.generational.* as a specific impl, that is ok with me. -Lane Eric B. Ridge wrote: > I've modified the NextRelease page on the website include what we want > our new package structure to be. This is based on the (little bit of) > discussion we've had here on this list. > > If you have comments please add them to the page, or discuss them here. > > http://www.webmacro.org/NextRelease > > eric > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel > |
237 messages has been excluded from this view by a project administrator.
