■Introduction to ColdSpring AOP
Aspect Oriented Programming is a fairly new programming model that assists in handling far reaching services, like logging, security, transactions and object caching, in your model. Services like these are beginning to be referred to as ‘crosscutting concerns’, because they are applied broadly across your application. In order to add a service such as logging to an application, you typically find yourself applying very similar code all throughout your model, which when scrutinized, probably has nothing to do with the actual functionality of your components. AOP allows you to insulate these types of crosscutting concerns from the rest of you application, and apply them broadly based on certain policies that you as the developer define.

アスペクト指向プログラミングは、modelのなかで、ロギング、セキュリティ、トランザクション及びオブジェクトキャシングなどの遠くに位置するサービスの処理をアシストするための全く新しいプログラミングモデルです。
これらのサービスはアプリケーションを通じて広く利用されるので、"横断的関心事：crosscutting concerns"として参照され始めています。
あるアプリケーションにロギングのようなサービスを加えるためにアプリケーションをよく吟味すると、おそらくコンポーネントの実際の機能性とは全く関係ない非常に似たようなコードがモデル中に散見されます。
AOP は、アプリケーションから横断的関心事となるAOPパターンを隔離できるので、開発者の定義するポリシーに広く基づいて応用できます。

Using AOP is basically a process of looking at the types of concerns in your application and then breaking them apart into primary concerns, like your managing your shopping cart or navigating through and administering your product catalog, your application’s primary business logic, and crosscutting, generalized concerns, such as logging and security. These crosscutting concerns become what are known as ‘aspects’, and with AOP can be written singularly focused on the issues they solve, becoming more portable and reusable. These aspects are then applied to your model according to policies that you define, through a process known as ‘weaving’, which is performed by the AOP framework.

AOP を使用することは、アプリケーション中の関心事のパターンを探し出し、ショッピングカートのマネージメントやナビゲーション及び商品カタログの管理など、主要な関心事をアプリケーション主要ビジネスロジックと、ロギングやセキュリティのような汎用的な関心事にバラバラに分割する基本的なプロセスを行うことです。
これらの横断的な関心事は、アスペクト（局面）として知れれるものになります。そして、AOPを用いると、よりポータブルで再利用性に優れた解決すべき核心だけにフォーカスされたプログラムを書くことができます。
これらのアスペクトは、'weaving'と呼ばれるプロセスを通じ、AOPフレームワークによって実行される定義済みのポリシーに従って、modelに適用されます。

Defining policies is a matter of identifying ‘join points’ in your model, specific areas where you would like to apply the ‘advice’ of your aspects, meaning the specific action that you would like to take place at a certain time in your application. Join points are created using ‘pointcuts’ which are defined with wildcards or regular expressions to identify methods in your objects. Don’t get too worried about the terminology here; the primary concept is that you already have objects with methods in them that you want to add functionality to. You do this through advice. There are three types of advice available in ColdSpring AOP, before, after, and around advice. Before advice is run before the join point will be performed; after advice will be run after the join point. Around advice is like a combination of both. Around advice is actually quite powerful because it is given full control of the execution of the join point and it has the ability to advise errors through try/catch blocks.

ポリシーを定義することは、modelコンポーネント内で、アスペクトの'advice'（アプリケーション内のあるときに起こしたい特定のアクションを意味します。）を適用したい特定の領域となるジョインポイント：joinpointをおよそ同定することです。
ジョインポイントは、オブジェクト内のメソッドを同定するためにワイルドカードや正規表現によって定義されたポイントカット：pointcutを使って生成されます。
ここでは、専門用語にあまり惑わされないでください。一番大事なコンセプトは、機能性を追加したいオブジェクト内にメソッドを有するオブジェクトを既に持っているということです。
ColdSpring AOPには、利用可能な３つの型式のアドバイス（'before'、'after'、そして'around'）があります。
'Before'アドバイスは、ジョインポイントが実行される前にコールされます。
'After'アドバイスは、ジョインポイントの実行後にコールされます。
'Around'アドバイスは、両方のコンビネーションです。'Around'アドバイスは、かなり強力です。なぜなら、ジョインポイントの実行の完全な制御を与えられ、try/catchブロックを通してエラーをアドバイスできるからです。

The final concepts to understand in AOP are ‘target’ and ‘proxy’ objects. The target object is object in your model that you want to apply your aspects to. Through the process of weaving, the AOP framework will use the policies you defined via pointcuts to build a new proxy object containing the configured advice, which, and here’s the most important part, appears to be one in the same as the target object to the rest of your application. Now I know a lot of this is sounding confusing and a bit difficult, but it’s important to understand that most of the work is actually done for you. You will primary concern yourself with creating the advice objects themselves. Pointcuts are defined through configuration and ColdSpring AOP handles the rest. In the context of ColdSpring, the configuration is done through an xml file, and the proxy object can be swapped out for the target object with minimal effort.

AOP で理解するべき最終的な概念は、'ターゲット：target' 及び'プロキシー：proxy'オブジェクトです。
ターゲットオブジェクトは、アスペクトを適用したいmodel内のオブジェクトです。
'weaving'プロセスを通して、AOP フレームワークは、設定済のアドバイスを含む新規のプロキシーオブジェクト（ここに最も重要な部分があります。
アプリケーションの残りに対するターゲットオブジェクトして唯一無比となるプロキシー）を生成するようにポイントカットで定義されたポリシーを使用します。
多くの仕事のほとんどが実際に終ったことを理解することは重要ですが、混乱と少しの困難さがあることもたくさん分かっています。アドバイスオブジェトをそれ自身に作成することによって、主要な関心をそれ自身に向けることができます。
ポイントカット はコンフィグレーションファイルを通して定義され、ColdSpring AOP はその残りを扱います。
ColdSpring のコンテキストでは、コンフィグレーションはxml ファイルを通して実行され、ターゲットオブジェクトは最小の努力でプロキシーオブジェクトを通して取り次がれます。

I’ll post some actual examples after I get a chance to run through them at the conference and get some feedback. Hopefully I’ll get a chance to meet a few people who just may have read some of this there!

私はあるコンファレンスでデモし、フィードバックを得るチャンスを得られたらいくつかのサンプルを投稿する予定です。うまく行けば、そのコンファレンスでこの記事を読んでくれた数人のメンバーと会うチャンスがあるでしょう！

posted by Chris Scott at 5:33 PM

■ColdSpring AOP Tutorial - Part One
Since I have already given an overview of ColdSpring’s AOP concepts, I’m going to just dive right into things. For part one of the developing with ColdSpring AOP, I’ll show how you can use a simple form of Advice called Before Advice to provide logging services to a model component. These examples are from the Klondike Records application that I showed at the frameworks conference last week, which we will also be releasing as an example application. I’ll show you how to define an Advice cfc, which will extends coldspring.aop.BeforeAdvice, how to define Pointcuts via Advisors in a standard ColdSpring config file, and how to use coldspring.aop.

ColdSpring AOP のコンセプト概要は既に説明したので、プログラミング詳細に没頭してみましょう。
ColdSpring AOPによるアプリケーション開発の第一弾として、modelコンポーネントにロギングサービス機能を提供するBeforeアドバイスと呼ばれるアドバイスの簡単なパターンを示します。
これらの例は、先週のフレームワークコンファレンスでデモした近い将来アプリケーション例としてリリースする予定のKlondike Recordsアプリケーションのパターンです。
coldSpring.aop.BeforeAdviceを継承したAdvice.cfc、ColdSpringコンフィグレーションファイルにおけるポイントカットとアドバイザーの定義方法、そして、coldspring.aopコンポーネント群の使用方法を示します。

ProxyFactoryBean to wrap the Advice around methods of a target object by creating a Proxy object, containing the target. Think about the proxy object like an egg. The object you want to apply logging to would be the yoke and the Advice that provides the logging functionality is the egg white surrounding it. When the proxy factory creates this egg, and this is the great part, everything in you application thinks that it’s the same object that’s in the yoke! OK, so so let’s get right into it. First we’ll define a model component, which will be called CatalogDAO.cfc which we’ll then add logging services to.

ターゲットオブジェクトを含むあるプロキシープロジェクトを作成することによって、あるターゲットオブジェクト内メソッド周辺のAdviceをラップすることがProxyFactoryBeanによって可能です。
プロキシーオブジェクトは卵のようなもとだと考えてください。
ロギングさせたいと望むオブジェクトは卵の黄身であり、ロギング機能を提供するアドバイスは、それを囲む卵白だということです。
プロキシーファクトリーがこの卵を生成するとき、そうこれが非常に重要なことですが、黄身のなかにあるオブジェクトと同じオブジェクトだとアプリケーションは考え、｢はいはい、その中に入っていきましょう。｣といいます。
最初にロギングを追加するCatalogDAO.cfc と呼ばれるmodelコンポーネントを定義してみましょう。

<cfcomponent name="CatalogDAO" output="false">

  <cffunction name="init" access="public" returntype="Any" output="false">
    <cfreturn this />
  </cffunction>

  <!--- setters for dependencies --->
  <cffunction name="setDataSource" returntype="void" access="public" output="false" hint="Dependency: datasource name">
    <cfargument name="dsn" type="string" required="rue"/>
    <cfset variables.m_dsn = arguments.dsn />
  </cffunction>

  <!--- fetch a record --->
  <cffunction name="fetch" returntype="query" access="public" output="false">
    <cfargument name="recordID" type="numeric" required="true" />
    <cfquery name="qrySelect" maxrows="1" datasource="#variables.m_dsn#">
    SELECT QUERY …
    </cfquery>
    <cfreturn qrySelect />
  </cffunction>

  <!--- insert record --->
  <cffunction name="create" returntype="void" access="public" output="false">
    <cfargument name="record" type="net.klondike.component.Record" required="true" />
    <cfset var qryInsert = 0 />
    <cfquery name="qryInsert" datasource="#variables.m_dsn#">
    INSERT QUERY …
    </cfquery>
  </cffunction>

  <!--- update record --->
  <cffunction name="update" returntype="void" access="public" output="false">
    <cfargument name="record" type="net.klondike.component.Record" required="true" />
    <cfset var qryUpdate = 0 />
    <cfquery name="qryUpdate" datasource="#variables.m_dsn#">
    UPDATE QUERY …
    </cfquery>
  </cffunction>
</cfcomponent>


Obviously we’re skipping some details, but the point is that this is just a standard model component; we don’t extend anything or put any special code here. The component should be completely usable with or without AOP. In my example app you will see that this dao is used as part of a service component, which is used by the catalogListener in the mach-ii app. The nice thing about using AOP to provide logging is that neither the dao nor the service component that uses it will have any code in them pertaining to logging. They are only concentrated on fetching and storing records, cohesion. I like to use log4j, so I’ll create a LoggingService cfc to handle the configuration details and provide a common api to my Aspects. Also, if I want to switch this out to use cflog or another implementation, I can do that in one place. So here’s the LoggingService cfc, but I’ll skip showing how to actually configure log4j, since I have already shown that in an earlier post. This service basically just retrieves the logger and wraps its info() method.

明らかに、細部はとばしていますが、これがちょうど標準的なModelコンポーネント（何も継承していないし、また特別なコードもない）であることがポイントです。
コンポーネントは、AOP の有無にかかわらず、完全に再利用可能であるべきです。
このサンプルアプリケーションでは、Mach-IIアプリケーションのcatalogリスナーによって利用されているサービスコンポーネントの一部としてdaoが使用されているということです。
ロギング提供のためにAOP を使用することの素晴らしいことは、ロギングに関係するコードを、daoやサービスコンポーネントの中に一切書く必要がないということです。
daoやサービスコンポーネントは、レコードデータのフェッチやストア及び結合に専念するだけです。
私はlog4j をよく使用するので、コンフィグレーションの細部取扱いと共通APIをアスペクトに提供するために、LoggingService.cfcを作成しています。
また、cflog を使用するか別の実装に転換したいと思うので、1 つの場所のロギングサービスを利用することができるようにしています。
LoggingService.cfc を以下に示しますが、以前の投稿で既にそれを示してしまったので、log4jの実際のコンフィグ方法は今回省略します。
このサービスは、基本的にロガーからログ情報を取り出し、info() メソッドに取次ぎます。

<cfcomponent name="LoggingService" output="false">

  <cffunction name="init" returntype="net.klondike.service.LoggingService" access="public" output="false">
    <cfset var category = CreateObject("java", "org.apache.log4j.Category") />
    <cfset variables.logger = category.getInstance('net.klondike') />
    <cfreturn this />
  </cffunction>

  <cffunction name="info" access="public" returntype="void" output="false">
    <cfargument name=message" type="string" required="true" />
    <cfif variables.logger.isInfoEnabled()>
    <cfset variables.logger.info(arguments.message) />
    </cfif>
  </cffunction>

</cfcomponent>


Ok, now onto the AOP part. I will first create a Before Advice to retrieve information about the current method being invoked and send it off as the message argument to the logging service’s info() method. Here’s the loggingBeforeAdvice cfc.

それでは、AOPパートに移りましょう。
最初にBeforeアドバイスを作成し、呼び出し先のカレントメソッドの情報を取り出し、ロギングサービスのinfo()メソッドに引数messageとして送り出します。
loggingBeforeAdvice.cfcを以下に示します。


<cfcomponent name="loggingBeforeAdvice" extends="coldspring.aop.BeforeAdvice">

  <!--- setters for dependencies --->
  <cffunction name="setLoggingService" returntype="void" access="public" output="false" hint="Dependency: security service">
    <cfargument name="loggingService" type="net.klondike.service.LoggingService" required="true"/>
    <cfset variables.m_loggingService = arguments.loggingService />
  </cffunction>
  <cffunction name="getLoggingService" returntype="net.klondike.service.LoggingService" access="public" output="false" hint="Dependency: security service">
    <cfreturn variables.m_loggingService />
  </cffunction>

  <!--- before() is called by the aop framework before method invocation --->
  <cffunction name="before" access="public" returntype="any">
    <cfargument name="method" type="coldspring.aop.Method" required="true" />
    <cfargument name="args" type="struct" required="true" />
    <cfargument name="target" type="any" required="true" />

    <cfset var arg = '' />
    <cfset var argString = '' />
    <cfset var objName = getMetadata(arguments.target).name />
    <cfloop collection="#args#" item="arg">
      <cfif isSimpleValue(args[arg])>
        <cfif len(argString)>
          <cfset argString = argString & ', ' />
        </cfif>
        <cfset argString = argString & arg & '=' & args[arg] >
      </cfif>
    </cfloop>

    <cfset variables.m_loggingService.info("[" & objName & "] " & method.getMethodName() & "(" & argString & ") called!") />

  </cffunction>

</cfcomponent>


This probably looks more complicated that it really is, so I’ll walk through it. First off we extend coldspring.aop.BeforeAdvice, which provides typing for the aop framework, and the ‘before’ method which you will overwrite. Next we have a setter and a getter which ColdSpring will use to inject the LoggingService, and the AOP framework will use to clone the Advice. The heart of this cfc, however, is the before() method, which gets passed a Method object, responsible for handling the actual method call, the argument collection passed to the method, and the target object which receives the method call. You can see that you have an amazing amount of power at this point. But all I’m going to do here is get the name of the target object through metadata, the name of the method from the Method object, and I’ll loop through the arguments to find simple values that I can print as strings. From this I make a string to pass to my loggingService that will look something like this: ‘[net.klondike.component.catalogGateway] getGenres() called!’. One important thing to note here is that Before Advice can alter the arguments going into the method at this point, but is not responsible for actually executing the method, even though it does have access to it. There is another type of Advice that should be used if you want control over method execution, called Around Advice, but I will delay that discussion until part two. Here’s where the advice of ‘be really careful’ comes in. No other object in you application has any idea of what is going on at this point, so you can really cause havoc, so be careful!

リアルに書いたので、ちょっと複雑に見えるかもしれませんので、順序良く追ってみたいと思います。
最初に、AOPフレームワークの型式を提供するcoldspring.aop.BeforeAdviceを継承し、'before'メソッドをオーバライドしています。
次に、LoggingServiceに投射するためにColdSpringが使用するsetterメソッドとgetterメソッドがあります。
そして、AOPフレームワークが複製として使用するAdviceメソッドがあります。
しかしながら、このcfcの心臓部は、実際のメソッドコールに責任を持つメソッドオブジェクト、メソッドに渡された引数のコレクション、メソッドコールを受け取るターゲットオブジェクトを渡されるbefore()メソッドにあります。
この時点で、驚くべきColdSpringAOPのすばらしさを垣間見ることができます。
しかし、ここにしようと思っているすべては、metadata を通して得るターゲットオブジェクト名、メソッドオブジェクトから得られるメソッド名を得ることであり、文字列として印刷可能なシンプルバリューを見つけるために私は引数コレクションをループします。
このことから、loggingService に渡す文字列（'[net.klondike.component.catalogGateway ] getGenres() called!' のような）作成します。
留意すべき一つの重要な事は、BeforeAdviceがこの時点でメソッドに投射する引数を変化させることができるということ、しかしながら、メソッドにアクセスできたとしてもメソッドを実際に実行できるかどうかはわからないということです。
'Around Advice'と呼ばれるメソッドの実行制御に際して使用するもう一つの型式のAdviceがありますが、本シリーズのパート２まで解説は先送りしておきます。
ここでは、Adviceは十分注意深く役割を果たすということに留めておきます。
アプリケーション内の他のオブジェクトは、この時点で何が進行しているか一切考えないので、本当に大混乱を引き起こすかもしれません。ですから、本当に注意してください!

Ok, so now we have a DAO that we want to apply logging to, a simple loggingService, and a Before Advice to apply the logging service with. Now this may seem like a lot of work to add logging to a method, and that’s true. But this Advice can be applied to ALL you model components without writing any more code, logging method calls across your entire application. All that’s left is configuring these components. As I wrote in my earlier post, this is a matter of identifying Join Points, methods that you want to log in objects, which is done through Pointcuts, with an Advisor. An Advisor is basically a collection of methods and advice to apply to them. OK, so here’s the ColdSpring config file that will tie all this together.

さて、私たちは、ロギングを適用するDAO、単純なロギングサービス及びロギングサービスを適用するBefore Adviceを持っています。
あるメソッドにロギングを追加するためには、たくさん行うべきことがあるように見えます。事実そうです。
しかし、このAdviceは、アプリケーション全体を渡ってメソッドコールをロギングするコードを書くことなしに、modelコンポーネント全体に適用することができます。
残りはすべて、これらのコンポーネントを構成するものとなります。以前の記事に書いたように、オブジェクト内でログを取りたいメソッド群は、ジョインポイントを認識するということです。
ロギングは、Advisorを伴い、PointCutsを通して行われます。Advisorは、基本的にメソッドのコレクションであり、メソッドにAdviceを与えます。
さあ、これらをすべてひとくくりにしたColdSpring の設定ファイルを見てみてください。

<beans>

  <!―define the logging service -->
  <bean id="loggingService"
class="net.klondike.component.LoggingService" />

  <!--define the loggingBeforeAdvice and set its logging service property to reference the bean above -->
  <bean id="loggingBeforeAdvice"
class="net.klondike.aspects.loggingBeforeAdvice">
    <property name="loggingService">
      <ref bean="loggingService" />
    </property>
  </bean>

  <!―now define a NamedMethodPointcutAdvisor, set the advice property to the bean above, and set its mappedNames property to ‘*’ which will create a pointcut to match all methods excluding any init method -->
  <bean id="loggingAdvisor"
class="coldspring.aop.support.NamedMethodPointcutAdvisor">
    <property name="advice">
      <ref bean="loggingBeforeAdvice" />
    </property>
    <property name="mappedNames">
      <value>*</value>
    </property>
  </bean>

  <!-- to create the proxy object, first create our dao as the target object -->
  <bean id="catalogDaoTarget"
class="net.klondike.component.catalogDAO">
    <property name="dsn">
      <value>klondike</value>
    </property>
  </bean>

  <!-- now create a ProxyFactoryBean with the id catalogDAO, set the target to the catalogDaoTarget bean above, and give it ,the id of the NamedMethodPointcutAdvisor above in the list of interceptorNames -->
  <bean id="catalogDAO"
class="coldspring.aop.framework.ProxyFactoryBean">
    <property name="target">
      <ref bean="catalogDaoTarget" />
    </property>
    <property name="interceptorNames">
      <list>
        <value>loggingAdvisor</value>
      </list>
    </property>
  </bean>

  <!--now to use the proxy DAO, we give the id of the ProxyFactoryBean to the catalog service as the reference for the property catalogDAO -->
  <bean id="catalogService"
class="net.klondike.component.CatalogService">
    <property name="catalogDAO">
      <ref bean="catalogDAO" />
    </property>
  </bean>

</beans>


That’s it for the configuration. When you ask the ColdSpring bean factory for your catalogService, ColdSpring will create the ProxyFactoryBean and ask it to return a proxy object. The ProxyFactoryBean will in turn get a reference to the target object, the real DAO object, get the Advisor which contains the Aspect we created, causing the loggingService to be created, and will finally generate an entirely new cfc, which contains the target object, the proxy for the catalogDAO. This proxy object will be the same type as the target object and will contain all the same methods as the target, except that it will now flow every method through an instance of the loggingBeforeAdvice. If I want to add the same advice say to a gatewayObject, all I have to do is create another target object, and another ProxyFactoryBean and give it the same Advisor. If this doesn’t seem powerful enough for you, you can also create a new Advice, say a securityAdvice, and create a new Advisor, matching only the ‘save’ method, and give this to the ProxyBeanFactory we defined above. That would make that bean definition look something like this:

それでは、コンフィギュレーションに移りましょう。
catalogService をColdSpringのbeanファクトリーに要求すると、ColdSpring はProxyFactoryBean を作成し、ProxyFactoryBeanを生成し、プロキシーオブジェクトを返すようにそれに依頼します。
ProxyFactoryBeanは、次に実際のDAOオブジェクトとなるターゲットオブジェクトへの参照を得て、生成したアスペクトを含むAdvisorを得ます。このAdvisorは、loggingServiceを生成することになります。
また、ProxyFactoryBeanは、最終的にcatalogDAOへのプロキシー機能を有する全く新規のcfcを作り出します。このプロキシーオブジェクトは、ターゲットオブジェクトと全く同一のタイプで、loggingBeforeAdviceのインスタンスとして、メソッドの実行毎に追跡することを除いて、ターゲットと全く同一のメソッドを含みます。
あるGatewayオブジェクトに同じAdviceをしゃべるように追加する場合でも、他のターゲットオブジェクトの生成及び他のProxyFactoryBeanの生成とAdvisorへのくくりつけは、全く不要です。
もし、不十分であるようなら、新規のAdvice、即ちsecurityAdviceを作成し、また'save'だけにマッチする新規Advisorを作成し、前述のProxyFactoryBeanに与えることができます。
以上のことをbean定義にすると、以下のようになります:

<bean id="catalogDAO"
class="coldspring.aop.framework.ProxyFactoryBean">
  <property name="target">
    <ref bean="catalogDaoTarget" />
  </property>
  <property name="interceptorNames">
    <list>
      <value>loggingAdvisor</value>
      <value>securityAdvisor</value>
    </list>
  </property>
</bean>


Adding the securityAdvisor after the loggingAdvisor causes it to be chained after the loggingAdvice, so if that Advice does something like throw an ‘InvalidCredentials’ error, the loggingAdvice will get a chance to write to the log before the method execution stops. So that’s just a small piece of the framework, the least powerful type of Advice we have available. After Advice is very similar to Before Advice, except that it occurs after method execution, giving you access to the return variable from the method as well as argument collection that was passed into the method. Wow, so that’s a pretty big blog post! I hope I’ve wet your appetite, and stay tuned because a super-prealpha-ubermethodology-oops-sorry-release is just around the corner!

loggingAdvisorに続いてsecurityAdvisorを追加すると、loggingAdviceに続いてsecurityAdviceをチェーンさせることになるので、loggingAdviceが何らかの'InvalidCredentials'エラーを投げるような何かを行った場合でも、loggingAdviceはメソッドの実行停止前にログを書き込むことができます。フレームワークのほんの小さな一部分ですが、Adviceは十分大きな力を発揮します。
AfterAdviceは、メソッドの実行後にインターセプトを発生させる点を除いて、BeforeAdviceに大変似ています。
これによって、メソッドに渡された引数コレクションなどをメソッド戻り値としてアクセスできるようになります。
さあて、かなり大きいblog の記事になってしまいましたね。 お気に召していただけましたか？あるsuper-prealpha-ubermethodology-oops-sorry-releaseの完成間近なので、このへんで失礼します。

posted by Chris Scott at 8:15 PM

■ColdSpring, Model-Glue and Logging with AOP
After a little bit of trial and error, I just succeeded in (a) integrating ColdSpring with Model-Glue, (b) defining logging advice after a method call and (c) actual logging results returned from methods!

ほんの少しのトライアルとエラーを経て、
(a)ColdSpringとModel-Glueを統合
(b)メソッドコール後のロギング用Adviceの定義
(c)メソッド実行後のロギング結果取得
に成功した。

Dave Ross shows how to use the Model-Glue adapter in ColdSpring - the returnType= attribute should actually specify the fully-qualified return type tho'. That combined with Chris Scott's AOP tutorial and a quick read of the source code (download 0.2.1 from cfopen).

Dave Rossは、ColdSpringにおけるModel-Glueアダプターの使用方法を示すなかで、returnTypeの属性指定を完全記述すべきであるとしている。Chris ScottのAOPチュートリアルとソースコードのクイックリードは結合されている（cfopenからVer0.2.1をダウンロードした）

My LoggingAfter CFC extends coldspring.aop.AfterReturningAdvice, implements afterReturning() which logs a message and then returns arguments.returnVal (very important!).

私のLoggingAfter.CFCは、coldspring.aop.AfterReturningAdviceを継承し、メッセージをロギングし、arguments.returnValを戻すafterReturning()を実装している。（とても重要）

My ColdSpring XML file specifies:
私のColdSpringXMLファイルの定義：

    * xxxTarget - my actual bean that I want to log methods in
    * xxx - a coldspring.aop.framework.ProxyFactoryBean that references xxxTarget and uses the logAfterAdvisor intercepter (below)
    * logAfterAdvice - my simple logging class
    * logAfterAdvisor - a coldspring.aop.support.NamedMethodPointcutAdvisor that specifies my logAfterAdvice as the advice property and * as the mappedNames (matches anything)

    * xxxTarget - ログを取りたいメソッドのターゲットbean名
    * xxx - xxxTargetを参照し、logAfterAdvisorインターセプター(以下)を使用するcoldspring.aop.framework.ProxyFactoryBean
    * logAfterAdvice - 単一のロギング機能を実装したのクラス
    * logAfterAdvisor - logAfterAdviceをAdviceのpropertyとして、* をmappedNamesとして指定した coldspring.aop.support.NamedMethodPointcutAdvisor
    

The results of calling methods in xxxTarget are logged automatically!
xxxTargetに指定されたメソッドの呼び出し結果が自動的にロギングされます！

Logging can be disabled by renaming the xxx and xxxTarget beans (so that my application code calls the actual bean, via the name xxx, instead of the proxy).

xxx BeanとxxxTarget Beanをリネームすることで、ロギング不可になります。（proxyの代わって、xxxによって実際のBeanを呼び出すので）

Very slick...
非常に滑らかです・・・

Update: see the next blog entry for an even simpler integration!

Posted At : 3:21 AM. | Posted By : seancorfield | modelglue, coldspring, cf | Comments (5) 

■Easy ColdSpring in Model-Glue
Dave Ross and Chris Scott are doing an _amazing_ job with the ColdSpring project. For those of you who aren't familiar with Spring, it's a Java framework that provides a number of services such as IoC (like ConfigBeans in Model-Glue), Aspect Oriented Programming, and ORM functionality amongst many things. Right now, ColdSpring is at 0.2.1 and provides IoC and Aspect Oriented functionality.

Dave RossとChris Scottが、ColdSpring のプロジェクトで_ 驚かせる_ 仕事をしている。Springをよく知られていない方々のために紹介すると、IoC (Model-GlueのConfigBeansのようなもの)、アスペクト指向プログラミング、そして多くのなかにあるORM（オブジェクトロールモデル）機能。今現在、ColdSpring は0.2.1 にあり、IoC 及びアスペクト指向機能を提供する。

Summary for the impatient - how to use ColdSpring seamlessly Model-Glue in four steps:
気短かな方のための概要- 4 つのステップでColdSpring とModel-Glueを使用する方法:

   1. Get latest from the BER Subversion repo.
   2. Add <setting name="beanFactoryLoader" value="ModelGlue.Core.ColdSpringLoader" /> to your ModelGlue.xml
   3. Change the beanMappings setting to the path to your ColdSpring xml: <setting name="beanMappings" value="/modelgluesamples/coldspring/config/beans/AllBeans.xml" />
   4. Instead of GetModelGlue().GetConfigBean("myBeanFileName.xml"), use GetModelGlue.GetConfigBean("ColdSpringBeanId") 

   1. Model-GlueのBERサブバージョンレポジトリから最新バージョンを入手。
   2. ModelGlue.xmlに以下を追加。
      <setting name="beanFactoryLoader" value="ModelGlue.Core.ColdSpringLoader" /> 
   3. ColdSpring xmlのパスをセットしているbeanMappingsを変更。
      <setting name="beanMappings" value="/modelgluesamples/coldspring/config/beans/AllBeans.xml" />
   4. GetModelGlue().GetConfigBean("myBeanFileName.xml")の代わりに、
      GetModelGlue.GetConfigBean("ColdSpringBeanId")を使用。 


ColdSpring is very nice, and Dave's done some nice work on Model-Glue integration that I decided to wrap into the framework itself, building some functionality into the Bleeding Edge Release of Model-Glue (svn://clearsoftware.net/clearsoftware.net/ModelGlue) that'll let you seamlessly use ColdSpring.

ColdSpringは、とてもすばらしい。そして、Daveは私がフレームワークに取り入れようとしていたModel-Glueとの統合をModel-GlueのBERリリース版にいくつかの機能を追加することで、見事にやってくれた(svn://clearsoftware.net/clearsoftware.net/ModelGlue) 。これで、Model-GlueからColdSpringをシームレスに使えるようになった。

Just add the following line of code to your ModelGlue.xml file:
使用方法は、ModelGlue.xmlに以下の１行を追加するだけです。

<setting name="beanFactoryLoader" value="ModelGlue.Core.ColdSpringLoader" />

Then change the beanMappings setting to your ColdSpring .xml file:
そして、ColdSpring .xmlのbeanMapping設定を変更します。

<setting name="beanMappings" value="/modelgluesamples/coldspring/config/beans/AllBeans.xml" />

Once that's done, if you do getModelGlue().getConfigBean(), instead of passing the filename of an XML file to get, just pass the ID of the ColdSpring bean to load.
一度、前述のことを行うと、XMLファイルを指定することなしに、getModelGlue().getConfigBean()を行うと、ColdSpringBeanのIDをローダーに渡してくれます。

If you get the latest M-G BER, you'll notice there's a modelgluesamples/coldspring app that shows it in action. The thing just _worked_ on the first try.
最新のModelGlue-BER版を入手すると、実際にそれを示したmodelgluesamples/coldspringサンプルアプリケーションがあることに気づくでしょう。まず、最初にそれを動かしてみることです。

Credit goes to Dave - he basically wrote the code to do it all, I just used the pluggable part of Model-Glue 1.0 to make it go.
Daveからの情報によると、彼は基本的なところはすべて書き上げており、私はその一部をModel-Glue Ver1.0に
プラグイン的に使いました。

Note: There are things to think about when using ColdSpring as the native bean factory in Model-Glue. You won't be able to use existing ChiliBean beans unless you create the ChiliBean BeanFactory by hand, so it's not something to implement mid-project. However, it wouldn't be hard to move ChiliBean XML files into a ColdSpring XML doc.

注意: ColdSpringをModel-Glueのネイティブなbeanファクトリーとして使用するにはまだまだ考慮すべきことがたくさんあります。ChiliBeanによるBeanファクトリーを手動で作成しないことには、既存のChiliBean Beanを使えなくなるでしょう。しかしながら、ChiliBeanXMLの内容をColdSpringXMLに移すことは、そう難しくはないでしょう。

Posted At : 10:12 AM. | Posted By : joe | Model-Glue Framework, OOP ColdFusion | Comments (2) 

■ColdSpring / Model-Glue Autowiring
I mentioned this feature earlier as an add-on but wanted to let folks know that the next release of ColdSpring will include the Model-Glue autowiring code (Dave Ross gave me commit access to the CVS repository - thanx!).

以前の記事でアドオンとして、ColdSpring / Model-Glue Autowiringを紹介しましたが、ColdSpringの次期バージョンにModel-Glue autowiringが実装されることになりました。（Dave RossがCVSレポジトリにアクセスすることの許可をくれました、サンクス Dave!)

That means that the Model-Glue / ColdSpring integration will be as simple as:
このため、Model-Glue と ColdSpring の統合は非常にシンプルになりました。

Specify the ColdSpring bean factory loader and location of the ColdSpring bean definition file in ModelGlue.xml:

ModelGlue.xmlのなかに、ColdSpring bean factory loaderとColdSpring bean定義ファイルのロケーションをを指定します。

<setting name="beanFactoryLoader" value="ModelGlue.Core.ColdSpringLoader" />
<setting name="beanMappings" value="/ggcc9/config/beans/ggcc.xml" />

Adding the autorwiring controller (as the first controller):
そして、第一のcontrollerとして、autorwiring controllerを追加します。

<controllers>
<controller name="csaw" type="coldspring.modelglue.AutoWire"/>
...other controllers...
</controllers>

Adding setXxx(yyy) methods to your controllers, where xxx is the name of the ColdSpring bean you want to be injected automatically.

各controllerにsetXxx(yyy) メソッドを追加します。xxxは、自動的に投射したいColdSpring bean名です。

Posted At : 2:25 PM. | Posted By : seancorfield | modelglue, coldspring, cf | Comments (2)