machine might be worth it if it saves you rack rental, or
allows your failover system to be easier, but likely as not isn't
worth it if you're just concerned with performance.
My one-pence (not even worth tuppence),
Hen
On Wed, 09 Mar 2005 13:54:33 -0500, Matt Sgarlata
[EMAIL PROTECTED] wrote
For performance and other reasons, we collocate the presentation tier
and business object tier on the same server. Question: why not take
this even further and put everything on the same server? If the DB is
on the same server as the rest of your application, then won't you get a
performance
shameless-plug
The Morph framework (morph.sourceforge.net) supports either syntax
out-of-the box. Morph had its first beta release yesterday.
For a comparison of Morph to JEXL, see
http://morph.sourceforge.net/alternatives/jexl.html
For a comparison of Morph to BeanUtils, see
Morph is a Java framework that eases the internal interoperability of an
application. As information flows through an application, it undergoes
multiple transformations. Morph provides a standard way to implement
these transformations.
The goal of this release is to provide a near-final look
Richard Sitze wrote:
news [EMAIL PROTECTED] wrote on 12/21/2004 08:04:09 AM:
+1, I agree with you and Ceki. TRACE is debatable (I personally like
it), more than TRACE is silly.
Well... call them what you will, I want em'!! lol
And yes, I'm leaning towards EXPLICITLY naming methods to encourage
I'm confused Ceki. You've spent a lot of time discussing
commons-logging on this list, while at the same time supporting
development of UGLI. Which component is your favorite? How come you're
working on 2?
Matt
Ceki Gülcü wrote:
On 2005-01-25 19:40:35, Richard Sitze wrote:
How in the
I'm sorry, I didn't mean for my post to sound angry, and I'm sorry if
anyone took offense. I was just asking :)
Ceki, thanks for that link. You have many excellent points, and I may
migrate my projects away from commons-logging.
Matt
Vic wrote:
Matt Sgarlata wrote:
You've spent a lot of time
Ceki Gülcü wrote:
At 03:05 AM 12/27/2004, Charles Daniels wrote:
If I understand the JCL discovery mechanism correctly, it actually
should work just fine in the scenario you describe above. For it to
work, you would not set the org.apache.commons.logging.LogFactory system
property, because, as
to runtime. The author of library net.sf.morph
probably does *not* wish to impose any logging related property on the
end-user. Consequently, it does not make sense to have package
specific properties at the JCL level. Would you agree?
At 08:26 PM 12/27/2004, Matt Sgarlata wrote:
Couldn't this be refined
Simon, I agree with you 80% and I think you're right that JCL should
stay as-is for now.
I think you're dead-on with this new line of thinking. It won't seem
like it because now I'm going to spend the rest of this email
disagreeing with you, but I'm with you on the big leap you took in your
Chris Lambrou wrote:
Matt Sgarlata wrote:
Does this mean .NET doesn't have reflection? That's such a killer
feature of Java; I can't believe they wouldn't have ported it to .NET.
Any .NET developers out there that can tell us how .NET deals with
reflection when you have multiple versions
robert burrell donkin wrote:
On 18 Dec 2004, at 23:07, Scott Deboy wrote:
Enter and exit should not be defined as severities. This is useful
information, but orthogonal to a logging event's severity attribute.
Good point. I think this would be an excellent distinction for a
logging
the nightmare that would ensue if
java.util.Vector were to change its semantics!)
Regards,
Daniel
Matt
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Im Auftrag von Matt Sgarlata
Gesendet: Dienstag, 21. Dezember 2004 13:04
An: commons-dev@jakarta.apache.org
Betreff
would look like until we hashed
it out in more detail. If we skipped over your original post, it was
(for me, at least) because we didn't understand it :)
Craig
On Tue, 21 Dec 2004 07:03:50 -0500, Matt Sgarlata
[EMAIL PROTECTED] wrote:
Chris Lambrou wrote:
Matt Sgarlata wrote:
Does this mean .NET
as
possible (e.g. - imagine the nightmare that would ensue if
java.util.Vector were to change its semantics!)
Regards,
Daniel
Matt
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:commons-dev-return-64857-
[EMAIL PROTECTED]
Im Auftrag von Matt Sgarlata
Gesendet: Dienstag, 21. Dezember
Comments below...
robert burrell donkin wrote:
On 21 Dec 2004, at 14:04, Matt Sgarlata wrote:
robert burrell donkin wrote:
snip
richard's proposal to add symantic methods (rather than severities)
is therefore interesting. exit and entry tracing is common. at the
moment, this works rather poorly
Richard Sitze wrote:
news [EMAIL PROTECTED] wrote on 12/21/2004 08:04:09 AM:
+1, I agree with you and Ceki. TRACE is debatable (I personally like
it), more than TRACE is silly.
Well... call them what you will, I want em'!! lol
Does this mean you want all 42 logging levels I described in my
David Graham wrote:
--- Daniel Florey [EMAIL PROTECTED] wrote:
BTW: Another advantage of this approach would be that imports would
indicate
which version of the component is in use. I had a lot of trouble to find
out, which version of jdom was in use by some libraries as this was not
indicated by
Daniel Florey wrote:
I think handling different versions of classes/jars at VM level would be a nice feature, but it would be very hard to implement nd to understand when it comes to reflection.
Does this mean .NET doesn't have reflection? That's such a killer
feature of Java; I can't believe
Craig McClanahan wrote:
On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
[EMAIL PROTECTED] wrote:
How do we go about petitioning Sun for something like this?
A while back now (while the details for Tiger were being planned), I
happened to be in a meeting with Graham Hamilton (who basically owns
Ceki Gülcü wrote:
Log4j version 1.4 or 2.0 is likely to introduce the notion of multiple
domains for categorizing logging statements. When that happens, the
notion of logging levels will be looked at very differently.
Commons-logging promises to abstract different logging APIs such as
log4j,
Ceki Gülcü wrote:
Log4j version 1.4 or 2.0 is likely to introduce the notion of multiple
domains for categorizing logging statements. When that happens, the
notion of logging levels will be looked at very differently.
Commons-logging promises to abstract different logging APIs such as
log4j,
Simon Kitching wrote:
Suppose for a moment that we were to choose between adding methods to
the Log interface, and turning it into an abstract class with some
methods; I don't understand what real pain would be incurred by having
custom logging adapters be declared as:
The pain (as Robert pointed
Emmanuel Bourg wrote:
Matt Sgarlata wrote:
This seems to me that this isn't just a problem with commons; it is a
problem with Java itself that .NET already has a very nice solution
for. I'm wondering if this isn't something that should be taken care
of at the JVM level i.e. - in Java 1.6
Noel J. Bergman wrote:
Simon Kitching wrote:
I've been convinced by the arguments put forward in this thread that
explicit enter/exit methods taking class+method strings should not
be encouraged
Actually, I agree. I'd prefer to see that semantic state encoded in the log
message, which I feel is
Max Rudman wrote:
Specifically, I'm not exactly planning on a Query-by-Example API, but
rather a dynamic SQL statement builder API (also insert, update,
delete, etc.). I run into this problem all the time where the user is
specifying what they'd like to search for, and so you need to build a
One thing under the Seeking Opinions section of the Wiki...
# [WWW]26056 [lang] Add methods to ArrayUtils: add at end and
insert-like ops - DONE - add(Object[], Object) is overloaded for all the
primitives, but add(Object[], int, Object) and addAll(Object[],
Object[]) are not overloaded for
Daniel Florey wrote:
Any proposals how to solve this issue in another way?
Correct me if I'm wrong, but didn't Microsoft come up with some type of
solution to DLL hell in Windows 2000 or XP? I seem to recall reading
that a long time ago, but I'm not a Windows programmer, so I have no
idea.
This may work, but does BCEL require the use of its own custom
classloader also?
This seems to me that this isn't just a problem with commons; it is a
problem with Java itself that .NET already has a very nice solution for.
I'm wondering if this isn't something that should be taken care of at
I never noticed Mapper before... interesting. Actually I will be
tackling some of the same problems once I get Morph out the door
(morph.sourceforge.net). It will be a separate project focused on DB
interaction but I haven't thought of a name yet (I'm calling it
Persistence for now, but
Simon Kitching wrote:
I think this demonstrates a major issue.
When using logging in an enterprise situation, the logging can be
considered a critical part of the application. If you have heavy-duty
monitoring systems watching for alerts from the software, and have
sysadmins on call 24x7 to deal
Response below...
Simon Kitching wrote:
On Thu, 2004-12-16 at 13:53, Matt Sgarlata wrote:
Simon Kitching wrote:
I think this demonstrates a major issue.
When using logging in an enterprise situation, the logging can be
considered a critical part of the application. If you have heavy-duty
as small as possible. I guess if someone
(e.g. - Matt Sgarlata) *really* wants a custom resource bundle
resolution strategy (e.g. - Spring + Log4J), he or she can always
subclass an existing LogFactory/Log combo to do the resolution. It's
not very exciting, but it keeps JCL as an ultra-thin
,
or functional equivalent.
- Bind a ResourceBundleName to an EnterpriseLog
instance.
- Expects that the named ResourceBundle is
available to the logger.
Matt
ras
Matt Sgarlata [EMAIL PROTECTED] wrote on 12/13/2004
12:11:30 PM:
The API I proposed yesterday
Then calling code that wants to make use of localized logging would make
this call:
private static final LocalizedLog log = (LocalizedLog)
LogFactory.getLog(MyClass.class);
Not sufficient.
a) Leaving the existing LogFactory alone allows a minimal implementation
to be obtained, if
Ah-hah, I understand our main disconnect now: I'm thinking in terms of
configuring logging for an overall application and you're thinking in
terms of components. So now at least I understand where you're coming
from, but I think it's time for us to agree to disagree :) I think
someone said
The API I proposed yesterday circumvents this problem and allows us to
add whatever methods we need for internationalization while not breaking
backwards compatability. Instead of adding methods to the Log
interface, we introduce a new interface, called LocalizedLog. The key
is that the Log
To support localized log messages, we only need to introduce one
*optional* interface that will *not* affect any existing functionality.
interface LocalizedLog extends Log { // methods TBD }
Then calling code that wants to make use of localized logging would make
this call:
private static
Richard Sitze wrote:
- For message level logging, support globalized
variants on the new EnterpriseLog interface:
info(Class callingClass,
String methodName,
String messageID);
info(Class callingClass,
String
Martin Cooper wrote:
This sure doesn't sound like Commons Logging would be an ultra-thin
bridge between different logging libraries any more.
http://jakarta.apache.org/commons/logging/
This sounds more like a different package altogether. IMO, we have
enough trouble as it is with some people
Morph 0.4.2 is available at http://morph.sourceforge.net.
THIS IS THE LAST NOTICE I will sent to this list. Spam is evil, so I don't
want you getting any from me :) If you would like to continue to receive
notices relating to Morph, please subscribe to one of the Morph mailing lists
by
- Original Message -
From: Mark Lowe [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Friday, December 03, 2004 5:43 AM
Subject: Re: [OT] Test generation
I'd really like to find a maven configable way for defining fixtures
for spring, so the db is setup
Sorry if I'm getting annoying with my plugs for the Morph framework, but
Morph's SimpleLanguage would allow users to use whatever expression language
they are already familiar with (the Struts/BeanUtils language, the Spring
language, or JSTL). The SimpleLanguage works with Maps out-of-the-box,
Comments below...
- Original Message -
From: Ron Blaschke [EMAIL PROTECTED]
To: Matt Sgarlata [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, November 26, 2004 6:47 PM
Subject: Re: [convert] a different approach...
I've taken a quick look at your description and the source, which
Morph 0.3.1 is available at http://morph.sourceforge.net.
Major changes in this release
- Introduced new Transformer abstraction, which is a common super-interface for
Converters and Copiers
- Removed isConvertible, isCopiable and isReflectable in favor of
getDestinationClasses,
make sure you add a link to the wiki so everyone can find morph :)
Done to the best of my ability. I apologize in advance if I abused the Wiki
in any way!
i don't see any real harm announcing releases and stuff on the mailing
lists though it'd probably be wiser not to phrase any posts so as
Thanks for the info Eric. I agree, it's much better to expose a simpler
interface and then write a single implementation that can expose that simple
interface as a Map. Otherwise, you're forcing each and every subclass to
implement Map, which is a huge pain. Of course ContextBase does this,
Hi everyone, thanks for your feedback. Sounds like my ideas for a different
Context are an enhancement request for Chain 1.1 or Chain 2.0.
As for the Context vs. Map issue, I think the approach I'll take in the
Morph framework is to have the DelegatingContext class implement Map. That
way,
Sorry, one more comment for ServletWebContext, below...
- Original Message -
From: Don Brown [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Sunday, November 21, 2004 11:11 PM
Subject: Re: [VOTE] Release Chain 1.0
As for ServletWebContext, I see your point,
Before a 1.0 release, I would like to suggest an alternative Context
interface. Sorry, I realize I'm getting to the game a little late ;) I
think it is inappropriate for Context to extend from Map, because a Context
as defined in the Chain package isn't really a Map. Maps are great, but for
Hi Robert, thanks for your comments : ) My responses are below...
why not start a little project on source forge...?
Already registered on SF this morning... I probably will create a SF project
this weekend :) My tentative project name is Morph.
- In place of BeanUtils.copyProperties there is
Hi Ron, Henri, Stephen, others -
I haven't been on the list a while but I saw your posts earlier this month. I
too, like Ron, spent some time developing my own approach to the goals of the
commons-convert project. I have some code started out that isn't incredibly
well documented, but all
52 matches
Mail list logo
