You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Paul Smith <ps...@aconex.com> on 2005/01/19 21:52:03 UTC
latest build.xml
The latest build.xml seems to _require_ that I have jms.jar to build
log4j at all. In the past, this was an optional dependency. The help
notes on build.xml says that the 'build' target will build all targets
except where dependencies are not found, which does not seem to be the
case for JMS at least.
Unfortunately I don't have time this morning to try to fix the build
file, but just FYI.
cheers,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: latest build.xml
Posted by Paul Smith <ps...@aconex.com>.
>
> When you say chainsaw could d/l those extra jars, which jar files are
> you referring to? For instance, to use DBReceiver, you also need the
> appropriate driver for your databasae system. Surely, we cannot
> provide these drivers through webstart. The same is true for
> JMSReceiver. To run JMSReceiver, you need the JMS API (the interfaces)
> but also the client-side implementation. Again, we cannot provide the
> client-side implementation through web-start.
>
No, we certainly can't download the driver jars. They would have to be
placed in the plugin directory by the end user.
> Agreed. My point is that if extra jar files are needed and cannot be
> provided automatically, then the user experience will be worse than
> the situation where you plainly state that webstart is not suitable
> for DB and JMS Receivers.
>
Not if the GUI is written well enough that clearly shows what else is
needed to be done etc. The *non*-webstart version of Chainsaw will
still need these driver jars, and the user will need to do something
by hand, I'm just trying to make that experience easier. Right now BOTH
webstart and non-webstart versions of Chainsaw are "not suitable for DB
& JMS Receivers" as you put it because of the extra work by the end
user. I don't want to provide to the community a product like Chainsaw
that cannot take advantage of all of the Receivers. In a true
enterprise environment, JMS & DB logging is going to be used a lot, so
why have Chainsaw as a 2nd class citizen? If we provide good
documentation (sadly lacking currently, but a goal of mine), then having
all Receivers work shouldn't be an issue.
Webstart has it's advantages in that it can be deployed more simply, can
receive easy updates
I'm not saying it's going to be _easy_, I'm just suggesting that it's a
worthy goal for us. If something was not developed because it was at
risk of being a source of bugs, then I wonder whether we'd develop much
at all.
cheers,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: latest build.xml
Posted by Ceki Gülcü <ce...@qos.ch>.
At 11:35 PM 1/19/2005, Paul Smith wrote:
>>OK, I see. You are trying to provide a full environment through
>>web-start. IMHO that's a waste of time at best, and in the worst case, a
>>source of confusion and bugs. As I understand it, the idea behind
>>web-start is to provide a self-contained application at click of a URL.
>>If several configuration steps are necessary, you might as well download
>>and launch the application through more conventional means.
>>Anyway, we have discussed this before and I'll go along with whatever you
>>prefer.
>What could happen inside Chainsaw though, is that it could d/l those extra
>jars and plonk them in the local directory for the user automatically.
When you say chainsaw could d/l those extra jars, which jar files are you
referring to? For instance, to use DBReceiver, you also need the
appropriate driver for your databasae system. Surely, we cannot provide
these drivers through webstart. The same is true for JMSReceiver. To run
JMSReceiver, you need the JMS API (the interfaces) but also the client-side
implementation. Again, we cannot provide the client-side implementation
through web-start.
>I don't see providing a good user experience a waste of time.
Agreed. My point is that if extra jar files are needed and cannot be
provided automatically, then the user experience will be worse than the
situation where you plainly state that webstart is not suitable for DB and
JMS Receivers.
>That's the point of a GUI, otherwise it's just easier to use grep, but
>that's not exactly a good user experience for new people...
>
>Paul
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: latest build.xml
Posted by Paul Smith <ps...@aconex.com>.
> OK, I see. You are trying to provide a full environment through
> web-start. IMHO that's a waste of time at best, and in the worst case,
> a source of confusion and bugs. As I understand it, the idea behind
> web-start is to provide a self-contained application at click of a
> URL. If several configuration steps are necessary, you might as well
> download and launch the application through more conventional means.
> Anyway, we have discussed this before and I'll go along with whatever
> you prefer.
>
What could happen inside Chainsaw though, is that it could d/l those
extra jars and plonk them in the local directory for the user
automatically.
I don't see providing a good user experience a waste of time. That's
the point of a GUI, otherwise it's just easier to use grep, but that's
not exactly a good user experience for new people...
Paul
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: latest build.xml
Posted by Ceki Gülcü <ce...@qos.ch>.
At 11:08 PM 1/19/2005, Paul Smith wrote:
>Many thanks for that!
My pleasure.
>Err, if the Appenders and Receivers are bundled in *-db.jar et al then yes
>we can drop the other webstart jar.
Yes, Appenders and Receivers are bundled in the same jar.
>The way I see it working. The user places the -db.jar or jms one in a
>local directory (the plugin directory) along with the required drivers and
>any other dependencies. this would mean that the core log4j & chainsaw
>classes are loaded via the main classloader (which turns out to be the
>Webstart classloader). The PluginClassloader is a child of this, and can
>load classes from jars/classes within the Plugin directory. This would
>mean that the JMSReceiver and DBReceiver classes can be properly loaded
>and used (I hope).
OK, I see. You are trying to provide a full environment through web-start.
IMHO that's a waste of time at best, and in the worst case, a source of
confusion and bugs. As I understand it, the idea behind web-start is to
provide a self-contained application at click of a URL. If several
configuration steps are necessary, you might as well download and launch
the application through more conventional means. Anyway, we have discussed
this before and I'll go along with whatever you prefer.
>configuration is another question entirely, and requires configuring the
>JMSReceiver or DBReceiver somehow. At the moment there's no way to do
>that in the GUI, it would have to be via an xml config I believe (I
>honestly have not tried the DB or JMS Receiver/Appender at all.
Both DBAppender/Receiver can be configured using config files in XML. Of
course, you still need the appropriate JDBC drivers. The same holds for
JMSAppender/Receiver.
>cheers,
>
>Paul Smith
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: latest build.xml
Posted by Paul Smith <ps...@aconex.com>.
Ceki Gülcü wrote:
>
> The "build" target builds everything so it's expected to fail if
> there are missing dependencies. If you just need basic log4j, you
> need to call the 'build.core' or 'log4j.jar' targets.
>
> Since it now depends on build.chainsaw instead of "build", the
> webstart target should work now.
Many thanks for that!
>
> Regarding the "webstart-dependant-receivers.jar" target, I think it is
> no longer needed in its current form since there is now log4j-jms.jar
> and log4j-db.jar.
Err, if the Appenders and Receivers are bundled in *-db.jar et al then
yes we can drop the other webstart jar.
>
> To set up a JMS connection or JDBC connection takes some effort. I
> don't see how anyone could expect JMS or JDBC to work just by clicking
> on a generic webstart URL. What am I missing?
>
The way I see it working. The user places the -db.jar or jms one in a
local directory (the plugin directory) along with the required drivers
and any other dependencies. this would mean that the core log4j &
chainsaw classes are loaded via the main classloader (which turns out to
be the Webstart classloader). The PluginClassloader is a child of this,
and can load classes from jars/classes within the Plugin directory. This
would mean that the JMSReceiver and DBReceiver classes can be properly
loaded and used (I hope).
configuration is another question entirely, and requires configuring the
JMSReceiver or DBReceiver somehow. At the moment there's no way to do
that in the GUI, it would have to be via an xml config I believe (I
honestly have not tried the DB or JMS Receiver/Appender at all. How
embarassing... :-$). Maybe one day we can improve the Receiver creation
process in Chainsaw (it's one area I'm not happy about at all).
cheers,
Paul Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: latest build.xml
Posted by Ceki Gülcü <ce...@qos.ch>.
The "build" target builds everything so it's expected to fail if there are
missing dependencies. If you just need basic log4j, you need to call the
'build.core' or 'log4j.jar' targets.
Since it now depends on build.chainsaw instead of "build", the webstart
target should work now.
Regarding the "webstart-dependant-receivers.jar" target, I think it is no
longer needed in its current form since there is now log4j-jms.jar and
log4j-db.jar.
To set up a JMS connection or JDBC connection takes some effort. I don't
see how anyone could expect JMS or JDBC to work just by clicking on a
generic webstart URL. What am I missing?
At 10:30 PM 1/19/2005, Paul Smith wrote:
>'build' doesn't work for me, nor does the 'webstart' one (which depends on
>build). the help text on 'build' says that it will only build available
>dependencies. Should this be changed?
>
>cheers,
>
>Paul
>
>Ceki Gülcü wrote:
>
>>
>>Hey Paul,
>>
>>The requirement depends on the target. Which target are you trying?
>>
>>At 09:52 PM 1/19/2005, you wrote:
>>
>>>The latest build.xml seems to _require_ that I have jms.jar to build
>>>log4j at all. In the past, this was an optional dependency. The help
>>>notes on build.xml says that the 'build' target will build all targets
>>>except where dependencies are not found, which does not seem to be the
>>>case for JMS at least.
>>>
>>>Unfortunately I don't have time this morning to try to fix the build
>>>file, but just FYI.
>>>
>>>cheers,
>>>
>>>Paul
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: latest build.xml
Posted by Paul Smith <ps...@aconex.com>.
'build' doesn't work for me, nor does the 'webstart' one (which depends
on build). the help text on 'build' says that it will only build
available dependencies. Should this be changed?
cheers,
Paul
Ceki Gülcü wrote:
>
> Hey Paul,
>
> The requirement depends on the target. Which target are you trying?
>
> At 09:52 PM 1/19/2005, you wrote:
>
>> The latest build.xml seems to _require_ that I have jms.jar to build
>> log4j at all. In the past, this was an optional dependency. The
>> help notes on build.xml says that the 'build' target will build all
>> targets except where dependencies are not found, which does not seem
>> to be the case for JMS at least.
>>
>> Unfortunately I don't have time this morning to try to fix the build
>> file, but just FYI.
>>
>> cheers,
>>
>> Paul
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: latest build.xml
Posted by Ceki Gülcü <ce...@qos.ch>.
Hey Paul,
The requirement depends on the target. Which target are you trying?
At 09:52 PM 1/19/2005, you wrote:
>The latest build.xml seems to _require_ that I have jms.jar to build log4j
>at all. In the past, this was an optional dependency. The help notes on
>build.xml says that the 'build' target will build all targets except where
>dependencies are not found, which does not seem to be the case for JMS at
>least.
>
>Unfortunately I don't have time this morning to try to fix the build file,
>but just FYI.
>
>cheers,
>
>Paul
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org