You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Andrei Ivanov <my...@surfeu.fi> on 2002/05/18 19:55:48 UTC
Re: James -> Phonix 4.0aX (minor changes)
Hi,
> I'm not sure what your suggesting... you can already pass attributes to
> Mailets as init parameters.
How? MailetConfig has only one method: String getInitParameter(String name)
...
>
> I'm not sure about the others... I don't think we can distribute the
> jsse jar,
I know that, of course we can't distribute jsse, but presence of them can be
detected in build (same way as in cornerstone). Many use jdk < 1.4 so that
there will be no need to modify build script.
> I'm not sure about the keystore... can you give a diff to show what
I'll send that later.
Regards,
Andrei
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: James -> Phonix 4.0aX (minor changes)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Andrei,
I presume you're modifying the matcher loader and config classes so that
JamesSpoolManager can pass the Configuration object, and adding
MatcherConfig.getInitParameter().
In MailetConfigImpl.getInitParameter, you might try the following:
configuration.getChildren(getMailetname() + ":" + name)
This supports the:
<mailet matcher="Foo[=cond]" class="Bar">
<Foo:tagname>value</Foo:tagname>
<Bar:tagname>value</Bar:tagname>
</mailet>
qualification I mentioned in an earlier note. if that fails, try:
configuration.getChildren("mailet-config:" + name)
which supports the <mailet-config:tagname>value</mailet-config:tagname>
style tag. Finally, and only for MailetConfigImpl, try:
configuration.getChildren(name);
You'll copy that method to MatcherConfigImpl, change mailet to matcher, and
remove the third case, which is only for mailets (provides compatibility
with existing configuration files).
As I said before, the code changes to the current code are very small. This
presumes that we stick with the basic Config.getInitParameter() scheme. I
imagine that Serge would not have a complaint about doing this, but if he
had wanted to use the full Configuration interface from Avalan, I suspect
he'd have done so by now.
--- Noel
-----Original Message-----
From: Andrei Ivanov [mailto:myfam@surfeu.fi]
Sent: Saturday, May 18, 2002 17:00
To: James Developers List
Subject: Re: James -> Phonix 4.0aX (minor changes)
Ok, I'll try to use your approach in my code to see how it works. Actually
you must be right because what I am doing now doesn't use matchers at all,
that logically resulted for me in my proposal (since I've been using that
extensively in my architecture where there are no matchers and therefore
there is no risk to flatten namespaces).
Andrei
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Saturday, May 18, 2002 11:36 PM
Subject: RE: James -> Phonix 4.0aX (minor changes)
> Andrei,
>
> Another alternative to your:
>
> <mailet ...>
> <addSubject enable="true" truncate="10"/>
> </mailet>
>
> could be:
>
> <mailet ...>
> <mailet-config:addSubject enable="true" truncate="10"/>
> </mailet>
>
> Similarly, my:
>
> <mailet matcher="Foo[=cond]" class="Bar">
> <matcher-config>
> <tagname>value</tagname>
> </matcher-config>
> <mailet-config>
> <tagname>value</tagname>
> </mailet-config>
> </mailet>
>
> could be:
>
> <mailet matcher="Foo[=cond]" class="Bar">
> <matcher-config:tagname>value</matcher-config:tagname>
> <mailet-config:tagname>value</mailet-config:tagname>
> </mailet>
>
> Unqualified tags would be assumed, for compatibility with previous
> releases of James, to be part of the mailet configuration.
>
> --- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: James -> Phonix 4.0aX (minor changes)
Posted by Andrei Ivanov <my...@surfeu.fi>.
Ok, I'll try to use your approach in my code to see how it works. Actually
you must be right because what I am doing now doesn't use matchers at all,
that logically resulted for me in my proposal (since I've been using that
extensively in my architecture where there are no matchers and therefore
there is no risk to flatten namespaces).
Andrei
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Saturday, May 18, 2002 11:36 PM
Subject: RE: James -> Phonix 4.0aX (minor changes)
> Andrei,
>
> Another alternative to your:
>
> <mailet ...>
> <addSubject enable="true" truncate="10"/>
> </mailet>
>
> could be:
>
> <mailet ...>
> <mailet-config:addSubject enable="true" truncate="10"/>
> </mailet>
>
> Similarly, my:
>
> <mailet matcher="Foo[=cond]" class="Bar">
> <matcher-config>
> <tagname>value</tagname>
> </matcher-config>
> <mailet-config>
> <tagname>value</tagname>
> </mailet-config>
> </mailet>
>
> could be:
>
> <mailet matcher="Foo[=cond]" class="Bar">
> <matcher-config:tagname>value</matcher-config:tagname>
> <mailet-config:tagname>value</mailet-config:tagname>
> </mailet>
>
> Unqualified tags would be assumed, for compatibility with previous
releases
> of James, to be part of the mailet configuration.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: James -> Phonix 4.0aX (minor changes)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Andrei,
Final option:
<mailet matcher="Foo[=cond]" class="Bar">
<Foo:tagname attr="val"/>
<Foo:tagname [attr="val"]>value</Foo:tagname>
<Bar:tagname attr="val"/>
<Bar:tagname [attr="val"]>value</Bar:tagname>
</mailet>
Using the matcher and mailet names to qualify the configuration tags.
Again, there are two seperate issues:
1. How to qualify the tags
2. Whether to allow only [name, value]-pairs from child elements,
or to allow full DOM semantics.
I'm suggesting that preserving the current [name, value] scheme is the
simplest solution, but if people want to expose an Avalon Configuration
object, I won't argue the point.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: James -> Phonix 4.0aX (minor changes)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Andrei,
Another alternative to your:
<mailet ...>
<addSubject enable="true" truncate="10"/>
</mailet>
could be:
<mailet ...>
<mailet-config:addSubject enable="true" truncate="10"/>
</mailet>
Similarly, my:
<mailet matcher="Foo[=cond]" class="Bar">
<matcher-config>
<tagname>value</tagname>
</matcher-config>
<mailet-config>
<tagname>value</tagname>
</mailet-config>
</mailet>
could be:
<mailet matcher="Foo[=cond]" class="Bar">
<matcher-config:tagname>value</matcher-config:tagname>
<mailet-config:tagname>value</mailet-config:tagname>
</mailet>
Unqualified tags would be assumed, for compatibility with previous releases
of James, to be part of the mailet configuration.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: James -> Phonix 4.0aX (minor changes)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Andrei,
I understand about org.apache.avalon.framework.configuration.Configuration,
but that is not what is exposed to matchers and mailets. If that is what
people decide should be exposed, then we don't even have to add methods;
just expose the underlying configuration object. All that is currently
exposed is a simple name=value approach, similar to that used elsewhere in
Java, e.g., Servlets. I was not proposing changing that scheme.
> you don't know if the element is intended for the matcher
> or mailet configuration.
> No this is not so. Child element is always specified as a method
parameter.
My proposal keeps parameters for matchers and parameters for mailets
separate, so that there isn't a chance of namespace collision. Remember
that matchers and mailets should be capable of arbitrary mixing. As I see
it, your scheme flattens and merges the name spaces.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: James -> Phonix 4.0aX (minor changes)
Posted by Andrei Ivanov <my...@surfeu.fi>.
Hi,
> structures, which are currently [name, value] pairs. You'd be
complicating
> access to the configuration data from the current value = get(name)
I am not sure. There is no complication and parsing and potential misusing
of configs. Everything
in org.apache.avalon.framework.configuration.Configuration is done for this.
It is a minor change which in no way interfere with any current
functionality. It just gives more
flexibility in configuring mailets.
It is only six methods getInitAttributeAsXXX to MailetConfig and ConfigImpl
and to GenericMailet.
> approach. And you don't know if the element is intended for the matcher
or
> mailet configuration.
No this is not so. Child element is always specified as a method parameter.
Andrei
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: James -> Phonix 4.0aX (minor changes)
Posted by "Noel J. Bergman" <no...@devtech.com>.
A problem with:
<maillet ...>
<addSubject enable="true" truncate="10"/>
</maillet>
is that it would complicate the parsing; and change the internal data
structures, which are currently [name, value] pairs. You'd be complicating
access to the configuration data from the current value = get(name)
approach. And you don't know if the element is intended for the matcher or
mailet configuration.
> just read Noel's response. I was thinking about simpler thing, but anyway
...
Actually, mine is an extension of exactly what is presently in the code.
All I did was add boundary tags to indicate which tags go into the matcher
or mailet config (currently, they all go into the mailet config), and clone
the mailet behavior onto the matcher. Very simple and straightforward to
implement from the code already present.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: James -> Phonix 4.0aX (minor changes)
Posted by Andrei Ivanov <my...@surfeu.fi>.
Hi, thanks for answer, may be I am mistaken, though... Suppose I want to
configure a mailet which does some tricks with message subject and I would
like to configure it the following way:
<maillet ...>
<addSubject enable="true"
truncate="10"/>
</maillet>
may be this is not very good example but "enable" and "truncate" are
attributes which I would like to access in mailet as e.g.
getInitAttributeAsInteger("addSubject", "truncate", 0);
Regards,
Andrei
PS just read Noel's response. I was thinking about simpler thing, but
anyway...
----- Original Message -----
From: "Serge Knystautas" <se...@lokitech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Saturday, May 18, 2002 9:23 PM
Subject: Re: James -> Phonix 4.0aX (minor changes)
> Can you explain what you mean by attributes? I think we're talking
> about very different things.
> --
> Serge Knystautas
> Loki Technologies - Unstoppable Websites
> http://www.lokitech.com/
>
> Andrei Ivanov wrote:
> > Hi,
> >
> >
> >>I'm not sure what your suggesting... you can already pass attributes to
> >>Mailets as init parameters.
> >
> >
> > How? MailetConfig has only one method: String getInitParameter(String
name)
> > ...
> >
> >
> >>I'm not sure about the others... I don't think we can distribute the
> >>jsse jar,
> >
> >
> > I know that, of course we can't distribute jsse, but presence of them
can be
> > detected in build (same way as in cornerstone). Many use jdk < 1.4 so
that
> > there will be no need to modify build script.
> >
> >
> >>I'm not sure about the keystore... can you give a diff to show what
> >
> >
> > I'll send that later.
> >
> > Regards,
> > Andrei
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: James -> Phonix 4.0aX (minor changes)
Posted by Serge Knystautas <se...@lokitech.com>.
Can you explain what you mean by attributes? I think we're talking
about very different things.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Andrei Ivanov wrote:
> Hi,
>
>
>>I'm not sure what your suggesting... you can already pass attributes to
>>Mailets as init parameters.
>
>
> How? MailetConfig has only one method: String getInitParameter(String name)
> ...
>
>
>>I'm not sure about the others... I don't think we can distribute the
>>jsse jar,
>
>
> I know that, of course we can't distribute jsse, but presence of them can be
> detected in build (same way as in cornerstone). Many use jdk < 1.4 so that
> there will be no need to modify build script.
>
>
>>I'm not sure about the keystore... can you give a diff to show what
>
>
> I'll send that later.
>
> Regards,
> Andrei
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: James -> Phonix 4.0aX (minor changes)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
I believe that Andrei is being precise in his use of the terminology.
As I see it, currently the <mailet> tag ATTRIBUTES are opaque. They are
processed in JamesSpoolManager.java. The MatchLoader uses the match
attribute to setup a mailet instance; the MailetLoader uses the class
attribute to setup a mailet instance. The Matcher is provided with just a
condition string taken from the match attribute. The Mailet is more
flexible: it gets to process child ELEMENTS of the <mailet> tag, via the
MailetConfig.getInitParameter() method.
Andrei is asking for more access to the attributes of the tag. With more
complex matchers, I can certainly see an argument for providing better
parameter passing to the matcher, rather than having to deal with a single
ad hoc encoded string.
I'm not sure if providing access to attributes is the right way to do it
(read as: I think that it is not), or if there should be optional
<matcher-config> and <mailet-config> child sections under <mailet>, e.g.,
<mailet matcher="Foo[=cond]" class="Bar">
<matcher-config>
<tagname>value</tagname>
</matcher-config>
<mailet-config>
<tagname>value</tagname>
</mailet-config>
</mailet>
Access would be via a [Mailet|Matcher]Config.getInitParameter() method as
currently exposed via MailetConfig.getInitParameter().
--- Noel
-----Original Message-----
From: Andrei Ivanov [mailto:myfam@surfeu.fi]
Sent: Saturday, May 18, 2002 13:56
To: James Developers List
Subject: Re: James -> Phonix 4.0aX (minor changes)
Hi,
> I'm not sure what your suggesting... you can already pass attributes to
> Mailets as init parameters.
How? MailetConfig has only one method: String getInitParameter(String name)
...
>
> I'm not sure about the others... I don't think we can distribute the
> jsse jar,
I know that, of course we can't distribute jsse, but presence of them can be
detected in build (same way as in cornerstone). Many use jdk < 1.4 so that
there will be no need to modify build script.
> I'm not sure about the keystore... can you give a diff to show what
I'll send that later.
Regards,
Andrei
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>