from:"Scott Eade"


 [ 
https://issues.apache.org/jira/browse/TRB-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Eade reassigned TRB-47:
-

Assignee: Scott Eade

 Create wrapper site for turbine.apache.org
 --

 Key: TRB-47
 URL: https://issues.apache.org/jira/browse/TRB-47
 Project: Turbine
  Issue Type: Sub-task
Reporter: Thomas Vandahl
 Assigned To: Scott Eade



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TRB-47) Create wrapper site for turbine.apache.org


 [ 
https://issues.apache.org/jira/browse/TRB-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Eade updated TRB-47:
--

Component/s: Site

This is in progress.  It is really just a matter of adding some PMC related 
stuff to our existing wrapper site.

 Create wrapper site for turbine.apache.org
 --

 Key: TRB-47
 URL: https://issues.apache.org/jira/browse/TRB-47
 Project: Turbine
  Issue Type: Sub-task
  Components: Site
Reporter: Thomas Vandahl
 Assigned To: Scott Eade



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TRB-50) Make the Jakarta site .htaccess change in svn to redirect to the new tlp


 [ 
https://issues.apache.org/jira/browse/TRB-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Eade updated TRB-50:
--

Component/s: Site
   Assignee: Scott Eade

I will do this when the site is closer to completion and after the mailing 
lists have been switched over.

I have already hacked together a turbine version of the velocity moving.hrml 
page.

 Make the Jakarta site .htaccess change in svn to redirect to the new tlp
 

 Key: TRB-50
 URL: https://issues.apache.org/jira/browse/TRB-50
 Project: Turbine
  Issue Type: Sub-task
  Components: Site
Reporter: Thomas Vandahl
 Assigned To: Scott Eade



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TRB-61) List new mailing lists on web site


 [ 
https://issues.apache.org/jira/browse/TRB-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Eade updated TRB-61:
--

Component/s: Site
   Assignee: Scott Eade

These are now listed, but not yet set up!

Depending on how they are configured (project/pom inheritance) the sub-projects 
may also need to be updated individually.

 List new mailing lists on web site
 --

 Key: TRB-61
 URL: https://issues.apache.org/jira/browse/TRB-61
 Project: Turbine
  Issue Type: Sub-task
  Components: Site
Reporter: Thomas Vandahl
 Assigned To: Scott Eade



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: tlp site progress

2007-05-26 Thread Scott Eade


Scott Eade wrote:

I have been committing changes to turbine-site (no commit messages?)
They are coming through now - one or two of them must be sitting in a 
spam folders somewhere.


Scott



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fulcrum Site Preview available ....

2007-05-25 Thread Scott Eade

If it is yaafi that you want to release then configure at as 1.0.5, make 
sure that any changes are documented (I know there is the changes.xml 
page, but you also need release notes including details of how to 
migrate from 1.0.4) and make the jar available somewhere so that we can 
test it.  When you think you have it right you can call for a vote based 
on the site and jar.


I have just started building the new turbine.apache.org site - since 
this is not announced yet there is probably no problem in this case 
deploying the fulcrum site directly to there (someone else will have to 
do it if you don't).


Thomas: No hurry at all, and I feel a little slack pushing this over to 
you all the time, but would you mind code wrestling turbine-site (no big 
deal really since it is never actually released).  turbine-2 trunk also 
needs to be done at some point in time.


Scott

Siegfried Goeschl wrote:

Hi folks,

I generated  uploaded a new site

1) svn developer activity is broken

2) is there any URL to show a HTML diff from the changelog report 
similiar to  VIEWCV


3) we have to align the dependencies - see 
http://people.apache.org/~sgoeschl/fulcrum/docs/dependency-convergence-report.html 



4) the Dashboard report is not correct because some coverage results 
are missing (yaffi, cache)


Cheers,

Siegfried Goeschl


Siegfried Goeschl wrote:

Hi Thomas,

1) I just got the SVN change reports running - it also helps to 
install the right svn client on a Mac  :-(


2) out of my head the security/turbine stuff but I'm rerunning the 
site generation with the maven-cobertura-plugin


Cheers,

Siegfried Goeschl


Thomas Vandahl wrote:

Siegfried Goeschl wrote:

Hi folks,

I was finally able to make a complete site build of Fulcrum to be 
found at http://people.apache.org/~sgoeschl/fulcrum/docs/


1) the SCM changelogs are not working so I have to investigate that


Could you check out if

maven.changelog.factory = org.apache.maven.svnlib.SvnChangeLogFactory

helps?

2) Generating the code coverage reports break tests - not sure if 
this is caused by maven-jcoverage plugin or be running the tests 
twice. TV pointed out that JCoverage is broken for JDK 1.5 so I 
have a look at Cobertura to see if it is better


Which tests are affected?


PS: Thanks to Thomas The Vandal for nailing down my build problems


I'm ready to demolish Karthago again anytime...

Bye, Thomas.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Deadline of Board Report May 2007?

2007-05-22 Thread Scott Eade


Siegfried Goeschl wrote:

do you have some dates?
My bad - our first report will be due in June.  I have updated the wiki 
to show the due dates.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Turbine is TLP :)

2007-05-20 Thread Scott Eade


Thomas Vandahl wrote:

What are the next steps
Henning provided a recipe of sorts: 
http://issues.apache.org/jira/browse/VELOCITY-470


Step 0 would be to create a Turbine specific clone of VELOCITY-470.

Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TRB-64) Move wiki and update site links

Move wiki and update site links
---

 Key: TRB-64
 URL: https://issues.apache.org/jira/browse/TRB-64
 Project: Turbine
  Issue Type: Sub-task
Reporter: Scott Eade




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Turbine going TLP - pending infrastructure changes, including to this mailing list

2007-05-20 Thread Scott Eade

Now that our proposal to become a top-level project (TLP) of the Apache 
Software Foundation (ASF) has been passed by the board, we will begin 
the process of migrating our resources across from 
jakarta.apache.org/turbine to turbine.apache.org.


There are a multitude of things that are going to change with this move, 
please see https://issues.apache.org/jira/browse/TRB-44 for full details.


Some of the tasks attached to TRB-44 may occur quicker than others.  In 
particular I draw your attention to the fact that the mailing lists for 
this project are likely to change fairly soon.  The specific changes are 
that turbine-dev@jakarta.apache.org will become [EMAIL PROTECTED] 
and [EMAIL PROTECTED] will become 
[EMAIL PROTECTED]  In addition to these, the commit messages that 
currently go to [EMAIL PROTECTED] will be directed to 
[EMAIL PROTECTED]


The site turbine.apache.org will also be set up at some point in the 
future, but it is likely to take a while for us to get this into shape 
with updated links, etc., so please bear with us while we jump through 
all of the necessary hoops and get things updated.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Assigned: (TRB-46) Move mailing lists to turbine.apache.org


 [ 
https://issues.apache.org/jira/browse/TRB-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Eade reassigned TRB-46:
-

Assignee: Scott Eade

 Move mailing lists to turbine.apache.org
 

 Key: TRB-46
 URL: https://issues.apache.org/jira/browse/TRB-46
 Project: Turbine
  Issue Type: Sub-task
Reporter: Thomas Vandahl
 Assigned To: Scott Eade



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRB-45) Create turbine.apache.org


[ 
https://issues.apache.org/jira/browse/TRB-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497318
 ] 

Scott Eade commented on TRB-45:
---

Created INFRA-1249.

 Create turbine.apache.org
 -

 Key: TRB-45
 URL: https://issues.apache.org/jira/browse/TRB-45
 Project: Turbine
  Issue Type: Sub-task
Reporter: Thomas Vandahl



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TRB-46) Move mailing lists archives to turbine.apache.org


 [ 
https://issues.apache.org/jira/browse/TRB-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Eade updated TRB-46:
--

Summary: Move mailing lists archives to turbine.apache.org  (was: Move 
mailing lists to turbine.apache.org)

The mailing lists were requested in sub-task TRB-45 - this task is being reused 
to follow up mailing list archive maintenance.

The ASF archive should be taken care of by TRB-4.

I have informed gmane.org, nabble.com and marc.theaimsgroup.com via email of 
the impending changes.

 Move mailing lists archives to turbine.apache.org
 -

 Key: TRB-46
 URL: https://issues.apache.org/jira/browse/TRB-46
 Project: Turbine
  Issue Type: Sub-task
Reporter: Thomas Vandahl
 Assigned To: Scott Eade



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRB-47) Create wrapper site for turbine.apache.org


[ 
https://issues.apache.org/jira/browse/TRB-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497323
 ] 

Scott Eade commented on TRB-47:
---

Fortunately we already have a wrapper site (jakarta/turbine/site in svn) so 
this should be easier for us than it was for Velocity.  We do still need to 
augment the site with additional information relating to the operation of the 
turbine TLP.

 Create wrapper site for turbine.apache.org
 --

 Key: TRB-47
 URL: https://issues.apache.org/jira/browse/TRB-47
 Project: Turbine
  Issue Type: Sub-task
Reporter: Thomas Vandahl



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Assigned: (TRB-53) Get a Turbine commits list


 [ 
https://issues.apache.org/jira/browse/TRB-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Eade reassigned TRB-53:
-

Assignee: Scott Eade

 Get a Turbine commits list
 --

 Key: TRB-53
 URL: https://issues.apache.org/jira/browse/TRB-53
 Project: Turbine
  Issue Type: Sub-task
Reporter: Thomas Vandahl
 Assigned To: Scott Eade



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRB-53) Get a Turbine commits list


[ 
https://issues.apache.org/jira/browse/TRB-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497326
 ] 

Scott Eade commented on TRB-53:
---

Requested in TRB-44 / INFRA-1249.

 Get a Turbine commits list
 --

 Key: TRB-53
 URL: https://issues.apache.org/jira/browse/TRB-53
 Project: Turbine
  Issue Type: Sub-task
Reporter: Thomas Vandahl
 Assigned To: Scott Eade



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TRB-51) Update SVN links


 [ 
https://issues.apache.org/jira/browse/TRB-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Eade updated TRB-51:
--

Summary: Update SVN links  (was: Move SVN)

The actual svn move was requested in TRB-44 / INFRA-1249.

This issue canbe used as a reminder to update the svn links on the sites.

 Update SVN links
 

 Key: TRB-51
 URL: https://issues.apache.org/jira/browse/TRB-51
 Project: Turbine
  Issue Type: Sub-task
Reporter: Thomas Vandahl



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (TRB-59) Update committee-info.txt


 [ 
https://issues.apache.org/jira/browse/TRB-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Eade closed TRB-59.
-

Resolution: Fixed

Henri has done this already - Thanks.

 Update committee-info.txt
 -

 Key: TRB-59
 URL: https://issues.apache.org/jira/browse/TRB-59
 Project: Turbine
  Issue Type: Sub-task
Reporter: Thomas Vandahl



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

intake blues

2007-05-15 Thread Scott Eade

I have a couple of fields defined in my intake.xml that are type=int 
and required=false.  In torque these are defined as type=INTEGER 
javaType=object, so an empty value on the form should result in a null 
in the database.


Since updating to the latest snapshot jar these fields are ending up 
with zero values in the database.  Not much has changed since the 
previous snapshot jar I was running - Thomas: is there any chance this 
could be related to your recent intake changes?  I need to dig further, 
but I'm too dead tired to look at this any more today (it's just gone 
2:15am)


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: intake blues

2007-05-15 Thread Scott Eade


Thomas Vandahl wrote:

Scott Eade wrote:
  

Since updating to the latest snapshot jar these fields are ending up
with zero values in the database.  Not much has changed since the
previous snapshot jar I was running - Thomas: is there any chance this
could be related to your recent intake changes?  I need to dig further,
but I'm too dead tired to look at this any more today (it's just gone
2:15am)



The only thing I changed was the order of operations so that now first
all fields are inited and then all fields are validated in two loops
whereas previously every field was inited and then validated in one
loop. I don't see that this could cause the described behavior.
  
The above problem is unrelated to either of our patches - it is a side 
effect of the fact that reflection is used by setProperties() that means 
that Intake is incapable of validating Integer fields where a null value 
needs to be distinguished from a zero.

I'm not entirely sure that your fix does what you want. As I see it, if
your field key is in the parameter parser, this means that the field was
meant to be set. The case null as a value should not happen then (The
parser takes care of this). If the value is empty (), however, this
could well be meant as deleting a fields contents. This would now result
in this field not to be set - and not to be validated, if I'm not
mistaken. I'll try to make up a test case to prove this.
  
Actually, the problem is that isSet() currently controls whether or not 
a field is validated - the problem with my patch is that a required 
field that is not set is no longer being validated.  The fix is to also 
check isRequired() when determining whether or not validation is required.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JSON-RPC Service for 2.3.3

2007-05-08 Thread Scott Eade

I have a JSON-RPC Service sitting here ready to commit just as soon as 
the necessary dependency is available via the maven 1 repository.


I can commit after http://jira.codehaus.org/browse/MAVENUPLOAD-1525 is 
actioned.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TLP proposal Turbine POI for this board meeting and todo items.

2007-05-08 Thread Scott Eade


Martin van den Bemt wrote:

Hi everyone,
  

Hi Martin

The 16th of May is the next board meeting, so I was wondering if you were all 
ready to go TLP at
this stage or if you prefer to wait for next months board meeting ?
Getting the approval done will not mean you have to move over everything 
immediately (we are still
volunteers) and gives us a better time-line to help out with moving things 
over, set up redirects, etc..
There are a couple of things I like to see (re) checked :

- Have all people added their name to the TLP proposal ?
  

To my knowledge nobody else has expressed a desire to be on the PMC.

- Is the proposal setup according to
https://svn.apache.org/repos/private/committers/board/templates/subproject-tlp-resolution.txt
 ?
(this was just changed recently)
  
I have updated the proposal at 
http://wiki.apache.org/jakarta-turbine/TLPTurbine to match the latest 
iteration of the template.

If everything is ok, ping me, so I can add it to the boards agenda.. Please 
remember that everything
that is added to the agenda needs to be  80 characters on a line :

I have reproduced the proposal below with line breaks  col 80.

I don't see any reason why this cannot go to the board this month.

Let us know if there is anything else we need to do in advance of this.

Thanks,

Scott
-- Proposal wrapped at  80 cols --

## Resolution to create a TLP from the subproject of an existing TLP

Establish the Apache Turbine Project

WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project, to be known as
Apache Turbine Project, related to the Turbine web
application framework, including Fulcrum (a repository of
Turbine related components based on Avalon/Excalibur
technology) and META (an Apache Maven plugin for creating
Turbine Project archetypes), for distribution at no charge
to the public.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC) is hereby is established pursuant to Bylaws
of the Foundation; and be it further

RESOLVED, that the Apache Turbine PMC be and hereby is
charged with the creation and maintenance of Apache Turbine;
and be it further

RESOLVED, that the office of Vice President, Apache Turbine
be and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache Turbine PMC, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Turbine PMC; and be it further

RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache Turbine PMC:

 * Jeffrey D. Brekke   [EMAIL PROTECTED]
 * Peter Courcoux  [EMAIL PROTECTED]
 * Scott Eade  [EMAIL PROTECTED]
 * Juergen Hoffmann[EMAIL PROTECTED]
 * Will Glass-Husain   [EMAIL PROTECTED]
 * Siegfried Goeschl   [EMAIL PROTECTED]
 * Henning Schmiedehausen  [EMAIL PROTECTED]
 * Thomas Vandahl  [EMAIL PROTECTED]

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Scott Eade be
appointed to the office of Vice President, Apache Turbine,
to serve in accordance with and subject to the direction of
the Board of Directors and the Bylaws of the Foundation
until death, resignation, retirement, removal or
disqualification, or until a successor is appointed; and
be it further

RESOLVED, that the Apache Turbine Project be and hereby is
tasked with the migration and rationalization of the Apache
Jakarta Project's Turbine; and be it further

RESOLVED, that all responsibility pertaining to the Apache
Turbine sub-project encumbered upon the Apache Jakarta
Project are hereafter discharged.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[RESULT][VOTE] Move Turbine to TLP

2007-05-06 Thread Scott Eade


Voting has ended.  The following votes were case:

+1: 19 votes

   * Will Glass-Husain (pmc)
   * Henning P. Schmiedehausen (pmc)
   * Juergen Hoffmann
   * Peter Courcoux
   * Thomas Vandahl
   * Jeff Brekke (pmc)
   * Henri Yandell (pmc)
   * Scott Eade (pmc)
   * Roland Weber (pmc)
   * Dion Gillard
   * Niall Pemberton (pmc)
   * Nathan Bubna (pmc)
   * Mark Thomas (pmc)
   * Rahul Akolkar (pmc)
   * Davanum Srinivas (pmc)
   * Jörg Schaible (pmc)
   * Martin van den Bemt (pmc)
   * Jesse Kuhnert
   * Rony G. Flatscher (pmc)

+0: None
-1: None

Thank you to those that participated.  I will ask Martin to take the 
proposal to the board.


Scott

Scott Eade wrote:
The Turbine project has been discussing a proposal to the board that 
the Turbine projects leave the Jakarta umbrella and become their own 
top level project.  We are now at the point in the process that calls 
for a vote to take place.


The proposal is available at:
   http://wiki.apache.org/jakarta-turbine/TLPTurbine

For the interested, most of the discussion took place in the following 
thread:

   http://www.nabble.com/-DISCUSS--TLP--tf3574436.html

Here are the vote options:
[ ] +1 I support the proposal
[ ] +0 I don't care
[ ] -1  I'm opposed to the proposal because...

Voting will close in one week.

Thanks,

Scott



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: StringTool anyone?

2007-05-04 Thread Scott Eade


Thomas Vandahl wrote:

Scott Eade wrote:
  

Is there any interest in a pull tool that provides various (admittedly
arbitrary) String related functions for use in templates?



Of course it would be desirable to have such a thing in the standard
distribution. Especially, because probably everybody wrote something
like this for their own purposes.
  
At the end of the day we are probably all going to have different 
requirements.  I just committed a small addition to turbine's 
DateFormatter class, but my requirements may not be representative of 
what others need.


Martin Lidgard's suggestion of Velocity Tools Generic Tools is probably 
the way to go - he posted a response to someone's query on the user list 
a while back that showed how easy it is to use these with Turbine:

you need to activate each tool in the velocity-tools-generic-1.2.jar by
adding a line in TurbineResources.properties:

tool.global.numberTool = org.apache.velocity.tools.generic.NumberTool
tool.global.escTool = org.apache.velocity.tools.generic.EscapeTool
tool.global.renderTool = org.apache.velocity.tools.generic.RenderTool
tool.global.sortTool = org.apache.velocity.tools.generic.SortTool 
  
Seems trivial.  This would provide for the escaping methods I have, but 
interestingly VT GT doesn't seem to have any basic String manipulation 
methods (not everything can be done in VTL).  It could probably replace 
DateFormatter really easily - in fact we should consider deprecating it 
with this in mind.


We should probably try and add a few comments in the Pull Service 
documentation on this for the pending release - I need to update the 
UIManager reference to UITool anyway.

As we are at it, would it be interesting to add formatting facilities to
the LocalizationTool for, say, floating point numbers, currency values
and such?
  
And Dates.  It looks like VT GT DateTool does this already, and 
NumberTool handles the floating point and currency values.  Try as I 
might though, these things sometimes still need to be done outside of 
templates, which is something the l10n service handles.  Also, it might 
be nice if the l10n service is a one stop localization shop rather than 
providing three tools.


Scott


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

StringTool anyone?

2007-05-03 Thread Scott Eade

Is there any interest in a pull tool that provides various (admittedly 
arbitrary) String related functions for use in templates?


I have one here that is pretty much a wrapper for various functions in 
commons-lang - StringUtils, WordUtils, StringEscapeUtils


It currently provides:

   * defaultString(String str)
   * defaultString(String str, String defaultStr)
   * caps(String input)
   * nocaps(String input)
   * escapeHtml(String str)
   * escapeJava(String str)
   * escapeJavaScript(String str)
   * escapeJavaScriptHtml(String str)
   * escapeXml(String str)

I can commit for the up coming 2.3.3 if people are interested. 


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Some quick things to tidy up before a 2.3.3-rc1

2007-05-02 Thread Scott Eade


Thomas Vandahl wrote:

Scott Eade wrote:
  

If anyone has anything else to add, please speak now.  If those present
at the AC.eu Hackathon (Thomas, Henning and perhaps Juergen later in the
week) can chew through a bunch of these it would be really great.  I
believe Siegfried is also attending, but I imagine his focus will be on
Yaafi (let's CodeWrestle that too if possible).



While looking through the code I spotted another candidate for
deprecation that probably had been forgotten: The DBSecurityService and
its associated classes. Should we deprecate these now? It's responsible
for a certain part of the hassles I went through yesterday when going to
Torque 3.2.
  
Yes, this should be deprecated so that it can be removed in a subsequent 
release.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Some quick things to tidy up before a 2.3.3-rc1

2007-05-02 Thread Scott Eade


Thomas Vandahl wrote:

Intermediate Status report:

Scott Eade wrote:
  

   * Deprecate ScheduleService for reasons stated earlier.


Scott: Would you please be so kind as to look over the documentation of
the fulcrum-quartz component, so that the transition is a bit easier?
  

I agree that the fulcrum-quartz documentation is a little light.

   * Update to Velocity 1.5 (perhaps with one or two dependencies)


This needs to be synchronized with the Torque stuff, I found. Work in
progress.
  

Okay.

   * Delete the ComponentService (and remove the Stratum dependency) -
 the AvalonComponentService and ACSYaafiComponentService can be
 used instead instead.  Obviously this needs to be highlighted in
 the release notes.


Done. Documentation needs to be adjusted/removed.
  

Done.

   * Update to a dated snapshot of Torque 3.3-rc3 with a caveat that
 turbine-2.3.3 final will not be released until torque -3.3 final
 has been released.


This probably needs a number of steps. Work in progress. Updated to
Torque 3.2 already.
  

Okay.

More:
- Compiled a list of further candidates for removal. Needs to be reviewed.
  

See my response.

Excellent progress Thomas!

Scott


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

2.3.3-dev site

2007-05-02 Thread Scott Eade

I have just redeployed the 2.3.3-dev site again.  It may take a couple 
of hours to sync.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Some quick things to tidy up before a 2.3.3-rc1

2007-05-02 Thread Scott Eade


Scott Eade wrote:

Thomas Vandahl wrote:

Intermediate Status report:

Scott Eade wrote:
 

   * Deprecate ScheduleService for reasons stated earlier.


Scott: Would you please be so kind as to look over the documentation of
the fulcrum-quartz component, so that the transition is a bit easier?
  

I agree that the fulcrum-quartz documentation is a little light.
BTW: I don't see this as a show stopper for deprecating ScheduleService 
in 2.3.3-rc1 - I will get to it, but possibly not before 2.3.3 final is 
released.


I would also be keen on seeing a couple of paragraphs from you on your 
Intake localization enhancements.


We will also have to put some release notes together - xdoc would be 
nice but wiki is fine too.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Move Turbine to TLP

2007-05-02 Thread Scott Eade


+1 from me (duh).

Scott

Scott Eade wrote:
The Turbine project has been discussing a proposal to the board that 
the Turbine projects leave the Jakarta umbrella and become their own 
top level project.  We are now at the point in the process that calls 
for a vote to take place.


The proposal is available at:
   http://wiki.apache.org/jakarta-turbine/TLPTurbine

For the interested, most of the discussion took place in the following 
thread:

   http://www.nabble.com/-DISCUSS--TLP--tf3574436.html

Here are the vote options:
[ ] +1 I support the proposal
[ ] +0 I don't care
[ ] -1  I'm opposed to the proposal because...

Voting will close in one week.

Thanks,

Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Deprecations

2007-05-01 Thread Scott Eade


Thomas Vandahl wrote:

Scott Eade wrote:
  

Candidates for removal before 2.3.3 include:

   * org.apache.turbine.util.SequencedHashtable
   * org.apache.turbine.util.StringStackBuffer
   * org.apache.turbine.util.FileUtils
   * org.apache.turbine.util.BufferCache
   * org.apache.turbine.util.QuickSort
   * org.apache.turbine.util.Comparable
   * org.apache.turbine.util.Log
   * org.apache.java.lang.Bytes
   * org.apache.java.security.MD5
   * org.apache.java.security.MessageDigest
   * org.apache.turbine.util.db.UUIdGenerator
   * org.apache.turbine.util.db.TableColumn
   * org.apache.turbine.services.resources.TurbineResources



Some more candidates are:

* org.apache.turbine.util.mail.*
* org.apache.turbine.util.validation.*
* org.apache.turbine.util.upload.*
* org.apache.turbine.services.db.*

  

Yes - I think these can all go.

Scott


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Some quick things to tidy up before a 2.3.3-rc1

2007-05-01 Thread Scott Eade

I just had a brief chat with a couple of our fellow Turbiners who were 
sitting together at ApacheCon.eu - present were Thomas, Henning and myself.


We discussed that we believe needs to be done for a 2.3.3-rc1 - here is 
what we came up with (in no particular order):


   * Delete the classes I noted in my recent post
   * Deprecate ScheduleService for reasons stated earlier.
   * Update to Velocity 1.5 (perhaps with one or two dependencies)
   * Delete the additional list of packages that Thomas posted a short
 time ago
   * Delete the ComponentService (and remove the Stratum dependency) -
 the AvalonComponentService and ACSYaafiComponentService can be
 used instead instead.  Obviously this needs to be highlighted in
 the release notes.
   * Update to a dated snapshot of Torque 3.3-rc3 with a caveat that
 turbine-2.3.3 final will not be released until torque -3.3 final
 has been released.
   * CodeWrestle the necessary license changes into the 2.3 branch

Since the chat ended I have also remembered that we also wanted to put a 
Maven 2 POM together.  I don't think this needs to be totally connected 
to 2.3.3-rc1, but it should be done and tested in advance of 2.3.3 final.


If anyone has anything else to add, please speak now.  If those present 
at the AC.eu Hackathon (Thomas, Henning and perhaps Juergen later in the 
week) can chew through a bunch of these it would be really great.  I 
believe Siegfried is also attending, but I imagine his focus will be on 
Yaafi (let's CodeWrestle that too if possible).


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Turbine 2.3 site redeployed

2007-04-30 Thread Scott Eade

I have just deployed a fresh copy of the Turbine 2.3 site to 
http://jakarta.apache.org/turbine/turbine/development/turbine-2.3/


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Deprecations

2007-04-30 Thread Scott Eade


Thomas Vandahl wrote:

Scott Eade wrote:
  

Candidates for deprecation in 2.3.3:

   * ScheduleService - not going to be ported to Fulcrum, use Fulcrum
 Quartz instead
   * LocalizationService - use Fulcrum Localization instead - relevant
 classes have not been carried over to trunk/2.4 so it should have
 been deprecated already anyway
   * IntakeService - same situation as l10n service
   * MimeTypeService - ditto
   * A bunch of other services for which we have Fulcrum components do
 still actually exist in the trunk/2.4 - should we not deprecate
 these also now so that we can have a cleaner base to work on with 2.4?


I'd not deprecate any services in the 2.3 branch, I expressed my
concerns about the state of their Fulcrum counterparts already. At least
their inter-dependencies need to be resolved. Localization and Intake
rely on the Factory and Pool services and the Parser component, which in
turn depends on the Upload service. If you want to use one of them, you
need to replace all. I would not want to recommend this to the user as
long as we haven't sorted that mess out.
  
Nothing says that we have to remove something that is deprecated in the 
immediately following release, but then it is also not really good form 
to deprecate things before the replacements are available.


Using this criteria I would suggest that we proceed with deprecating the 
ScheduleService since it is pretty much stand alone and it has a 
reasonably serious issue relating to DST that is unlikely to be addressed.


For the other services, I agree with your reasoning - i.e. let's hold 
off until their replacements have been fully implemented in the desired 
fashion.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Velocity 1.5?

2007-04-30 Thread Scott Eade


I knew that would get Henning and Wills' attention.

I am wondering if for 2.3.3 we should update some of our dependencies.

I know Will updated his apps to use Velocity 1.5 - where there any 
changes required for this (to turbine or your app)?


Torque also springs to mind - we could at least go to 3.2 (hmm, does 
Torque 3.2 work with ACSYaafiComponentService or do I need to add a 
comment that trunk/3.3 is required?)


Thomas has already taken care of commons-fileupload, but there may be a 
couple more that can also be dropped in.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRB-27) Turbine 2.3.2 compatible Service to use YAAFI instead of the AvalonComponentService

2007-04-29 Thread Scott Eade (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRB-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Eade resolved TRB-27.
---

   Resolution: Fixed
Fix Version/s: Core 2.3.3
 Assignee: Scott Eade

org.apache.turbine.services.avaloncomponent.ACSYaafiComponentService has been 
committed to the 2.3 branch along with docs and a basic test case.

 Turbine 2.3.2 compatible Service to use YAAFI instead of the 
 AvalonComponentService
 ---

 Key: TRB-27
 URL: https://issues.apache.org/jira/browse/TRB-27
 Project: Turbine
  Issue Type: Improvement
  Components: Fulcrum
Affects Versions: Core 2.3.2
Reporter: Thomas Vandahl
 Assigned To: Scott Eade
 Fix For: Core 2.3.3

 Attachments: ACSYaafiComponentService.java


 I changed a few lines in the TurbineYaafiComponentService to make it run as a 
 Drop-In replacement of the TurbineAvalonComponentService which is based on 
 ECM. To use this, you just need to change the line
 services.AvalonComponentService.classname=org.apache.turbine.services.avalon.TurbineAvalonComponentService
 into
 services.AvalonComponentService.classname=org.apache.turbine.services.yaafi.TurbineYaafiComponentService
 and add
 services.AvalonComponentService.containerConfiguration = 
 /WEB-INF/conf/containerConfiguration.xml
 to the TurbineResources.properties file.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Pull tools and access classes

2007-04-29 Thread Scott Eade

In the proposals directory of the trunk I have sitting there some 
enhancements to the UI pull tool.


Rather than just a pull tool I have implemented a service, since this 
makes it more practical to provide a class that implements static 
accessor methods to get at the skinning data from within action classes 
as well as in templates (via a pull tool).


If this was to be converted over to a fulcrum component, where would the 
turbine specific code (the pull tool and the static accessor class) go?  
I suggest that once we have the maven 2 build system in place these 
types of classes could actually remain with turbine and the fulcrum 
dependency could be listed as being optional.  Does this sound 
reasonable or does anyone else have a better suggestion?


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Deprecations

2007-04-29 Thread Scott Eade

Is there any reason we cannot deprecate things in a point release (e.g. 
2.3.3) so that they can later be removed in 2.4?


Candidates for deprecation in 2.3.3:

   * ScheduleService - not going to be ported to Fulcrum, use Fulcrum
 Quartz instead
   * LocalizationService - use Fulcrum Localization instead - relevant
 classes have not been carried over to trunk/2.4 so it should have
 been deprecated already anyway
   * IntakeService - same situation as l10n service
   * MimeTypeService - ditto
   * A bunch of other services for which we have Fulcrum components do
 still actually exist in the trunk/2.4 - should we not deprecate
 these also now so that we can have a cleaner base to work on with 2.4?

What about removing some of the deprecated code before 2.3.3?  It has 
been ages since 2.3.2 was released so I think we can justify removing 
this code.


Candidates for removal before 2.3.3 include:

   * org.apache.turbine.util.SequencedHashtable
   * org.apache.turbine.util.StringStackBuffer
   * org.apache.turbine.util.FileUtils
   * org.apache.turbine.util.BufferCache
   * org.apache.turbine.util.QuickSort
   * org.apache.turbine.util.Comparable
   * org.apache.turbine.util.Log
   * org.apache.java.lang.Bytes
   * org.apache.java.security.MD5
   * org.apache.java.security.MessageDigest
   * org.apache.turbine.util.db.UUIdGenerator
   * org.apache.turbine.util.db.TableColumn
   * org.apache.turbine.services.resources.TurbineResources

Comments?

Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Progress on TLP proposal (Was: Re: [Jakarta-turbine Wiki] Update

2007-04-28 Thread Scott Eade


Henning P. Schmiedehausen wrote:

Scott Eade [EMAIL PROTECTED] writes:
  
There is one last thing I want to do before kicking off the vote and 
that is to put together a Wiki page concerning thoughts on how we will 
proceed towards a 2.4 release.  Would anyone care to list the tasks they 
believe are outstanding.  Again, this is only for us (i.e. the TLP 
proposal does not actually depend upon it), but I see it as being part 
of us having our house in order before we go ahead with the TLP vote.



I wouldn't connect this, but if you feel it is necessary before going
TLP, go ahead. As I said, every OSS project should be user driven (and
committers are mostly users, too). If e.g. Martin starts to send in
his changes and enhancements, there will obviously progress. Until
then, development pace happens at the speed set by the committers. I
do not really believe in artificial road maps and mile stones.
  
What I am actually after is some thinking on what needs to be done, not 
when it might be done.


I can see that there is little to be gained from connecting this to the 
TLP discussion - I will kick off the vote shortly.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Move Turbine to TLP

2007-04-28 Thread Scott Eade

The Turbine project has been discussing a proposal to the board that the 
Turbine projects leave the Jakarta umbrella and become their own top 
level project.  We are now at the point in the process that calls for a 
vote to take place.


The proposal is available at:
   http://wiki.apache.org/jakarta-turbine/TLPTurbine

For the interested, most of the discussion took place in the following 
thread:

   http://www.nabble.com/-DISCUSS--TLP--tf3574436.html

Here are the vote options:
[ ] +1 I support the proposal
[ ] +0 I don't care
[ ] -1  I'm opposed to the proposal because...

Voting will close in one week.

Thanks,

Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: Coding Specification - do we care?

2007-04-26 Thread Scott Eade


Thomas Vandahl wrote:

Juergen Hoffmann wrote:
Since I volunteered in updating the headers, and I have the 
formatting rules
ready, I will do all o fit in one swoosh. (Thomas, do you mind if we 
just
quickly echange the eclipse configurations of code formatting rules, 
just so
we both have the same ruleset? If you agree, I will send you mine 
later today)


Yes, please do. But it's not only the formatting in Eclipse, it's 
everything CheckStyle checks for, naming of methods, fields and 
constants, magic numbers etc. etc.
We need to strike a balance here - I would mostly like to see changes 
limited to whitespace and brackets.


If we are going to reformat in batch I would probably vote to retain the 
80 character line length so as to reduce the overall number of changes 
that result.


I would probably go for a more pragmatic approach also, say:

   * Don't do it for any branch other than trunk (the licenses need to
 be updated, but I see little sense addressing the formatting for
 what is essentially a maintenance branch)
   * Do it for turbine trunk separately to, but in close proximity to
 the license update (actually, this would be the one argument for
 either holding off for now or applying the standard to the 2.3
 branch - efforts to keep the two in sync will be a little easier
 if both are reformatted)
   * Consider updating the fulcrum components as part of (or even
 shortly after) their next individual release (above bracketed
 concern also applies)

I guess I am still wary of pulling the rug from under the maintainers of 
the existing code.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Progress on TLP proposal (Was: Re: [Jakarta-turbine Wiki] Update of SubProjectReport-April2007 by ScottEade)

2007-04-26 Thread Scott Eade


Apache Wiki wrote:

The following page has been changed by ScottEade:
http://wiki.apache.org/jakarta-turbine/SubProjectReport-April2007

The comment on the change is:
If we were to report to the board today, it would be something like this - DRAFT
  
Take a look at this and make any changes you feel are relevant.  This is 
really only for us at present, but I wanted to make sure we present as 
well before kicking off the vote on the TLP proposal.


There is one last thing I want to do before kicking off the vote and 
that is to put together a Wiki page concerning thoughts on how we will 
proceed towards a 2.4 release.  Would anyone care to list the tasks they 
believe are outstanding.  Again, this is only for us (i.e. the TLP 
proposal does not actually depend upon it), but I see it as being part 
of us having our house in order before we go ahead with the TLP vote.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: apachecon - Amsterdam

2007-04-25 Thread Scott Eade


Juergen Hoffmann wrote:

who will be when at the apachecon?

I will probably be there on May 4th, since I will be in Mallorca May 2nd  and
3rd 
  
Well I will not be there, but I put together a page on the wiki with 
some potential discussion points / Hackathon activities.


The page is http://wiki.apache.org/jakarta-turbine/ApacheCon07EU

Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: fulcrum-quartz configuration

2007-04-25 Thread Scott Eade


Scott Eade wrote:
While debugging an unrelated issue I was forcing stack traces from 
tomcat via kill -3 (very useful).

Ctrl-Break on Windows.

This revealed a couple of issues with fulcrum-quartz.

1. By default there are 10 worker threads being initiated for 
DefaultQuartzScheduler - this is way more than are likely to be 
required.  The documentation 
(http://www.opensymphony.com/quartz/wikidocs/ConfigThreadPool.html) 
says If you only have a few jobs that fire a few times a day, then 1 
thread is plenty!.  Tuning this should be a simple matter of 
configuring org.quartz.threadPool.threadCount = 1


2. The quartz threads are currently prefixed with 
DefaultQuartzScheduler - I have four webapps and I cannot tell which 
of the threads relates to which instance (44 threads in all due to 
issue 1 described above).  Altering this should be a simple matter of 
configuring org.quartz.scheduler.threadName to be something 
environment specific rather than the default of: instanceName + 
'_QuartzSchedulerThread' (see: 
http://www.opensymphony.com/quartz/wikidocs/ConfigMain.html)  I am 
trusting that this will change the prefix of the worker threads also 
(4 scheduler threads and 40 workers).
Setting org.quartz.scheduler.instanceName rather than threadName has the 
advantage that the scheduler thread is also distinguishable in the stack 
trace.


I haven't looked into the fulcrum end of this yet - I assume it that 
adding these will be a simple matter of updating the config in 
componentConfiguration.mxl - IOC and all that I imagine it it should 
be a piece of cake.
Okay, simple enough, but there are a at least a couple of ways to 
achieve this now:


   * Using system properties via Yaafi's SystemPropertyService thus:

   SystemPropertyService
   property name=org.quartz.threadPool.threadCount1/property
   property 
name=org.quartz.scheduler.instanceName${myapp.servlet.name}_Quartz/property

   /SystemPropertyService

   * Using quartz.properties, note however that if Quartz finds a
 quartz.properties it does not load it's own and hence it is also
 necessary to define the other properties required to bootstrap
 quartz (just copy them across from the quartz.properties included
 in the quartz jar file).

One further option would be to update DefaultQuartzScheduler to read in 
a bunch of additional properties directly from the 
componentConfiguration file - these would be read in configure() and 
then applied via SchedulerFactory.initialize() after moving the 
instantiation of the scheduler there also (it is currently instantiated 
in service() which would be before the new properties would be 
available).  I think there would be a down side to this - you would 
again need to define all of the properties (the defaults would not be 
loaded) and you would lose the ability to override properties using 
system properties.


So the first two options work fine for now.  Does anyone feel that the 
third options should be implemented?


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Coding Specification - do we care?

2007-04-25 Thread Scott Eade

How strongly do you guys feel about coding standards?  Turbine has 
always had this: 
http://jakarta.apache.org/turbine/common/code-standards.html but we have 
a tonne of code that simply does not conform.


I guess I am in two minds about this.  On one hand I like to see 
consistently formatted code - it is just easier when it looks the same 
throughout a  codebase.  On the other hand, I don't see any of us with 
the luxury of time available to dedicate to this aspect of the project 
(i.e. one that doesn't really move us forward in any material way).


Corrective action has me in two minds also - we all most likely use 
IDE's that provide automated code formatting facilities, so it is not 
difficult to do, but on the other hand commits that do nothing but 
reformat code are a hassle when it comes to reviewing changes to code 
over time (IDE compare options that ignore whitespace changes go some of 
the way, but we do not always look at this via an IDE).


I guess my overriding consideration has to date been that contributors 
would be discouraged by a bunch of please reformat your code posts - 
hell, we need all the contributions we can get.


So does anybody feel strongly about this or should we just continue as 
we are now and just be happy to receive the commits?  If we were going 
to try to adhere to them more closely I would certainly want to review 
the 80 character line length standard - my monitors and printer can deal 
with just so much more.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRB-10) Make Intake file uploads work in 2 3 1

2007-04-24 Thread Scott Eade (JIRA)


[ 
https://issues.apache.org/jira/browse/TRB-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491154
 ] 

Scott Eade commented on TRB-10:
---

So 2.3 handles this correctly.  The fulcrum components are a little convoluted 
when it comes to ParameterParser, UploadService, etc.  The current situation is 
that fulcrum-parser's DefaultParameterParser checks if fulcrum-upload is 
configured and if so causes it to deal with any included files.  It does not 
however retain a record of the uploaded files, so once again, keySet() and 
containsKey() will not include FileItems.  These two supposedly independent 
components are reasonably tightly coupled (though parser can be used without 
upload) - it may make sense to tie them in a little further by having upload 
retain a record of the uploaded files in much the same way as in 2.3.

  Make Intake file uploads work in 2 3 1
 ---

 Key: TRB-10
 URL: https://issues.apache.org/jira/browse/TRB-10
 Project: Turbine
  Issue Type: Improvement
  Components: Fulcrum, Turbine 2.3
Affects Versions: Core 2.3.2
Reporter: Scott Eade
Priority: Minor

 init() in FileItemField invokes the parser's containsKey() method to 
 determine whether the incoming request contains a file item for the 
 FileItemField. The containsKey() method that gets invoked is inherited by 
 DefaultParameterParser from BaseValueParser and searches the parameters 
 attribute also inherited from BaseValueParser. However, file items are kept 
 in DefaultParameterParser's fileParameters attribute. Hence, containsKey() 
 never reports true for file items.
 My suggested fix is to simply add a containsKey() function to 
 DefaultParameterParser, which also searches fileParameters:
 public boolean containsKey(Object key)
 {
   return super.containsKey(key) || 
 fileParameters.containsKey(convert((String)key));
 }
 With this fix, file uploads for file upload fields marked as required work.
 Scarab issue TTWS65 was created by Thomas Lopatic (thomas at lopatic dot de).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SV: [DISCUSS] TLP?

2007-04-24 Thread Scott Eade


Martin Lidgard | Tibet Server wrote:

I would be interested in being a part of the PMC.  Our CMS uses Turbine and
our company would be willing to commit to supporting the continuing
development of Turbine. Please let me know in what way we could support the
project.
  

Hi Martin,

We are certainly interested in more people becoming involved in 
maintenance and future development of Turbine.  PMC members are elected 
from among the committers - becoming a committer is a reasonably 
straightforward process of contributing towards the project by way of 
fixes and enhancements to code and documentation.  We are always happy 
to accept these, and the existing PMC members (currently for Turbine 
this is the Jakarta PMC) pay attention to these contributions in order 
to assess when somebody has demonstrated their ability to work with the 
community in a cohesive fashion.  When this is the case the person 
involved will usually be invited to become a committer and continued 
involvement leads to being elected to the PMC.  For details see 
http://www.apache.org/foundation/how-it-works.html#roles


So for now we welcome your moral support, and we look forward to 
whatever level of commitment you are able to come through with in the 
future.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

fulcrum-hsqldb build failures

2007-04-24 Thread Scott Eade

fulcrum-hsqldb builds just fine on its own, but the test hangs when the 
reactor or gump is used.


For maven 1 I run 1.0.2 and I see that gump does also.  Looking at the 
stack trace when I interrupt the jvm (see below) it would appear that 
the problem has nothing to do with fulcrum-hsqldb.


Is anyone is running maven 1.1-rc1 or newer - I am wondering if this 
problem occurs with that.


Scott

-- JVM  stack trace follows --

Full thread dump Java HotSpot(TM) Client VM (1.5.0_09-b03 mixed mode):

Thread-54 daemon prio=6 tid=0x470305b8 nid=0x37b0 runnable 
[0x47e8f000..0x47e8fbe8]

   at java.io.FileInputStream.readBytes(Native Method)
   at java.io.FileInputStream.read(FileInputStream.java:177)
   at 
org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java:105)

   at java.lang.Thread.run(Thread.java:595)

Thread-53 daemon prio=6 tid=0x472a4c98 nid=0x2f04 runnable 
[0x47e4f000..0x47e4fb68]

   at java.io.FileInputStream.readBytes(Native Method)
   at java.io.FileInputStream.read(FileInputStream.java:194)
   at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
   at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
   at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
   - locked 0x02ae9170 (a java.io.BufferedInputStream)
   at java.io.FilterInputStream.read(FilterInputStream.java:90)
   at 
org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java:105)

   at java.lang.Thread.run(Thread.java:595)

Low Memory Detector daemon prio=6 tid=0x0096d7a0 nid=0x1040 runnable 
[0x..0x]


CompilerThread0 daemon prio=10 tid=0x0096c4a0 nid=0x1b94 waiting on 
condition [0x..0x46f6f848]


Signal Dispatcher daemon prio=10 tid=0x0096b750 nid=0x47d4 waiting on 
condition [0x..0x]


Finalizer daemon prio=8 tid=0x00962790 nid=0x2d8c in Object.wait() 
[0x46eef000..0x46eefc68]

   at java.lang.Object.wait(Native Method)
   - waiting on 0x078f9ad8 (a java.lang.ref.ReferenceQueue$Lock)
   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
   - locked 0x078f9ad8 (a java.lang.ref.ReferenceQueue$Lock)
   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
   at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

Reference Handler daemon prio=10 tid=0x00961328 nid=0x25d4 in 
Object.wait() [0x46eaf000..0x46eafce8]

   at java.lang.Object.wait(Native Method)
   - waiting on 0x078f9b58 (a java.lang.ref.Reference$Lock)
   at java.lang.Object.wait(Object.java:474)
   at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
   - locked 0x078f9b58 (a java.lang.ref.Reference$Lock)

main prio=6 tid=0x00037d68 nid=0x1b34 runnable [0x0007e000..0x0007fc3c]
   at java.lang.ProcessImpl.waitFor(Native Method)
   at org.apache.tools.ant.taskdefs.Execute.waitFor(Execute.java:466)
   at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:448)
   at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeAsForked(JUnitTask.java:685)
   at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:559)
   at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:532)

   at org.apache.tools.ant.Task.perform(Task.java:341)
   at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185)
   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
   at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
   at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)

   at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
   at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
   at 
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
   at 
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)

   at com.werken.werkz.Goal.fire(Goal.java:639)
   at com.werken.werkz.Goal.attain(Goal.java:575)
   at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
   at com.werken.werkz.Goal.attain(Goal.java:573)
   at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
   at com.werken.werkz.Goal.attain(Goal.java:573)
   at 
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)

   at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
   at 
org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:368)

   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
   at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
   at 
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
   at

[jira] Commented: (TRB-10) Make Intake file uploads work in 2 3 1

2007-04-24 Thread Scott Eade (JIRA)


[ 
https://issues.apache.org/jira/browse/TRB-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491311
 ] 

Scott Eade commented on TRB-10:
---

Okay, so I should run svn update before making that last comment.  
fulcrum-parser does now keep a record of the uploaded files, but these are 
intermingled with the rest of the parameters.  The remaining problem is that a 
getString() o(or for that matter a get() or a getParam()) for a file item 
results in a ClassCastException.  We either need to follow the turbine 2.3 
model of maintaining the list of uploads separately or ensure that getString() 
 getParam() cater for FileItems.  I will commit a failing test case for this.

  Make Intake file uploads work in 2 3 1
 ---

 Key: TRB-10
 URL: https://issues.apache.org/jira/browse/TRB-10
 Project: Turbine
  Issue Type: Improvement
  Components: Fulcrum, Turbine 2.3
Affects Versions: Core 2.3.2
Reporter: Scott Eade
Priority: Minor

 init() in FileItemField invokes the parser's containsKey() method to 
 determine whether the incoming request contains a file item for the 
 FileItemField. The containsKey() method that gets invoked is inherited by 
 DefaultParameterParser from BaseValueParser and searches the parameters 
 attribute also inherited from BaseValueParser. However, file items are kept 
 in DefaultParameterParser's fileParameters attribute. Hence, containsKey() 
 never reports true for file items.
 My suggested fix is to simply add a containsKey() function to 
 DefaultParameterParser, which also searches fileParameters:
 public boolean containsKey(Object key)
 {
   return super.containsKey(key) || 
 fileParameters.containsKey(convert((String)key));
 }
 With this fix, file uploads for file upload fields marked as required work.
 Scarab issue TTWS65 was created by Thomas Lopatic (thomas at lopatic dot de).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: [DISCUSS] migration to maven2

2007-04-23 Thread Scott Eade


Thomas Vandahl wrote:
I'd like to do a Turbine 2.3 branch release in the near future where I 
would not want to deal with a maven2 migration because that would 
delay things. Fulcrum is another story. +1 on this one, *after* the 
YAAFI release 1.0.5

I think this describes the most acceptable path forward.

Does anyone have a strong argument for not proceeding in this manner?

Scott


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

fulcrum-quartz configuration

2007-04-20 Thread Scott Eade

While debugging an unrelated issue I was forcing stack traces from 
tomcat via kill -3 (very useful).


This revealed a couple of issues with fulcrum-quartz.

1. By default there are 10 worker threads being initiated for 
DefaultQuartzScheduler - this is way more than are likely to be 
required.  The documentation 
(http://www.opensymphony.com/quartz/wikidocs/ConfigThreadPool.html) says 
If you only have a few jobs that fire a few times a day, then 1 thread 
is plenty!.  Tuning this should be a simple matter of configuring 
org.quartz.threadPool.threadCount = 1


2. The quartz threads are currently prefixed with 
DefaultQuartzScheduler - I have four webapps and I cannot tell which 
of the threads relates to which instance (44 threads in all due to issue 
1 described above).  Altering this should be a simple matter of 
configuring org.quartz.scheduler.threadName to be something environment 
specific rather than the default of: instanceName + 
'_QuartzSchedulerThread' (see: 
http://www.opensymphony.com/quartz/wikidocs/ConfigMain.html)  I am 
trusting that this will change the prefix of the worker threads also (4 
scheduler threads and 40 workers).


I haven't looked into the fulcrum end of this yet - I assume it that 
adding these will be a simple matter of updating the config in 
componentConfiguration.mxl - IOC and all that I imagine it it should be 
a piece of cake.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC - Releasing fulcrum-yaafi 1.0.5

2007-04-19 Thread Scott Eade


Siegfried Goeschl wrote:


I would like to release the current version of fulrum-yaafi-1.0.5-dev as 
1.0.5 to enable to commit my current refactoring.


The main problem is that fulcrum-yaafi got too fat over the time. The 
main task is to move he interceptor support into a seperate library 
exposing a ServiceManager only. This allows to support different 
implemenation and decoupling of the service framework, e.g. to use newer 
versions of JAMon.


+) Are there other requirements out there I'm not aware?
+) Any comments before I call a final vote?!


Hi Siegfried,

There are actually a few things that need to be done:
1. We need to CodeWrestle the licenses into order.
2. We need to produce the release distribution and site somewhere where 
we can see it so that we are actually voting on the end product
3. We have a vote and upon success notify the existing PMC and then 
deploy the distribution and site to the real location.


Scott


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: AW: RFC - Releasing fulcrum-yaafi 1.0.5

2007-04-19 Thread Scott Eade


Jürgen Hoffmann wrote:

Hi Siegfried,


I don't want to pack a small release together with a multi-project Maven
2 migration ... :-)


I could at least try, couldn't I? ;)
There is nothing stopping you from trying anything :) but Siegfried is 
obviously keen to get a release of Yaffi out and wants to avoid the 
potential delay that a relatively invasive change such as migrating the 
build system might cause.


I am inclined to agree that maven 2 has many advantages over maven 1 for 
a multiproject build like fulcrum, but I would prefer to see a little 
more discussion before we do so.  In particular, we should probably 
cover exactly what will be converted, by who and in what timeframe and 
most importantly the directory structure that will be used.


This is probably a good candidate for a small plan to be created in the 
Wiki.


It is great that both you and Siegfried are keen - let's just agree on a 
few details before we all unintentionally head off in different directions.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: [DISCUSS] TLP?

2007-04-18 Thread Scott Eade


Jürgen Hoffmann wrote:

Since Thomas is also on skype, Maybe we can have a little chat there too.
  

Or on irc://irc.freenode.net/turbine to allow others to participate.

Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DISCUSS] TLP?

2007-04-18 Thread Scott Eade


Scott Eade wrote:
Let's discuss this here before I go to the trouble of putting a proposal 
together.
Okay, so I think it would be fair to say that the discussion has all 
been pretty positive, and on the basis of this I have gone ahead and 
drafted a TLP proposal.


I used the Velocity TLP proposal as a template for this and I expect we 
will follow their lead for the rest of this process (thanks to Henning, 
Will and the Velocity crowd for their breadcrumbs).


As I see it the following issues are at hand:

* Decide on a VP and fill in the blank on the proposal.  I will gladly 
support anyone else that nominates themselves for this role, but will 
nominate myself in the absence of any other offers.


* Reading the Velocity TLP mail archive there was discussion concerning:
-- Dormancy.  This was dismissed fairly quickly, but similar arguments 
could be applied to Turbine.  At the end of the day we have a bunch of 
committers (including members) that are interested in seeing patches 
applied and continued incremental progress on Turbine and it's related 
Fulcrum components.
-- Possibility of developing into an Umbrella project.  We are not at 
present considering bringing anything else into the Turbine fold.  The 
strongest argument in this area would be the Fulcrum could spiral out of 
control.  The fact of the matter is that while the Fulcrum components 
target any implementation of the Avalon framework, for all intents and 
purposes they exist primarily to support Turbine so as to enable updates 
to the components to be decoupled from Turbine itself.  While there may 
be exceptions to this (Siegfried?) they are not so widely used that 
there is any risk of this getting out of control.
-- Future plans.  While we do occasionally discuss this, we should take 
advantage of the Wiki to document this a little better.  Again, the 
reality is that with limited time available we are progressing only 
slowly towards our next Turbine release.  I do not however feel that 
this is a problem - progress is being made and fixes are being 
backported to the 2.3 branch as necessary.


Hopefully the above comments should head off any objections to our 
moving forward, but different interpretations, discussion and new points 
are certainly welcome.


So let's quickly resolve the VP question, we will then be in a position 
to ping the [EMAIL PROTECTED] list informing them of our plan (this should 
hopefully pull in a few more votes and possibly PMC members) and to kick 
off a formal vote.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[DISCUSS] TLP?

2007-04-13 Thread Scott Eade

There are once again rumblings in Jakarta about the number of 
sub-projects and sub-sub-projects, their varying levels of 
activity/inactivity and whether or not the existing PMC is able to 
perform its obligations with respect to oversight.


While progress on Turbine may be slow, I believe that there are enough 
people that rely on it and want to see it actively maintained to enable 
us to put together a proposal to become a top level project (TLP) 
consisting of Turbine (including META) and Fulcrum.


What I would like to know is whether or not you would make yourself 
available to participate in a new Turbine Project Management Committee 
(PMC).  The PMC is ultimately responsible to the board of the ASF in 
terms of overseeing the project and ensuring that it fits within the 
goals and meets the requirements of the foundation.


What do you think?  Do you think we have the numbers to go TLP?  Would 
you be interested in being part of the initial PMC?


Let's discuss this here before I go to the trouble of putting a proposal 
together.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DISCUSS] TLP?

2007-04-13 Thread Scott Eade


Hi Will,

The level of participation you are offering would be fine - providing 
oversight such that we are able to maintain the necessary number of 
binding votes to keep things working is something we will need to 
demonstrate that we can do.


Scott

Will Glass-Husain wrote:

Hi Scott,

I rely heavily on Turbine, though silent on the mailing lists.  (I'm much
more active in the Velocity TLP).

I'd be willing to be on the PMC if it was helpful to keep the project 
alive,

though my involvement would likely be light -- e.g. related to oversight
rather than direct coding.  If that's not enough, then I'm happy to stay on
the developer lists and just contribute in discussion there.

WILL



On 4/13/07, Scott Eade [EMAIL PROTECTED] wrote:


There are once again rumblings in Jakarta about the number of
sub-projects and sub-sub-projects, their varying levels of
activity/inactivity and whether or not the existing PMC is able to
perform its obligations with respect to oversight.

While progress on Turbine may be slow, I believe that there are enough
people that rely on it and want to see it actively maintained to enable
us to put together a proposal to become a top level project (TLP)
consisting of Turbine (including META) and Fulcrum.

What I would like to know is whether or not you would make yourself
available to participate in a new Turbine Project Management Committee
(PMC).  The PMC is ultimately responsible to the board of the ASF in
terms of overseeing the project and ensuring that it fits within the
goals and meets the requirements of the foundation.

What do you think?  Do you think we have the numbers to go TLP?  Would
you be interested in being part of the initial PMC?

Let's discuss this here before I go to the trouble of putting a proposal
together.

Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]









-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRB-41) User/Group/Role and TorqueObject should be serializable

2007-03-14 Thread Scott Eade (JIRA)

[
https://issues.apache.org/jira/browse/TRB-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480734
]

Scott Eade commented on TRB-41:
---

I don't have any problem with you committing this to the 2.3 branch (nor
TRB-42) and I doubt that any of the others involved will either. Please go
ahead and do so.

Scott

User/Group/Role and TorqueObject should be serializable
---

Key: TRB-41
URL: https://issues.apache.org/jira/browse/TRB-41
Project: Turbine
Issue Type: Bug
Affects Versions: Core 2.3.2
Reporter: Will Glass-Husain
Attachments: serialize.patch

In Turbine 2.3.2, when I shut down/restart Tomcat I'm automatically logged
out. When I restart I get an exception on value.unbound() from the session.
(I'm using the Torque Security service.)
The problem is that TorqueUser is only partially serialized/deserialized.
Specfically the superclass TorqueObject is not serializable. The TorqueUser
is saved upon shutdown of Tomcat but the persistent object is not. Thus when
Tomcat starts back up the user is not logged in.
I've attached a patch that sets TorqueObject to be serializable. Also Group,
Role, and Permission. (This parallels User, which is already serializable,
and allows the AccessControlObject to be serialized).
I note that Turbine has been extensively restructured for 2.4. But I'd be
interested in seeing this patch be applied to the Turbine 2.3 branch. Would
anyone mind if I applied it?
(I'm a Jakarta and Velocity committer and long-term Turbine user. I think
some of my bug fixes back in 2002 made it into Turbine 2.3, but I've been in
stealth mode on the lists since).

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CfV: Jürgen Hoffmann for Turbine C ommittership

2006-11-06 Thread Scott Eade


Henning Schmiedehausen wrote:

[X] +1,Yes, Turbine needs more committers anyway
[ ]  0 I don't care
[ ] -1 No (please explain)
I wouldn't +1 merely because Turbine needs more committers - Jürgen has 
earned the right.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

TorqueSecurityService optimizations for 2.3.x

2006-08-21 Thread Scott Eade


My webapp runs Turbine 2.3.2 and uses the TorqueSecurityService.

While looking into an unrelated performance issue I finally got around 
to looking into why my SQL logs are always full of queries to the 
turbine security service tables.


Pretty much all of these can be eliminated by extending 
TorqueSecurityService thus:


package your.package.name.here.services.security.torque;

import org.apache.turbine.om.security.Role;
import org.apache.turbine.util.security.DataBackendException;
import org.apache.turbine.util.security.GroupSet;
import org.apache.turbine.util.security.PermissionSet;
import org.apache.turbine.util.security.RoleSet;
import org.apache.turbine.util.security.UnknownEntityException;

public class TorqueSecurityService extends
   org.apache.turbine.services.security.torque.TorqueSecurityService
{
   static GroupSet allGroups;
   static PermissionSet allPermissions;
   static RoleSet allRoles;
  
   public GroupSet getAllGroups() throws DataBackendException

   {
   if (null == allGroups)
   {
   allGroups = super.getAllGroups();
   }
   return allGroups;
   }

   public PermissionSet getAllPermissions() throws DataBackendException
   {
   if (null == allPermissions)
   {
   allPermissions = super.getAllPermissions();
   }
   return allPermissions;
   }

   public RoleSet getAllRoles() throws DataBackendException
   {
   if (null == allRoles)
   {
   allRoles = super.getAllRoles();
   }
   return allRoles;
   }

   public Role getRoleByName(String name)
   throws DataBackendException, UnknownEntityException
   {
   Role role = getAllRoles().getRoleByName(name);
   if (role == null)
   {
   throw new UnknownEntityException(
   The specified role does not exist);
   }
   PermissionSet permissions = null;
   try
   {
   permissions = role.getPermissions();
   }
   catch (Exception e)
   {
   // Not thrown for Torque, not sure about other implementations.
   }
   if (permissions == null)
   {
   role.setPermissions(getPermissions(role));
   }
   return role;
   }

   public Role getRoleById(int id)
   throws DataBackendException,
  UnknownEntityException
   {
   Role role = getAllRoles().getRoleById(id);
   if (role == null)
   {
   throw new UnknownEntityException(
   The specified role does not exist);
   }
   PermissionSet permissions = null;
   try
   {
   permissions = role.getPermissions();
   }
   catch (Exception e)
   {
   // Not thrown for Torque, not sure about other implementations.
   }
   if (permissions == null)
   {
   role.setPermissions(getPermissions(role));
   }
   return role;
   }

}


Don't forget to update TurbineResources.properties to point to your new 
SecurityService class.


Without the above change Turbine's ACLs would actually be mutable when 
according to the JavaDoc they should not be.


Apart from a very brief examination of the JavaDoc I haven't looked how 
this might apply to the trunk - IIRC the TorqueSecurityService is one of 
the items we need to address for a 2.4 release.  In the mean time, the 
code above can save a bunch of database hits on existing Turbine 2.3.x 
applications that use Torque.


Enjoy,

Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: my patches to the parser

2006-07-29 Thread Scott Eade


Hi Thomas (this is off-list),

Thanks for looking at this - I am totally snowed under here with my day 
(and night!) job.


Jürgen probably had the impression that the changes in T2.3 needed to be 
ported over to Fulcrum with no changes - enhancements/improvements are 
of course fine.  A change that breaks backward compatibility should 
however be noted in the change log (e.g. removal of support for 
DateSelector and TimeSelector).


My thanks to Jürgen and you for your effort on this.

Scott

Thomas Vandahl wrote:

Jürgen Hoffmann wrote:

Hi Scott,
Hi Thomas,

since you two seem to be the only two left active on the Project. Did 
you have a chance to lok at the patches I made to the fulcrum-parser 
at all?


Ok, here are my comments regarding the parser. They are not only about 
your patches but about the component in general.


- The components have some logic errors (see 
ParameterParser.setUploadData() or 
DefaultParameterParser.getRepository() for examples.


- In the BaseValueParser there is a lot of array copying going on. I 
don't believe that this is the smartest way to do things.


- The encapsulation of the components leaves much to be desired. See 
UploadService.getFileUpload() or the Exception types thrown.


- Please comment added methods and keep the indents. See 
UploadService.getAutomatic() and DefaultParameterParser.setRequest()


- I think that exposing the automatic setting is not a good idea. I 
would suggest moving it from the UploadService to the Parser anyway. 
The  upload service can't do something about automatic parsing at all. 
This is a configuration of the parser.


- The handling of the component dependencies is clumsy at best. I 
believe that the parser should work without an upload service installed.


- Strongly -1 against the inclusion of the DateSelector and 
TimeSelector classes. They are a relict of the stone age, add a 
unnecessary dependency on ECS and have nothing to do with the business 
logic layer.


I fixed some of the issues above and will commit the rest of it shortly.

Bye, Thomas.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[RESULT][VOTE] Thomas Vandahl as Committer on Jakarta Turbine

2006-07-04 Thread Scott Eade


A week has passed so here are the results:

+1: 5 binding (3 PMC) and 1 non-binding votes
Scott Eade (PMC)
Siegfried Goeschl (PMC)
Jeffery Painter
Frank-Matthias Kuschel (non-binding)
Peter Courcoux
Henning Schmiedehausen (PMC)

+0: none
-1: none

So the vote passes.

I will send a result message to the PMC list and request karma.

Welcome Thomas!

Scott

Scott Eade wrote:

I propose that Thomas Vandahl be made a committer to the Jakarta Turbine
project.

Note that Thomas is already a committer to the DB Torque project.

Here's a bit about Thomas:

I was born in 1969 in Vacha a small town in Thuringia, Germany. I 
studied semiconductor physics and electronics at the Technical 
University of Ilmenau, Germany, where I got my PhD in 1997.


I consider myself an old-school programmer, beginning with BASIC and 
Z80-Assembler in the 80s, continuing with Pascal, C (still my favorite), 
C++ and now settling with Java.


I work for TeWiSoft, a company providing web-based applications for 
office organization and communication.


I'm married and got two kids (a boy of 11 and a girl of 5). I like good 
wine, good food, cooking and my garden.



[ ] +1 yes, accept Thomas as a Jakarta Turbine committer
[ ] +0 don't care
[ ] -1 no, don't accept Thomas as a Jakarta Turbine committer

+1 from me.

Scott Eade




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

GroovyTest - OutOfMemoryException

2006-06-27 Thread Scott Eade

During my attempts at building the fulcrum site a came across a problem 
testing the Script component.


The problem is that testNamespaceDemo3 script that is executed from 
GroovyTest results in an OutOfMemoryException:



test:test:
[junit] Running org.apache.fulcrum.script.GroovyTest
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 5 sec
[junit] Exception in thread main java.lang.OutOfMemoryError: Java heap 
space
[junit] [ERROR] TEST org.apache.fulcrum.script.GroovyTest FAILED
[junit] Running org.apache.fulcrum.script.RhinoTest
[junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 12.125 sec

BUILD FAILED
File.. C:\Documents and 
Settings\seade\.maven\cache\maven-test-plugin-1.6.2\plugin.jelly
Element... fail
Line.. 181
Column 54
There were test failures.
Total time: 24 seconds
Finished at: Tue Jun 27 17:09:12 EST 2006


Does anyone (i.e. Siegfried) know enough about this to fix it.

Thanks,

Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: which version of torque?

2006-06-26 Thread Scott Eade


Jürgen Hoffmann wrote:
as seen on http://db.apache.org/torque/download.html torque 3.2 is released. 
Should Turbine 2.4 ship with torque 3.2 or 3.1.1? 
  
Where possible and appropriate we use the latest releases.  In this case 
3.2 would be the appropriate choice.


Scott

--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRB-28) bug in name on changes.xml

2006-06-26 Thread Scott Eade (JIRA)

 [ http://issues.apache.org/jira/browse/TRB-28?page=all ]
 
Scott Eade resolved TRB-28:
---

Resolution: Fixed
 Assign To: Scott Eade

Fixed.  Author tag appears to work okay.

 bug in name on changes.xml
 --

  Key: TRB-28
  URL: http://issues.apache.org/jira/browse/TRB-28
  Project: Turbine
 Type: Bug

   Components: Site
 Reporter: Jürgen Hoffmann
 Assignee: Scott Eade
 Priority: Trivial
  Attachments: patch-site.txt

 Error with my name ;) which hindered the creation of site. My name should not 
 cause problems here ;)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Thomas Vandahl as Committer on Jakarta Turbine

2006-06-26 Thread Scott Eade


I propose that Thomas Vandahl be made a committer to the Jakarta Turbine
project.

Note that Thomas is already a committer to the DB Torque project.

Here's a bit about Thomas:

I was born in 1969 in Vacha a small town in Thuringia, Germany. I studied 
semiconductor physics and electronics at the Technical University of Ilmenau, 
Germany, where I got my PhD in 1997.

I consider myself an old-school programmer, beginning with BASIC and 
Z80-Assembler in the 80s, continuing with Pascal, C (still my favorite), C++ 
and now settling with Java.

I work for TeWiSoft, a company providing web-based applications for office 
organization and communication.

I'm married and got two kids (a boy of 11 and a girl of 5). I like good wine, 
good food, cooking and my garden.


[ ] +1 yes, accept Thomas as a Jakarta Turbine committer
[ ] +0 don't care
[ ] -1 no, don't accept Thomas as a Jakarta Turbine committer

+1 from me.

Scott Eade



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TRB-10) Make Intake file uploads work in 2 3 1

 [ http://issues.apache.org/jira/browse/TRB-10?page=all ]

Scott Eade updated TRB-10:
--

Comment: was deleted

  Make Intake file uploads work in 2 3 1
 ---

  Key: TRB-10
  URL: http://issues.apache.org/jira/browse/TRB-10
  Project: Turbine
 Type: Improvement

   Components: Turbine 2.3, Fulcrum
 Versions: Core 2.3.2
 Reporter: Scott Eade
 Priority: Minor


 init() in FileItemField invokes the parser's containsKey() method to 
 determine whether the incoming request contains a file item for the 
 FileItemField. The containsKey() method that gets invoked is inherited by 
 DefaultParameterParser from BaseValueParser and searches the parameters 
 attribute also inherited from BaseValueParser. However, file items are kept 
 in DefaultParameterParser's fileParameters attribute. Hence, containsKey() 
 never reports true for file items.
 My suggested fix is to simply add a containsKey() function to 
 DefaultParameterParser, which also searches fileParameters:
 public boolean containsKey(Object key)
 {
   return super.containsKey(key) || 
 fileParameters.containsKey(convert((String)key));
 }
 With this fix, file uploads for file upload fields marked as required work.
 Scarab issue TTWS65 was created by Thomas Lopatic (thomas at lopatic dot de).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRB-10) Make Intake file uploads work in 2 3 1

[ http://issues.apache.org/jira/browse/TRB-10?page=comments#action_12417709 
] 

Scott Eade commented on TRB-10:
---

A bit of tangled history here.

When TTWS58 (from Scarab) was addressed the change suggested here was applied 
to DefaultParameterParser.  This was committed to the 2_3 branch (affected 
version should actually be 2.3.1), but it, and a bunch of other changes to 
DefaultParameterParser (et al), has not yet been ported across to the fulcrum 
parser code.

In addition to this, the additional DefaultParameterParserTest test case 
attached to TRB-8 illustrates a shortcoming in this solution - i.e. keySet() 
and containsKey() deal with the combined set of keys but getStrings() (and 
possibly other methods that are inherited from BaseValuePArser) do not.

So while in effect this patch has in fact been applied (at least to the 2_3 
branch), further work needs to be done to resolve inconsistent handling of keys 
in DefaultParameterParser and in porting the changes across to the fulcrum code 
base.


  Make Intake file uploads work in 2 3 1
 ---

  Key: TRB-10
  URL: http://issues.apache.org/jira/browse/TRB-10
  Project: Turbine
 Type: Improvement

   Components: Turbine 2.3, Fulcrum
 Versions: Core 2.3.2
 Reporter: Scott Eade
 Priority: Minor


 init() in FileItemField invokes the parser's containsKey() method to 
 determine whether the incoming request contains a file item for the 
 FileItemField. The containsKey() method that gets invoked is inherited by 
 DefaultParameterParser from BaseValueParser and searches the parameters 
 attribute also inherited from BaseValueParser. However, file items are kept 
 in DefaultParameterParser's fileParameters attribute. Hence, containsKey() 
 never reports true for file items.
 My suggested fix is to simply add a containsKey() function to 
 DefaultParameterParser, which also searches fileParameters:
 public boolean containsKey(Object key)
 {
   return super.containsKey(key) || 
 fileParameters.containsKey(convert((String)key));
 }
 With this fix, file uploads for file upload fields marked as required work.
 Scarab issue TTWS65 was created by Thomas Lopatic (thomas at lopatic dot de).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRB-8) Incorrect handling of a null return value

 [ http://issues.apache.org/jira/browse/TRB-8?page=all ]
 
Scott Eade resolved TRB-8:
--

Resolution: Fixed
 Assign To: Scott Eade

Patch committed.

Thanks.

 Incorrect handling of a null return value
 -

  Key: TRB-8
  URL: http://issues.apache.org/jira/browse/TRB-8
  Project: Turbine
 Type: Bug

   Components: Core
 Versions: Core 2.3.2
 Reporter: Gunther Olesch
 Assignee: Scott Eade
 Priority: Minor
  Attachments: npe_patch.txt, npe_patch.txt, test-TRB-8.txt

 I have found a bug within turbine 2.3.2 which results in a NullPointer to be 
 thrown within TemplateURI Line 274. 
 I found the Bug because I used $link.addPathInfo($data.getParameters()) which 
 takes all keys within the request, and adds the Keys and their values to the 
 link. The Problem is within getStrings(String key) which returns null of no 
 values are found. TemplateURI does not check the return value for null. I 
 have a patch ready.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Future of Turbine

2006-06-25 Thread Scott Eade


Peter Courcoux wrote:
My view and Eric's if I recall correctly was that turbine should 
ideally have service managers for Avalon, Spring, Hivemind, osgi etc, 
which would allow turbine users to take advantage of components from 
any of these sources, preferably wrapping all of these in some common 
lookup service which searched all the framework service managers for 
the required component.
Rather than 2.4 I think this could be a goal for turbine 2.6 - perhaps 
we should cal it turbine 4 (skipping 3 due to its historical baggage).


Clearly, the best bet is to have an Avalon Service Manager working, as 
this is the easiest way to maintain backwards compatibility. The 
others can be added as required.


Is there a document somewhere which explains the steps needed to 
replace ECM with YAAFI in a t2.4 application? I'm pleased to hear that 
you are successfully using YAAFI and I ought to try it out.
If we want to get 2.4 out the door in a reasonable timeframe we need to 
make some decisions and lay out some plans.  From what I can see the 
most important issues/steps to get us to 2.4 are:
1. Determine the service manager(s) that we will offer for 2.4 - 
compatibility is an excellent reason for sticking with an Avalon based 
implementation for this release and lack of available resources is a 
great justification for not opening the gates to all the other options 
(sure, lets do it, but not in this cycle).
2. Porting remaining 2_3 branch fixes and enhancements over to the trunk 
and fulcrum. This includes intake, parser, template and security.  The 
joy of fulcrum will be that these and the other fulcrum components can 
be released individually from one another.  Since code is available we 
should also provide for the AJAX support.
3. Generally making sure everything works (testing, bug fixes, 
documentation, etc.)


Jürgen is clearly interested in moving jumping in with maven 2 support, 
JMX support, etc.  These, along with the support of multiple service 
managers are great, but I think they would be best addressed as the next 
steps on from a 2.4 release.


I propose we work on items 1 and 2 above with a view to producing beta 
releases of 2.4 and the as yet unreleased fulcrum components.  Once we 
have these we can truly encourage the adventurous to adopt 2.4 and work 
on polishing things up for a final release.


Comments on the above and volunteers to work on outstanding issues are 
most welcome.


I intend nominating Jürgen and Thomas as committers in the near future 
(after following due process) so as to beef up the active committership.


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRB-26) WebWork is no longer supported

 [ http://issues.apache.org/jira/browse/TRB-26?page=all ]
 
Scott Eade resolved TRB-26:
---

Resolution: Fixed
 Assign To: Scott Eade

Patch applied.

Thanks.

 WebWork is no longer supported
 --

  Key: TRB-26
  URL: http://issues.apache.org/jira/browse/TRB-26
  Project: Turbine
 Type: Bug

   Components: Site
 Reporter: Jürgen Hoffmann
 Assignee: Scott Eade
  Attachments: patch-site.txt

 Removed a reference to webwork, which is no longer supported

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRB-9) Intake: Handling of empty values

 [ http://issues.apache.org/jira/browse/TRB-9?page=all ]
 
Scott Eade resolved TRB-9:
--

Resolution: Fixed

Patch applied.

Thanks.

 Intake: Handling of empty values
 

  Key: TRB-9
  URL: http://issues.apache.org/jira/browse/TRB-9
  Project: Turbine
 Type: Bug

   Components: Turbine 2.3
 Versions: Core 2.3.2
 Reporter: Stefan Broetz
 Priority: Blocker
  Attachments: patch_TRB-9.txt

 It seems to be impossible transmit the empty string as a value: In the HTTP 
 request
   http://.../turbine/...?aaa=123bbb=ccc=456
 the parameter bbb is ignored.
 If you look at 
 org.apache.turbine.services.intake.model.Field.init(ValueParser pp) you find:
 if (pp.containsKey(getKey()))
 {
 if (isDebugEnabled)
 {
 log.debug(name + : Found our Key in the request, setting 
 Value);
 }
 if (StringUtils.isNotEmpty(pp.getString(getKey(
 {
 setFlag = true;
 }
 validate();
 }
 else if (pp.containsKey(getValueIfAbsent()) 
 pp.getString(getValueIfAbsent()) != null)
 {
 pp.add(getKey(), pp.getString(getValueIfAbsent()));
 setFlag = true;
 validate();
 }
 The StringUtils.isNotEmpty() condition (line 342) prevents that a field can 
 take up the empty string as its value.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRB-17) Avalon component JCSCacheService

[ http://issues.apache.org/jira/browse/TRB-17?page=comments#action_12417715 
] 

Scott Eade commented on TRB-17:
---

I was hoping to commit this without too much trouble, but when I attempt to run 
the tests I get a bunch of errors Could not initialize the container - is 
there something missing from the patch file?

 Avalon component JCSCacheService
 

  Key: TRB-17
  URL: http://issues.apache.org/jira/browse/TRB-17
  Project: Turbine
 Type: New Feature

   Components: Fulcrum
 Reporter: Thomas Vandahl
  Attachments: fulcrum-jcs-cache.diff

 This is a patch for the Fulcrum cache component which implements the 
 GlobalCacheService with JCS. Documentation update and test case are also 
 contained.
 Unfortunately this is based on JCS 2003.something, which is the only version 
 officially available from ibiblio. The newer versions need to be fetched from 
 SVN. This service has been tested against a 1.2.7.0 build and works fine. If 
 JCS 1.3 is released, some calls to deprecated methods need to be changed and 
 I guess it would be possible to replace the refresh thread with some event 
 handler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRB-19) Extend Fulcrum XSLT Service

 [ http://issues.apache.org/jira/browse/TRB-19?page=all ]
 
Scott Eade resolved TRB-19:
---

Resolution: Fixed
 Assign To: Scott Eade

Patch applied.
I corrected the copyright dates and added an entry to changes.xml - if you can 
do this in the future it would be helpful.
I also bumped the version to 1.0.4-dev (perhaps this should be 1.1 for a 
release).

Thanks.

 Extend Fulcrum XSLT Service
 ---

  Key: TRB-19
  URL: http://issues.apache.org/jira/browse/TRB-19
  Project: Turbine
 Type: Improvement

   Components: Fulcrum
 Reporter: Thomas Vandahl
 Assignee: Scott Eade
  Attachments: fulcrum-xslt.diff

 I ported my changes to the TurbineXSLTService over to Fulcrum.
 This is what I did:
 - Get rid of direct File() access in DefaultXSLTService and replace it with 
 URL access. The change also allows to place the repository of XSL files 
 elsewhere. You can, for example, define your style sheet path as 
 http://style.acme.com/;
 - Add transform() methods having an additional parameter to forward a 
 parameter set to the XSLT. The parameters can be used in the style sheet.
 - Addition of several JavaDocs
 - Code formatting
 - Fixed visibility issues
 The Turbine 2.3.2 code base has additionally
 - Replace the cache Map() with a LRUMap() to avoid infinite memory growth
 I did not want to add a dependency on commons-collections just for this only 
 purpose, so I left that out.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Future of Turbine

2006-06-24 Thread Scott Eade


Scott Eade wrote:
I order to move forward what is really needed is for some adventurous 
people to migrate forward to 2.4 - I would think that the major 
refactoring and architectural changes intended for 2.4 final have been 
completed, it is now a matter of tidying up any loose ends, finding 
bugs, updating documentation, etc.  People that adopt 2.4 (even the 
2.4 milestone 1 release) can contribute to this process without regard 
to the 2.3 branch.

...
Remember of course however that 2.4 is not yet released - if that kind 
of thing bothers you then stick with 2.3.2.  If you are going to the 
trouble of addressing issues in 2.3.x however you probably have the 
skills necessary to provide your own support (with the help of the 
list) for the unreleased 2.4.

A further word of caution.

2.4-m1 includes the code extracted into the yet to be released fulcrum 
Intake, Parser and Template components (these were apparently created 
after 2.4-m1).


Someone needs update these three components to the same level as that in 
the 2.3 branch before they can be relied upon.


In effect a turbine 2.4 release would require the release of these three 
components as a prerequisite.


Scott


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: stupid question about site

2006-06-24 Thread Scott Eade


Jürgen Hoffmann wrote:
I was just about reading off onto t2.4 branch and reading 
http://jakarta.apache.org/turbine/turbine/turbine-2.4-M1/index.html I saw 
that there was a reference to the TDK and that the Maven Plugin is dead... So 
I checked out trunk and wanted to fix it there... But to my surprise Scott 
already did so...


How long does it take for these changes to be brought up on the live server?
  
The trunk was updated, so only the 2.4 development site is updated: 
http://jakarta.apache.org/turbine/turbine/development/turbine-2.4/index.html


Scott

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRB-16) TemplateURI mishandles the empty String

 [ http://issues.apache.org/jira/browse/TRB-16?page=all ]
 
Scott Eade resolved TRB-16:
---

Resolution: Fixed
 Assign To: Scott Eade

The existing behaviour for null is retained - after all null != .
An empty String is now retained as such.
Thanks for your patch.

 TemplateURI mishandles the empty String
 ---

  Key: TRB-16
  URL: http://issues.apache.org/jira/browse/TRB-16
  Project: Turbine
 Type: Bug

   Components: Turbine 2.3
 Versions: Core 2.3.2
 Reporter: Jürgen Hoffmann
 Assignee: Scott Eade
  Attachments: patch-TRB-16-t2.4.txt, patch-TRB-16.txt

 If you pass a value of  TemplateURI adds the value null instead. This 
 makes it hard to evaluate the passed value, and which is definetly unwanted 
 behaviour.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TRB-16) TurbineURI mishandles the empty String

 [ http://issues.apache.org/jira/browse/TRB-16?page=all ]

Scott Eade updated TRB-16:
--

Summary: TurbineURI mishandles the empty String  (was: TemplateURI 
mishandles the empty String)

 TurbineURI mishandles the empty String
 --

  Key: TRB-16
  URL: http://issues.apache.org/jira/browse/TRB-16
  Project: Turbine
 Type: Bug

   Components: Turbine 2.3
 Versions: Core 2.3.2
 Reporter: Jürgen Hoffmann
 Assignee: Scott Eade
  Attachments: patch-TRB-16-t2.4.txt, patch-TRB-16.txt

 If you pass a value of  TemplateURI adds the value null instead. This 
 makes it hard to evaluate the passed value, and which is definetly unwanted 
 behaviour.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TRB-16) TurbineURI mishandles the empty String

 [ http://issues.apache.org/jira/browse/TRB-16?page=all ]

Scott Eade updated TRB-16:
--

Description: If you pass a value of  TurbineURI adds the value null 
instead. This makes it hard to evaluate the passed value, and which is 
definetly unwanted behaviour.  (was: If you pass a value of  TemplateURI adds 
the value null instead. This makes it hard to evaluate the passed value, and 
which is definetly unwanted behaviour.)

Corrected the title and description so as to avoid confusion.

 TurbineURI mishandles the empty String
 --

  Key: TRB-16
  URL: http://issues.apache.org/jira/browse/TRB-16
  Project: Turbine
 Type: Bug

   Components: Turbine 2.3
 Versions: Core 2.3.2
 Reporter: Jürgen Hoffmann
 Assignee: Scott Eade
  Attachments: patch-TRB-16-t2.4.txt, patch-TRB-16.txt

 If you pass a value of  TurbineURI adds the value null instead. This 
 makes it hard to evaluate the passed value, and which is definetly unwanted 
 behaviour.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRB-8) Incorrect handling of a null return value

[ http://issues.apache.org/jira/browse/TRB-8?page=comments#action_12417430 
] 

Scott Eade commented on TRB-8:
--

I added a coupld of test cases to TurbineURITest in the 2.3 branch to try and 
catch this problem but my tests pass.

Under what circumstances would pp.getStrings(key) return null?

 Incorrect handling of a null return value
 -

  Key: TRB-8
  URL: http://issues.apache.org/jira/browse/TRB-8
  Project: Turbine
 Type: Bug

   Components: Core
 Versions: Core 2.3.2
 Reporter: Gunther Olesch
 Priority: Minor
  Attachments: npe_patch.txt, npe_patch.txt

 I have found a bug within turbine 2.3.2 which results in a NullPointer to be 
 thrown within TemplateURI Line 274. 
 I found the Bug because I used $link.addPathInfo($data.getParameters()) which 
 takes all keys within the request, and adds the Keys and their values to the 
 link. The Problem is within getStrings(String key) which returns null of no 
 values are found. TemplateURI does not check the return value for null. I 
 have a patch ready.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRB-8) Incorrect handling of a null return value

[ http://issues.apache.org/jira/browse/TRB-8?page=comments#action_12417471 
] 

Scott Eade commented on TRB-8:
--

The test case you have added seems to be for an unrelated ussue (take a look at 
TRB-10).

Scott

 Incorrect handling of a null return value
 -

  Key: TRB-8
  URL: http://issues.apache.org/jira/browse/TRB-8
  Project: Turbine
 Type: Bug

   Components: Core
 Versions: Core 2.3.2
 Reporter: Gunther Olesch
 Priority: Minor
  Attachments: npe_patch.txt, npe_patch.txt, test-TRB-8.txt

 I have found a bug within turbine 2.3.2 which results in a NullPointer to be 
 thrown within TemplateURI Line 274. 
 I found the Bug because I used $link.addPathInfo($data.getParameters()) which 
 takes all keys within the request, and adds the Keys and their values to the 
 link. The Problem is within getStrings(String key) which returns null of no 
 values are found. TemplateURI does not check the return value for null. I 
 have a patch ready.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRB-10) Make Intake file uploads work in 2 3 1

[ http://issues.apache.org/jira/browse/TRB-10?page=comments#action_12417475 
] 

Scott Eade commented on TRB-10:
---

A bit of tangled history here.

When TTWS65 (from Scarab) was addressed the change was exactly the one 
suggested by this issue.  It was committed to the 2.3 branch (affected version 
should actually be 2.3.1).  But, it has not yet been ported across to the 
fulcrum parser code.

In addition to this, the test case attached to TRB-8 (doesn't quite seem to 
relate to TRB-8) is illustrating a possible shortcoming in the currently 
implemented solution.

  Make Intake file uploads work in 2 3 1
 ---

  Key: TRB-10
  URL: http://issues.apache.org/jira/browse/TRB-10
  Project: Turbine
 Type: Improvement

   Components: Turbine 2.3, Fulcrum
 Versions: Core 2.3.2
 Reporter: Scott Eade
 Priority: Minor


 init() in FileItemField invokes the parser's containsKey() method to 
 determine whether the incoming request contains a file item for the 
 FileItemField. The containsKey() method that gets invoked is inherited by 
 DefaultParameterParser from BaseValueParser and searches the parameters 
 attribute also inherited from BaseValueParser. However, file items are kept 
 in DefaultParameterParser's fileParameters attribute. Hence, containsKey() 
 never reports true for file items.
 My suggested fix is to simply add a containsKey() function to 
 DefaultParameterParser, which also searches fileParameters:
 public boolean containsKey(Object key)
 {
   return super.containsKey(key) || 
 fileParameters.containsKey(convert((String)key));
 }
 With this fix, file uploads for file upload fields marked as required work.
 Scarab issue TTWS65 was created by Thomas Lopatic (thomas at lopatic dot de).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Future of Turbine

2006-06-23 Thread Scott Eade


I would say that the future is clearly 2.4 (i.e. svn trunk) and fulcrum.

Your frustration stems from the fact that you are attempting to address 
issues you have identified in 2.3.x - in order to resolve the issues for 
your application you need to patch the 2.3 branch.  If you submit a 
patch to 2.3 without regard to future releases (i.e. 2.4 and fulcrum) 
that is fine - _if_ a committer decides to use some of their time to 
commit your patch they will hopefully consider the trunk and address the 
issue there too (of course if you do consider the future and provide 
patches accordingly there will be a greater chance that a committer will 
apply them).


I order to move forward what is really needed is for some adventurous 
people to migrate forward to 2.4 - I would think that the major 
refactoring and architectural changes intended for 2.4 final have been 
completed, it is now a matter of tidying up any loose ends, finding 
bugs, updating documentation, etc.  People that adopt 2.4 (even the 2.4 
milestone 1 release) can contribute to this process without regard to 
the 2.3 branch.


Will there be a 2.3.3 release?  Well that would require one or more 
committers with the need and motivation to produce it to step forward.  
More likely committers will be interested in polishing off 2.4.


I too have implemented AJAX support using JSON 1.0 for 2.3.x - my 
intention would however be to move my application forward to 2.4 and 
provide the implementation for 2.4.  If we can induce people to move up 
to 2.4 then we reduce the problem of also having to maintain the old branch.


Remember of course however that 2.4 is not yet released - if that kind 
of thing bothers you then stick with 2.3.2.  If you are going to the 
trouble of addressing issues in 2.3.x however you probably have the 
skills necessary to provide your own support (with the help of the list) 
for the unreleased 2.4.


For Turbine to move forward it needs people to step forward.  If there 
is little activity from existing committers then we need new people to 
step forward - provide a few patches, have them accepted and committed 
and you will most likely be voted in as a committer.  It is a bit of a 
catch-22 - if there is little activity from committers it is usually 
difficult to attract new committers.  If people want Turbine to move 
forward they will need to contribute - on mailing lists, patches to the 
trunk including documentation, supporting others that show an interest, etc.


There are certainly at least a couple of people contributing patches at 
present - they are firm candidates for becoming committers without too 
much delay (though of course an existing committer at least has to 
review and apply patches and provide guidance as to the way things work 
at the ASF).


Keep the patches coming.  Migrate to 2.4 if you can.  Let's crank this 
Turbine up again :-)


Scott

Jürgen Hoffmann wrote:

Hi All,

since Development on Turbine is stalling a bit, I am asking the folks who know 
best :) What is the future of Turbine? is it the t2.3.2 branch, or the 2.4 
branch with pipelining support? 

Is it the t2.3.2 branch with fulcrum components? Questions over questions. 
From my understanding there are 2 parties. One using happily 2.3.2 and one 
using 2.4 happily. Do I see this wrong? Where are the points at which these 
two could merge together, and what would be next? t2.5 or rather turbine3? 


when someone contributes to the codebase, where is it to be done best?

Turbine has in my eyes so many features, that other popular frameworks lack. 
But has some major disadvantages. One of them is lacking AJAX support. We 
have used json 1.0 in some of our projects and are very happy with it. I 
would be willing to again contribute the JSON Screen, that we have developped 
for that and which is based upon the link found at the wiki... Another is 
Lack of RAD Tools Support, and a centralized Page Authorization Concept 
(correct me if i am wrong).


I just want to minimize my effort in integrating this into 3 different 
codebases all the time. So what I really want to start is development into 
turbines future again and make people use this great framework more.


Kind regards

Juergen Hoffmann
  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRB-14) Intake fails to load correct Default Validators if rules are empty

2006-06-22 Thread Scott Eade (JIRA)

 [ http://issues.apache.org/jira/browse/TRB-14?page=all ]
 
Scott Eade resolved TRB-14:
---

Resolution: Fixed
 Assign To: Scott Eade

Patch applied to fulcrum trunk and turbine 3.2 branch.

 Intake fails to load correct Default Validators if rules are empty
 --

  Key: TRB-14
  URL: http://issues.apache.org/jira/browse/TRB-14
  Project: Turbine
 Type: Bug

   Components: Turbine 2.3
  Environment: - Ubuntu Dapper Drake 6.06 LTS
 - Tomcat 5.5.12
 - Turbine 2.3.2
 Reporter: Jürgen Hoffmann
 Assignee: Scott Eade
  Attachments: patch-TRB-14.txt, patch-fulcrum-TRB-14.txt

 If the rules for an unrequired field are empty, the Default Validator is not 
 loaded correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRB-9) Intake: Handling of empty values

2006-06-22 Thread Scott Eade (JIRA)

[ http://issues.apache.org/jira/browse/TRB-9?page=comments#action_12417424 
] 

Scott Eade commented on TRB-9:
--

Is the attached patch solving one or two problems?

The change:
-if (StringUtils.isNotEmpty(pp.getString(getKey(
+if (pp.getString(getKey()) != null)
would appear to address this issue, but the changes concerning setter.invoke() 
appear to be addressing a different problem.

It isn't really a problem, but I would at least like to be able to more 
accurately describe what is being addressed in the change log and the commit 
message.

 Intake: Handling of empty values
 

  Key: TRB-9
  URL: http://issues.apache.org/jira/browse/TRB-9
  Project: Turbine
 Type: Bug

   Components: Turbine 2.3
 Versions: Core 2.3.2
 Reporter: Stefan Broetz
 Priority: Blocker
  Attachments: patch_TRB-9.txt

 It seems to be impossible transmit the empty string as a value: In the HTTP 
 request
   http://.../turbine/...?aaa=123bbb=ccc=456
 the parameter bbb is ignored.
 If you look at 
 org.apache.turbine.services.intake.model.Field.init(ValueParser pp) you find:
 if (pp.containsKey(getKey()))
 {
 if (isDebugEnabled)
 {
 log.debug(name + : Found our Key in the request, setting 
 Value);
 }
 if (StringUtils.isNotEmpty(pp.getString(getKey(
 {
 setFlag = true;
 }
 validate();
 }
 else if (pp.containsKey(getValueIfAbsent()) 
 pp.getString(getValueIfAbsent()) != null)
 {
 pp.add(getKey(), pp.getString(getValueIfAbsent()));
 setFlag = true;
 validate();
 }
 The StringUtils.isNotEmpty() condition (line 342) prevents that a field can 
 take up the empty string as its value.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[SOURCE] Issue #FULS4 modified

2006-06-20 Thread Scott Eade

You can view the issue detail at the following URL:

http://issues.apache.org/scarab/issues/id/FULS4

Type
 Patch

Issue ID
 FULS4 (Intake, mapToObject, and using Interfaces)

Modified by
 Scott Eade
 [EMAIL PROTECTED] ([EMAIL PROTECTED])

The following modifications were made to this issue:
-

Status set to Closed
Resolution set to Moved

Reason:
Moved to: http://issues.apache.org/jira/browse/TRB-11

-
This message is automatically generated by the Scarab
issue tracking system.  For more information:
http://scarab.tigris.org/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TRB-11) Intake, mapToObject, and using Interfaces

Intake, mapToObject, and using Interfaces
-

 Key: TRB-11
 URL: http://issues.apache.org/jira/browse/TRB-11
 Project: Turbine
Type: Improvement

  Components: Fulcrum  
 Environment: PC / RedHat
Reporter: Scott Eade
Priority: Minor
 Attachments: Group.interfaces.diffs

This is/was bugzilla bug #12661. Moving it to Scarab.

Short version: Intake won't use interfaces for the mapTo 
Attached is a patch that provides this.

Details:

I've been using Intake quite successfully until a recent change I
 made in my code. The mapTo object is a configuration object that
 does the PropertyChange and VetoableChange JavaBean pattern and it
 got rather tedious. So I switched to using an dynamic Proxy
(java.lang.reflect.Proxy). Testing with regular Java classes it works
great.

Following the code, Intake.mapTo(Retrievable) uses the Retrievable's
classname (and superclasses) as the key into a Map for fields (and
ultimately their setter/getters. The dynamic Proxy is initialized by
providing an interface. Sun's implementation in the JDK auto-creates
a new class that implements the interface as well as extending Object
while naming the class Proxy0 (as in zero, not oh). Therefore, the
proxied object ends up with a name not known to Intake yet
implementing an interface. So Group.init(Retrievable)'s logic of
chasing the classes and superclasses won't find any fields for the
class.

Wow, from bugzilla to Scarab to JIRA.  Issue raised by Evan Koffler ([EMAIL 
PROTECTED]).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TRB-11) Intake, mapToObject, and using Interfaces

 [ http://issues.apache.org/jira/browse/TRB-11?page=all ]

Scott Eade updated TRB-11:
--

Attachment: Group.interfaces.diffs

 Intake, mapToObject, and using Interfaces
 -

  Key: TRB-11
  URL: http://issues.apache.org/jira/browse/TRB-11
  Project: Turbine
 Type: Improvement

   Components: Fulcrum
  Environment: PC / RedHat
 Reporter: Scott Eade
 Priority: Minor
  Attachments: Group.interfaces.diffs

 This is/was bugzilla bug #12661. Moving it to Scarab.
 Short version: Intake won't use interfaces for the mapTo 
 Attached is a patch that provides this.
 Details:
 I've been using Intake quite successfully until a recent change I
  made in my code. The mapTo object is a configuration object that
  does the PropertyChange and VetoableChange JavaBean pattern and it
  got rather tedious. So I switched to using an dynamic Proxy
 (java.lang.reflect.Proxy). Testing with regular Java classes it works
 great.
 Following the code, Intake.mapTo(Retrievable) uses the Retrievable's
 classname (and superclasses) as the key into a Map for fields (and
 ultimately their setter/getters. The dynamic Proxy is initialized by
 providing an interface. Sun's implementation in the JDK auto-creates
 a new class that implements the interface as well as extending Object
 while naming the class Proxy0 (as in zero, not oh). Therefore, the
 proxied object ends up with a name not known to Intake yet
 implementing an interface. So Group.init(Retrievable)'s logic of
 chasing the classes and superclasses won't find any fields for the
 class.
 Wow, from bugzilla to Scarab to JIRA.  Issue raised by Evan Koffler ([EMAIL 
 PROTECTED]).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TRB-12) Allow TemplateEmail to BCC also.

Allow TemplateEmail to BCC also.


 Key: TRB-12
 URL: http://issues.apache.org/jira/browse/TRB-12
 Project: Turbine
Type: Improvement

  Components: Fulcrum  
Reporter: Scott Eade
Priority: Minor
 Attachments: email.diff

I'm unable to easily compile to completely test this - I'm on a windows system 
and have not been able to get maven running properly.  But I think that the 
attached patch will add bcc capabilities to TemplateEmail.

Scarab issue was raised by thierry lach (thierry dot lach at bbdodetroit dot 
com).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TRB-12) Allow TemplateEmail to BCC also.