<?xml version="1.0" encoding="UTF-8"?>
<chapter id="joinpoint">
  <title>Joinpoint - Accessing a Bean</title>

  <para>WARNING: The joinpoint model is subject to change without notice. It
  is currently under developement as issues with AOP integration and using the
  Microcontainer in more constrained environments are investigated.</para>

  <para>The joinpoint model provides a mechanism to access class operations in
  a standard way.</para>

  <section>
    <title>Aims</title>

    <section>
      <title>Stanardize reflection operations</title>

      <para>There are many places that use reflection within JBoss. The
      joinpoint provides a mechansim to deal with reflection dispatching
      without having worry about all the standard error handling, etc.</para>
    </section>

    <section>
      <title>Overridding Definition</title>

      <para>The joinpoint allows the mechanism of dispatch to be overridden
      either through configuration or implementation. Examples would be not
      using get/set to define a property either because it is a different
      method name or it should use direct field access.</para>
    </section>
  </section>

  <section>
    <title>Issues</title>

    <section>
      <title>javabean versus object</title>

      <para>Much of the javabean abstraction has moved the BeanInfo model, it
      is questionable whether the ability to override on a plain object is
      still required.</para>
    </section>

    <section>
      <title>Alternative implementations</title>

      <para>One use of this abstraction would be to precompile reflection
      objects using javassist for use in environments where dynamic reflection
      is not supported.</para>
    </section>

    <section>
      <title>AOP</title>

      <para>Another potential other use is to "optimize away" reflection when
      already dispatching requests through AOP.</para>
    </section>
  </section>
</chapter>