axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@macromedia.com>
Subject Today's IRC chat log
Date Tue, 16 Jul 2002 19:56:37 GMT

[12:37] *** Glen-lunch is now known as GlenDaniels
[12:59] <GlenDaniels> gonna grab some coffee before the chat
[12:59] <GlenDaniels> brb
[13:00] <RichShirley> I'll be back in a few minutes for the chat
[13:00] *** SamRuby has joined #ApacheAXIS
[13:02] <GlenDaniels> OK, I gots my coffee, and am rarin' to go.  Hi Sam!
[13:03] <GlenDaniels> Anyone know if Mr. Sitze is planning to join us today?
[13:07] <RussellButek> I'll see if I can find Mr Sitze.
[13:09] <RussellButek> He's around, but he's been reconfiguring his hardware, so he
doesn't know if he has irc right now.
[13:09] <RichShirley> He's trying to log in right now
[13:11] <GlenDaniels> Hohokay
[13:11] <GlenDaniels> tnx
[13:11] <GlenDaniels> I wanted to discuss the output proliferation stuff
[13:11] *** Glyn has joined #ApacheAXIS
[13:12] <RussellButek> On another topic, until Richard joins us, Rahul sounds like he'll
join our telecon tomorrow.  Do folks agree with my 3 points about the doc/lit issue?
[13:12] <RichShirley> I agree
[13:12] <RussellButek> Rahul's email about it doesn't really seem to answer our concerns.
[13:13] <GlenDaniels> Could you summarize again here?  This is the wrapped thing, right?
[13:14] <RichShirley> Yes, we need to know the exact pattern for doing wrapped.
[13:14] *** sitze has joined #ApacheAxis
[13:14] <GlenDaniels> +1
[13:15] <GlenDaniels> Hi Richard!
[13:15] <RussellButek> Right.  My first point essentially says that the TCK wrapped
test doesn't exactly follow the JAX-RPC example.
[13:15] <RussellButek> My second point states that the spec allows two interpretations
for the example, whereas the test requires the first.
[13:15] <sitze> Greetings all.
[13:16] <RichShirley> Hey I thought they were my points :-)
[13:16] <RussellButek> Lastly is the issue with binding info affecting the SEI.
[13:16] <RussellButek> Sorry, Rich.  The points in my note...
[13:16] <GlenDaniels> The points from "R, of IBM" :)
[13:16] <RussellButek> yeah!
[13:16] <GlenDaniels> Yes, I agree with those points.
[13:17] <RichShirley> :-)
[13:17] <SamRuby> Would a spec erratta address the issue?
[13:17] <Glyn> SEI?
[13:17] <RussellButek> SEI - Service Endpoint Interface - the interface generated from
the WSDL.
[13:17] <Glyn> Russell: thanks
[13:18] <RussellButek> Sam, a spec errata COULD address the issue if it clearly stated
the wrapped pattern and removed the alternate mapping.
[13:18] <RussellButek> We follow the alternate mapping.  The TCK requires the first
mapping.
[13:19] <SamRuby> For consistency (portability of source code) wouldn't it be better
if there were only one mapping?
[13:19] <GlenDaniels> Nope
[13:19] <RussellButek> Yes.  But we also follow the .NET pattern.  The spec and .NET
seem to follow a pattern.  The TCK didn't follow this same pattern, at least not our understanding
of the pattern.
[13:19] <GlenDaniels> If there are attributes on the top-level (wrapper) element, you're
hosed if you try to wrap.
[13:19] <GlenDaniels> (unless you tweak the method signature to account for the attributes....)
[13:20] <RussellButek> That's easy.  If there are attributes, you can't unwrap it.
[13:20] <GlenDaniels> ?
[13:20] <SamRuby> Glen: I don't see how you are arguing against there being only one
mapping, only that you feel that Axis's is better.  Did I misunderstand?
[13:20] <RichShirley> Right, but we need to know the rule to follow...none of the specs
specify the rule.
[13:20] <RussellButek> It's things like that that MUST be clearly defined.
[13:20] <RussellButek> What Glen said.
[13:20] <GlenDaniels> Yes. I like that you *can* wrap, and there are times to do it.

[13:21] <GlenDaniels> I'd rather not always be forced into the "Bean" mapping.
[13:21] <RichShirley> Glen: +1
[13:21] <RussellButek> An example is not a rule.  All JAX-RPC has is an example.
[13:21] <GlenDaniels> But if a) there is one part, b) it's an element, c) the element
QName matches the operation, and d) there are no attributes... wrap away
[13:21] <GlenDaniels> otherwise, I think don't. :)
[13:22] <RussellButek> That sounds about right.  With little caveats all over - like
what to do with attributes.
[13:22] <GlenDaniels> I'd say we should punt when there are attributes, and just don't
wrap, and allow the bean mapping to deal.
[13:22] <RussellButek> And should this ONLY occur with doc/lit or always when the pattern
is encountered?
[13:22] <GlenDaniels> seems simplest
[13:22] <GlenDaniels> only doc/lit!
[13:22] <RichShirley> e) the element is referenced via an element= in the part
[13:22] <GlenDaniels> RPC is already "wrapped" for you
[13:23] <GlenDaniels> That's (b), Rich :)
[13:23] <RussellButek> But then we have my point #3 problem.
[13:23] <GlenDaniels> um... (scrolling back furiously)
[13:23] <GlenDaniels> oh, binding affecting the SEI
[13:23] <RussellButek> If we have 2 bindings, one doc/lit, the other RPC, then we could
have two different SEI's with the same name.
[13:23] <RichShirley> I think wrapped should apply to both RPC and doc/lit in order
to retain the same SEI
[13:23] <RussellButek> Rich.  +1
[13:23] <GlenDaniels> How do you apply wrapped to RPC?
[13:24] <RussellButek> The same way we do with the .NET pattern.
[13:24] <RussellButek> We're talking Java API here, not SOAP message.
[13:24] <GlenDaniels> You're talking about RPC/literal then, which is out of scope.
[13:25] <RussellButek> no I'm not.
[13:25] * SamRuby sighs
[13:25] <RichShirley> The point is that the same rules need to be followed in all cases
in order to preserve the SEI
[13:25] * GlenDaniels looks over at Sam quizzically
[13:25] <RussellButek> Say the element name is E.  E contains A and B.
[13:25] <GlenDaniels> But the rules are different for RPC and lit, n'est-ce pas?
[13:26] <RussellButek> If we don't wrap this, a method m with look like void m(E);
[13:26] <RussellButek> If we DO wrap this, we have void m(A, B).
[13:26] <RussellButek> That changes the SEI.
[13:26] <SamRuby> If Sun hears this type of discussion, we will not likely get what
we want or further phone calls.
[13:26] <GlenDaniels> Right, but according to WSDL, you shouldn't have RPC combined
with <part element="">
[13:26] <RussellButek> The SEI SHOULD NOT CHANGE.
[13:26] <RichShirley> Russell: your example breaks the rule...the Element can only contain
one element.
[13:26] <GlenDaniels> Sam: whyzzat?  Are we subconsciously Sun-bashing?
[13:26] <RussellButek> ?
[13:27] <RussellButek> Glen, you can't have part element="" for RPC?
[13:27] <RichShirley> What are the parm names for A and B ?
[13:27] <SamRuby> Independent of the what the rules are, we need to figure out what
we want.  Do we want the spec fixed or the test thrown out.  It sounds like Rahul is more
likely to accept the former.
[13:27] <RussellButek> Rich, E is a schema element, not the message.
[13:27] <GlenDaniels> Russell: I think that is indeed the case.
[13:27] <RussellButek> Glen, let me look at the spec....
[13:28] <RichShirley> The parameters come from the name of the message part...thus A
and B will have the same parameter names
[13:28] <GlenDaniels> Ah, sorry, you can't have encoded + element
[13:28] <GlenDaniels> You can have RPC + element
[13:28] <GlenDaniels> That's RPC/literal
[13:29] <RichShirley> Where does it say you can't have encoded + element ?
[13:29] <GlenDaniels> 3.5, third para after the example XML
[13:29] <GlenDaniels> "If use is encoded, then..."
[13:30] <GlenDaniels> And the WSDL spec is pretty insistent (if not clear :)) about
the following.  In RPC mode, there WILL BE a wrapper element which is the name of the operation.
 In doc mode, there WILL NOT.
[13:31] <RussellButek> So if we have an element, the binding had better be doc/lit.
 If not, it's an error.
[13:31] <GlenDaniels> That is our prerogative.  We can choose to deal with it, or fault.
 Right now we take our best shot.
[13:31] <RussellButek> Conversely, if the message has a type, then the bidning had better
be rpc/encoded.
[13:32] <RussellButek> So we know, without looking at the binding, what the binding
must be.
[13:32] <RichShirley> I assume that if type= is used, the type is never wrapped...always
treated as a bean.
[13:32] <GlenDaniels> Not necessarily (of course).
[13:32] <GlenDaniels> All combos are legal, but we don't have to support them all.
[13:33] <GlenDaniels> Those two hairy paragraphs in 3.5 do define the rules, though
they're a bit... opaque.
[13:33] <RussellButek> This all assumes we punt on rpc/lit and doc/encoded, right?
[13:33] <RussellButek> All we MUST support is rpc/encoded and doc/lit, right?
[13:33] <GlenDaniels> I believe that is correct.
[13:34] <SamRuby> For what it is worth, WS-I is heading towards doc/lit and rpc/lit.
 And having rpc imply type and doc imply element.
[13:34] <RussellButek> Then my statements are correct.  We don't need the binding to
know what we've got, wrapped or beaned.
[13:34] <GlenDaniels> So if we see a WSDL with <part element=""> and then there
is an RPC binding, we can fault if we want
[13:34] <RussellButek> OK.  By the way, this is all new to me, but I think I can live
with it.
[13:35] <SamRuby> We can live with what?
[13:35] <RichShirley> New to me too...we should change Axis to refuse element= for encoded...this
will require rewriting some tests.
[13:35] <RussellButek> So back to the TCK.  If an errata would explicitly give the wrapped
rules, than I can live with an errata.
[13:35] <RichShirley> I also think Axis should be changed to force wrapping if element=
is used.
[13:36] <RichShirley> Russ: + 1
[13:36] <RussellButek> (as long as it's not too different than the implicit .NET rules)
[13:36] <GlenDaniels> Rather than faulting, can we do something else like mangle the
names and have two different SEIs if there are multiple bindings?
[13:36] <RussellButek> Rich, and fault if there is more than 1 part.
[13:37] <GlenDaniels> I rather like that we pretty much deal with RPC/lit now, and it
would be a shame for that to disappear, I think.
[13:37] <RussellButek> The spec used to allow us to do this, Glen.  It doesn't now.
[13:37] <GlenDaniels> could you elucidate a bit more?
[13:38] <RussellButek> The spec says the SEI name comes from the portType name.  Period.
 It used to say that, if the binding affects the SEI, then the SEI name comes from the binding
name.  But that statement is gone.
[13:38] <GlenDaniels> ah
[13:39] <RussellButek> (this is a problem with mime attachments, too - see my axis-tck
note)
[13:39] <RussellButek> Are we all on the same page for the TCK discussion with Rahul?
 If he gives us a clear set of rules for wrapped, we can follow them?
[13:41] <GlenDaniels> Yup.  Why don't we give him a clear set of rules and see if he
likes them.  That should make life a bit easier for him.
[13:41] <SamRuby> Glen: +1
[13:41] <RussellButek> Sure, you wanna respond to my note to him?  Give him the rules
you stated above?
[13:41] <GlenDaniels> Will do.
[13:41] <RussellButek> thanks.  On to logging?
[13:42] <GlenDaniels> Ya mon.
[13:42] <GlenDaniels> So, Richard....  :)
[13:42] <RussellButek> Rich, nudge Rich.
[13:42] <SamRuby> To the best of our knowledge, would the RI follow those rules?
[13:42] <sitze> Sure, I'm for reforestation myself...
[13:42] <GlenDaniels> Sam : probably NOT right now.  It would have to once they publish
them.
[13:42] <RussellButek> Sam, dunno.  The TCK doesn't follow OUR(and .NET's) rules.
[13:43] <RussellButek> The TCK's schema element isn't the same name as the operation.
 That's one of our rules.
[13:43] <GlenDaniels> IMHO, that's a good one. :)
[13:43] <RussellButek> The spec example DOES follow our rules, so we clearly don't know
what Rahul's rules would be.
[13:44] <GlenDaniels> OK... logging/output
[13:44] <sitze> That's an interop rule, but doesn't have to be required... (but you've
probably already hashed that out quite a bit..).
[13:44] <GlenDaniels> I think there is some consensus here that our current test runs
produce too much output.
[13:44] * GlenDaniels gazes meaningfully at Richard
[13:44] <GlenDaniels> So... what can we do about it to make everyone happy? :)
[13:45] <sitze> OK, let's talk about it.  First question - is the output correct?
[13:45] <GlenDaniels> What do you mean by "correct"?
[13:45] <GlenDaniels> Should we be seeing it?  I think no.
[13:45] <sitze> Is it what you want to see in production?  
[13:45] <GlenDaniels> This is stuff like stack traces for expected (caught) exceptions....
[13:46] <sitze> expected?  Expected and dealt with or expected and logged as error?
[13:46] <GlenDaniels> If a production system catches and deals with an Exception, I
don't think it needs to be logged.
[13:46] <GlenDaniels> Expected, and dealt with.  I.e. "this test should fail in this
way - ah, good, it did.  Success."
[13:47] <RussellButek> There are a number of calls to log.info(JavaUtils.getMessage("toAxisFault00",
e);"  Should these be log.debug(...)?
[13:47] <sitze> Ahh...  the key to your comment is "test".  If a test is testing an
exception, then you should expect to see exceptional output. :-)
[13:47] <sitze> Russ: no
[13:47] <GlenDaniels> Um... what?
[13:48] <RichShirley> Huh ?
[13:48] <GlenDaniels> "exceptional output" for a test that expects an Exception would
be when there is NO exception.
[13:48] <GlenDaniels> (ha!  mine was just as confusing as yours! :))
[13:48] <sitze> (you win)
[13:49] <sitze> Seriously, you should expect to see stack traces in a test-for-proper-exception-handling.
[13:49] <GlenDaniels> NO
[13:49] <GlenDaniels> -1
[13:49] <GlenDaniels> nyet
[13:49] <sitze> YES
[13:49] <sitze> Why did it fail.  FORGET that it is a test for the moment.
[13:49] <GlenDaniels> OK, we agree to disagree.  Others?
[13:49] <RichShirley> You should see stack-traces for unexpected exceptions not the
expected ones
[13:50] <Glyn> I wonder who is running tests in production? Sounds like a non-profit
making organisation to me! But seriously, who cares about tests unless we are talking about
build logs.
[13:50] <GlenDaniels> It didn't fail, because it threw the expected Exception.
[13:50] <sitze> Glen, let's talk this through.
[13:50] <RussellButek> IT IS UP TO THE CLIENT TO DECIDE WHICH EXCEPTIONS TO EXPOSE!
[13:50] <RussellButek> If you turn debugging on, that's a different story.
[13:50] <GlenDaniels> Richard : I didn't mean to imply we were done talking... just
that I wanted to get other opinions.
[13:50] <RichShirley> Bottom line. The tremendous amount of output has caused us to
miss errors... The point of the tests is to identify errors.
[13:50] <SamRuby> The only output of tests should be "pace notes" (i.e., running test
foo) and actionable items (things that one should have to fix).
[13:50] <GlenDaniels> +1 Sam
[13:50] <sitze> Russ: we don't have that level of control.  NONE of the logging toolkits
grant that to us.  We would be breaking new ground if we did (which isn't bad).
[13:51] <GlenDaniels> Also +1 to Russell's LOUD NOTE above :)
[13:51] <GlenDaniels> Richard - of course we do.
[13:51] <sitze> Rich: that's A DIFFERENT problem, that can be dealt with in other ways.
 You DON'T go breaking production rules to satisfy testers.
[13:51] <GlenDaniels> Exceptions should be logged in the places where they end up, if
at all.
[13:52] <GlenDaniels> If they end up somewhere that eats them and deals with them without
logging them, that's perfectly fine.  You can't force logging in all cases, and shouldn't.
[13:52] <sitze> Sam: the problem is that we are dumping our "log" message to the screen.
[13:52] <sitze> Since AXIS is middleware, it doesn't have any other form of output.
 Just logs.
[13:52] <GlenDaniels> I don't even think these things should be logged to INFO, to tell
you true.
[13:52] <GlenDaniels> DEBUG, ok.
[13:52] <sitze> Glen:  Where/how?
[13:53] *** ChrisHaddad has joined #ApacheAxis
[13:54] <sitze> Exceptions should be logged PERIOD.  If you have a production problem
that isn't resolved appropriately by the system, then you must have a record in the logs to
be able to go back and resolve the problems.  First Failure Problem Identification.
[13:55] <sitze> DEBUG NO.  INFO, ERROR yes
[13:55] <RichShirley> Fine then change the tests to log the expected exceptions in a
different place so they don't pollute the screen.
[13:55] <SamRuby> Playing devils advocate for the moment: what important output would
we lose if we didn't log to the "screen"?
[13:55] <GlenDaniels> So you're one of these guys who owns a lot of land in the plains
states on which to build all the warehouses where you're gonna store all the logs of all these
zillions of "normal" exceptions, huh? :)
[13:55] <sitze> Even better would be a way to enable/disable EXCEPTIONS across log-levels...
[13:56] <rickr> Can we put something in our logging code that test for a class (the
testing framework) and an static flag that says expect an a error maybe even the exact exception
and then choose not to log it?  If a production enviroment that test framework class would
be there.
[13:56] <rickr> not be there /
[13:56] <sitze> Rich: would be nice, but since they are INFO (and should be), you will
miss other "stuff" that you folks want to see.
[13:56] <GlenDaniels> I really, truly believe that it is up to the CATCHER of a given
exception to decide whether or not to log it at all.
[13:58] <GlenDaniels> So where, in particular, are these log.info() calls right now
which are biting us?
[13:58] <sitze> rickr: I would agree - that lets the customer decide in an appropriate
manner.  By forcing the customer to have debug level on means that in order to obtain "first
failure capture" requires an order of magnitude MORE warehouse than Glen has already assessed
to be in my possession.
[13:58] <RussellButek> Sam, it appears that the exceptions that we're seeing are the
ones that are converted to AxisFault.  I'm not sure that's all of them.
[13:59] <sitze> Glen: I agree, and in a business environ, the CATCHER may have that
imposed on him.. and in this is one such case ;-)
[14:00] <sitze> May I suggest an "alternate" test mech?
[14:01] <RussellButek> Wait just a moment.  I BELIEVE most(all?) of the offending stack
dumps are associated with changing an exception from the real exception to an AxisFault. 
I agree that it's a good idea to keep track of the original exception when one exception is
caught and another is thrown.  HOWEVER, AxisFault CONTAINS the other exception, so there is
no reason to log this change.
[14:02] <GlenDaniels> Personally, I agree w/Russell.
[14:02] <RussellButek> Therefore, all log.info(JavaUtil.getMessage("toAxisFault00"),
e) statements should be debug.
[14:02] <sitze> You have no guarentee that the AxisFault is going to be delivered across
the wire....  If you would log that 'last' exception fully JUST before sending it back across
the wire, then OK.
[14:03] <GlenDaniels> That is, IMHO, the appropriate place for such logging if you want
to do it.
[14:03] <Glyn> I disagree. What about exceptions that are known to be serious or fatal
at the point they are thrown. I think these should always be logged before being thrown.
[14:03] <GlenDaniels> Sure, Glyn.  That's up to the component.
[14:04] <SamRuby> Glyn: I don't think that the AxisFault constructor is one of those
cases...
[14:04] <Glyn> Good. I didn't like always leaving it up to the catcher.
[14:04] <RussellButek> Glyn, but we've already got an exception.  It's just being changed
to AxisFault.  At the point where it's being changed, we don't have to log it.
[14:04] <GlenDaniels> I don't think that every code path should be entirely silent until
the top.
[14:04] <Glyn> Sam: agreed
[14:04] <Glyn> Russell: agreed
[14:04] <GlenDaniels> So where are these calls?
[14:04] <GlenDaniels> My IDE is busy building JRun in the background...
[14:05] <Glyn> Gotta go. Interesting chat. Must loook up "punt on" in an American dictionary...
Bye!
[14:05] <RussellButek> JavaProvider.  FaultableHandler, Call, JWSProcessor, EJBProvider.
[14:05] *** Glyn has quit IRC (Quit: )
[14:05] <sitze> I'd still like to propose modifications to the current test framework...
[14:06] <RussellButek> Richard, just curious.  How do I turn off all logging messages
in 'ant functional-tests'?
[14:07] <RussellButek> I wanna see what we'd miss.
[14:07] <GlenDaniels> I don't see this in JavaProvider...?
[14:07] <sitze> You have to modify the log4j.properties file (easiest for me).
[14:08] <RussellButek> Glen, search for "toAxisFault"
[14:09] <GlenDaniels> got it thanks
[14:09] <GlenDaniels> So OK, VOTE:
[14:09] <GlenDaniels> s/log.info/log.debug/ in these cases?
[14:09] <GlenDaniels> +1
[14:09] <RussellButek> Rich, what do I change in log4j.properties?
[14:09] <sitze> NO VOTE YET.  You haven't heard me out.
[14:09] <GlenDaniels> oh
[14:10] <GlenDaniels> ok
[14:10] * GlenDaniels listens
[14:10] <RichShirley> I think they were trying to herd you out.
[14:10] <GlenDaniels> ar ar ar
[14:10] <RichShirley> :-)
[14:10] <sitze> It still seems to me that your concern is the *TEST* problems, NOT the
production environment.
[14:10] <GlenDaniels> He's not cowed, though! :)
[14:11] <GlenDaniels> For me, at least, it's both.
[14:11] <sitze> Rickr proposed exactly what we need for production, that would help
with your test (bmooo).
[14:11] <RichShirley> I think the point is that the logging AxisFault is redundant in
either case.
[14:11] <RussellButek> For me it's both.  This is an unnecessary log as long as we don't
lose the original exception info.
[14:11] <sitze> We need a switch that turns Exception logging (at info level) on/off
independent of the log level threshold.
[14:12] <sitze> So... follow this through:
[14:12] <GlenDaniels> sitze: Sure
[14:12] <RussellButek> It's certainly unnecessary in Call.  You could argue that the
server-side ones are still necessary, but if we log it JUST before going across the wire,
that should be enough.
[14:12] <sitze> 1.  Remove unnecessary exception logging... AxisFaults get logged once
before we put them on the wire.
[14:12] <RichShirley> How about an axis logging interface...sorry couldn't help myself.
 Slap me.
[14:13] <sitze> 2.  On the wire means "literally", and (client-side) just before we
cross the barrier from "axis" to "user" code.
[14:13] * GlenDaniels slaps Rich :)
[14:14] <sitze> 3.  Switch for this faulure-capture logging, independent of log-levels.
[14:14] <sitze> 4.  Turn off logging-to-screen in tests, turn on logging-to-file for
tests.
[14:16] <sitze> 5.  Part of testing framework is to capture "good logs" in CVS, and
compare with newly generated logs.  Diff can be taught to ignore IP's and other variances.
 Test passes if diff same, test fails otherwise.  Tester analyzes that ONE log (one log file
per test) and either adjusts diff, checks in new log to CVS, or corrects code.
[14:16] <sitze> OK.  I'm done for now.
[14:16] <GlenDaniels> (sorry, phone call)
[14:17] <GlenDaniels> okback
[14:17] <GlenDaniels> (reading)
[14:17] <SamRuby> I agree with step #1.  ;-)
[14:17] <GlenDaniels> Step 1 : +1!
[14:18] <GlenDaniels> #2 : Sure.
[14:18] <RussellButek> I agree with 1.  I agree with the first part of 2.  I don't agree
with the client statement in 2.  That's for the client to decide.
[14:18] <GlenDaniels> So Call tosses the exception up, and that's it
[14:18] <sitze> Russ: client doesn't have our logging interface, and YOU will have to
go debug it one day :-)
[14:19] <SamRuby> TcpTunnel
[14:19] <GlenDaniels> Richard is suggesting a switch though.
[14:19] <RussellButek> Just FYI, I turned logging to ERROR in log4j.properties and got
rid of all but one of the offending stack traces.
[14:19] <sitze> Russ:  that's the difference between a simple API and middleware...
we have go to be proactive.
[14:19] <GlenDaniels> Seems like we wouldn't even need a separate switch API... just
the logging API should do it.
[14:20] <GlenDaniels> We can have a "serverExceptions" logger and a "clientExceptions"
logger, which you configure just like any others.
[14:21] <RussellButek> I don't like 5.  We already have the test reporting success or
failure.  We don't need another mechanism to do that.
[14:21] <sitze> Glen/Russ: when I originally put this all in (at info), I raised the
threshold to error... you folks weren't happy about that back then because it took out to
much.  You wanted to see more.  I'm OK with that solution, just FYI.
[14:21] <sitze> It leaves the logs, automates the varification that the output is as-expected,
which is why you wanted to see it in the first place, etc.
[14:22] <RussellButek> Hmmm...  I've no clue why I would have complained.  It looks
OK to me.  Or did we log more stuff before?  I think the tests just dump to System.out.
[14:23] <RussellButek> brb
[14:25] <sitze> Russell: the current test mechanism isn't good enough for testing exceptions.
 You have to look at the stacktrace & other info to verify that the exception was generated
in the expected spot, handled correctly, etc.  Today, we only know that we got an exception...
but little more.  It's broken folks.
[14:27] <GlenDaniels> I think confirming that the Exception is what you expect (type)
is sufficient.
[14:27] <GlenDaniels> Yes, scanning the stacktrace to make sure it came from exactly
the right place is a good test too, but what you're really testing is from your POV, the inputs
you tossed in generated the expected result (a particular Exception)
[14:27] <sitze> Ah..no.   AxisFault is a wrapper... remember.
[14:28] <sitze> The expected result is not necessarily correct... AxisFault may be expected,
but it can be generated many ways.
[14:28] <GlenDaniels> So you check the fault code, and potentially the wrapped exception.
[14:29] <GlenDaniels> Side question - what's the equivalent of what used to be msg.getSOAPPart().getAsString()?
[14:29] <sitze> Is that done today?  Even so, are you sure that something else didn't
generate a similar exception?  Are you SURE axis is functioning correctly?
[14:29] <GlenDaniels> getSOAPPart().toString()?
[14:30] <sitze> I've no idea.. is anyone else out there?
[14:30] <GlenDaniels> Rick?
[14:30] <GlenDaniels> Hellooooooooooooooo....
[14:31] <rickr> Hello
[14:31] <GlenDaniels> (see Q above)
[14:31] <rickr> I'v not made any changes  in that code for ages.
[14:31] <GlenDaniels> ah
[14:31] <GlenDaniels> Dims would probably be the culprit then.
[14:32] <rickr> Probably.  Something wrong in that area?
[14:32] <rickr> Glen. Sound right to me.
[14:33] <sitze> say hello
[14:33] <sitze> hello
[14:33] <RussellButek> Richard.  Feel free to slap me up a bit.  (a new source for enlightenment
- bathroom tiles)  I see the light (or dark) of logging.  In a monstrous system, you need
CYA logging.  That logging must occur on boundaries:  before the wire, before going to the
client.  (I still think this particular log is a bit overdone, but SOMETHING is necessary.)
 Our primary concern is WHERE this log is seen.  In a big system, it goes to the console and
the u
[14:33] <RussellButek> ser never sees it.  In our system the console happens to be System.out.
 Bummer.
[14:33] <sitze> just playing folks...sorry.
[14:33] <rickr> THink there is a convenience method getSoapPartAsString()
[14:33] <GlenDaniels> ah ha!
[14:33] <GlenDaniels> thanks
[14:34] <GlenDaniels> CYA?
[14:34] <sitze> I'd never slap a co-conspirator!
[14:34] <RussellButek> Cover Your Ass.
[14:34] <GlenDaniels> ah
[14:34] <RussellButek> When the other side of the boundary conplains, you can say, "See?
 The log shows that we reported this exception to you."
[14:35] <GlenDaniels> Here's what I don't want.  I don't want someone to install Axis
out of the box, run it for five minutes, and find a 3 megabyte log file on their disk.
[14:35] <GlenDaniels> I'm dandy with configurability which lets you get the exact right
granularity and directionality of log messages.
[14:35] <sitze> which is why we don't log exceptions at the "debug" level!!!
[14:35] <RussellButek> So out of the box, we should turn logging to ERROR.
[14:35] <GlenDaniels> Actually, no.
[14:35] <sitze> No, we turn it to "INFO".
[14:35] <GlenDaniels> I think we should have logging at INFO.
[14:36] <sitze> Now that's a 3rd!!
[14:36] <GlenDaniels> I just think that by default we should not have certain places
log.
[14:36] <sitze> party time!
[14:36] <rickr> Are we having a telecon tomorrow?  Is it a regular thing or was it just
for B3?
[14:36] <GlenDaniels> As Richard says, it's not about system-wide logging level, it's
about whether you want "enterprise-level warehouse-style logging" or not.
[14:36] <RussellButek> Rick, yes, we're having a telecon, but Rahul will be there and
the topic will be the TCK.
[14:37] <rickr> Ok thnx
[14:39] <RussellButek> The order is trace, debug, info, warn,...  enterprise-level doesn't
want debug, it wants info.  Glen wants info but doesn't want what Richard thinks is info stuff.
 Sounds like info should be two levels.
[14:39] <RussellButek> Glen, why not warn?
[14:40] <sitze> Russell: that's why I've proposed the 'switch'.  It's actually orthogonal
to the level.
[14:41] <RussellButek> Refresh my memory.  The switch just tells us where the output
goes, right?  It still generates the output.
[14:41] <GlenDaniels> No.
[14:41] <GlenDaniels> There should be a choice of whether or not to generate the "enterprise"
output at particular places.
[14:42] <GlenDaniels> This is easily done by using an "enterprise" logger and configuring
it appropriately.
[14:42] <rickr> "enterprise" ?
[14:43] <GlenDaniels> We can include a default log4j config which has enterprise=FATAL,
then let you change that.
[14:44] <sitze> Glen, so you propose a new log category (great idea!) for these?
[14:44] <sitze> I need to think about that...
[14:45] <GlenDaniels> how about "analServer" and "analClient"? :) :)
[14:45] <GlenDaniels> Seriously, "enterpriseServer"/"enterpriseClient" should be fine
if appropriate.
[14:45] <sitze> hey!  :-)  this is business, nothing personal..
[14:46] <RussellButek> I think I understand what you're suggesting, and I think I like
it.
[14:46] <RussellButek> Is it doable?
[14:46] <RussellButek> (I have to ask since I'm logging-ignorant)
[14:47] <GlenDaniels> Yes
[14:47] <rickr> Under what condition would I use the "enterprise" level in logging?
[14:47] <GlenDaniels> It's easy.  You just say Log serverLog = logFactory.getLog(Constants.ENTERPRISE_SERVER_LOG)
[14:47] <GlenDaniels> It's not a level
[14:48] <GlenDaniels> It's a whole separate logger
[14:48] <sitze> Very simple.  I think Glen is proposing that we have a "Log entServier
= LogFactory.getLog("enterpriseServer");" global variable...
[14:48] <GlenDaniels> right
[14:48] <sitze> ouch.. got me.
[14:48] <GlenDaniels> :)
[14:48] <GlenDaniels> same same
[14:48] <sitze> No, mine failed code review.
[14:49] <RussellButek> So.  Shall we vote for it?  Who'll volunteer?
[14:49] <GlenDaniels> *snork*
[14:49] <sitze> Well, it's a do-ocracy... :-)
[14:50] <RussellButek> It's also a don't-ocracy.
[14:50] <sitze> See.. we need AxisInternals.java back :-)
[14:50] <GlenDaniels> Nah.  You just make it a field in each class where you want to
use it.
[14:50] <sitze> yeach.
[14:50] <GlenDaniels> That's the point of the LogFactory, to make sure that getLog("foo")
and getLog("foo") do the same thing anywhere.
[14:51] <rickr> Even it works, I'm sure It'll fail the TCK so -1 :-) :-) ;-)
[14:52] <GlenDaniels> If IBM ever lays you guys off, you all have fine careers in stand-up
comedy ahead of you. :)
[14:52] <sitze> Yes, across components.  But what did you gain?  You still have to resort
to a central point (Constants) to maintain integrity... and you introduced *all* :-) that
overhead.
[14:52] <GlenDaniels> All what overhead?  How many places do you expect to use this
thing?
[14:52] <RussellButek> Now we've lost the association between the enterprise messages
and all other messages.
[14:53] <GlenDaniels> Que?
[14:54] <RussellButek> If you don't understand me then I think I just don't understand
logging.  I'll shut up until I can be more coherent.
[14:54] <sitze> Russ: that's good.  You can turn on/off other messages.  The stacktrace
will show the important detail.   But I agree, I'd like to ponder all the ramifations of this..
[14:55] <rickr> Sorry to slow down the conversation, but under what circumstances would
I use the "enterprise" logger?
[14:56] <GlenDaniels> Incidentally, there are a number of other "cross-class" loggers
we might want as well.  "transport", "provider", "serialization", among others... just something
to consider.
[15:01] <sitze> ok.. here is a thought.  What about "LogFactory.getLog(className + ".enterprise")
???
[15:01] <sitze> Does log4j (and other loggers) allow us to set "org.apache.axis.*.enterprise=INFO"?
[15:03] <GlenDaniels> sure
[15:03] <GlenDaniels> it's just a string
[15:04] <GlenDaniels> oh
[15:04] <GlenDaniels> wait
[15:04] <GlenDaniels> I see what you're asking
[15:04] <GlenDaniels> no
[15:04] <GlenDaniels> I don't think so, but maybe
[15:04] <GlenDaniels> that'd be cool
[15:05] <sitze> We are here (3 of us - we win :-) discussing association...  
[15:05] <GlenDaniels> but why not just use the enterprise logger Axis-wide, and make
sure to prefix messages with the class name if you want it?
[15:05] <sitze> We loose the benefits of association given to us by the hierarchy
[15:05] <GlenDaniels> explain
[15:06] <sitze> If you enable org.apache.axis to some LOGGER in your config file, everything
below follows... you would have to explicitly send enterprise to the same LOGGER.
[15:06] <GlenDaniels> Right.
[15:07] <GlenDaniels> The point is that enterprise is its own category.
[15:07] <sitze> If you have different portions of the code sending to different LOGGERS,
then you would want to send enterprise to all of these LOGGERS.
[15:07] <GlenDaniels> ?
[15:07] <rickr> But then how do you choose on just the suffix?
[15:07] <GlenDaniels> You don't
[15:07] <GlenDaniels> The point is that enterprise is its own category.
[15:07] <sitze> And you would be unable to pull out the enterprise info related to the
class's that you are looking at.   Not necessarily a bad thing, and I think the benefits outweight..
[15:08] <rickr> Glen What I was pointing to what rich said
[15:09] <GlenDaniels> The idea is that, despite being in FooClass, you want to log something
that follows the "enterprise" rules.  So you use the enterprise Log object to do it.  If you
care that it comes from this particular class, you use best practices to add the classname
to the beginning of the log message.
[15:09] <rickr> By appending class + ".enterprise"
[15:10] <RussellButek> If you create one logger file per class file, and a class generates
messages to both it's log file and the enterprise log file, you lose the association of where
in the flow of execution a given enterprise message falls within the set of class log file
messages.
[15:10] <sitze> We need a real cross-category grouping mechanism :-(  Oh well, we'll
use what we've got!
[15:10] <sitze> Russ, they can be time stamped.
[15:10] <GlenDaniels> Russell - that's a tradeoff, and you can use the timestamp.
[15:10] <sitze> merge, sort, etc.
[15:10] <GlenDaniels> right
[15:10] <sitze>  :-(
[15:11] <RussellButek> Ah, of course.  Silly me.
[15:12] <RussellButek> I think my concerns are covered.  As long as we have SOME way
to get the associations (even if it's a tool that sorts all the files) then I'm OK with it.
[15:12] <GlenDaniels> associations==sequence
[15:12] <sitze> And again, you can (manually) route enterprise to all LOGGERS.
[15:14] <sitze> OK.  Sounds great.
[15:14] <RussellButek> Glen, associations also equals what class generated the message.
[15:14] <GlenDaniels> That's easy, though.
[15:14] <sitze> We still need (for integrety) to capture test log files & compare.
 ESPECIALLY for tests that look for exceptions.
[15:15] <RussellButek> Sitze, Huh?
[15:15] <sitze> my point 5, way back when
[15:15] <RussellButek> The test that looks for exceptions looks at the exceptions and
decides whether it passes or fails.  Why do we have to get the logger involved?
[15:15] <RussellButek> The one that I didn't agree with.  Explain it to me again.
[15:16] <sitze> Because you may not have the exception you thought you have.  Espcially
AxisFault.
[15:17] <GlenDaniels> He's saying that just becuase you have an AxisFault which contains
an IllegalArgumentException doesn't necessarily mean that it came from RPCProvider line 542.
[15:19] <GlenDaniels> Although the easy way to deal with this is to look at the Exception
itself, rather than logging it and grovelling through the log file, IMO.
[15:19] <GlenDaniels> The Exception message should be enough in 99% of cases (certainly
the ones we care about in our tests)
[15:21] <sitze> ok.  I agree that there are places that my suggestion will not help,
and that this can be defered :-)
[15:22] <sitze> WHICH raises another topic :-)
[15:22] <sitze> Can Matt (our tester) dump his reorged tests?
[15:22] <GlenDaniels> ?
[15:23] <sitze> We've got a fellow here who posted to axis-dev a while back.. he has
reoganized the axis tests.
[15:23] <sitze> He communicated with a few folks that were interested (one of yours,
as I recall).
[15:23] <GlenDaniels> Are his changes written up?
[15:23] <sitze> I'd like to push SOMETHING out, just to get us started.  Fine tune as
we go.
[15:24] <sitze> He can push out his note w/ updates again...
[15:24] <sitze> then we can vote?
[15:24] <GlenDaniels> Yes and no.  I'd rather see at least the broad strokes up front,
then vote.   Yes.
[15:25] <GlenDaniels> He can just point to his note in the archives if there hasn't
been substantial change since then.
[15:25] <sitze> OK.  I'll have matt intro his changes... and I'll check with him to
be sure that it's in a state to push out :-)
[15:26] <sitze> Do you want a copy to review first?
[15:26] <sitze> (details details.. devils always in the details)
[15:26] <GlenDaniels> I want him to send a note to the list
[15:27] <GlenDaniels> Or if the old one is still valid, just point to that
[15:27] <sitze> Yup.
[15:28] <GlenDaniels> I don't need an individual copy, the list is great.
[15:28] <sitze> What I meant was, do you want a copy of the *code* to review?
[15:28] <sitze> Code, delta's, changes, etc.
[15:29] <GlenDaniels> He could send the diffs along with the note, I suppose.
[15:29] <sitze> may be big :-)  ok.
[15:31] <RussellButek> So.  Back to the logging issue.  Do we agree with one enterprise
category?  And the few calls that dump this "toAxisFault" message are our first enterprise
messages?
[15:32] <RussellButek> hello?
[15:32] <GlenDaniels> +1
[15:32] <sitze> I still want to think about it... but it would help if we had "org.apache.axis.enterprise".
[15:33] <GlenDaniels> ?
[15:33] <rickr> Are we saying that if I throw an exeception and want to log it I need
to the enterprise category?
[15:33] <GlenDaniels> No
[15:33] <RussellButek> No, Rick.
[15:33] <rickr> IF it will get wrapped by axis fault evenetually?
[15:33] *** Taras has quit IRC (Ping timeout)
[15:33] <GlenDaniels> we're saying that there is a particular set of exceptions which
are caught at particular places which should only be logged if the enterprise thingy is on.
[15:34] <GlenDaniels> Has nothing to do with AxisFault
[15:34] <GlenDaniels> It's just a logging category
[15:34] <rickr> But what is the criteria for using that category?
[15:34] <RussellButek> There are boundary-crossing points that must be logged, but they're
only important in enterprise environments:  when an exception becomes an AxisFault, when an
exception is passed over the wire, when an exception is passed to the client.  That sort of
condition.
[15:34] <GlenDaniels> Example.  If enterprise logging is enabled, I probably want to
log EVERY fault that goes from the server back to a client.
[15:35] <GlenDaniels> If it's not, I probably don't.
[15:35] <RussellButek> Glen, right.
[15:35] <GlenDaniels> Russell, right. :)
[15:36] <sitze> Glen/Russell, right.

Mime
View raw message