error."
without needing to dig into stacktraces, and often not know the context enough
to have a clue what went wrong.
IMHO, exception handling is a very sad chapter in most software.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
On Thursday 01 November 2007 14:39, David Jencks wrote:
> I think that Alex and i agree that, if both of these are roles, we
> would handle this using role inheritance, making the app-specific
> "Finance Package Admin" a sub-role
Inheritance sounds to be the wrong term for an "Implies" stereo
are often
defined by the application/resource itself.
At Triplesec level, you want to be able to correlate that CFO (org role)
implies the role "Finance Package Admin" (app role).
Hope you can work out the different perspectives you guys have...
Cheers
--
Niclas Hedhman, Software
f QDox. (Not sure about its current status.)
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
velopment" to worry about.
Modularity also allows for smaller pieces to be released independently, as
long as inter-modular interfaces remain stable. This can also help users a
lot to be fairly close to bleeding-edge, without compiling the TRUNK with
possibility of failures and such.
Cheer
On 9/20/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> This is also were we want ADS to be extended with triggers, stored
> procedures and views, as any RDBMS. Triggers will help to manage cross
> updates (remove a user => automatic removal from groups). Stored
> procedure can be used to creat
lar...
If you have any suggestions on how to solve the N x M explosion of values to
manage, I am all ears. Otherwise, I think I am hanging up my hat...
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
On Thursday 13 October 2005 00:27, Trustin Lee wrote:
> I was talking about the original monitor pattern which is different from
> yours. It abstracts all log messages into individual hook methods.
Ok, perhaps we read material differently. To the letter, you right of course,
but I see a subtle u
On Wednesday 12 October 2005 08:24, Trustin Lee wrote:
> This monitor pattern is overengineering IMHO. Why should I add extra
> methods whenever I write debug log messages and provide a bridge for known
> logging frameworks? And we can say using monitors is implementing AOP
> almost by hand.
If
On Tuesday 11 October 2005 14:13, Noel J. Bergman wrote:
> Or to depend on STANDARD APIs, since some library developers seems to have
> lost their way with respect to preserving absolute compatibility across
> versions.
Why "depend"??
Once you understand Paul Hammant's argument of "No Logging",
On Monday 10 October 2005 21:37, Nick Faiz wrote:
> Given the constraint that it is now an either/or scenario between
> log4j and nlog4j, if ApacheDS were to be embedded in an existing
> log4j application, the log4j jar would have to be removed
IMHO, it is getting more and more apparent that "
On Friday 02 September 2005 15:35, Nick Faiz wrote:
> The messageFormat bit is nice for i18n.
Yes, but the primary concern was that whatever message string you put in,
people would want something slightly different.
> In general, I'm a little cautious about using static behaviours
Me too... an
On Friday 02 September 2005 07:36, Nick Faiz wrote:
> I've always thought that end users see too many stack-traces
> and that applications don't really gain by throwing away exception
> information.
Totally agree.
See http://issues.apache.org/jira/browse/DIR-113 where I have created
somethin
[ http://issues.apache.org/jira/browse/DIR-113?page=all ]
Niclas Hedhman updated DIR-113:
---
Attachment: Main.java
And correct file would be good...
> Usage of NullArgumentException to precondition public meth
[ http://issues.apache.org/jira/browse/DIR-113?page=all ]
Niclas Hedhman updated DIR-113:
---
Attachment: Main2.java
Main.class
Two simple classes that tests the NullArgumentException class. I guess should
be converted to JUnit, but
[ http://issues.apache.org/jira/browse/DIR-113?page=all ]
Niclas Hedhman updated DIR-113:
---
Attachment: (was: Main.class)
> Usage of NullArgumentException to precondition public meth
[ http://issues.apache.org/jira/browse/DIR-113?page=all ]
Niclas Hedhman updated DIR-113:
---
Attachment: NullArgumentException.java
The NullArgumentException class.
> Usage of NullArgumentException to precondition public meth
Usage of NullArgumentException to precondition public methods.
--
Key: DIR-113
URL: http://issues.apache.org/jira/browse/DIR-113
Project: Directory
Type: Improvement
Reporter: Niclas Hedhman
Assigned to
On Friday 02 September 2005 00:35, Emmanuel Lecharny wrote:
> Using a good pattern in conjonction with slf4j could help a lot :
>
> if (arg == null)
> {
> log.error("the third parameter ('history') is null");
> throw new IAE();
> }
> ...
>
> As you can exhibit the method name and th
Even better if the offending caller's identity is extracted, reformatted for
human consumption and placed as the argument in the exception thrown;
java.lang.IllegalArgumentException: The class org.niclas.hedhman.SomeCode
passed a null argument for the third parameter ("history") on line 263, to
On Thursday 01 September 2005 02:23, Alex Karasulu wrote:
> Question: How best to respond to null arguments?
A subject every programmer will have an opinion about, I guess.
> Option #1: Ignore it and let a NPE result on its own
> Option #2: Test to see if arg is null early and throw a descriptiv
On Wednesday 31 August 2005 19:25, Enrique Rodriguez wrote:
Duh! I get the feeling you don't understand encodings.
Run;
try
{
String string1 = "Jérôme";
String string2 = new String( "Jérôme".getBytes( "UTF-8" ), "UTF-8" );
String string3 = new String( "Jérôme".getBytes( "ISO-8859-
On Wednesday 31 August 2005 17:34, Emmanuel Lecharny wrote:
> So you always should use a new String("Jérôme", "UTF-8") before sending
> data to Ldap. It applies to search filters, too.
I think you are somewhat mistaken. The above constructor doesn't exist, nor
makes any sense.
The straight forwa
On Tuesday 16 August 2005 00:42, Sanjiva Weerawarana wrote:
> On Mon, 2005-08-15 at 11:12 +0800, Niclas Hedhman wrote:
> > An interesting "enhancement" would be to base it on MINA, which is a NIO
> > subsystem, made to drive high volume traffic, and has an active
&g
On Monday 15 August 2005 14:13, Brett Porter wrote:
> > Would you like access?
>
> If you trust me to poke around without damaging anything when a
> project goes down, I'm happy to go in and fix it again - sure.
They trusted me, so you'll be Ok :o)
> > Heck, would you like to be on the Gump PMC?
On Saturday 30 July 2005 02:13, Michael A. Olson wrote:
> We don't have the "no additional restrictions"
> language
> that appears in the GPL, and specifically without limitations on
> patents. So,
> from a straight legal perspective, putting Berkeley DB and some Apache
> Licensed software toge
On Saturday 30 July 2005 01:14, Jim Jagielski wrote:
> GPL says that no
> other license can place restrictions or requirements on code
> that the GPL does not already place on it (think of the
> old AL and the "advertising clause")
And for ALv2 it is about the patent grants and license termination
On Wednesday 27 July 2005 08:31, Alex Karasulu wrote:
> -1 [] Reject this release
> 0 [] Indifferent
> +1[X] Approve the release
Releases spurs interest and confidence.
Issues should be extracted and published with the release for accuracy.
Release early, release often :o)
Cheers
Niclas
On Tuesday 26 July 2005 13:28, Alex Karasulu wrote:
> Niclas Hedhman wrote:
> >Ok. And Apache projects can not use GPLed products for the same reasons.
> > (And according to FSF GPLed projects can't use Apache licensed products,
> > due to some patent grant issues...)
On Tuesday 26 July 2005 07:56, Michael A. Olson wrote:
> Let me begin by pointing out what may be obvious -- there's no issue
> of compatibility between the Apache License 2.0 and the Sleepycat
> Public License. The Sleepycat license was designed to be identical in
> effect with the GPL.
Ok.
On Monday 25 July 2005 23:50, Bharath Sundararaman wrote:
> Do you have any example code where MINA sends/receives data from a PLC?
> I'm trying to use Ethernet/IP (CIP over Ethernet) to talk to PLCs in
> vain.
No. I have not been using MINA at all, and in fact never production deployed
any "fact
On Sunday 24 July 2005 11:54, Alex Karasulu wrote:
> >>Does the license for JE require company A to have to license JE from
> >>SleepyCat?
> >>
> >
> >If they don't provide source code to their product under some kind of
> >free software license, the answer seems to be yes.
> >
>
> So all the
On Wednesday 20 July 2005 09:05, Trustin Lee wrote:
> "big2 with this project -
> What do you mean by "big2"? :) Thanks!
On swedish keyboard layouts the double quote character is located above the
"number 2" key, so Magnus just missed to press the shift properly, so it was
meant to be
"
On Wednesday 20 July 2005 02:34, Bharath Sundararaman wrote:
> Scenario 2
> I have an application that does asynchronous reads and writes to devices
> (e.g. PLC) via ethernet/ip.
> So, communication with the device happens using a SelectableChannel (tied
> to the device's IP address) which regist
On Tuesday 05 July 2005 12:26, Nick Faiz wrote:
> I sat down on the weekend to make SLF4J run. I immediately
> encountered a NoSuchMethodError via a Spring dependency, via
> commons-logging, to log4j (while I was running with nlog4j).
This could be one of the notorious JCL NoSuchMethodExceptions t
On Tuesday 05 July 2005 11:18, Trustin Lee wrote:
> Disconnection from server prevents the application from functioning but we
> cannot say that it is a FATAL situation because server will get up and run
> soon possibly. We'll have to say it is in a FATAL situation if client
> cannot proceed the
On Friday 01 July 2005 01:49, Alex Karasulu wrote:
[X] SLF4J
[ ] Commons Logging
[ ] Log4J Straight
[ ] JDK 1.4 Logging Straight
On Friday 01 July 2005 01:25, Noel J. Bergman wrote:
> > Commons logging seems to have known problems: for
> > example, http://www.qos.ch/logging/thinkAgain.jsp .
>
> Remember whose site you are quoting: the Log4J author!
The JCL team has been invited to discuss each and every item specifically on
On Tuesday 28 June 2005 12:47, Niclas Hedhman wrote:
> The codebase URLs is the third item which written out, which of course can
> be very large.
I want to correct myself. The above is not true for serialization itself, only
in combination with MarshalledObject, which is what RMI uses.
On Tuesday 28 June 2005 23:39, Trustin Lee wrote:
> If performance is not a problem, we can just go with object serialization,
> but currently our performance is not really good, and it is being caused by
> large extra I/O from object serialization.
Ok. If you feel it is an urgent thing, then I wo
On Tuesday 28 June 2005 09:56, Marc Boorshtein wrote:
> doesn't commons logging do just that? let you easily migrate between
> log4j & built in logging?
Jakarta Commons-Logging has many issues related to its dynamic
lookup/resolution of the logging system to use.
Ceki Gülcü has an article that
On Tuesday 28 June 2005 08:23, Trustin Lee wrote:
> The biggest problem is the class descriptors written by
> ObjectOutputStream. It is sometimes even bigger than actual object data. We
> can override some protected methods to store the descriptors somewhere
> else, and it makes the serialized da
On Monday 27 June 2005 14:51, Emmanuel Lecharny wrote:
> I don't think so, but I may be wrong. I do think that debug is for debug
> purpose, when writing code (I mean, when in production, it's too late to
> run in debug mode). So if you have a problem, you should isolate the
> data that produce it,
On Sunday 26 June 2005 23:11, Emmanuel Lecharny (JIRA) wrote:
> Even better, add a
> private static final boolean DEBUG = log.isDebugEnabled();
>
> and use it this way :
>
> if (DEBUG)
> {
> log.debug(...)
> }
>
> As DEBUG will be evaluated only once, the test is faster (no function
> called).
On Friday 24 June 2005 22:11, Trustin Lee (JIRA) wrote:
Couple of notes;
> Using Java serialization has couple of cons:
>
> * Slow
That is a very relative term. Compared to other generic serialization
mechanisms I don't think it fairs much better or worse.
> * Resulting data is big
Again, ver
On Sunday 19 June 2005 12:15, Trustin Lee wrote:
> 3) DatabaseNexus and RootNexus
>
> The role of DatabaseNexus is similar to that of RootNexus. We could
> forward any operations to appropriate Database implementation. Using
> DatabaseNexus, we will be able to make RootNexus just a frontend to
>
46 matches
Mail list logo
