You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Chris Kimpton <ki...@yahoo.com> on 2002/04/01 13:09:53 UTC
Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Hi,
Regarding my thread on problems using Torque with Jetspeed (and
Turbine), and in particular accessing the /WEB-INF/ directories.
I suggest we amend the ComponentLoader to pass the TR.props
configuration to each component as a "default" configuration behind
the specific component configuration.
This allows for setting properties globally in the TR.props file.
For the case where Turbine is not being used, it does the same as it
does now.
For the case where Turbine is in use, it allows the webappRoot
property to be defined for Torque and thus things can be defined
relative to that directory - eg the hsql db, or logging.
Patch to follow.
Chris
=====
SHAMELESS PLUG: http://www.soccer2002.org.uk - Football World Cup 2002 Japan/Korea
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - send holiday greetings for Easter, Passover
http://greetings.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PATCH] Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Chris Kimpton <ki...@yahoo.com>.
>
> I suggest we amend the ComponentLoader to pass the TR.props
> configuration to each component as a "default" configuration behind
> the specific component configuration.
>
> This allows for setting properties globally in the TR.props file.
> For the case where Turbine is not being used, it does the same as
> it
> does now.
>
> For the case where Turbine is in use, it allows the webappRoot
> property to be defined for Torque and thus things can be defined
> relative to that directory - eg the hsql db, or logging.
>
Patch attached.
Chris
=====
------------------------------------------
http://www.soccer2002.org.uk
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - send holiday greetings for Easter, Passover
http://greetings.yahoo.com/
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Eric Dobbs <er...@dobbse.net>.
On Wednesday, April 3, 2002, at 09:04 AM, Chris Kimpton wrote:
> I added
>
> maven.home = .
>
> to my stratum build.properties and ran this to do my tests:
>
> ant -f build-maven.xml maven:test
>
> Is that how I use maven?
Maven is probably the most thoroughly documented project
in Turbine land. Where you probably want to start in
this case is the install doc:
<http://jakarta.apache.org/turbine/maven/install.html>
-Eric
ps. maven pretty easy, and very cool
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
I presume someones knows/is going to fix the default.properties entry
for xmlrpc.jar - the update-jars task downloads version 1.1 - which
then doesn't get found...
> >
> > When running the stratum unit tests on a freshly checked out
> stratum,
> > all the xo.* tests are failing:
> >
> > loader constraints violated when linking
> org/xml/sax/EntityResolver
> > class
> >
> > java.lang.LinkageError: loader constraints violated when linking
> > org/xml/sax/EntityResolver class
> > at org.dom4j.io.SAXReader.read(SAXReader.java:298)
> > at org.dom4j.io.SAXReader.read(SAXReader.java:246)
> > at org.apache.stratum.xo.Mapper.map(Mapper.java:378)
> > at org.apache.stratum.xo.Mapper.map(Mapper.java:358)
> >
> >
> > I presume this is an existing problem.
>
> Are you are using Java 1.4? There are two copies of the SAX
> interfaces
> in your classpath somewhere.
Nope - 1.3.1_02 on XP and classpath not set before running ant:
F:\cvslocal\jakarta\jakarta-turbine-stratum>java -version
java version "1.3.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02)
Java HotSpot(TM) Client VM (build 1.3.1_02-b02, mixed mode)
F:\cvslocal\jakarta\jakarta-turbine-stratum>set classpath
Environment variable classpath not defined
I am using ant 1.4.1, which uses jaxp, crimson and have xalan in the
ant/lib.
I see that jaxp and crimson are referenced by the build-tests.xml -
but are not in my repo.lib. I copied them into my repo.lib and
voila - no errors/failures.
>
> You should also get used to using maven as the old build systems
> are
> going to disappear. And the maven build takes care of everything
> you
> need.
>
I added
maven.home = .
to my stratum build.properties and ran this to do my tests:
ant -f build-maven.xml maven:test
Is that how I use maven?
Chris
=====
------------------------------------------
http://www.soccer2002.org.uk
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the
ComponentLoader config onto the Components
Posted by James Taylor <jt...@4lane.com>.
> maven.home = .
>
> to my stratum build.properties and ran this to do my tests:
>
> ant -f build-maven.xml maven:test
>
> Is that how I use maven?
Not quite =]
You must install maven by either building:
http://jakarta.apache.org/turbine/maven/bootstrap.html
Or an installer:
http://jakarta.apache.org/turbine/maven/install.html
maven.home ends up being the directory it is installed to (~/maven or
whatever). Then ant -f build-maven.xml maven:test should work fine.
-- jt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the
ComponentLoader config onto the Components
Posted by Jason van Zyl <jv...@zenplex.com>.
On Wed, 2002-04-03 at 11:03, Chris Kimpton wrote:
> Hi,
>
> I presume someones knows/is going to fix the default.properties entry
> for xmlrpc.jar - the update-jars task downloads version 1.1 - which
> then doesn't get found...
1) use the new torque mailing lists :-)
2) use maven as the old build system is deprecated and not being kept
up. tests and system build using maven.
There will also be a problem with using the xmlrpc jar produced by
default because it includes SAX parser interfaces. I haven't fixed this
yet in xmlrpc land.
> > >
> > > When running the stratum unit tests on a freshly checked out
> > stratum,
> > > all the xo.* tests are failing:
> > >
> > > loader constraints violated when linking
> > org/xml/sax/EntityResolver
> > > class
> > >
> > > java.lang.LinkageError: loader constraints violated when linking
> > > org/xml/sax/EntityResolver class
> > > at org.dom4j.io.SAXReader.read(SAXReader.java:298)
> > > at org.dom4j.io.SAXReader.read(SAXReader.java:246)
> > > at org.apache.stratum.xo.Mapper.map(Mapper.java:378)
> > > at org.apache.stratum.xo.Mapper.map(Mapper.java:358)
> > >
> > >
> > > I presume this is an existing problem.
> >
> > Are you are using Java 1.4? There are two copies of the SAX
> > interfaces
> > in your classpath somewhere.
>
> Nope - 1.3.1_02 on XP and classpath not set before running ant:
>
> F:\cvslocal\jakarta\jakarta-turbine-stratum>java -version
> java version "1.3.1_02"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02)
> Java HotSpot(TM) Client VM (build 1.3.1_02-b02, mixed mode)
>
> F:\cvslocal\jakarta\jakarta-turbine-stratum>set classpath
> Environment variable classpath not defined
>
>
> I am using ant 1.4.1, which uses jaxp, crimson and have xalan in the
> ant/lib.
>
> I see that jaxp and crimson are referenced by the build-tests.xml -
> but are not in my repo.lib. I copied them into my repo.lib and
> voila - no errors/failures.
>
>
> >
> > You should also get used to using maven as the old build systems
> > are
> > going to disappear. And the maven build takes care of everything
> > you
> > need.
> >
>
> I added
>
> maven.home = .
>
> to my stratum build.properties and ran this to do my tests:
>
> ant -f build-maven.xml maven:test
>
> Is that how I use maven?
>
> Chris
>
> =====
> ------------------------------------------
> http://www.soccer2002.org.uk
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
I presume someones knows/is going to fix the default.properties entry
for xmlrpc.jar - the update-jars task downloads version 1.1 - which
then doesn't get found...
> >
> > When running the stratum unit tests on a freshly checked out
> stratum,
> > all the xo.* tests are failing:
> >
> > loader constraints violated when linking
> org/xml/sax/EntityResolver
> > class
> >
> > java.lang.LinkageError: loader constraints violated when linking
> > org/xml/sax/EntityResolver class
> > at org.dom4j.io.SAXReader.read(SAXReader.java:298)
> > at org.dom4j.io.SAXReader.read(SAXReader.java:246)
> > at org.apache.stratum.xo.Mapper.map(Mapper.java:378)
> > at org.apache.stratum.xo.Mapper.map(Mapper.java:358)
> >
> >
> > I presume this is an existing problem.
>
> Are you are using Java 1.4? There are two copies of the SAX
> interfaces
> in your classpath somewhere.
Nope - 1.3.1_02 on XP and classpath not set before running ant:
F:\cvslocal\jakarta\jakarta-turbine-stratum>java -version
java version "1.3.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02)
Java HotSpot(TM) Client VM (build 1.3.1_02-b02, mixed mode)
F:\cvslocal\jakarta\jakarta-turbine-stratum>set classpath
Environment variable classpath not defined
I am using ant 1.4.1, which uses jaxp, crimson and have xalan in the
ant/lib.
I see that jaxp and crimson are referenced by the build-tests.xml -
but are not in my repo.lib. I copied them into my repo.lib and
voila - no errors/failures.
>
> You should also get used to using maven as the old build systems
> are
> going to disappear. And the maven build takes care of everything
> you
> need.
>
I added
maven.home = .
to my stratum build.properties and ran this to do my tests:
ant -f build-maven.xml maven:test
Is that how I use maven?
Chris
=====
------------------------------------------
http://www.soccer2002.org.uk
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the
ComponentLoader config onto the Components
Posted by Jason van Zyl <jv...@zenplex.com>.
On Wed, 2002-04-03 at 09:49, Chris Kimpton wrote:
> Hi,
>
> --- James Taylor <jt...@4lane.com> wrote:
> > On Wed, 2002-04-03 at 02:01, Chris Kimpton wrote:
> >
> > > Any "best practices" on the testing - I see unit-test and
> > > servlet-tests for turbine - are both maintained? I just see
> > > unit-tests for stratum.
> >
>
> When running the stratum unit tests on a freshly checked out stratum,
> all the xo.* tests are failing:
>
> loader constraints violated when linking org/xml/sax/EntityResolver
> class
>
> java.lang.LinkageError: loader constraints violated when linking
> org/xml/sax/EntityResolver class
> at org.dom4j.io.SAXReader.read(SAXReader.java:298)
> at org.dom4j.io.SAXReader.read(SAXReader.java:246)
> at org.apache.stratum.xo.Mapper.map(Mapper.java:378)
> at org.apache.stratum.xo.Mapper.map(Mapper.java:358)
>
>
> I presume this is an existing problem.
Are you are using Java 1.4? There are two copies of the SAX interfaces
in your classpath somewhere.
You should also get used to using maven as the old build systems are
going to disappear. And the maven build takes care of everything you
need.
> I also assume you don't mind if I add a test-report task that
> generates xml output and runs junitreport on the results.
>
> Chris
>
> =====
> ------------------------------------------
> http://www.soccer2002.org.uk
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
--- James Taylor <jt...@4lane.com> wrote:
> On Wed, 2002-04-03 at 02:01, Chris Kimpton wrote:
>
> > Any "best practices" on the testing - I see unit-test and
> > servlet-tests for turbine - are both maintained? I just see
> > unit-tests for stratum.
>
When running the stratum unit tests on a freshly checked out stratum,
all the xo.* tests are failing:
loader constraints violated when linking org/xml/sax/EntityResolver
class
java.lang.LinkageError: loader constraints violated when linking
org/xml/sax/EntityResolver class
at org.dom4j.io.SAXReader.read(SAXReader.java:298)
at org.dom4j.io.SAXReader.read(SAXReader.java:246)
at org.apache.stratum.xo.Mapper.map(Mapper.java:378)
at org.apache.stratum.xo.Mapper.map(Mapper.java:358)
I presume this is an existing problem.
I also assume you don't mind if I add a test-report task that
generates xml output and runs junitreport on the results.
Chris
=====
------------------------------------------
http://www.soccer2002.org.uk
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the
ComponentLoader config onto the Components
Posted by James Taylor <jt...@4lane.com>.
On Wed, 2002-04-03 at 02:01, Chris Kimpton wrote:
> Any "best practices" on the testing - I see unit-test and
> servlet-tests for turbine - are both maintained? I just see
> unit-tests for stratum.
Yes, all are maintained. Closest thing we have to best practices right
now is:
http://jakarta.apache.org/turbine/turbine-3/core-testing.html
-- jt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
--- Jason van Zyl <jv...@zenplex.com> wrote:
>
> I don't see any tests? The patch looks fine but I would feel better
> if
> you included, or added to the tests currently in place.
>
My test is Jetspeed ;-)
Any "best practices" on the testing - I see unit-test and
servlet-tests for turbine - are both maintained? I just see
unit-tests for stratum.
Regards,
Chris
=====
------------------------------------------
http://www.soccer2002.org.uk
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the
ComponentLoader config onto the Components
Posted by Jason van Zyl <jv...@zenplex.com>.
On Tue, 2002-04-02 at 14:41, Chris Kimpton wrote:
> Hi,
>
> --- Eric Dobbs <er...@dobbse.net> wrote:
> > On Tuesday, April 2, 2002, at 08:16 AM, Chris Kimpton wrote:
> >
> > >> I would prefer to do
> > >> this with an explicit configuration entry in
> > >> TurbineResources.properties like this:
> > >>
> > >> component.fulcrum.property.webappRoot=${webappRoot}
> > >> component.fulcrum.property.applicationRoot=${applicationRoot}
> > >>
> > >
>
> Attached is the patch for this.
>
> Note it is fairly similar to the previous patch - as I use
> Configuration.subset to extract the component properties and then use
> these as a "defaults" configuration for each component.
I don't see any tests? The patch looks fine but I would feel better if
you included, or added to the tests currently in place.
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the
ComponentLoader config onto the Components
Posted by Jason van Zyl <jv...@zenplex.com>.
On Wed, 2002-04-03 at 13:32, Chris Kimpton wrote:
> Hi,
>
> --- Chris Kimpton <ki...@yahoo.com> wrote:
> > >
> > > Yes, maven handles that. I don't want any patches to the old
> > build
> > > system. Please use maven because those build systems are going
> > bye
> > > bye
> > > sooner rather then later hopefully this week.
> >
>
> Ok - I have maven installed. I can update my jars and jar my code,
> which also runs the tests.
>
> The docs seem to imply that you have one lib.repo for everything - is
> that the reccomended choice? I was having one per project - stratum,
> turbine, etc...
Yes, having one lib.repo is the recommend way to go.
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
--- Chris Kimpton <ki...@yahoo.com> wrote:
> >
> > Yes, maven handles that. I don't want any patches to the old
> build
> > system. Please use maven because those build systems are going
> bye
> > bye
> > sooner rather then later hopefully this week.
>
Ok - I have maven installed. I can update my jars and jar my code,
which also runs the tests.
The docs seem to imply that you have one lib.repo for everything - is
that the reccomended choice? I was having one per project - stratum,
turbine, etc...
I also noticed that the {maven.home}/build-test.xml references
specific versions of files - I presume that will be replaced by
references to the dependencies stuff.
I also see a junit-xml task. I want to run this against my turbine
and stratum projects - do I amend the turbine/stratum build-maven.xml
to have a task that calls the one in {maven.home}. Or is there some
other way of getting it?
I don't suppose you can't just "import" all tasks from one build.xml
file into another? This would remove the need to have stub tasks
that forward the calls.
I suggest you remove that old build system asap - there are enough
build files to follow now without some being redundant...
Chris
=====
------------------------------------------
http://www.soccer2002.org.uk
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
--- Jason van Zyl <jv...@zenplex.com> wrote:
> On Wed, 2002-04-03 at 11:36, Chris Kimpton wrote:
> > Hi,
> >
> > Attached is a revised patch with fixed/new tests to cover the
> > changes. I have also added a test-report task to build-test.xml
> - is
> > this file deprecated and replaced by something in maven?
>
> Yes, maven handles that. I don't want any patches to the old build
> system. Please use maven because those build systems are going bye
> bye
> sooner rather then later hopefully this week.
Don't worry - I will install it soon. But I presume that does not
invalidate my patch?
>
> > I presume stratum discussions stay on this list - the xmlrpc
> build
> > problem was in the stratum project...
>
> If you are using xmlrpc 1.1 then I would assume the jar contains
> SAX
> interface classes which will bonk the build process using java 1.4
> because of the xml parser included with 1.4.
>
I am not using xmlrpc at all - I just did a clean checkout of
stratum, update-jars and then a compile and that is when it
complained.
All the tests run fine with no errors/failures after I copied
jaxp/crimson into my repo.lib directory.
Chris
=====
------------------------------------------
http://www.soccer2002.org.uk
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the
ComponentLoader config onto the Components
Posted by Jason van Zyl <jv...@zenplex.com>.
On Wed, 2002-04-03 at 11:36, Chris Kimpton wrote:
> Hi,
>
> Attached is a revised patch with fixed/new tests to cover the
> changes. I have also added a test-report task to build-test.xml - is
> this file deprecated and replaced by something in maven?
Yes, maven handles that. I don't want any patches to the old build
system. Please use maven because those build systems are going bye bye
sooner rather then later hopefully this week.
> I presume stratum discussions stay on this list - the xmlrpc build
> problem was in the stratum project...
If you are using xmlrpc 1.1 then I would assume the jar contains SAX
interface classes which will bonk the build process using java 1.4
because of the xml parser included with 1.4.
> Chris
>
>
> =====
> ------------------------------------------
> http://www.soccer2002.org.uk
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
> ----
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Eric Dobbs <er...@dobbse.net>.
On Thursday, April 4, 2002, at 11:06 AM, Chris Kimpton wrote:
> Attached is a revised patch file - hopefully this will be readable
> too.
patches applied.
Thanks, Chris.
I particularly like that the ComponentLoader will return an array
of the loaded components. Nice addition. Thanks also for the
additional tests.
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
--- Eric Dobbs <er...@dobbse.net> wrote:
> Hi Chris.
>
>
> On Wednesday, April 3, 2002, at 09:36 AM, Chris Kimpton wrote:
>
> > Attached is a revised patch with fixed/new tests to cover the
> > changes. I have also added a test-report task to build-test.xml
> - is
> > this file deprecated and replaced by something in maven?
>
>
> The attached patch, passthru3.diffu, is garbled both in my inbox
> and in
> the archived copy at mail-archive.com. Please resend it.
>
> While you're at it, I noticed a few items in passthru2.diffu that
> were
> not adhering to our coding standards. In particular
>
> } else {
>
> should be
>
> }
> else
> {
>
> same for 'else if' etc.
>
> The one other thing I am unsure about is the change in the
> arguments you
> added to the PropertiesConfiguration constructor. I think it would
>
> probably be better to add a new constructor instead of replacing
> the
> existing one. I don't know what other code might be using the
> existing
> constructor. Otherwise things look good to me.
>
Attached is a revised patch file - hopefully this will be readable
too.
Can someone else take a look at this?
Thanks,
Chris
=====
------------------------------------------
http://www.soccer2002.org.uk
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
--- Eric Dobbs <er...@dobbse.net> wrote:
>
>
> The attached patch, passthru3.diffu, is garbled both in my inbox
> and in
> the archived copy at mail-archive.com. Please resend it.
Same here - I will do this tonight when I get to my home machine.
>
> } else {
>
> should be
>
> }
> else
> {
>
> same for 'else if' etc.
I presume it should be
}
else if
{
>
> The one other thing I am unsure about is the change in the
> arguments you
> added to the PropertiesConfiguration constructor. I think it would
> probably be better to add a new constructor instead of replacing
> the
> existing one. I don't know what other code might be using the
> existing
> constructor. Otherwise things look good to me.
I did a new constructor - its the diff that decided to make it look I
amended the old one - I presume you refer to changing this ctor:
- public PropertiesConfiguration(String file, String defaultFile)
+ public PropertiesConfiguration(String file, Configuration
defaultConfig)
but you will see later this line;
+ public PropertiesConfiguration(String file, String defaultFile)
So - that ctor is still there.
Chris
=====
------------------------------------------
http://www.soccer2002.org.uk
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Eric Dobbs <er...@dobbse.net>.
Hi Chris.
On Wednesday, April 3, 2002, at 09:36 AM, Chris Kimpton wrote:
> Attached is a revised patch with fixed/new tests to cover the
> changes. I have also added a test-report task to build-test.xml - is
> this file deprecated and replaced by something in maven?
The attached patch, passthru3.diffu, is garbled both in my inbox and in
the archived copy at mail-archive.com. Please resend it.
While you're at it, I noticed a few items in passthru2.diffu that were
not adhering to our coding standards. In particular
} else {
should be
}
else
{
same for 'else if' etc.
The one other thing I am unsure about is the change in the arguments you
added to the PropertiesConfiguration constructor. I think it would
probably be better to add a new constructor instead of replacing the
existing one. I don't know what other code might be using the existing
constructor. Otherwise things look good to me.
<maven-problems>
I'm copying this email to turbine-maven-dev...
I tried applying the patches in passthru2.diffu but was unable to build
stratum with them. Probably because I have an older installation of
maven on my box here at home. I tried updating my copy of maven from
cvs to remedy that problem, but 'ant -f build-bootstrap.xml boostrap'
failed in two places. The first is apparently because commons logging
is now needed and the second because log4j is not properly configured.
</maven-problems>
Unfortunately, I don't have any more time to work on this tonight and
I'm going to be skiing tomorrow and catching up on work on Friday. So I
won't be able to get to this before the weekend. So someone else will
have to commit the patches if they want it sooner than that.
Take care.
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
--- Chris Kimpton <ki...@yahoo.com> wrote:
> --- Eric Dobbs <er...@dobbse.net> wrote:
> > On Tuesday, April 2, 2002, at 08:16 AM, Chris Kimpton wrote:
> >
> > >> I would prefer to do
> > >> this with an explicit configuration entry in
> > >> TurbineResources.properties like this:
> > >>
> > >> component.fulcrum.property.webappRoot=${webappRoot}
> > >> component.fulcrum.property.applicationRoot=${applicationRoot}
> > >>
> > >
>
> Attached is the patch for this.
>
> Note it is fairly similar to the previous patch - as I use
> Configuration.subset to extract the component properties and then
> use
> these as a "defaults" configuration for each component.
>
> I've changed the signature of the public loadComponent method - not
> sure how safe that is - do we want to provide backwards
> compatibility
> on that method, its safe to pass in a null additional properties
> configuration.
>
> I added the Object based setters/getters (eg getBoolean(String
> key,Boolean defaultValue) ) to the Configuration interface - as
> this
> allows us to set the defaults object from a Configuration object
> without casting it to a BaseConfiguration.
>
> The BaseConfiguration now uses the defaults Configuration in the
> interpolate method - the main point of this patch.
>
> I have changed the getStringArray method to also call interpolate
> on
> returned values. This is because the code for accessing log4j
> properties call getStringArray (cos log4j uses commas in
> properties)
> - but also could contain ${key} stuff - ie webappRoot.
>
> I have also changed the subset method to interpolate its values
> too.
> This is because when you use subset to get the properties for a
> service, some of those may contain ${key} stuff - which should be
> expanded, if possible.
>
> Lastly and most controversially I changed interpolate to leave
> unchanged any unmatched ${key} stuff. That is, the old behaviour
> for
> a property ${foo}/blah would be to interpolate it into /blah if
> there
> was no previous property with a key of "foo". It now leaves it as
> ${foo}/blah. We need this because when the logging service (a
> primary service) gets its properties using getResources,
> ${webappRoot} is not defined at that point. The old behaviour
> would
> lose this information. We can then add the webappRoot property
> manually and let the interpolation work.
>
Attached is a revised patch with fixed/new tests to cover the
changes. I have also added a test-report task to build-test.xml - is
this file deprecated and replaced by something in maven?
I presume stratum discussions stay on this list - the xmlrpc build
problem was in the stratum project...
Chris
=====
------------------------------------------
http://www.soccer2002.org.uk
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
--- Eric Dobbs <er...@dobbse.net> wrote:
> On Tuesday, April 2, 2002, at 08:16 AM, Chris Kimpton wrote:
>
> >> I would prefer to do
> >> this with an explicit configuration entry in
> >> TurbineResources.properties like this:
> >>
> >> component.fulcrum.property.webappRoot=${webappRoot}
> >> component.fulcrum.property.applicationRoot=${applicationRoot}
> >>
> >
Attached is the patch for this.
Note it is fairly similar to the previous patch - as I use
Configuration.subset to extract the component properties and then use
these as a "defaults" configuration for each component.
I've changed the signature of the public loadComponent method - not
sure how safe that is - do we want to provide backwards compatibility
on that method, its safe to pass in a null additional properties
configuration.
I added the Object based setters/getters (eg getBoolean(String
key,Boolean defaultValue) ) to the Configuration interface - as this
allows us to set the defaults object from a Configuration object
without casting it to a BaseConfiguration.
The BaseConfiguration now uses the defaults Configuration in the
interpolate method - the main point of this patch.
I have changed the getStringArray method to also call interpolate on
returned values. This is because the code for accessing log4j
properties call getStringArray (cos log4j uses commas in properties)
- but also could contain ${key} stuff - ie webappRoot.
I have also changed the subset method to interpolate its values too.
This is because when you use subset to get the properties for a
service, some of those may contain ${key} stuff - which should be
expanded, if possible.
Lastly and most controversially I changed interpolate to leave
unchanged any unmatched ${key} stuff. That is, the old behaviour for
a property ${foo}/blah would be to interpolate it into /blah if there
was no previous property with a key of "foo". It now leaves it as
${foo}/blah. We need this because when the logging service (a
primary service) gets its properties using getResources,
${webappRoot} is not defined at that point. The old behaviour would
lose this information. We can then add the webappRoot property
manually and let the interpolation work.
Regards,
Chris
=====
------------------------------------------
http://www.soccer2002.org.uk
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://http://taxes.yahoo.com/
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Eric Dobbs <er...@dobbse.net>.
On Tuesday, April 2, 2002, at 08:16 AM, Chris Kimpton wrote:
>> I would prefer to do
>> this with an explicit configuration entry in
>> TurbineResources.properties like this:
>>
>> component.fulcrum.property.webappRoot=${webappRoot}
>> component.fulcrum.property.applicationRoot=${applicationRoot}
>>
>
> That is a much cleaner solution - shall I submit a patch or will you
> do it?
Go ahead and submit a patch. I'll review and commit it.
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
--- Eric Dobbs <er...@dobbse.net> wrote:
> On Monday, April 1, 2002, at 04:09 AM, Chris Kimpton wrote:
>
> > Regarding my thread on problems using Torque with Jetspeed (and
> > Turbine), and in particular accessing the /WEB-INF/ directories.
> >
> > I suggest we amend the ComponentLoader to pass the TR.props
> > configuration to each component as a "default" configuration
> behind
> > the specific component configuration.
>
> I would rather not put all of the TurbineResources.properties
> into Torque and Fulcrum. Torque doesn't need anything from
> Fulcrum's configuration, and vice versa. In the case of
> Fulcrum (which I happen to be spending more time on at the
> moment) I think some of the services configurations would
> conflict between Turbine's legacy services framework and
> what's in Fulcrum.
The patch does not merge fulcrum and torque configurations - so thats
not a problem.
The torque and fulcrum properties have priority over the
TR.properties - but I can see (for example) if you removed a
parameter from the torque properties, assuming some default setting
would be used - when in fact it would revert to your TR.properties
setting, if defined.
>
> > This allows for setting properties globally in the TR.props file.
> > For the case where Turbine is not being used, it does the same as
> it
> > does now.
> >
> > For the case where Turbine is in use, it allows the webappRoot
> > property to be defined for Torque and thus things can be defined
> > relative to that directory - eg the hsql db, or logging.
>
> It seems like the main thing you want to accomplish is to be
> able pass ${webappRoot} and ${applicationRoot} into the
> config for Torque. If that's the case, I would prefer to do
> this with an explicit configuration entry in
> TurbineResources.properties like this:
>
> component.fulcrum.property.webappRoot=${webappRoot}
> component.fulcrum.property.applicationRoot=${applicationRoot}
>
That is a much cleaner solution - shall I submit a patch or will you
do it?
Chris
=====
------------------------------------------
http://www.soccer2002.org.uk
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://http://taxes.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components
Posted by Eric Dobbs <er...@dobbse.net>.
On Monday, April 1, 2002, at 04:09 AM, Chris Kimpton wrote:
> Regarding my thread on problems using Torque with Jetspeed (and
> Turbine), and in particular accessing the /WEB-INF/ directories.
>
> I suggest we amend the ComponentLoader to pass the TR.props
> configuration to each component as a "default" configuration behind
> the specific component configuration.
I would rather not put all of the TurbineResources.properties
into Torque and Fulcrum. Torque doesn't need anything from
Fulcrum's configuration, and vice versa. In the case of
Fulcrum (which I happen to be spending more time on at the
moment) I think some of the services configurations would
conflict between Turbine's legacy services framework and
what's in Fulcrum.
> This allows for setting properties globally in the TR.props file.
> For the case where Turbine is not being used, it does the same as it
> does now.
>
> For the case where Turbine is in use, it allows the webappRoot
> property to be defined for Torque and thus things can be defined
> relative to that directory - eg the hsql db, or logging.
It seems like the main thing you want to accomplish is to be
able pass ${webappRoot} and ${applicationRoot} into the
config for Torque. If that's the case, I would prefer to do
this with an explicit configuration entry in
TurbineResources.properties like this:
component.fulcrum.property.webappRoot=${webappRoot}
component.fulcrum.property.applicationRoot=${applicationRoot}
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>