Re: [Fulcrum] security/torque is broken ....
Siegfried Goeschl wrote: the last fix wfor HsqlDB.java as probably not successful - you have to parse any SQL file and execute individual SQL statements. As I mentioned early I made the same mistake (plus two more) a while ago for a customer project. It works for me (TM). I ran the tests successfully. What doesn't work? A few idea +) can we use the fulcrum-hsqldb component to run the database (avoid code duplication eat your own dog food) +1 As you are at it, could you please have a look at the gump-build problems that the component has? +) I might crank out a fulcrum-sqlscript service tonight (unfortunatly this is the most boring work on the planet - how many thousands similiar thingies were written on this planet) +0 The maven-torque-plugin could do this. I'll try if that works. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Fulcrum Components need real/official maintainers ...
Siegfried Goeschl wrote: Hi folks, going TLP forces us to do many sensible and good things. On the top of my list is to find caring parents for a couple of Fulcrum Components (the more the better because we need at least one maintainer per component) My initial list of components I wrote or able to maintain properly bsf - ??? cache - ??? tv commonsemail - sgoeschl configuration - ??? tv crypto - ??? dvsl - ??? factory - ??? tv groovy - sgoeschl hsqldb - sgoeschl intake - ??? tv localization - ??? tv mimetype - ??? naming - ??? osworkflow - ??? parser - ??? tv pbe - sgoeschl pool - ??? quartz - sgoeschl resourcemanager - sgoeschl script - sgoeschl security - ??? tv template - ??? (tv) testcontainer - sgoeschl upload - ??? xmlrpc - sgoeschl xslt - sgoeschl yaafi - sgoeschl Wouldn't that make a good Wiki page? Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fulcrum Site Preview available ....
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?
Siegfried Goeschl wrote: I would like to avoid being pinged by little fellows called Marvin ... :-) Oh God, I'm so depressed. And then of course I've got this terrible pain in all the diodes down my left hand side... Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r540571 - in /jakarta/turbine/fulcrum/trunk/security/adapters/turbine/src/test: componentTurbineConfiguration.xml componentTurbineConfigurationBasicModel.xml
[EMAIL PROTECTED] wrote: Author: sgoeschl Date: Tue May 22 06:04:54 2007 New Revision: 540571 URL: http://svn.apache.org/viewvc?view=revrev=540571 Log: Mhmm, some new classes from fulcrum-security-api-1.0.8-dev were referenced so this could shouldn't work at all. Reverted to 1.0.7 class names to fix the tests. Grrr. All security implementations should use the 1.0.8-dev classes. I'm just trying to update things the other way round. However Maven just stopped to lookup the turbine-repo for me. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r540571 - in /jakarta/turbine/fulcrum/trunk/security/adapters/turbine/src/test: componentTurbineConfiguration.xml componentTurbineConfigurationBasicModel.xml
Hi Siegfried, Siegfried Goeschl wrote: correct me if I'm wrong - those activities took in the beginning of April. So this code was broken for 6 weeks and therefore in my way to fix the Fulcrum build. Mea culpa, mea maxima culpa. Sorry for that. Actually, the Fulcrum tree never built fully on me, so I didn't care too much. I promise to fix it. Regarding Maven - I experience the same problem and can't build the fulcrum site - OutOfMemory. Setting MAVEN_OPTS=-Xmx1024m doesn't help? Don't know if I waste more time on M1 ... I'm not sure if you're better off with m2, based on the things I hear... Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Turbine is TLP :)
Martin van den Bemt wrote: Hi everyone, In case you haven't heard already : the TLP request passed at the board meeting... Great. Thanks to all who made this happen. What are the next steps? Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TRB-45) Create turbine.apache.org
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] Created: (TRB-46) Move mailing lists to turbine.apache.org
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 -- 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] Created: (TRB-48) Get a Solaris zone for Turbine
Get a Solaris zone for Turbine -- Key: TRB-48 URL: https://issues.apache.org/jira/browse/TRB-48 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] Created: (TRB-47) Create wrapper site for turbine.apache.org
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] Created: (TRB-51) Move SVN
Move SVN 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] Created: (TRB-50) Make the Jakarta site .htaccess change in svn to redirect to the new tlp
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 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] Created: (TRB-52) Remove Turbine from Jakarta site
Remove Turbine from Jakarta site Key: TRB-52 URL: https://issues.apache.org/jira/browse/TRB-52 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] Created: (TRB-53) Get a Turbine commits list
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 -- 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] Created: (TRB-54) Repair Gump to send notifications to the right email address
Repair Gump to send notifications to the right email address Key: TRB-54 URL: https://issues.apache.org/jira/browse/TRB-54 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] Created: (TRB-55) Update JIRA to send notifications to turbine-commits
Update JIRA to send notifications to turbine-commits Key: TRB-55 URL: https://issues.apache.org/jira/browse/TRB-55 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] Created: (TRB-57) Get private@ added to pmcs@
Get private@ added to pmcs@ --- Key: TRB-57 URL: https://issues.apache.org/jira/browse/TRB-57 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] Created: (TRB-56) Update SVN to send commits to turbine-commits
Update SVN to send commits to turbine-commits - Key: TRB-56 URL: https://issues.apache.org/jira/browse/TRB-56 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] Created: (TRB-58) Add Scott to list of chairs
Add Scott to list of chairs --- Key: TRB-58 URL: https://issues.apache.org/jira/browse/TRB-58 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] Created: (TRB-59) Update committee-info.txt
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]
[jira] Created: (TRB-60) Create new JIRA group
Create new JIRA group - Key: TRB-60 URL: https://issues.apache.org/jira/browse/TRB-60 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] Created: (TRB-61) List new mailing lists on web site
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 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] Created: (TRB-62) Create new Turbine download page
Create new Turbine download page Key: TRB-62 URL: https://issues.apache.org/jira/browse/TRB-62 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] Created: (TRB-63) Reflect the new locations in the POM(s)
Reflect the new locations in the POM(s) --- Key: TRB-63 URL: https://issues.apache.org/jira/browse/TRB-63 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]
Re: Turbine is TLP :)
Scott Eade wrote: 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. Done. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: intake blues
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. 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. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StringTool anyone?
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. 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? Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deprecations
Scott Eade wrote: I am unsure about the three xmlrpc classes, but I believe the rest should go. From what I know, these are mere examples of how to use the service and should not have been there in the first place. I'll ask Siegfried, he may know. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deprecations
Thomas Vandahl wrote: Scott Eade wrote: I am unsure about the three xmlrpc classes, but I believe the rest should go. From what I know, these are mere examples of how to use the service and should not have been there in the first place. I'll ask Siegfried, he may know. For the record, Siegfried suggested to put these into some contrib directory and mark them as examples in the docs. I second this. I will therefore not remove them right now. Bye, Thomas. - 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
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. Bye, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deprecations
Scott Eade wrote: 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. I tried to compile a list of all deprecated classes left in the 2.3 brnach and came up with this: org.apache.turbine.modules.layouts.DefaultLayout org.apache.turbine.modules.layouts.VelocityECSLayout org.apache.turbine.modules.navigations.DefaultTopNavigation org.apache.turbine.modules.navigations.DefaultBottomNavigation org.apache.turbine.services.pull.tools.RelativeTemplateLink org.apache.turbine.services.pull.tools.TemplateLinkWithSlash org.apache.turbine.services.xmlrpc.util.AuthenticatedFileHandler org.apache.turbine.services.xmlrpc.util.FileHandler org.apache.turbine.services.xmlrpc.util.FileTransfer org.apache.turbine.util.template.RelativeTemplateLink org.apache.turbine.util.template.TemplateLink org.apache.turbine.util.template.TemplateLinkWithSlash org.apache.turbine.util.template.TemplatePageAttributes org.apache.turbine.util.ContentURI org.apache.turbine.util.CookieParser org.apache.turbine.util.CSVParser org.apache.turbine.util.DataStreamParser org.apache.turbine.util.DynamicURI org.apache.turbine.util.ParameterParser org.apache.turbine.util.RelativeDynamicURI org.apache.turbine.util.RunDataFactory org.apache.turbine.util.StringUtils org.apache.turbine.util.TSVParser org.apache.turbine.util.ValueParser Should they go? Bye, Thomas. - 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
Intermediate Status report: Scott Eade wrote: * Delete the classes I noted in my recent post Done for the first part, see the list of my further candidates in the list. * 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? * 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. * Delete the additional list of packages that Thomas posted a short time ago Done. * 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. * 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. * CodeWrestle the necessary license changes into the 2.3 branch Done. 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). More: - Deprecated the DBSecurityService. - Compiled a list of further candidates for removal. Needs to be reviewed. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity 1.5?
Scott Eade wrote: 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?) Torque 3.2 works fine with YAAFI, no problems there. I don't think we're in a hurry here, so I'd suggest to use 3.3 when it is released (RC3 is almost there, so this shouldn't take too long to the final release) Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deprecations
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.* Probably more. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deprecations
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. 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 +1 on this one. Go ahead. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move Turbine to TLP
[X] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Thanks, Scott, for bringing this to life. Bye, Thomas. 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: Pull tools and access classes
Scott Eade wrote: 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? For components I write I usually place the static accessor class into the same package as the service interface, because it not actually Turbine specific code. The pull tool is then placed in a .turbine package in my application code. So I'd propose to keep the pull tool with Turbine and everything else in the Fulcrum repository. Just my two cents. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coding Specification - do we care?
Scott Eade wrote: 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 know, I tried to reformat stuff when it passed my way. Actually I *do* care about coding standards, because they help the developer himself to structurize his code and they help the community to understand each other. 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). Reformatting is a matter of a mouse click in Eclipse, you know. Maybe we can combine this with the re-licensing, where we need to touch all files anyway. However there will still be a lot of JavaDocs missing and/or wrong, especially in the Fulcrum code base. 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. I understand your point and I agree with you here, for the time being. But remember, the above-mentioned coding style is widespread *and* is known by the name of our project, it's Turbine Coding Style. So that we, of all people, should be the first to adhere to it. 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. -0.5 on the line length issue. I like to use screen real estate for context information, for example. My editor window usually takes only half of the screen width. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Coding Specification - do we care?
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. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: apachecon - Amsterdam
Siegfried Goeschl wrote: I will be there ... :-) ... and I would love to have your problems Me, too. I will be there from April 30 till May 5. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: apachecon - Amsterdam
Scott Eade wrote: 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 I read this and promise to do my homework... :-) Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: question
Juergen Hoffmann wrote: i would like to update all necessary license Headers so we can move forward with the releases, we have in the pipeline. Which license is the right one to insert and on which branches should I update those? You know about Hennings CodeWrestler, do you? It's just setting the right configuration and off you go, a matter of minutes. The license header policy of the ASF can be found in http://www.apache.org/legal/src-headers.html Actually, the headers need to be updated in all branches that we want to do further releases from, that is core/trunk, core/branches/TURBINE_2_3_BRANCH, fulcrum/trunk, maybe site. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [DISCUSS] migration to maven2
Juergen Hoffmann wrote: I would recommend moving the whole build system to maven2, since it would keep things consistent. What do the others think? 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 Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] TLP?
Scott Eade wrote: * 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. I think that you would be the right person for the PMC chair, as Henning already suggested and I will be happy to support you (and learn!). * 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. I guess this would be a good time to clean up a bit in the heap of Fulcrum components (the good into the pot, the bad into the crop). That would make things easier to maintain. -- 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. I'd suggest to do a 2.3.x release in the near^H^H^H^Hnot to far future to make some of the changes publicly available. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] TLP?
Henning P. Schmiedehausen wrote: IMHO the whole Fulcrum issue gets more and more moot. Avalon has obviously failed, Excalibur is intentionally kept at a very low profile and just lost two of its biggest supporters (James to Spring AFAIK and Cocoon to OSGi), so IMHO it would be good to clarify here and say Fulcrum is a repository of Turbine related components based on Avalon/Excalibur technology. We should make this clear in the TLP proposal because the board will surely ask about it. I see no need to rush after enter name of component technology of the year here. Avalon has its advantages. The whole Excalibur stuff has just been updated. However I agree that probably more Turbine applications use components from outside than Fulcrum components are used outside Turbine. Anybody cares to comment about the assumed usage of Fulcrum components? Progress is done by user support and developer needs. If the amount of request and patches from the user community is not that high, slow progress is ok. Remember this is not a commercial project with release dates and deadlines. This is a question of supply and demand, I guess. Growth generates growth... Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] TLP?
Henning P. Schmiedehausen wrote: I can help you cutting an RC @ AC EU Hackathon. Its all about wrestling again, isn't it? :-) Yes, we can go the first steps, but let me first get Torque 3.3 out of the door. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [DISCUSS] TLP?
Henning P. Schmiedehausen wrote: Skype, skype, that is something like phone, isn't it? :-) The headset would probably do no harm, but you can also type... Search for my name in Skype and we can practice a little bit. :-) In turn, I would need some basic hints about IRC. Never used that before. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC - Releasing fulcrum-yaafi 1.0.5
Siegfried Goeschl wrote: Hi folks, 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. +1 +) Are there other requirements out there I'm not aware? +) Any comments before I call a final vote?! Just go ahead. Bye, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] TLP?
Scott Eade wrote: 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? I'm too much a rookie to oversee the consequences of that TLP-thingy. But yes, absolutely, I want Turbine to live long and prosper and I would happily be available for the PMC. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] TLP?
Hi Peter, Peter Courcoux wrote: I am still using Turbine (svn head). I still keep an eye on the lists and am still interested. If I can help, I will. Fortunately for me I am kept very busy with paying work. Unfortunately, this keeps me from being able to commit as much time as I would like to the Turbine project. Good to hear from you. I dimly remember that you use some home-grown Fortress adapter for Turbine, is that correct? If so, could you please give me the code, cause I would like to test some things with pooled service instances which YAAFI doesn't support? There are some strange things happening in the code of the parser handling (see TRB-42) Bye, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TRB-40) Fulcrum Security-API uses objects where it should provide interfaces
[ https://issues.apache.org/jira/browse/TRB-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl reassigned TRB-40: - Assignee: Thomas Vandahl Fulcrum Security-API uses objects where it should provide interfaces Key: TRB-40 URL: https://issues.apache.org/jira/browse/TRB-40 Project: Turbine Issue Type: Improvement Components: Fulcrum Affects Versions: Core 2.4 Reporter: Thomas Vandahl Assigned To: Thomas Vandahl The Fulcrum Security-API provides the classes - org.apache.fulcrum.security.model.basic.entity.BasicGroup - org.apache.fulcrum.security.model.basic.entity.BasicUser - org.apache.fulcrum.security.model.dynamic.entity.DynamicGroup - org.apache.fulcrum.security.model.dynamic.entity.DynamicPermission - org.apache.fulcrum.security.model.dynamic.entity.DynamicRole - org.apache.fulcrum.security.model.dynamic.entity.DynamicUser - org.apache.fulcrum.security.model.turbine.entity.TurbineGroup - org.apache.fulcrum.security.model.turbine.entity.TurbinePermission - org.apache.fulcrum.security.model.turbine.entity.TurbineRole - org.apache.fulcrum.security.model.turbine.entity.TurbineUser - org.apache.fulcrum.security.model.turbine.entity.TurbineUserGroupRole The mapping of these classes to new features requires these classes to be extended which is not always desirable, sometimes not even possible. However the classes are used all over the API and particularly in the unit tests. It would be easier to have them as interfaces and provide an additional default implementation for the services that use them now. -- 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] Resolved: (TRB-40) Fulcrum Security-API uses objects where it should provide interfaces
[ https://issues.apache.org/jira/browse/TRB-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved TRB-40. --- Resolution: Fixed Fix Version/s: Core 2.4 Fulcrum Security-API uses objects where it should provide interfaces Key: TRB-40 URL: https://issues.apache.org/jira/browse/TRB-40 Project: Turbine Issue Type: Improvement Components: Fulcrum Affects Versions: Core 2.4 Reporter: Thomas Vandahl Assigned To: Thomas Vandahl Fix For: Core 2.4 The Fulcrum Security-API provides the classes - org.apache.fulcrum.security.model.basic.entity.BasicGroup - org.apache.fulcrum.security.model.basic.entity.BasicUser - org.apache.fulcrum.security.model.dynamic.entity.DynamicGroup - org.apache.fulcrum.security.model.dynamic.entity.DynamicPermission - org.apache.fulcrum.security.model.dynamic.entity.DynamicRole - org.apache.fulcrum.security.model.dynamic.entity.DynamicUser - org.apache.fulcrum.security.model.turbine.entity.TurbineGroup - org.apache.fulcrum.security.model.turbine.entity.TurbinePermission - org.apache.fulcrum.security.model.turbine.entity.TurbineRole - org.apache.fulcrum.security.model.turbine.entity.TurbineUser - org.apache.fulcrum.security.model.turbine.entity.TurbineUserGroupRole The mapping of these classes to new features requires these classes to be extended which is not always desirable, sometimes not even possible. However the classes are used all over the API and particularly in the unit tests. It would be easier to have them as interfaces and provide an additional default implementation for the services that use them now. -- 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] Created: (TRB-39) TurbineRunDataService makes invalid use of Fulcrum-PoolService, causes NPE
TurbineRunDataService makes invalid use of Fulcrum-PoolService, causes NPE -- Key: TRB-39 URL: https://issues.apache.org/jira/browse/TRB-39 Project: Turbine Issue Type: Bug Components: Core, Fulcrum Reporter: Thomas Vandahl The current trunk of Turbine contains a TurbineRunDataService implementation which makes use of the Fulcrum-PoolService. The PoolService is used to create ParameterParser objects. The PoolService creates new objects instead of looking them up from the ServiceManager, which in turn leaves the Fulcrum-DefaultParameterParser unconfigured. The access to the logger via getLogger() fails, causing a NullPointerException in setRequest(). -- 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-39) TurbineRunDataService makes invalid use of Fulcrum-PoolService, causes NPE
[ https://issues.apache.org/jira/browse/TRB-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated TRB-39: -- Affects Version/s: Core 2.4 TurbineRunDataService makes invalid use of Fulcrum-PoolService, causes NPE -- Key: TRB-39 URL: https://issues.apache.org/jira/browse/TRB-39 Project: Turbine Issue Type: Bug Components: Core, Fulcrum Affects Versions: Core 2.4 Reporter: Thomas Vandahl The current trunk of Turbine contains a TurbineRunDataService implementation which makes use of the Fulcrum-PoolService. The PoolService is used to create ParameterParser objects. The PoolService creates new objects instead of looking them up from the ServiceManager, which in turn leaves the Fulcrum-DefaultParameterParser unconfigured. The access to the logger via getLogger() fails, causing a NullPointerException in setRequest(). -- 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] Created: (TRB-40) Fulcrum Security-API uses objects where it should provide interfaces
Fulcrum Security-API uses objects where it should provide interfaces Key: TRB-40 URL: https://issues.apache.org/jira/browse/TRB-40 Project: Turbine Issue Type: Improvement Components: Fulcrum Affects Versions: Core 2.4 Reporter: Thomas Vandahl The Fulcrum Security-API provides the classes - org.apache.fulcrum.security.model.basic.entity.BasicGroup - org.apache.fulcrum.security.model.basic.entity.BasicUser - org.apache.fulcrum.security.model.dynamic.entity.DynamicGroup - org.apache.fulcrum.security.model.dynamic.entity.DynamicPermission - org.apache.fulcrum.security.model.dynamic.entity.DynamicRole - org.apache.fulcrum.security.model.dynamic.entity.DynamicUser - org.apache.fulcrum.security.model.turbine.entity.TurbineGroup - org.apache.fulcrum.security.model.turbine.entity.TurbinePermission - org.apache.fulcrum.security.model.turbine.entity.TurbineRole - org.apache.fulcrum.security.model.turbine.entity.TurbineUser - org.apache.fulcrum.security.model.turbine.entity.TurbineUserGroupRole The mapping of these classes to new features requires these classes to be extended which is not always desirable, sometimes not even possible. However the classes are used all over the API and particularly in the unit tests. It would be easier to have them as interfaces and provide an additional default implementation for the services that use them now. -- 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: Turbine architechture - some suggestions for intake
Thomas UNG wrote: 1. Extend rules with custom java class So we will have the following in the xml file: field name=password .. rule name=extend value=org.turbine.rules.XYZsystem.form.field.mandatory/rule /field Custom validators are possible already. With them, you can introduce any rule you like. I'd rather replace the existing validators with the ones from commons-validator and make the interfaces compatible. and implement an interface that receives RunData/ServerData, the field name and the intake group as parameters. What for? 2. The intake tool is commonly known for field validation based on implementated rules. But it is also great to use it to render automatically UI forms. For instance, a 'LoginGrp' group is created in the intake.xml file, the screen class extends an 'Engine' and generates automatically the form fields described in the intake file and put the result in the context. (see an example in the attached file). This works partially for me, there are some missing pieces: This is where Velocity macros shine. Like so: #macro (intakeTextField $ref) input type=text if($ref.isRequired())class=required#end maxlength=$ref.MaxSize size=$ref.displaySize name=$ref.Key id=$ref.Key value=$!ref.HTMLString / #intakeMessage($ref) #end field name=password mapToWidgetObject=org.turbine.service.intake.widget.passwordfield .. This is nice for programmers but very difficult for web designers. IMO, this is not what the MVC concept is about. (2) can we introduce a new attribute in 'group's field' called 'displayHint'? e.g. field name=username displayName=system.basic.username displayHint=system.basic.username.hint ... In Torque, we just introduced generic options in the XML schema. Maybe I want to make sure a certain class or event handler or whatever is attached to a certain field. With a generic concept like this, you can add whatever you want, be it MVC or not. import com.bobo.tools.DojoTool; Could I have a look at this thingy? Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r481255 - /jakarta/turbine/fulcrum/trunk/security/torque/project.xml
[EMAIL PROTECTED] wrote: + groupIdmysql/groupId + version3.1.12/version Version 5.0.4 is current. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WG: svn commit: r477445 - in /jakarta/turbine/core/tags/TURBINE_2_3_2:
Henning P. Schmiedehausen wrote: Even better, merge the previous release by doing 'svn merge' the last good release back. Just for my understanding: This will create a new revision as well or won't it? Bye, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WG: svn commit: r477445 - in /jakarta/turbine/core/tags/TURBINE_2_3_2: conf/test/TurbineResourcesWithIntake.properties conf/test/intake.xml src/test/org/apache/turbine/services/intake/IntakeServic
Juergen Hoffmann wrote: little call for help here. I am not such a big subversion guru, and just noticed that I was working on the tag rather than the branch. But too late. How do I revert the mistake I made? I already switched the project within eclipse to use https://svn.apache.org/repos/asf/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH Actually, you don't revert things in subversion at all. You will always leave traces. Simply remove the changes by checking out the previous version of the files and re-committing them. Bye, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CfV: Jürgen Hoffmann for Turbine C ommittership
[X] +1,Yes, Turbine needs more committers anyway [ ] 0 I don't care [ ] -1 No (please explain) Henning Schmiedehausen wrote: Hi, Jürgen Hoffmann ([EMAIL PROTECTED]) is one of the rare individuals that does active Turbine development and is not already a committer. And he does so for a very long time, however he somehow slipped through the cracks all the time. Jürgen should be a Turbine committer! [ ] +1,Yes, Turbine needs more committers anyway [ ] 0 I don't care [ ] -1 No (please explain) Vote collection till Thursday, 9th, 12:00 MET Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TorqueSecurityService optimizations for 2.3.x
Scott Eade wrote: My webapp runs Turbine 2.3.2 and uses the TorqueSecurityService. Mine, too. 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. When I do permission checks, I normally use ---8--- AccessControlList acl = data.getACL(); PermissionSet ps = (acl != null) ? acl.getPermissions() : null; boolean isAuthorized = (ps != null) ps.containsName(MyPermission.PERFORM_ACTION); ---8--- This does not hit the database more than once per session. 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. I'm currently implementing the Torque flavour of the Fulcrum security service. I'm almost done, apart from the documentation stuff. The design seems to be a little bit Hibernate-biased, so I'm facing a couple of obstacles... Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fulcrum] Preparing vor fulrcum-yaafi 1.5
Hi Siegfried, Siegfried Goeschl wrote: 1) The James developers implemented a short code snippet which allows setter dependency injection instead of ServiceManager lookups. The main problem is that this feature is not compatible across Avalon containers and I'm not really keen to implement proprietary extensions. Any opinions out there if it is worth the effort? Could you please point me to an example of this? I would like to understand what that means. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Avalon Poolable marker
Hi folks, when I applied the patches to the parser component I thought that the dependency on the fulcrum-pool component would be a little bit disturbing. While reading some JavaDocs, I came across the Poolable marker interface of Excalibur. It seems to me that all stuff described there is exactly what fulcrum-pool does. Is that the case? Would it be better to use this implementation to make the components work with less inter-dependency? What do you guys think? Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: my patches to the parser
Scott Eade wrote: 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). From my point of view, the selectors do not belong to the parser code. They are view components which would not even work with the Velocity templating engine nor JSP without tricks. Moreover while fixing the BaseValueParserTest I was thinking that having the parser as an Avalon component might be questionable at all. The parser is an object which normally is pooled (using the pool component for example). The way it is done now, you need to teach the pool service to lookup components from the container, which is not what we want (if I'm not mistaken). My thanks to Jürgen and you for your effort on this. You're welcome. To make myself clear: Most of the topics discussed were not based on Juergens patches. These are fine. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: my patches to the parser
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]
[jira] Commented: (TRB-32) Port Parser from t2.3.2 to 2.4m1
[ http://issues.apache.org/jira/browse/TRB-32?page=comments#action_12424296 ] Thomas Vandahl commented on TRB-32: --- Ok I committed the changes plus some more to the Fulcrum parser and the UploadService to SVN. Port Parser from t2.3.2 to 2.4m1 Key: TRB-32 URL: http://issues.apache.org/jira/browse/TRB-32 Project: Turbine Issue Type: Task Components: Core Reporter: Jürgen Hoffmann Assigned To: Thomas Vandahl Attachments: fulcrum-parser-patch-2.txt, fulcrum-parser-patch.txt, turbine-trunk-patch.txt Port the changes made to the Parameter Parser on the 2.3.2 Branch over to the equivalent fulcrum component parser -- 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: my patches to the parser
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? Not yet. However I promise to look into this during next week. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TRB-32) Port Parser from t2.3.2 to 2.4m1
[ http://issues.apache.org/jira/browse/TRB-32?page=all ] Thomas Vandahl reassigned TRB-32: - Assignee: Thomas Vandahl Port Parser from t2.3.2 to 2.4m1 Key: TRB-32 URL: http://issues.apache.org/jira/browse/TRB-32 Project: Turbine Issue Type: Task Components: Core Reporter: Jürgen Hoffmann Assigned To: Thomas Vandahl Attachments: fulcrum-parser-patch-2.txt, fulcrum-parser-patch.txt, turbine-trunk-patch.txt Port the changes made to the Parameter Parser on the 2.3.2 Branch over to the equivalent fulcrum component parser -- 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] Assigned: (TRB-18) Improvement to ConfigurationService
[ http://issues.apache.org/jira/browse/TRB-18?page=all ] Thomas Vandahl reassigned TRB-18: - Assignee: Thomas Vandahl Improvement to ConfigurationService --- Key: TRB-18 URL: http://issues.apache.org/jira/browse/TRB-18 Project: Turbine Issue Type: Improvement Reporter: Thomas Vandahl Assigned To: Thomas Vandahl Attachments: fulcrum-configuration.diff I would like to suggest some changes to the ConfigurationService. It allows for more flexibility when using several configuration sources. I've attached a diff for your kind review. -- 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-18) Improvement to ConfigurationService
[ http://issues.apache.org/jira/browse/TRB-18?page=all ] Thomas Vandahl resolved TRB-18. --- Resolution: Fixed Committed to SVN Improvement to ConfigurationService --- Key: TRB-18 URL: http://issues.apache.org/jira/browse/TRB-18 Project: Turbine Issue Type: Improvement Reporter: Thomas Vandahl Assigned To: Thomas Vandahl Attachments: fulcrum-configuration.diff I would like to suggest some changes to the ConfigurationService. It allows for more flexibility when using several configuration sources. I've attached a diff for your kind review. -- 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: [RESULT][VOTE] Thomas Vandahl as Committer on Jakarta Turbine
Scott Eade wrote: Welcome Thomas! Thanks Scott and all the others. I'll do my best. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LONG: working on the parser
Jürgen Hoffmann wrote: Now to my question. Do we really want one jar file for all possible Parsers and create a new Interface for the CSV/TSVParser and have then 4 components inside one jar file, or do we want to split this up further inside fulcrum-baseparser fulcrum-parameter-parser fulcrum-cookie-parser fulcrum-string-parser fulcrum-csv-parser have those components implement contextualizable, and make them lookup fulcrum-baseparser? I'd vote for the single jar. The parsers are closely interconnected and in quite heavy use. I suspect performance issues if they need to lookup another instance every time. Other than that, the split-up would need a lot more stuff in the container configuration, which can be screwed up. Another thing is that we have ParserUtils inside t2.3.2. ParserUtils check the TR.props for the desired folding. Now in Trunk there is a ParserUtils, but we do not want to use it, because this creates a dependency upon turbine, which is surely not what we want. So to come by this, I made DefaultParameterParser implement Configurable, and added the necessary Methods (convertAndTrim) to the ValueParser Interface. Now why in there, and not to (I)ParameterParser? Because BaseValueParser has a method convert(String) which calls convertAndTrim(String). Henning solved this by creating the ParserUtils class, which was a basic Utility Class providing static Methods. Now because of the aforementioned probable dependency, I am asking what would be best. Keep ParserUtils, and create another static Method to set the desired UrlCaseFolding Value during Configuration of the Component, or keep it inside the Interface ValueParser? I think that setting the value during configure() is exactly the way the components are meant to work. I understand that this is a method for internal string handling anyway, isn't it? Should we at least create different packages for the Parsers that are dependant on BaseValueParser and those dependant on DataStreamParser? Feel free to use whatever structure you find useful. Bye, Thomas. - 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_12417737 ] Thomas Vandahl commented on TRB-17: --- Could you please provide the output of maven maven.log ? It is entirely possible that a dependency is missing from the project.xml 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] Updated: (TRB-17) Avalon component JCSCacheService
[ http://issues.apache.org/jira/browse/TRB-17?page=all ] Thomas Vandahl updated TRB-17: -- Attachment: fulcrum-jcs-cache.diff Sorry, the dependency on commons-lang was missing from the POM I was running the JUNIT tests in Eclipse and forgot the synchronization. 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, 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] Created: (TRB-27) Turbine 2.3.2 compatible Service to use YAAFI instead of the AvalonComponentService
Turbine 2.3.2 compatible Service to use YAAFI instead of the AvalonComponentService --- Key: TRB-27 URL: http://issues.apache.org/jira/browse/TRB-27 Project: Turbine Type: Improvement Components: Fulcrum Versions: Core 2.3.2 Reporter: Thomas Vandahl 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. - 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-27) Turbine 2.3.2 compatible Service to use YAAFI instead of the AvalonComponentService
[ http://issues.apache.org/jira/browse/TRB-27?page=all ] Thomas Vandahl updated TRB-27: -- Attachment: ACSYaafiComponentService.java Just the source for there is no source package for this. Turbine 2.3.2 compatible Service to use YAAFI instead of the AvalonComponentService --- Key: TRB-27 URL: http://issues.apache.org/jira/browse/TRB-27 Project: Turbine Type: Improvement Components: Fulcrum Versions: Core 2.3.2 Reporter: Thomas Vandahl 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. - 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
Peter Courcoux wrote: 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. As far as I can see, the TurbineYaafiComponentService is already part of the Turbine core trunk. So you just need to change the classname in the configuration and provide a container configuration file as described in the YAAFI tutorial. That should do it. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TRB-27) Turbine 2.3.2 compatible Service to use YAAFI instead of the AvalonComponentService
[ http://issues.apache.org/jira/browse/TRB-27?page=comments#action_12417785 ] Thomas Vandahl commented on TRB-27: --- This is for Turbine 2.3.2, remember. There, the method AvalonComponentService.lookup returns Component. If I return Object in this case, this would break code which relies on the Component interface. I agree that for Turbine 2.4 this is not an issue, but for 2.3 it is relevant. Turbine 2.3.2 compatible Service to use YAAFI instead of the AvalonComponentService --- Key: TRB-27 URL: http://issues.apache.org/jira/browse/TRB-27 Project: Turbine Type: Improvement Components: Fulcrum Versions: Core 2.3.2 Reporter: Thomas Vandahl 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. - 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
Peter Courcoux wrote: YAAFI is worth looking at. I just don't know if it has been used in a large complex application and if it handles these issues. I have been meaning to look again at this for a long time but haven't got round to it. It is, indeed. I changed a few lines in TurbineYaafiService (which lies sleeping in the contrib directory of Yaafi) to make it compatible with the AvalonComponentService integrated in Turbine 2.3.2. It worked like a charm and we currently move all our Turbine services to Avalon components (makes them easier, actually!). So I'm quite happy with YAAFI. It may lack some of the advanced features but does everything else and is stable. In short, I'm not sure that Avalon is worth the effort. Not for me anyway. However, there are some options, both Avalon and non-avalon. It really depends on who gets to it first and how they feel about it all. :-) In my opinion, Avalon has proved to be a mature framework with a stable API. I'm not convinced that changing horses every so often is a good option. I'd stick with Avalon for the time being and bring Turbine 2.4 and the necessary components to a release. Just my two cents. Bye, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future of Turbine
Hi Juergen, Jürgen Hoffmann wrote: centralized Page Authorization Concept, is a concept to decide which links a given user sees. This helps you keep customers business rules in one place instead of having them all over your application. Having this in one place, makes it possible to test it, and easy to maintain. In my company we have been using an XML Approach in which we map links to permissions and if a certain user does not have the permission, he cannot see the link. But I think there could be even better ways, Maybe a linktool, which is not only creating the href part, but the whole link as an image- or textlink. This is called security by obscurity, right? :-) You should get to know a guy I work with. For him, not seeing a link does not mean he cannot use it. And if he doesn't know a link, he is a genius at guessing... I wanted to take a way quite similar to the one you describe, but because of some evil demonstrations he did, decided against it. I think that if a user should not see some information or perform some action, this must be prevented in the controller, not in the view component. Is this part of the concept? Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future of Turbine
Hi Juergen, Jürgen Hoffmann wrote: Thomas seems to have used t2.4 for a bit, since he has provided some patches which seem to address some flexibilty problems. Maybe he can share his knowledge with me. Do you mean me? If so: No, I'm using Turbine 2.3.2 with the help of additional home-grown Avalon components and Fulcrum components. I can offer some experience with those components now and I think I have a fair understanding of what's going on in Turbine. So again: we are Ready to Rumble! :-) Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future of Turbine
Jürgen Hoffmann wrote: [stuff deleted] Does that sound like a reasonable solution? Absolutely. This seems to fit perfectly into the Turbine pipeline concept. I would like to have a look at it. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TRB-17) Avalon component JCSCacheService
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] Updated: (TRB-17) Avalon component JCSCacheService
[ http://issues.apache.org/jira/browse/TRB-17?page=all ] Thomas Vandahl updated TRB-17: -- Attachment: fulcrum-jcs-cache.diff Patch against the Fulcrum/cahce trunk. 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] Created: (TRB-18) Improvement to ConfigurationService
Improvement to ConfigurationService --- Key: TRB-18 URL: http://issues.apache.org/jira/browse/TRB-18 Project: Turbine Type: Improvement Reporter: Thomas Vandahl Attachments: fulcrum-configuration.diff I would like to suggest some changes to the ConfigurationService. It allows for more flexibility when using several configuration sources. I've attached a diff for your kind review. -- 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-18) Improvement to ConfigurationService
[ http://issues.apache.org/jira/browse/TRB-18?page=all ] Thomas Vandahl updated TRB-18: -- Attachment: fulcrum-configuration.diff Diff against laetst Fulcrum/config trunk Improvement to ConfigurationService --- Key: TRB-18 URL: http://issues.apache.org/jira/browse/TRB-18 Project: Turbine Type: Improvement Reporter: Thomas Vandahl Attachments: fulcrum-configuration.diff I would like to suggest some changes to the ConfigurationService. It allows for more flexibility when using several configuration sources. I've attached a diff for your kind review. -- 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-19) Extend Fulcrum XSLT Service
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 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]
[jira] Updated: (TRB-19) Extend Fulcrum XSLT Service
[ http://issues.apache.org/jira/browse/TRB-19?page=all ] Thomas Vandahl updated TRB-19: -- Attachment: fulcrum-xslt.diff Patch against latest Fulcrum/xslt trunk 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 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]
JCSCacheService
Hi folks,
attached, as already promised, is the 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.
If anything rises questions, let me know.
Bye, Thomas.
Index: maven.xml
===
--- maven.xml (revision 412192)
+++ maven.xml (working copy)
@@ -1,7 +1,15 @@
-project default=jar:jar xmlns:maven=jelly:maven xmlns:j=jelly:core
xmlns:util=jelly:util
+project default=jar:jar xmlns:maven=jelly:maven xmlns:j=jelly:core
xmlns:util=jelly:util xmlns:ant=jelly:ant
preGoal name=site
attainGoal name=maven-jcoverage-plugin:deregister/
/preGoal
+ preGoal name=test:test
+ant:copy todir=${maven.test.dest}
+ ant:fileset dir=${basedir}/src/test
+ant:include name=*.ccf /
+ /ant:fileset
+/ant:copy
+ /preGoal
+
/project
\ No newline at end of file
Index: project.xml
===
--- project.xml (revision 415866)
+++ project.xml (working copy)
@@ -31,6 +31,13 @@
version1.2beta4/version
/dependency
+dependency
+ groupIdjcs/groupId
+ artifactIdjcs/artifactId
+ version20030822.182132/version
+ typejar/type
+/dependency
+
!-- Needed only for testing --
dependency
groupIdfulcrum/groupId
Index: src/java/org/apache/fulcrum/cache/CachedObject.java
===
--- src/java/org/apache/fulcrum/cache/CachedObject.java (revision 412192)
+++ src/java/org/apache/fulcrum/cache/CachedObject.java (working copy)
@@ -36,6 +36,11 @@
implements Serializable
{
+/**
+ * Serialization key
+ */
+private static final long serialVersionUID = -9107764093769042092L;
+
/** Cache the object with the Default TTL */
public static final int DEFAULT = 0;
Index: src/java/org/apache/fulcrum/cache/impl/JCSCacheService.java
===
--- src/java/org/apache/fulcrum/cache/impl/JCSCacheService.java (revision 0)
+++ src/java/org/apache/fulcrum/cache/impl/JCSCacheService.java (revision 0)
@@ -0,0 +1,370 @@
+/*
+ * Copyright 2001-2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.fulcrum.cache.impl;
+
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+import java.io.ObjectOutputStream;
+import java.io.Serializable;
+import java.util.ArrayList;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Set;
+
+import org.apache.avalon.framework.activity.Disposable;
+import org.apache.avalon.framework.activity.Initializable;
+import org.apache.avalon.framework.configuration.Configurable;
+import org.apache.avalon.framework.configuration.Configuration;
+import org.apache.avalon.framework.configuration.ConfigurationException;
+import org.apache.avalon.framework.logger.AbstractLogEnabled;
+import org.apache.avalon.framework.thread.ThreadSafe;
+import org.apache.fulcrum.cache.CachedObject;
+import org.apache.fulcrum.cache.GlobalCacheService;
+import org.apache.fulcrum.cache.ObjectExpiredException;
+import org.apache.fulcrum.cache.RefreshableCachedObject;
+import org.apache.jcs.JCS;
+import org.apache.jcs.access.exception.CacheException;
+import org.apache.jcs.engine.ElementAttributes;
+
+/**
+ * Default implementation of JCSCacheService
+ *
+ * @author a href=mailto:[EMAIL PROTECTED]Thomas Vandahl/a
+ * @version $Id:$
+ */
+public class JCSCacheService
+extends AbstractLogEnabled
+implements GlobalCacheService, Runnable, Configurable, Disposable,
Initializable, ThreadSafe
+{
+/**
+ * Cache check frequency in Millis (1000 Millis = 1 second).
+ * Value must be 0.
+ * Default = 5 seconds
+ */
+public static final long DEFAULT_CACHE_CHECK_FREQUENCY = 5000; // 5 seconds
+
+/**
+ * cacheCheckFrequency (default - 5 seconds)
+ */
+private long cacheCheckFrequency
Re: [SOURCE] Issue #TTWS52 modified
, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
- */
+ */
+
import java.io.File;
import java.math.BigDecimal;
import java.math.BigInteger;
@@ -21,6 +22,9 @@
import java.util.List;
import java.util.Properties;
+import javax.naming.InitialContext;
+import javax.naming.NamingException;
+
import org.apache.avalon.framework.configuration.Configurable;
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;
@@ -29,460 +33,591 @@
import org.apache.avalon.framework.context.Contextualizable;
import org.apache.avalon.framework.logger.AbstractLogEnabled;
import org.apache.avalon.framework.thread.ThreadSafe;
+import org.apache.commons.configuration.CompositeConfiguration;
import org.apache.commons.configuration.ConfigurationFactory;
+import org.apache.commons.configuration.JNDIConfiguration;
+import org.apache.commons.configuration.PropertiesConfiguration;
+import org.apache.commons.configuration.SystemConfiguration;
+import org.apache.commons.configuration.XMLConfiguration;
/**
* Starts up a commons configuration Configuration object via an
* Avalon container.
- *
+ *
+ * The component configuration is carved after the
+ * a
href=http://jakarta.apache.org/commons/configuration/howto_configurationfactory.html;CompositeConfiguraton/a
+ * from Commons Configuration and allows similar expressions. The
implementation understands the
+ * following types of configurations:br
+ * pre
+ *
+ * lt;ConfigurationServicegt;
+ *lt;system/gt;
+ *lt;jndi prefix=java:comp/env/gt;
+ *lt;properties fileName=test.properties optional=true/gt;
+ *lt;xml fileName=test.xml optional=true/gt;
+ * lt;/ConfigurationServicegt;
+ *
+ * /pre
+ * All other XML elements are considered to be keys of a configuration and
their contents is
+ * treated as string value.
+ *
* @author a href=mailto:[EMAIL PROTECTED]Eric Pugh/a
* @author a href=mailto:[EMAIL PROTECTED]Stephen McConnell/a
+ * @author a href=mailto:[EMAIL PROTECTED]Thomas Vandahl/a
* @version $Id$
* @avalon.component name=config lifestyle=singleton
* @avalon.service type=org.apache.commons.configuration.Configuration
* @avalon.attribute key=urn:composition:deployment.timeout value=0
+ *
*/
public class DefaultConfigurationService
extends AbstractLogEnabled
-implements org.apache.commons.configuration.Configuration, Configurable,
Contextualizable, ThreadSafe
+implements org.apache.commons.configuration.Configuration,
+Configurable, Contextualizable, ThreadSafe
{
/**
-* The property specifying the location where to read in the
configuration
-* path from.
-*/
+ * The property specifying the location where to read in the configuration
+ * path from.
+ */
String CONFIGURATION_PATH = configurationPath;
private String applicationRoot;
-private org.apache.commons.configuration.Configuration configuration;
+private CompositeConfiguration configuration;
/**
-* @see org.apache.commons.configuration.Configuration
-*/
+ * @see
org.apache.commons.configuration.Configuration#addProperty(java.lang.String,
java.lang.Object)
+ */
public void addProperty(String arg0, Object arg1)
{
configuration.addProperty(arg0, arg1);
}
/**
-* @see org.apache.commons.configuration.Configuration
-*/
+ * @see
org.apache.commons.configuration.Configuration#clearProperty(java.lang.String)
+ */
public void clearProperty(String arg0)
{
configuration.clearProperty(arg0);
}
/**
-* @see org.apache.commons.configuration.Configuration
-* @return
-*/
+ * @see
org.apache.commons.configuration.Configuration#containsKey(java.lang.String)
+ */
public boolean containsKey(String arg0)
{
return configuration.containsKey(arg0);
}
-/*
-* (non-Javadoc)
-*
-* @see java.lang.Object#equals(java.lang.Object)
-*/
+/**
+ * @see java.lang.Object#equals(java.lang.Object)
+ */
public boolean equals(Object obj)
{
return configuration.equals(obj);
}
/**
-* @see org.apache.commons.configuration.Configuration
-* @return
-*/
+ * @see
org.apache.commons.configuration.Configuration#getBoolean(java.lang.String)
+ */
public boolean getBoolean(String arg0)
{
return configuration.getBoolean(arg0);
}
/**
-* @see org.apache.commons.configuration.Configuration
-* @return
-*/
+ * @see
org.apache.commons.configuration.Configuration#getBoolean(java.lang.String,
boolean)
+ */
public boolean
New commits ahead, was: Re: svn commit: r386104 - in /jakarta/turbine/fulcrum/trunk/cache...
Scott Eade wrote: Thomas, you may well be able to commit this yourself now that commit access has been opened up for all of Jakarta (with the exception of poi for legal reasons). Not sure if there is any new etiquette with regards to jumping in to new sub-projects. It is probably better to post a quick note to the dev list (this one) saying hey, I am about to do this (commit thing_x)... - shout now if you would rather I submitted it as a patch. Ok, now. I would like to add a couple of methods to Fulcrum XSLT which allow to give parameters to the stylesheets. I also added a lot of comments and fixed the JavaDoc. Furthermore I added some more functionality to the ConfigurationService. It is now possible to use JNDI resources, XML files and the System properties as a configuration source, just like Commons configuration does when using the Configuration factory. Properties and XML files can be marked optional. *** I have an Implementation of the GlobalCacheService ready which uses JCS. If only a release of a current version would be available at ibilio! Aaron, please! I cannot commit this unless JCS is officially available! *** As I wrote before, I changed the TurbineYaafiService to implement AvalonComponentService. Siegfried, please let me know if you prefer a new source file (may be two different derived classes of one Base class) or a change of the existing file. If anything of this does not suit you, please speak now. Otherwise I will commit the patches next week. Bye, Thomas (Torque Committer) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for TurbineYaafiService - WAS Re: svn commit: r386104 - in /....
Hi Siegfried, Siegfried Goeschl wrote: please send me the patch regarding the TurbineYaafiService ... or what was wrong with the implementation? Not exactly wrong, it was just not implementing AvalonComponentService but some other (similar) interface. However AvalonComponentService is subject to special care inside Turbine 2.3, so I decided to adjust that a little bit. :-) I'll send you a patch tomorrow as I have the code at work. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for TurbineYaafiService - WAS Re: svn commit: r386104 - in /....
Hi Siegfried,
Siegfried Goeschl wrote:
please send me the patch regarding the TurbineYaafiService ... or what
was wrong with the implementation?
Here we go. I implemented AvalonComponentService and changed the return
types, parameter types and exception types to comply with that. Then I
shifted the logger creation into the configuration creation. The logger
uses avalon now as category which is the value of AVALON_LOG_CATEGORY
as defined in the interface.
I hope everything I did is ok with you. I look forward to your comments.
Bye, Thomas.
Index: /yaafi/contrib/TurbineYaafiComponentService.java
===
--- /yaafi/contrib/TurbineYaafiComponentService.java(revision 388478)
+++ /yaafi/contrib/TurbineYaafiComponentService.java(working copy)
@@ -22,7 +22,10 @@
import org.apache.avalon.framework.activity.Disposable;
import org.apache.avalon.framework.activity.Initializable;
+import org.apache.avalon.framework.component.Component;
+import org.apache.avalon.framework.component.ComponentException;
import org.apache.avalon.framework.logger.Log4JLogger;
+import org.apache.avalon.framework.service.ServiceException;
import org.apache.commons.configuration.Configuration;
import org.apache.fulcrum.yaafi.framework.container.ServiceContainer;
import
org.apache.fulcrum.yaafi.framework.factory.ServiceContainerConfiguration;
@@ -31,28 +34,30 @@
import org.apache.turbine.Turbine;
import org.apache.turbine.services.InitializationException;
import org.apache.turbine.services.TurbineBaseService;
+import org.apache.turbine.services.avaloncomponent.AvalonComponentService;
import org.apache.turbine.services.servlet.TurbineServlet;
/**
* An implementation of Turbine service initializing the YAAFI container
*
* @author a href=mailto:[EMAIL PROTECTED]Siegfried Goeschl/a
+ * @author a href=mailto:[EMAIL PROTECTED]Thomas Vandahl/a
*/
public class TurbineYaafiComponentService
extends TurbineBaseService
-implements YaafiComponentService, Initializable, Disposable
+implements AvalonComponentService, Initializable, Disposable
{
- /** property to lookup the container configuration file */
- public final String CONTAINER_CONFIGURATION_KEY =
containerConfiguration;
+/** property to lookup the container configuration file */
+public final String CONTAINER_CONFIGURATION_KEY = containerConfiguration;
- /** the default value for the container configuration file */
- public final String CONTAINER_CONFIGURATION_VALUE =
/WEB-INF/conf/containerConfiguration.xml;
+/** the default value for the container configuration file */
+public final String CONTAINER_CONFIGURATION_VALUE =
/WEB-INF/conf/containerConfiguration.xml;
/** property to lookup the properties file */
- public final String COMPONENT_PARAMETERS_KEY = parameters;
+public final String COMPONENT_PARAMETERS_KEY = parameters;
- /** the default value for the parameter file */
- public final String COMPONENT_PARAMETERS_VALUE =
/WEB-INF/conf/parameters.properties;
+/** the default value for the parameter file */
+public final String COMPONENT_PARAMETERS_VALUE =
/WEB-INF/conf/parameters.properties;
/** YAFFI container */
private ServiceContainer container;
@@ -75,7 +80,7 @@
*
* @throws InitializationException Something went wrong in the init stage
*/
-public void init( Object data )
+public void init()
throws InitializationException
{
try
@@ -134,22 +139,15 @@
this.logger.info( Using the following home : +
home.getAbsolutePath() );
// create the configuration for YAAFI
-
-ServiceContainerConfiguration config =
this.createServiceContainerConfiguration(conf);
-
-config.setLogger( this.createAvalonLogger( yaafi ) );
-config.setApplicationRootDir( home );
+ServiceContainerConfiguration config =
this.createServiceContainerConfiguration(conf, home.getAbsolutePath());
try
{
-this.container = ServiceContainerFactory.create(
-config
-);
+this.container = ServiceContainerFactory.create(config);
}
catch (Throwable t)
{
-String msg = Initializing YAAFI failed;
-this.logger.error(msg,t);
+this.logger.error(Initializing YAAFI failed, t);
}
}
@@ -172,90 +170,98 @@
* @return an instance of the named component
* @throws Exception generic exception
*/
-public Object lookup(String path) throws Exception
+public Component lookup(String path) throws ComponentException
{
-return this.container.lookup(path);
+try
+{
+return (Component)this.container.lookup(path);
+}
+catch (ServiceException e)
+{
+throw new ComponentException
Re: Patch for TurbineYaafiService - WAS Re: svn commit: r386104 - in /....
Hi Siegfried, Siegfried Goeschl wrote: I'm not good at reading diffs and I'm currently work at a customer site but I think you return Component on lookup() instead of Object which probably is not a good idea. Yes, I know. This is what AvalonComponentService requires. It also requires ComponentExceptions to be thrown when in reality a ServiceException is more appropriate. I wanted the service to be an exact implementation of ACS as it is in Turbine 2.3 Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r386104 - in /jakarta/turbine/fulcrum/trunk/cache:./ src/java/org/apache/fulcrum/cache/ src/java/org/apache/fulcrum/cache/impl/src/test/ src/test/org/apache/fulcrum/cache/ xdocs/
Eric Pugh wrote: Hi all, Only that I had used it with Hibernate. I already have the dependency on EHCache in my project, so I was just sticking with that. I'd be happy to see support for JCS added to the fulcrum-cache project as well! I've got something ready using JCS which implements GlobalCacheService and can be used as a drop-in replacement of the standard implementation. However I have yet to see my XSLT-patches reach SVN... Eric, would you mind trying again to add my changes to the XSLT component of Fulcrum? I have also a patch to offer which makes the TurbineYaafiService play nicely as a drop-in replacement for AvalonComponentService, if anybody cares. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSLT-Service, was: T2.4 Integration of Pool Factory
Eric Pugh wrote:
Thomas,
Can you resend this as an attachment? Not sure what has changed, but I
could not get it to apply.
I created this patch again using TortoiseSVN which proved to work with
Torque quite well. I don't know what happened to the patch file, I
thought I had attached it correctly in the first place.
Bye, Thomas.
Index: src/java/org/apache/fulcrum/xslt/DefaultXSLTService.java
===
--- src/java/org/apache/fulcrum/xslt/DefaultXSLTService.java(revision
344962)
+++ src/java/org/apache/fulcrum/xslt/DefaultXSLTService.java(working copy)
@@ -1,6 +1,5 @@
package org.apache.fulcrum.xslt;
-
/*
* Copyright 2001-2004 The Apache Software Foundation.
*
@@ -17,14 +16,16 @@
* limitations under the License.
*/
-
import java.io.File;
import java.io.Reader;
import java.io.StringWriter;
import java.io.Writer;
+import java.net.MalformedURLException;
+import java.net.URL;
import java.util.Hashtable;
+import java.util.Iterator;
+import java.util.Map;
-
import javax.xml.transform.Result;
import javax.xml.transform.Source;
import javax.xml.transform.Templates;
@@ -44,132 +45,131 @@
import org.apache.avalon.framework.logger.AbstractLogEnabled;
import org.apache.avalon.framework.service.ServiceManager;
import org.apache.avalon.framework.service.Serviceable;
+import org.w3c.dom.Node;
/**
* Implementation of the Turbine XSLT Service. It transforms xml with a given
- * xsl file. XSL stylesheets are compiled and cached (if the service property
- * is set) to improve speeds.
+ * xsl file. XSL stylesheets are compiled and cached (if the service property
is
+ * set) to improve speeds.
*
* @author a href=mailto:[EMAIL PROTECTED]Leon Messerschmidt/a
* @author a href=mailto:[EMAIL PROTECTED]Sam Ruby/a
* @author a href=mailto:[EMAIL PROTECTED]Eric Pugh/a
+ * @author a href=mailto:[EMAIL PROTECTED]Thomas Vandahl/a
*/
-public class DefaultXSLTService
-extends AbstractLogEnabled
-implements
XSLTService,Initializable,Configurable,Contextualizable,Serviceable
-
+public class DefaultXSLTService extends AbstractLogEnabled implements
+XSLTService, Initializable, Configurable, Contextualizable, Serviceable
{
/**
* The application root
*/
-private String applicationRoot;
-
+private StringapplicationRoot;
+
/**
* Property to control the caching of Templates.
*/
-protected boolean caching = false;
+protected boolean caching= false;
/**
- * Path to style sheets used for tranforming well-formed
- * XML documents. The path is relative to the webapp context.
+ * Path to style sheets used for tranforming well-formed XML documents. The
+ * path is relative to the webapp context.
*/
-protected String path;
+protected String path;
/**
- * What the configured value was
- */
-private String styleSheetPath;
-
-/**
* Cache of compiled Templates.
*/
-protected Hashtable cache = new Hashtable();
+protected Hashtable cache = new Hashtable();
-protected final static String STYLESHEET_PATH = path;
+protected final static String STYLESHEET_PATH= path;
-protected final static String STYLESHEET_CACHING = cache;
+protected final static String STYLESHEET_CACHING = cache;
/**
* Factory for producing templates and null transformers
*/
private static TransformerFactory tfactory;
-
-
/**
- * Get a valid and existing filename from a template name.
- * The extension is removed and replaced with .xsl. If this
- * file does not exist the method attempts to find default.xsl.
- * If it fails to find default.xsl it returns null.
+ * Try to create a valid url object from the style parameter.
+ *
+ * @param style
+ *the xsl-Style
+ * @return a codeURL/code object or null if the style sheet could not
+ * be found
*/
-protected String getFileName (String templateName)
+private URL getStyleURL(String style)
{
-// First we chop of the existing extension
-int colon = templateName.lastIndexOf (.);
+StringBuffer sb = new StringBuffer(128);
+
+sb.append(path);
+
+// we chop off the existing extension
+int colon = style.lastIndexOf(.);
+
if (colon 0)
{
-templateName = templateName.substring (0,colon);
+sb.append(style.substring(0, colon));
}
+else
+{
+sb.append(style);
+}
-// Now we try to find the file ...
-File f = new File (path+templateName+.xsl);
-if (f.exists())
+sb.append(.xsl);
+
+URL url = null;
+
+try
{
-return path+templateName+.xsl;
+url
XSLT-Service, was: T2.4 Integration of Pool Factory
Hi Siegfried,
Siegfried Goeschl wrote:
+) can you sent your current patch (again)?
You'll find it attached.
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 it out.
+) do you also have test cases for it - there are no tests in the code
base :-(
Not yet. But I'm using the code in production...
Bye, Thomas.
Index: /xslt/src/java/org/apache/fulcrum/xslt/XSLTServiceFacade.java
===
--- /xslt/src/java/org/apache/fulcrum/xslt/XSLTServiceFacade.java
(revision 344962)
+++ /xslt/src/java/org/apache/fulcrum/xslt/XSLTServiceFacade.java
(working copy)
@@ -1,6 +1,5 @@
package org.apache.fulcrum.xslt;
-
/*
* Copyright 2001-2004 The Apache Software Foundation.
*
@@ -17,22 +16,24 @@
* limitations under the License.
*/
-
import java.io.Reader;
import java.io.Writer;
+import java.util.Map;
+
import org.w3c.dom.Node;
/**
* This is a static accesor class for [EMAIL PROTECTED] XSLTService}.
*
* @author a href=mailto:[EMAIL PROTECTED]Leon Messerschmidt/a
+ * @author a href=mailto:[EMAIL PROTECTED]Thomas Vandahl/a
*/
public class XSLTServiceFacade
{
private static XSLTService xsltService;
+
/**
- * Utility method for accessing the service
- * implementation
+ * Utility method for accessing the service implementation
*
* @return a XSLTService implementation instance
*/
@@ -40,33 +41,121 @@
{
return xsltService;
}
-
-protected static void setService(XSLTService xsltService){
-XSLTServiceFacade.xsltService=xsltService;
+
+/**
+ * Static utility method to set the service instance to be used in the
+ * facade
+ *
+ * @param xsltService
+ *the service instance
+ */
+protected static void setService(XSLTService xsltService)
+{
+XSLTServiceFacade.xsltService = xsltService;
}
-public static void transform (String xslName, Reader in, Writer out)
-throws Exception
+/**
+ * Uses an xsl file to transform xml input from a reader and writes the
+ * output to a writer.
+ *
+ * @param xslName The name of the file that contains the xsl stylesheet.
+ * @param in The reader that passes the xml to be transformed
+ * @param out The writer for the transformed output
+ */
+public static void transform(String xslName, Reader in, Writer out)
+throws Exception
{
-getService().transform (xslName,in,out);
+getService().transform(xslName, in, out);
}
-public static String transform (String xslName, Reader in)
-throws Exception
+/**
+ * Uses an xsl file to transform xml input from a reader and returns a
+ * string containing the transformed output.
+ *
+ * @param xslName The name of the file that contains the xsl stylesheet.
+ * @param in The reader that passes the xml to be transformed
+ */
+public static String transform(String xslName, Reader in) throws Exception
{
-return getService().transform (xslName,in);
+return getService().transform(xslName, in);
}
-public void transform (String xslName, Node in, Writer out)
-throws Exception
+/**
+ * Uses an xsl file to transform xml input from a DOM note and writes the
+ * output to a writer.
+ *
+ * @param xslName The name of the file that contains the xsl stylesheet.
+ * @param in The DOM Node to be transformed
+ * @param out The writer for the transformed output
+ */
+public void transform(String xslName, Node in, Writer out) throws Exception
{
-getService().transform (xslName,in,out);
+getService().transform(xslName, in, out);
}
+/**
+ * Uses an xsl file to transform xml input from a DOM note and returns a
+ * string containing the transformed output.
+ *
+ * @param xslName The name of the file that contains the xsl stylesheet.
+ * @param in The DOM Node to be transformed
+ */
+public String transform(String xslName, Node in) throws Exception
+{
+return getService().transform(xslName, in);
+}
-public String transform (String xslName, Node in)
-throws Exception
+/**
+ * Uses an xsl file to transform xml input from a reader
Re: Ideas on Removing Circular Dependency between Turbine and Intake?
Eric Pugh wrote: 1) Move parser classes to Fulcrum-Parsers, and rejuvenate that project. 2) Move parser classes to a seperate Turbine sub component, and let that build and have both Turbine and Intake depend on that. 3) Move Intake back into the Turbine project as a sub component, and not have it be a Fulcrum component, but still deal with 1 or 2. I'd go for 3) at the moment. Though Intake may be a valuable standalone component, it is very much Turbine centric right now. IMHO it is always possible to duplicate the few relevant classes in both code trees. Their code is fairly static anyway, so it's not a big maintenance issue. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exceptions thrown in actions
Henning P. Schmiedehausen wrote: Hm. This was put in two years ago. I do remember that I got this from load testing one of our applications and that was the solution. We were getting spurious ITEs without any real cause in the application but out of the invoke() code. It raised no comment on the -dev list back then (according to the archives). That's interesting. I have a similar case that somehow depends on MS IE as a client, where the eventSubmit_doSomething call fails somehow and this causes the doPerform() method to be executed afterwards. As the method making the call is only catching an ITE, I wonder now if this may be related to your problem (we're talking 2.3.1). I wrote an ugly workaround to fix this, so I would rather get rid of it asap. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
