On Oct 10, 2007, at 2:44 AM, Emmanuel Lecharny wrote:
Hi guys,
I would be very interested (and the users too) to get some page on our
wiki explaining how to add a new interceptor in the current chain,
using xbeans. I'm trying to figure out how to have the ChangeLog
interceptor configured and used by the server, but I must admit I
don't have a clue.
Of course, it's not really urgent, but I think we need it before we
move to Phase II
Let's preview an explanation here to see if it explains enough.
1. Make sure xbean can find your interceptor by including
@org.apache.xbean.XBean in the class level javadoc. Simple single-
valued configuration attributes don't need any special attention, but
collection-valued configuration attributes need additional info so
xbean can figure out the type: @org.apache.xbean.Property
nestedType="org.apache.directory.server.core.partition.Partition" on
a setter for instance. I haven't figured out how to annotate
collection-valued constructor args yet.
2. If your interceptor is part of apacheds you just need to make sure
that the source jar for the module is a dependency of the apacheds-
xbean-spring module so xbean will process your annotations with all
the others. If you are writing a 3rd-party interceptor you need to
configure the xbean maven plugin to produce the schema and property
files for your components. If there's only one jar involved you
should configure the x-m-p in the module itself, whereas if there are
multiple jars involved you may wish to have maven compile source jars
and generate a single schema as in apacheds-xbean-spring so all
components share the same schema namespace. A typical x-m-p
configuration would look like:
<build>
<plugins>
<plugin>
<groupId>org.apache.xbean</groupId>
<artifactId>maven-xbean-plugin</artifactId>
<executions>
<execution>
<configuration>
<namespace>http://my.project.com/config/1.0</namespace>
<schema>target/xbean/${pom.artifactId}.xsd</schema>
</configuration>
<goals>
<goal>mapping</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- lets ensure that the XSD gets deployed -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>attach-artifacts</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>${basedir}/target/xbean/$
{pom.artifactId}.xsd</file>
<type>xsd</type>
</artifact>
<artifact>
<file>${basedir}/target/xbean/$
{pom.artifactId}.xsd.html</file>
<type>xsd.html</type>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Note the namespace that you should adjust to something appropriate
for your project.
3. To include and configure your interceptor you need to modify the
server.xml used by your server. Here's the bit that configures the
interceptors with a mythical fooInterceptor from the mythical third
party project included:
<interceptors>
<normalizationInterceptor/>
<authenticationInterceptor/>
<referralInterceptor/>
<aciAuthorizationInterceptor/>
<defaultAuthorizationInterceptor/>
<exceptionInterceptor/>
<operationalAttributeInterceptor/>
<!-- Uncomment to enable the password policy interceptor
<passwordPolicyInterceptor/>
<keyDerivationInterceptor/>
-->
<fooInterceptor size="1" color="blue" xmlns="http://
my.project.com/config/1.0">
<bar>
<bar width="2000"/>
</bar>
</fooInterceptor>
<schemaInterceptor/>
<subentryInterceptor/>
<collectiveAttributeInterceptor/>
<eventInterceptor/>
<triggerInterceptor/>
<!-- Uncomment to enable replication interceptor
<replicationInterceptor>
<configuration>
<replicationConfiguration serverPort="10390"
peerReplicas="[EMAIL PROTECTED]:10392">
<replicaId>
<replicaId id="instance_a"/>
</replicaId>
</replicationConfiguration>
</configuration>
</replicationInterceptor>
-->
</interceptors>
thanks
david jencks
Thanks a lot !
On 10/10/07, David Jencks <[EMAIL PROTECTED]> wrote:
In rev 583375 I moved all the non-ldap protocol servers into
independent
components and provided 2 NTP implementations as a basis for further
discussion.
NtpConfiguration illustrates the approach of a single component to
configure
both udp and tcp versions of the same protocol. This could
trivially be
enhanced with flags to enable/disable the tcp or udp choices. If
we decide
on this approach I would rename the class NtpServer.
server.xml configuration of this looks like:
<ntpConfiguration ipPort="80123">
<apacheDs>#apacheDS</apacheDs>
</ntpConfiguration>
AbstractNtpServer, TcpNtpServer, and UdpNtpServer illustrate the
approach of
a component per protocol version. server.xml configuration of
this looks
like:
<udpNtpConfiguration ipPort="81123">
<apacheDs>#apacheDS</apacheDs>
</udpNtpConfiguration>
<tcpNtpConfiguration ipPort="81123">
<apacheDs>#apacheDS</apacheDs>
</tcpNtpConfiguration>
I don't have a strong preference between these two approaches and
think they
both are equally good components. I think the first, single
component
managing both servers, will be easier for our users to understand and
configure, although it might be conceptually slightly less pure.
Whatever the outcome of this discussion I think the next step,
other than
conforming the protocol servers to whatever we decide, is to move
the mina
setup code in ApacheDS into a separate component: this would
replace the
ApacheDS reference in all these servers.
thanks
david jencks
On Oct 9, 2007, at 2:25 PM, Alex Karasulu wrote:
On 10/9/07, David Jencks <[EMAIL PROTECTED]> wrote:
NTP is pretty darn simple and I'm going to code up a couple of
examples using it so we can better see what we are talking about.
NTP is simple and one of the reasons why I picked it for the
example. Also
as you
say it can be used for a simple experiment to see the impact of
what we want
to do
without a massive investment in time.
On the other hand although NTP is the easiest to understand the same
reasoning may not
apply to the other protocols. Enrique understands these best so
he might
have something to share
about it. Knowing that he's not on IRC I made sure he got wind of
it by
posting it here.
There's an extreme danger here of making a mountain out of a
molehill :-)
Well the plan was simple: get rid of the configuration beans and
directly
wire up the components.
As I said this was your idea and a damn good one. I just don't want
configuration beans floating
around with one exception here and one exception there.
Let's set a standard pattern to follow and stick to it.
Alex
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
