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/03/30 23:34:26 UTC

Using current Torque with Jetspeed - a few problems...

Hi,

Turbine points::

I have had to add a log4j.properties file covering the stratum,
torque and fulcrum appenders - this doesn't sound right - but maybe
this is the first time several disparate log4j-using components have
been used together?

How can you use the webappRoot stuff in the Torque.properties file -
I managed to get it to work by specifying a full path to the file.

Lastly (although this maybe a hsql config issue), I get a DB already
in use error when the Torque connection tries to work.  This will be
because the Turbine user connection is via the old turbine om stuff,
but the dbpsml stuff is done via the new torque stuff - so 2 separate
connections.  Is it easy to upgrade the turbine user stuff to the new
torque?  Or just amend the hsql config to support multiple
connections - assuming this can be done...

Jetspeed points::

The DatabasePsmlManagerService uses Torque (in the import) - I tried
to move it the late init, but that seems to never get called for that
service...

What I have now, is a system that works without dbpsml - but can
build a new torque config, compiles with it - just errors on startup
due to the connection issues above.  Thus I don't think it is worth
commiting yet.

TIA,
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>


Re: [PATCH] Re: Using current Torque with Jetspeed - log4j problem- proposed solution

Posted by Eric Dobbs <er...@dobbse.net>.
applied.  Thanks.

Chris, would you mind taking a crack at some tests for these
additions?  We're a little thin on tests in the T2 codebase
and you did a nice job in the patches to stratum.

Thanks again.
-Eric

On Tuesday, April 2, 2002, at 02:05  PM, Chris Kimpton wrote:

> I chose to effectively backport what
> torque and fulcrum do, that is, use log4j properties directly, for
> example:
>
> # An example configuration for using Log4Java, with log4j properties
> inline
> # The category name - at the end of this line - needs to match the
> logging facility name - the first log4j.
> # need this rootCategory entry to capture the torque/fulcrum etc
> logging
> services.LoggingService.logforj.log4j.rootCategory = DEBUG, logforj
> # need this category entry for the actual jetspeed logging (I don't
> know why it doesn't get covered by the root category!)
> services.LoggingService.logforj.log4j.category.logforj = DEBUG,
> logforj
> services.LoggingService.logforj.log4j.appender.logforj.file
> =${webappRoot}/WEB-INF/log/jetspeed_log4j.log
> services.LoggingService.logforj.log4j.appender.logforj =
> org.apache.log4j.FileAppender
> services.LoggingService.logforj.log4j.appender.logforj.layout =
> org.apache.log4j.PatternLayout
> services.LoggingService.logforj.log4j.appender.logforj.layout.conversionPattern
> = [%d{ABSOLUTE} %-5p] %m%n
> services.LoggingService.logforj.log4j.appender.logforj.append = false
> services.LoggingService.logforj.className=org.apache.turbine.services.logging.
> Log4JavaLogger
> services.LoggingService.logforj.level=DEBUG
>
> This gives the full flexibility of log4j - in particular allows for
> merging the torque et al logs into one, while keeping the turbine
> TR.props configuration of it.
>
> This patch relies on the stratum patches submitted earlier - in
> particular for the interpolate additions relating to getStringArray
> and subset.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


[PATCH] Re: Using current Torque with Jetspeed - log4j problem- proposed solution

Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,

> 
> --- Chris Kimpton <ki...@yahoo.com> wrote:
> > I have had to add a log4j.properties file covering the stratum,
> > torque and fulcrum appenders - this doesn't sound right - but
> maybe
> > this is the first time several disparate log4j-using components
> > have
> > been used together?
> > 
> 
> The logical solution to this seems to be to extend the turbine-2
> Log4JavaLogger to provide appenders for torque, fulcrum and
> stratum.
> 
> Thus I propose to extend the LoggingConfig to have a couple more
> properties to configure the logging facility:
> 
> ..category - set to nothing to use the root category - which is
> probably all that will make the above work together
> 
> ..layout - class to use for layout
> 
> ..layout.pattern - patten to use for layout (if PatternLayout)
> 
> ..append - true/false - whether the log file is appended to or
> started from afresh
> 
> So - the changes will affect TR.props, PropertiesLoggingConfig,
> LoggingConfig and Log4JavaLogger.
> 
> Does this sound like the correct way to solve this problem?
> 

Attached is the patch for this.  I chose to effectively backport what
torque and fulcrum do, that is, use log4j properties directly, for
example:

# An example configuration for using Log4Java, with log4j properties
inline
# The category name - at the end of this line - needs to match the
logging facility name - the first log4j.
# need this rootCategory entry to capture the torque/fulcrum etc
logging
services.LoggingService.logforj.log4j.rootCategory = DEBUG, logforj
# need this category entry for the actual jetspeed logging (I don't
know why it doesn't get covered by the root category!)
services.LoggingService.logforj.log4j.category.logforj = DEBUG,
logforj
services.LoggingService.logforj.log4j.appender.logforj.file
=${webappRoot}/WEB-INF/log/jetspeed_log4j.log
services.LoggingService.logforj.log4j.appender.logforj =
org.apache.log4j.FileAppender
services.LoggingService.logforj.log4j.appender.logforj.layout =
org.apache.log4j.PatternLayout
services.LoggingService.logforj.log4j.appender.logforj.layout.conversionPattern
= [%d{ABSOLUTE} %-5p] %m%n
services.LoggingService.logforj.log4j.appender.logforj.append = false
services.LoggingService.logforj.className=org.apache.turbine.services.logging.Log4JavaLogger
services.LoggingService.logforj.level=DEBUG

This gives the full flexibility of log4j - in particular allows for
merging the torque et al logs into one, while keeping the turbine
TR.props configuration of it.

This patch relies on the stratum patches submitted earlier - in
particular for the interpolate additions relating to getStringArray
and subset.

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 Jetspeed - log4j problem- proposed solution

Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,

--- Chris Kimpton <ki...@yahoo.com> wrote:
> I have had to add a log4j.properties file covering the stratum,
> torque and fulcrum appenders - this doesn't sound right - but maybe
> this is the first time several disparate log4j-using components
> have
> been used together?
> 

The logical solution to this seems to be to extend the turbine-2
Log4JavaLogger to provide appenders for torque, fulcrum and stratum.

Thus I propose to extend the LoggingConfig to have a couple more
properties to configure the logging facility:

..category - set to nothing to use the root category - which is
probably all that will make the above work together

..layout - class to use for layout

..layout.pattern - patten to use for layout (if PatternLayout)

..append - true/false - whether the log file is appended to or
started from afresh

So - the changes will affect TR.props, PropertiesLoggingConfig,
LoggingConfig and Log4JavaLogger.

Does this sound like the correct way to solve this problem?

Regards,
Chris

=====
------------------------------------------
http://www.soccer2002.org.uk

__________________________________________________
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>


Re: Using current Torque with Jetspeed - a few problems...

Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,

> 
> I solved (?) this by wrapping the Torque pool so that is looked
> like
> the Turbine Pool Service.  I had to mess around adding a couple of
> wrapper classes - for DB/DBConnection - as they are different types
> between Turbine and Torque.
> 

Is there any interest in this for the Turbine cvs - or shall I just
put it in Jetspeed cvs.

Regards,
Chris

=====
------------------------------------------
http://www.soccer2002.org.uk

__________________________________________________
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>


Using current Torque with Turbine - proposal to pass the ComponentLoader config onto the Components

Posted by Chris Kimpton <ki...@yahoo.com>.
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>


RE: Using current Torque with Jetspeed - a few problems...

Posted by David Sean Taylor <da...@bluesunrise.com>.
Chris,

> 
> I solved (?) this by wrapping the Torque pool so that is 
> looked like the Turbine Pool Service.  I had to mess around 
> adding a couple of wrapper classes - for DB/DBConnection - as 
> they are different types between Turbine and Torque.

This is an amazing amount of crap to go thru, and Im sorry Chris that
you got stuck with it.
I thought maybe this time upgrading the Turbine jar would be simple and
painless. Right.
Im really sick of this lack of planning and consideration for their user
base. Turbine-2 is a mess.
I vote that we work towards completely removing Torque/Peers from
Jetspeed permanently.
This will involve:

1) creating a new Jetspeed DB Service (Im working on that now - its
based on OJB an a thin layer)
	http://sourceforge.net/projects/objectbridge
2) rewriting the DB PSML to use this service
3) creating a new Security Model and dumping the old Turbine security
model


David



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Using current Torque with Jetspeed - a few problems...

Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,

--- Chris Kimpton <ki...@yahoo.com> wrote:
> 
> How can you use the webappRoot stuff in the Torque.properties file
> -
> I managed to get it to work by specifying a full path to the file.
> 
> Lastly (although this maybe a hsql config issue), I get a DB
> already
> in use error when the Torque connection tries to work.  This will
> be
> because the Turbine user connection is via the old turbine om
> stuff,
> but the dbpsml stuff is done via the new torque stuff - so 2
> separate
> connections.  Is it easy to upgrade the turbine user stuff to the
> new
> torque?  Or just amend the hsql config to support multiple
> connections - assuming this can be done...
> 

I solved (?) this by wrapping the Torque pool so that is looked like
the Turbine Pool Service.  I had to mess around adding a couple of
wrapper classes - for DB/DBConnection - as they are different types
between Turbine and Torque.

The problem still is how to specify the /WEB-INF/ directory in the
Torque.properties file - it doesn't seem to be servlet-aware - or get
past to it the ServletConfig - so it can't use getRealPath to
access/define ${webappRoot}.  Are there plans to extend
Stratum/ComponentLoader to pass this information?  Or is there
another way to track this down.

> Jetspeed points::
> 
> The DatabasePsmlManagerService uses Torque (in the import) - I
> tried
> to move it the late init, but that seems to never get called for
> that
> service...
> 

I solved this by moving the setInit(true) to the start of the late
init method - and then the importer can be done in the late init...
not ideal I know.

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>


Re: Using current Torque with Jetspeed - a few problems...

Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,

> >
> >Since torque and some of the other new components use log4j, it
> seems
> >the cleanest way forward is to default to using log4j file logging
> >for jetspeed.
> >
> >Is that ok with everyone?
> >
> I thought we were already using it, but as we are using Turbine
> logging 
> service I could be wrong. At least you could configure log4j as
> default 
> logger.
> 

I must admit that I am assuming that since the default logger
jetspeed uses is the FileLogger (not the Log4JavaLogger) that this is
a Turbine custom logger and not log4j...  but I just plan to change
the default to a new entry in the TR.props that will definitely use
the log4j logger - in a way that allows us to mix other log4j apps -
ie by defining a root category.

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 Jetspeed - a few problems...

Posted by Santiago Gala <sg...@hisitech.com>.
Chris Kimpton wrote:

>Hi,
>
>I am nearly there with this.... pending a few turbine patches to be
>committed.
>
>Anyone got any concerns with this in general?
>
>--- Chris Kimpton <ki...@yahoo.com> wrote:
>
>>Hi,
>>
>>Turbine points::
>>
>>I have had to add a log4j.properties file covering the stratum,
>>torque and fulcrum appenders - this doesn't sound right - but maybe
>>this is the first time several disparate log4j-using components
>>have
>>been used together?
>>
>
>Since torque and some of the other new components use log4j, it seems
>the cleanest way forward is to default to using log4j file logging
>for jetspeed.
>
>Is that ok with everyone?
>
I thought we were already using it, but as we are using Turbine logging 
service I could be wrong. At least you could configure log4j as default 
logger.

>
>>
>>Jetspeed points::
>>
>>The DatabasePsmlManagerService uses Torque (in the import) - I
>>tried
>>to move it the late init, but that seems to never get called for
>>that
>>service...
>>
>
>I got this working - so the dbpsml import is now done in the late
>init (due to its reliance on Torque which is loaded between early and
>late inits).
>
>Any concerns with this?  Obviously its an impact on the first user -
>but then again, it should probably be turned off once the first
>import is done anyway...
>
I have global concerns with service initialization in turbine2, but none 
specially with this.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Using current Torque with Jetspeed - a few problems...

Posted by David Sean Taylor <da...@bluesunrise.com>.
I thought we already used log4j?

> -----Original Message-----
> From: Chris Kimpton [mailto:kimptoc_mail@yahoo.com] 
> Sent: Tuesday, April 02, 2002 1:16 PM
> To: jetspeed-dev@jakarta.apache.org
> Subject: Re: Using current Torque with Jetspeed - a few problems...
> 
> 
> Hi,
> 
> I am nearly there with this.... pending a few turbine patches 
> to be committed.
> 
> Anyone got any concerns with this in general?
> 
> --- Chris Kimpton <ki...@yahoo.com> wrote:
> > Hi,
> > 
> > Turbine points::
> > 
> > I have had to add a log4j.properties file covering the 
> stratum, torque 
> > and fulcrum appenders - this doesn't sound right - but 
> maybe this is 
> > the first time several disparate log4j-using components have
> > been used together?
> 
> Since torque and some of the other new components use log4j, 
> it seems the cleanest way forward is to default to using 
> log4j file logging for jetspeed.
> 
> Is that ok with everyone?
> 
> > 
> > 
> > Jetspeed points::
> > 
> > The DatabasePsmlManagerService uses Torque (in the import) - I tried
> > to move it the late init, but that seems to never get called for
> > that
> > service...
> > 
> 
> I got this working - so the dbpsml import is now done in the 
> late init (due to its reliance on Torque which is loaded 
> between early and late inits).
> 
> Any concerns with this?  Obviously its an impact on the first 
> user - but then again, it should probably be turned off once 
> the first import is done anyway...
> 
> 
> 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>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Using current Torque with Jetspeed - a few problems...

Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,

I am nearly there with this.... pending a few turbine patches to be
committed.

Anyone got any concerns with this in general?

--- Chris Kimpton <ki...@yahoo.com> wrote:
> Hi,
> 
> Turbine points::
> 
> I have had to add a log4j.properties file covering the stratum,
> torque and fulcrum appenders - this doesn't sound right - but maybe
> this is the first time several disparate log4j-using components
> have
> been used together?

Since torque and some of the other new components use log4j, it seems
the cleanest way forward is to default to using log4j file logging
for jetspeed.

Is that ok with everyone?

> 
> 
> Jetspeed points::
> 
> The DatabasePsmlManagerService uses Torque (in the import) - I
> tried
> to move it the late init, but that seems to never get called for
> that
> service...
> 

I got this working - so the dbpsml import is now done in the late
init (due to its reliance on Torque which is loaded between early and
late inits).

Any concerns with this?  Obviously its an impact on the first user -
but then again, it should probably be turned off once the first
import is done anyway...


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 Jetspeed - a few problems...

Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,

--- Chris Kimpton <ki...@yahoo.com> wrote:
> 
> How can you use the webappRoot stuff in the Torque.properties file
> -
> I managed to get it to work by specifying a full path to the file.
> 
> Lastly (although this maybe a hsql config issue), I get a DB
> already
> in use error when the Torque connection tries to work.  This will
> be
> because the Turbine user connection is via the old turbine om
> stuff,
> but the dbpsml stuff is done via the new torque stuff - so 2
> separate
> connections.  Is it easy to upgrade the turbine user stuff to the
> new
> torque?  Or just amend the hsql config to support multiple
> connections - assuming this can be done...
> 

I solved (?) this by wrapping the Torque pool so that is looked like
the Turbine Pool Service.  I had to mess around adding a couple of
wrapper classes - for DB/DBConnection - as they are different types
between Turbine and Torque.

The problem still is how to specify the /WEB-INF/ directory in the
Torque.properties file - it doesn't seem to be servlet-aware - or get
past to it the ServletConfig - so it can't use getRealPath to
access/define ${webappRoot}.  Are there plans to extend
Stratum/ComponentLoader to pass this information?  Or is there
another way to track this down.

> Jetspeed points::
> 
> The DatabasePsmlManagerService uses Torque (in the import) - I
> tried
> to move it the late init, but that seems to never get called for
> that
> service...
> 

I solved this by moving the setInit(true) to the start of the late
init method - and then the importer can be done in the late init...
not ideal I know.

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>