Serge Knystautas wrote:
> Noel J. Bergman wrote:
>
>>> Ahem... JSR 47 HAS produced a common API for logging. It's called
>>> java.util.logging.
>>
>> True ... but it is neither in the Servlet API nor exposed to Mailets,
>> which
>> was sort of the context of the discourse.
The main point is that the JSR 47 is not geared towards server applications.
Static accessors for server apps is a potential security hazard.
Overmore, we need to supply logging to jdk 1.3.
> Sorry, but from my view this discourse went like this... you were
> advocating adding logging to the mailet API. I said there are too many
> ways and pointed to the fact there are many implementations. You said
> there are so many implementations only because there was no common API.
> I'm pointing out how their was a JSR and so there is a common API. So,
> tracing it back, I think there are multiple implementations not because
> of a lack of a common API... it's because there are different needs.
> There are different needs, so we shouldn't add this into the mailet API.
Leave logging out of the API but put Avalon Framework savy container as
a requirement.
> We provide log(), which is basically an equivalent of System.err. If a
> developer wants serious logging capabilities, he/she can either use what
> comes with the JDK, use Avalon's logger, or whatever third party library
> they have around. I don't think adding some other jar is a violation of
> the mailet portability nor using JDK 1.4 logging as a violation of it.
Ok, so I will write this mailet:
public class MyMailet implements Mailet,
org.apache.avalon.framework.logging.LogEnabled,
org.apache.avalon.framework.context.Contextualizable
org.apache.avalon.framework.parameters.Parameterizable
{
void enableLogging( Logger logger );
void contextualize( Context context )
throws ContextException;
void parameterize( Parameters parameters )
throws ParameterException;
....
}
and my container will honor the Avalon contracts.
You will write
public class MyMailet implements Mailet
{
(in any method:)
[
StaticLogger.log("hi");
String param1 = Configuration.getParam("root.address");
]
}
Do these classes look like the same API?
By doing this, you are *sure* that the Mailet classes won't be portable.
Or, if they are, you loose any sensible functionality.
> Sorry, I don't mean to sound like a broken record, but I just wanted to
> clarify the context of the discourse as I remembered it.
>
>> Wait, I have not said that James + Avalon Frameworks doesn't do
>> something!
>> I said that a Mailet API *WITHOUT* Avalon Frameworks is anemic, and
>> that if
>> we don't specify how to fill the gaps (using the Avalon Frameworks is one
>> way), then those gaps will be filled with vendor-specific solutions, and
>> that is the thing that is unacceptable.
>
>
> Again, I'd like to hear what you want to add to the mailet API. Again,
> from my perspective most of the conversation talks about Java and
> programming language concepts instead of concrete concepts to change in
> the mailet API.
interface MailetContext
{
(as now +)
void log(String message); // deprecated
void log(String message, Throwable t); // deprecated
}
interface Mailet
{
void service(Mail mail) ;
}
But *REQUIRE* to abide to Avalon contracts (example):
public class MyMailet
implements Mailet
org.apache.avalon.framework.lifecycle.Initializable,
org.apache.avalon.framework.lifecycle.Disposable,
org.apache.avalon.framework.logging.LogEnabled,
org.apache.avalon.framework.service.Serviceable
org.apache.avalon.framework.parameters.Parameterizable
{
void service(Mail mail){...}
void init (){...}
void dispose (){...}
void enableLogging( Logger logger ){...}
void service( ServiceManager manager )
throws ServiceException{...}
void parameterize( Parameters parameters )
throws ParameterException{...}
}
>>> You've got a mailet API... you've got composable, etc-able
>>> interfaces that you can get as servlet context attributes.
>>> You can log, you can store, and whatever else that the
>>> Avalon-framework is providing.
>>
>> Exactly! And I want to be able to RELY upon that regardless of whose
>> container implementation I'm using. That's it exactly!
>
> I guess I would only suggest you take a look at the "competing"
> solutions to mailets right now.
I suggest you to look at Avalon.
Competing solutions are never an answer, but a problem, or you would be
using those.
> I think the more we rely on other existing Java API, the easier it will
> be for mailet developers to get up to speed, and ultimately the more
> portable mailets will be.
Avalon Api is very simple.
I bet that the above mailet is more portable and easier to understand
than any other possible implementation-API.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
