You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Peter DeGregorio <pd...@comcast.net> on 2005/04/08 20:42:39 UTC
[logging] log4j 1.0.4 trace does not map to log4j 1.3 trace
I'm interested in using trace(...) and isTraceEnabled() with log4j. Jakarta
Commons Logging (JCL) version 1.0.4 indicates support for log4j 1.3, which
now includes a trace level. Shouldn't JCL which as of 1.0.4 detects whether
is is using version 1.2 or not map trace to trace. I've looked at the source
code for JCL 1.0.4 and it calls log4j 1.3 debug methods when trace is used.
I have read every post here with "trace" in the subject and do not see this
being discussed. If however, I've missed it somewhere else (like the
developers list, which I have not looked at entirely) my apologies.
-- Peter
(Message entered without [logging] on the subject line before so
resubmitted)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [Digester] How to apply rules on XML tags (SAX events) based
on previously encountered tags?
Posted by José Antonio Pérez Testa <ja...@indra.es>.
IMO you must code this logic in the Objects instantiated by Digester.
You can not take actions based on element's attributes ("MEGA",
"Preview"), but you can set properties
of objects in order to make appropiate decisions when they are called
from Digester parsing.
Soaring Eagle wrote:
>Hello,
>
>I am using Digester to create a rules engine for an application. This
>rules engine should be capable of determining what should be done for
>certain type of financial securities based on their type and the
>business event that has occured. Such rules are maintained in XML. How
>do I apply digester rules based on nested criteria in this case?
>
>For example, in the XML below, I would like to instantiate the class
>com.services.EmailAction only if the type of security is "MEGA" and
>the action is "Publish". How do i do that?
>
>--
>Thanks in advance!
>Eagle
>
><Services>
> <Security type="DUSARM">
> <Event type="Preview">
> <Action>
> <ClassName>
> com.services.EmailAction
> </ClassName>
> <ClassName>
> com.services.EmailAction
> </ClassName>
> </Action>
> </Event>
> </Security>
> <Security type="MEGA">
> <Event type="Preview">
> <Action>
> <ClassName>
> com.services.EmailAction
> </ClassName>
> <ClassName>
> com.services.EmailAction
> </ClassName>
> </Action>
> </Event>
> </Security>
></Services>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [Digester] How to apply rules on XML tags (SAX events) based on previously encountered tags?
Posted by Soaring Eagle <co...@gmail.com>.
Thank you for the responses. It looks like the responses indicate a
different way of doing what I am doing right now - though both the
responses help me understand the issue better.
This is how I am achieving the desired effect right now:
I am extending the Rule abstract class and in the begin event for
Security and Event tags, I check for required conditions. If
conditions match, I add a boolean true object on a named object stack
(named as "SecurityEventMatch"). I have another Rule object that looks
for the body of a "ClassName" tag and then instantiates the class in
the ClassName tag only of all objects on the SecurityEventMatch stack
are true. In this process, I remove all objects from the
SecurityEventMatch stack.
The above approach works fine, but is highly dependent on the xml
contents (i.e. this is not generic), is dependent on the names I use
in code.
I am thinking that this may be a usual problem for many developers and
am hoping to find a design pattern that will help here.
--Eagle.
On 4/13/05, Simon Kitching <sk...@apache.org> wrote:
> On Wed, 2005-04-13 at 09:41 -0400, Soaring Eagle wrote:
> > Hello,
> >
> > I am using Digester to create a rules engine for an application. This
> > rules engine should be capable of determining what should be done for
> > certain type of financial securities based on their type and the
> > business event that has occured. Such rules are maintained in XML. How
> > do I apply digester rules based on nested criteria in this case?
> >
> > For example, in the XML below, I would like to instantiate the class
> > com.services.EmailAction only if the type of security is "MEGA" and
> > the action is "Publish". How do i do that?
> >
> > --
> > Thanks in advance!
> > Eagle
> >
> > <Services>
> > <Security type="DUSARM">
> > <Event type="Preview">
> > <Action>
> > <ClassName>
> > com.services.EmailAction
> > </ClassName>
> > <ClassName>
> > com.services.EmailAction
> > </ClassName>
> > </Action>
> > </Event>
> > </Security>
> > <Security type="MEGA">
> > <Event type="Preview">
> > <Action>
> > <ClassName>
> > com.services.EmailAction
> > </ClassName>
> > <ClassName>
> > com.services.EmailAction
> > </ClassName>
> > </Action>
> > </Event>
> > </Security>
> > </Services>
>
> I think you could use the FactoryCreateRule to achieve this (instead of
> using ObjectCreateRule).
>
> MyActionFactory myActionFactory = new MyActionFactory();
> digester.addFactoryCreate(
> "Services/Security/Event/Action/ClassName",
> myActionFactory);
>
> where
>
> class MyActionFactory extends ObjectCreationFactory {
> public Object createObject(Attributes attributes)
> throws Exception {
> Digester d = getDigester();
>
> // here you can inspect the xml attributes on the ClassName tag,
> // and inspect any of the objects on the Digester stack in order
> // to determine what kind of object to instantiate and return.
> // Presumably there will be objects representing the current
> // Security and Event on the digester stack so their "type"
> // is accessable.
> //
> // If you don't want to create *any* object, I don't know whether
> // you can get away with returning null, or will have to return
> // some kind of NoAction dummy object.
> }
> }
>
> Is this what you wanted to achieve?
>
> Regards,
>
> Simon
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [Digester] How to apply rules on XML tags (SAX events) based
on previously encountered tags?
Posted by Simon Kitching <sk...@apache.org>.
On Wed, 2005-04-13 at 09:41 -0400, Soaring Eagle wrote:
> Hello,
>
> I am using Digester to create a rules engine for an application. This
> rules engine should be capable of determining what should be done for
> certain type of financial securities based on their type and the
> business event that has occured. Such rules are maintained in XML. How
> do I apply digester rules based on nested criteria in this case?
>
> For example, in the XML below, I would like to instantiate the class
> com.services.EmailAction only if the type of security is "MEGA" and
> the action is "Publish". How do i do that?
>
> --
> Thanks in advance!
> Eagle
>
> <Services>
> <Security type="DUSARM">
> <Event type="Preview">
> <Action>
> <ClassName>
> com.services.EmailAction
> </ClassName>
> <ClassName>
> com.services.EmailAction
> </ClassName>
> </Action>
> </Event>
> </Security>
> <Security type="MEGA">
> <Event type="Preview">
> <Action>
> <ClassName>
> com.services.EmailAction
> </ClassName>
> <ClassName>
> com.services.EmailAction
> </ClassName>
> </Action>
> </Event>
> </Security>
> </Services>
I think you could use the FactoryCreateRule to achieve this (instead of
using ObjectCreateRule).
MyActionFactory myActionFactory = new MyActionFactory();
digester.addFactoryCreate(
"Services/Security/Event/Action/ClassName",
myActionFactory);
where
class MyActionFactory extends ObjectCreationFactory {
public Object createObject(Attributes attributes)
throws Exception {
Digester d = getDigester();
// here you can inspect the xml attributes on the ClassName tag,
// and inspect any of the objects on the Digester stack in order
// to determine what kind of object to instantiate and return.
// Presumably there will be objects representing the current
// Security and Event on the digester stack so their "type"
// is accessable.
//
// If you don't want to create *any* object, I don't know whether
// you can get away with returning null, or will have to return
// some kind of NoAction dummy object.
}
}
Is this what you wanted to achieve?
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
[Digester] How to apply rules on XML tags (SAX events) based on previously encountered tags?
Posted by Soaring Eagle <co...@gmail.com>.
Hello,
I am using Digester to create a rules engine for an application. This
rules engine should be capable of determining what should be done for
certain type of financial securities based on their type and the
business event that has occured. Such rules are maintained in XML. How
do I apply digester rules based on nested criteria in this case?
For example, in the XML below, I would like to instantiate the class
com.services.EmailAction only if the type of security is "MEGA" and
the action is "Publish". How do i do that?
--
Thanks in advance!
Eagle
<Services>
<Security type="DUSARM">
<Event type="Preview">
<Action>
<ClassName>
com.services.EmailAction
</ClassName>
<ClassName>
com.services.EmailAction
</ClassName>
</Action>
</Event>
</Security>
<Security type="MEGA">
<Event type="Preview">
<Action>
<ClassName>
com.services.EmailAction
</ClassName>
<ClassName>
com.services.EmailAction
</ClassName>
</Action>
</Event>
</Security>
</Services>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [logging] log4j 1.0.4 trace does not map to log4j 1.3 trace
Posted by Simon Kitching <sk...@apache.org>.
Hi Peter,
Thanks for submitting your patch.
Files can be attached in bugzilla by clicking on the link "Create a New
Attachment". However for a patch of this size just pasting it in is ok
too.
Note that all comments made on the bugzilla entry get sent as emails to
the commons-dev list automatically, so there's normally no need to send
follow-up emails to the commons-dev or commons-user list (unless you
aren't getting any response to a bugzilla entry, or you explicitly want
commons-user members to be aware of the discussion re a bug entry).
I'll put my followup questions/comments into bugzilla.
Regards,
Simon
On Wed, 2005-04-13 at 10:06 -0400, Peter DeGregorio wrote:
> I have submitted a bug report and patch
> http://issues.apache.org/bugzilla/show_bug.cgi?id=34437.
>
> Thanks for offering advice on the patch. It turns out the mod was easy as
> JCL 1.0.4 already detects the log4j version and so backwards compatibility
> is preserved. Regarding the patch I made, I pasted the patch into the bug
> description rather than attaching it as a file because I did not see a way
> to do that. Is that the way it should be done?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [logging] log4j 1.0.4 trace does not map to log4j 1.3 trace
Posted by Peter DeGregorio <pd...@comcast.net>.
I have submitted a bug report and patch
http://issues.apache.org/bugzilla/show_bug.cgi?id=34437.
Thanks for offering advice on the patch. It turns out the mod was easy as
JCL 1.0.4 already detects the log4j version and so backwards compatibility
is preserved. Regarding the patch I made, I pasted the patch into the bug
description rather than attaching it as a file because I did not see a way
to do that. Is that the way it should be done?
Regards,
Peter
----- Original Message -----
From: "Simon Kitching" <sk...@apache.org>
Newsgroups: gmane.comp.jakarta.commons.user
Sent: Tuesday, April 12, 2005 10:45 PM
Subject: Re: [logging] log4j 1.0.4 trace does not map to log4j 1.3 trace
> Yep, I agree with Robert :-).
>
> I suspect it's not too hard, but not trivial either; JCL would need to
> detect whether log4j 1.3 was present (vs 1.2) and if so call different
> methods. Of course full backwards compatibility needs to be retained.
> And performance needs to be kept in mind.
>
> I would personally be happy to see such a patch committed to jcl, so if
> you want this, please submit a patch via bugzilla or this list! If you
> need any advice while working on the patch, feel free to ask.
>
> Cheers,
>
> Simon
>
> On Mon, 2005-04-11 at 22:00 +0100, robert burrell donkin wrote:
>> submit a patch :)
>>
>> - robert
>>
>> On Fri, 2005-04-08 at 14:42 -0400, Peter DeGregorio wrote:
>> > I'm interested in using trace(...) and isTraceEnabled() with log4j.
>> > Jakarta
>> > Commons Logging (JCL) version 1.0.4 indicates support for log4j 1.3,
>> > which
>> > now includes a trace level. Shouldn't JCL which as of 1.0.4 detects
>> > whether
>> > is is using version 1.2 or not map trace to trace. I've looked at the
>> > source
>> > code for JCL 1.0.4 and it calls log4j 1.3 debug methods when trace is
>> > used.
>> >
>> > I have read every post here with "trace" in the subject and do not see
>> > this
>> > being discussed. If however, I've missed it somewhere else (like the
>> > developers list, which I have not looked at entirely) my apologies.
>> >
>> > -- Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [logging] log4j 1.0.4 trace does not map to log4j 1.3 trace
Posted by Simon Kitching <sk...@apache.org>.
Yep, I agree with Robert :-).
I suspect it's not too hard, but not trivial either; JCL would need to
detect whether log4j 1.3 was present (vs 1.2) and if so call different
methods. Of course full backwards compatibility needs to be retained.
And performance needs to be kept in mind.
I would personally be happy to see such a patch committed to jcl, so if
you want this, please submit a patch via bugzilla or this list! If you
need any advice while working on the patch, feel free to ask.
Cheers,
Simon
On Mon, 2005-04-11 at 22:00 +0100, robert burrell donkin wrote:
> submit a patch :)
>
> - robert
>
> On Fri, 2005-04-08 at 14:42 -0400, Peter DeGregorio wrote:
> > I'm interested in using trace(...) and isTraceEnabled() with log4j. Jakarta
> > Commons Logging (JCL) version 1.0.4 indicates support for log4j 1.3, which
> > now includes a trace level. Shouldn't JCL which as of 1.0.4 detects whether
> > is is using version 1.2 or not map trace to trace. I've looked at the source
> > code for JCL 1.0.4 and it calls log4j 1.3 debug methods when trace is used.
> >
> > I have read every post here with "trace" in the subject and do not see this
> > being discussed. If however, I've missed it somewhere else (like the
> > developers list, which I have not looked at entirely) my apologies.
> >
> > -- Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [logging] log4j 1.0.4 trace does not map to log4j 1.3 trace
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
submit a patch :)
- robert
On Fri, 2005-04-08 at 14:42 -0400, Peter DeGregorio wrote:
> I'm interested in using trace(...) and isTraceEnabled() with log4j. Jakarta
> Commons Logging (JCL) version 1.0.4 indicates support for log4j 1.3, which
> now includes a trace level. Shouldn't JCL which as of 1.0.4 detects whether
> is is using version 1.2 or not map trace to trace. I've looked at the source
> code for JCL 1.0.4 and it calls log4j 1.3 debug methods when trace is used.
>
> I have read every post here with "trace" in the subject and do not see this
> being discussed. If however, I've missed it somewhere else (like the
> developers list, which I have not looked at entirely) my apologies.
>
> -- Peter
>
> (Message entered without [logging] on the subject line before so
> resubmitted)
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
--
robert burrell donkin <ro...@blueyonder.co.uk>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org