월별 글 목록: 2008년 3월월

Association Vs Aggregation Vs Composition

An Association is a channel between classes through which messages can be sent. As sending messages translates to calling methods in Java, Associations are typically (but not necessarily) implemented by references.

An Aggregation is an Association which denotes an “is part of” relationship. Unfortunately, the definition of this relationship is quite lax, so basically everyone is using his own interpretation. The only definitive (?) property is that in an instance graph, aggregations are not allowed to be circular – that is, an object can not be “a part of itself”. (or) When building new classes from existing classes using aggregation, a composite object built from other constituent objects that are its parts.Java supports aggregation of objects by reference,since objects can’t contain other objects explicitly.

A Composition adds a lifetime responsibility to Aggregation. In a garbage collected language like Java it basically means that the whole has the responsibility of preventing the garbage collector to prematurely collect the part – for example by holding a reference to it. (In a language like C++, where you need to explicitely destroy objects, Composition is a much more important concept.) Only one whole at a time can have a composition relationship to a part, but that relationship doesn’t need to last for the whole lifetime of the objects – with other words, lifetime responsibility can be handed around.

Aggregation and Composition Guidelines :

Sometimes an object is made up of other objects. For example, an airplane is made up of a fuselage, wings, engines, landing gear, flaps, and so on. A delivery shipment contains one or more packages. A team consists of two or more employees. These are all examples of the concept of aggregation, which represents 밿s part of?relationships. An engine is part of a plane, a package is part of a shipment, and an employee is part of a team. Aggregation is a specialization of association, specifying a whole-part relationship between two objects. Composition is a stronger form of aggregation where the whole and parts have coincident lifetimes, and it is very common for the whole to manage the lifecycle of its parts. From a stylistic point of view, because aggregation and composition are both specializations of association the guidelines for associations apply.

출처는 http://faq.javaranch.com/java/AssociationVsAggregationVsComposition 입니다.

Struts2 아키텍처..

아래의 이미지는 Strut2의 아키텍처이고, 이 구조에서 사용자가 요청을 하면,

1. Request를 처리할 액션(Action)을 ActionMaper에서 찾아서 실행한다
2. Request가 처리되면서 Action의 Interceptor 전,후 처리를 한다.
3. Response를 한다. 

사용자 삽입 이미지

In the diagram, an initial request goes to the Servlet container (such as Jetty or Resin) which is passed through a standard filter chain. The chain includes the (optional) ActionContextCleanUp filter, which is useful when integrating technologies such as SiteMesh Plugin. Next, the required FilterDispatcher is called, which in turn consults the ActionMapper to determine if the request should invoke an action.

If the ActionMapper determines that an Action should be invoked, the FilterDispatcher delegates control to the ActionProxy. The ActionProxy consults the framework Configuration Files manager (initialized from the struts.xml file). Next, the ActionProxy creates an ActionInvocation, which is responsible for the command pattern implementation. This includes invoking any Interceptors (the before clause) in advance of invoking the Action itself.

Once the Action returns, the ActionInvocation is responsible for looking up the proper result associated with the Action result code mapped in struts.xml. The result is then executed, which often (but not always, as is the case for Action Chaining) involves a template written in JSP or FreeMarker to be rendered. While rendering, the templates can use the Struts Tags provided by the framework. Some of those components will work with the ActionMapper to render proper URLs for additional requests.

<!–[if !vml]–><!–[endif]–>

All
objects in this architecture (Actions, Results, Interceptors,
and so forth) are created by an ObjectFactory.
This ObjectFactory is pluggable. We can provide our own ObjectFactory for any
reason that requires knowing when objects in the framework are created. A
popular ObjectFactory implementation uses Spring as provided by the Spring
Plugin
.

Interceptors are executed again (in reverse order, calling the after clause). Finally, the response returns through the filters configured in the web.xml. If the ActionContextCleanUp filter is present, the FilterDispatcher will not clean up the ThreadLocal ActionContext. If the ActionContextCleanUp filter is
not present, the FilterDispatcher will cleanup all ThreadLocals.

스트러츠 2의 .action 확장자 변경하기

스트러츠(struts) 2는 기본으로 아래와 같은 환경파일을 사용하고 있다. 이 파일들 중에 struts.properties 파일이 스트러츠 2의 기본 설정을 가지고 있다.

File
Optional
Location Purpose
web.xml no /WEB-INF/ Web deployment descriptor to include all
necessary framework components
struts.xml yes /WEB-INF/classes/ Main configuration, contains result/view
types, action mappings, interceptors, and so forth
struts.properties yes /WEB-INF/classes/ Framework properties
struts-default.xml yes /WEB-INF/lib/struts2-core.jar Default configuration provided by Struts
struts-default.vm yes /WEB-INF/classes/ Default macros referenced by
velocity.properties
struts-plugin.xml yes At the root of a plugin JAR Optional configuration files for Plugins struts.xml. in
the same format as
velocity.properties yes /WEB-INF/classes/ Override the default Velocity configuration


위 설정 파일들 중에서 struts.properties 에서
### Used by the DefaultActionMapper

### You may provide a comma separated list, e.g.
struts.action.extension=action,jnlp,do struts.action.extension=action
위의 빨간색 설정 부분을
xxx,do,action 등과 같이 우선순위가 높은 순서대로 설정 하면 된다.