지난 10월 30일에 Spring Framewrk 2.5.6버전이 릴리즈 되었다.
지금 내가 하고 있는 프로젝트는 Spring 2.5.5를 기반으로 개발하고 있는데, 현재 개발자 테스트를 시작하고 있는 중이다. 프로젝트 종료가 올해말로 예정되어 있기 때문에 현재 구성되어 있는 개발 환경을 바꾸지 않고 올해 말까지 진행 하기로 하였다. 

그래도 변경된 부분을 살펴봐야 하기에 로그를 살펴 보았는데, 여느때 보다는 수정된 목록들의 개수가 적었다. 그 만큼 많은 부분들이 안정되어 간다는 말일 거다.

Changes in version 2.5.6 (2008-10-31)
-------------------------------------

General
* removed outdated EAR support from sample applications
* upgraded to AspectJ 1.6.2 (retaining compatibility with AspectJ 1.5.x and 1.6.x)
* upgraded to EHCache 1.5.0 (retaining compatibility with EHCache 1.2 and higher)
* upgraded to TestNG 5.8 (retaining compatibility with TestNG 5.5 and higher)
* upgraded to OpenJPA 1.1.0 (retaining compatibility with OpenJPA 1.0.x as well as 1.2.0)
* upgraded to EclipseLink 1.0.1 (EclipseLinkJpaVendorAdapter requires EclipseLink 1.0.0+ now)

Package org.springframework.aop
* AbstractAutoProxyCreator (as used by "aop:config") correctly ignores null bean instances
* "aop:aspect" doesn't insist on aspect bean reference to be specified when just containing declare-parents elements
* "bean" pointcut matches exposed FactoryBean products only; "&..." syntax supported for matching FactoryBean itself

Package org.springframework.beans
* BeanUtils skips conventional editor check for array classes (in order to not break AspectJ weaving)
* BeanWrapper's introspection resolves bridge methods to find setter method for getter method with covariant return type
* TypeMismatchException message differentiates between editor with inappropriate value returned versus no editor at all
* containing bean definition is exposed to ParserContext for BeanDefinitionDecorators as well
* BeanDefinition objects are considered equal even if their originating resource objects are different
* AbstractFactoryBean's early singleton proxy handles equals, hashCode and toString calls locally (avoiding eager init)
* PropertyPathFactoryBean logs a warning if the target bean is still in creation at the time of obtaining the property
* exposed public "copyRegisteredEditorsTo" method on ConfigurableBeanFactory interface
* fixed corner case in AbstractBeanDefinition where a ClassCastException could arise in "getBeanClass(Name)"
* DefaultSingletonBeanRegistry eagerly cleans up cached dependency information when destroying a bean
* AbstractBeanFactory rejects getBean request with arguments in case of a pre-existing singleton of same name as well
* AbstractAutowireCapableBeanFactory preserves possible matches hint in property exception
* SmartInstantiationAwareBeanPostProcessor's "determineCandidateConstructors" is only invoked for non-null bean Class
* ServiceLocatorFactoryBean handles equals and hashCode based on proxy object identity
* factored out "createBeanDefinition" template method in BeanDefinitionParserDelegate
* turned visibility of BeanDefinitionParserDelegate's "checkNameUniqueness" method to protected
* XML list/set/map elements (in both the beans and the util namespace) support nested description element

Package org.springframework.cache
* EhCacheFactoryBean obtains decorated Ehcache instead of raw Cache, honoring pre-configured cache decorators
* removed useless "diskStorePath" property from EhCacheFactoryBean (ignored by all current EHCache versions anyway)

Package org.springframework.context
* DefaultMessageSourceResolvable and FieldError implement "equals" and "hashCode" such that all fields are respected
* ClassPathBeanDefinitionScanner performs trace/debug logging during class resource introspection
* ClassPathBeanDefinitionScanner ignores same class found multiple times in the classpath (i.e. equal bean definition)
* component-scan preserves original source of scanned bean definitions, for silently ignoring already scanned classes
* annotation-config registers PersistenceAnnotationBeanPostProcessor independent from client bundle's class loader
* added CUSTOM value to FilterType enumeration

Package org.springframework.core
* ClassPathResource uses cleaned path for relative resources as well
* PathMatchingResourcePatternResolver considers URL protocol "vfszip" as jar file (to search JBoss-managed jars)
* GenericCollectionTypeResolver correctly resolves collection element type even when target bean is a collection itself

Package org.springframework.ejb
* SpringBeanAutowiringInterceptor calls "InvocationContext.proceed()" in order to invoke subsequent interceptors as well

Package org.springframework.instrument
* ShadowingClassLoader excludes "net.sf.cglib." package from shadowing by default

Package org.springframework.jdbc
* provided Jdbc4SqlXmlHandler as default implementation of the SqlXmlHandler interface
* added SqlValue class to "jdbc.support" package, with SqlXmlValue derived from SqlValue instead of SqlTypeValue
* SQLErrorCodesFactory always loads its "sql-error-codes.xml" files from Spring's class loader (-> static singleton)
* added "transientDataAccessResourceCodes" category to "sql-error-codes.xml", with default codes for DB2 and Sybase
* SQLErrorCodeSQLExceptionTranslator applies default SQLExceptionSubclassTranslator after error code translation only
* SQLErrorCodeSQLExceptionTranslator is able to work without fallback SQLState translation as well
* SQLExceptionSubclassTranslator translates SQLFeatureNotSupportedException to InvalidDataAccessApiUsageException
* SQLStateSQLExceptionTranslator returns TransientDataAccessResourceException for well-known vendor-specific SQL states
* factored out AbstractFallbackSQLExceptionTranslator base class for consistent "fallbackTranslator" capabilities
* CallableStatementCreatorFactory strictly honors "SqlParameter.isInputValueProvided" (allowing for statement caching)
* JdbcTemplate passes full Calendar argument to JDBC driver even in case of no SQL type specified
* JdbcTemplate does not call the costly "Statement.getWarnings()" unless ignoreWarnings=false or debug logging is on
* added "checkFullyPopulated" setting to BeanPropertyRowMapper, for validating that all bean properties have been mapped

Package org.springframework.jms
* JmsException message and logged JMSException message explicitly includes linked exception now if not already contained
* SingleConnectionFactory only calls "Connection.stop()" on reset when the shared Connection has actually been started
* SingleConnectionFactory explicitly creates Queue/TopicConnection when first call is createQueue/TopicConnection method
* CachingConnectionFactory explicitly creates Queue/TopicSession when first call is createQueue/TopicConnection method
* CachingConnectionFactory's JMS Session proxies implement SessionProxy interface, allowing for access to target Session
* CachingConnectionFactory rolls back cached transacted JMS Sessions on logical close if no commit/rollback was issued
* CachingConnectionFactory explicitly closes cached JMS Sessions on Connection close
* CachingConnectionFactory's cached producers pass on "disableMessageID" and "disableMessageTimestamp" properties
* CachingConnectionFactory also caches MessageConsumers (controlled through "cacheConsumers" property)
* AbstractJmsListeningContainer eagerly clears shared JMS Connection after releasing, avoiding repeated close exceptions
* revised DefaultMessageListenerContainer to correctly work with non-JMS transaction manager and CACHE_CONNECTION level
* DefaultMessageListenerContainer supports a stop notification callback for unlimited maxMessagesPerTask as well now
* introduced SubscriptionNameProvider interface for message listener objects suggesting default subscription names
* "jms:listener-container" uses actual message listener object's class name as default subscription name

Package org.springframework.jmx
* fixed NotificationListenerHolder to correctly handle multiple specified object names
* added "allowEagerInit" property to MBeanExporter, for autodetecting lazy-init beans and FactoryBean-produced objects
* added "environment" property to MBeanClientInterceptor and NotificationListenerRegistar, allowing for JMX env entries
* added "refreshOnConnectFailure" property to MBeanClientInterceptor, allowing for reconnect in case of I/O failure

Package org.springframework.mail
* ConfigurableMimeFileTypeMap explicitly closes the InputStream that it uses for "mime.types" resource reading

Package org.springframework.mock
* SimpleNamingContextBuilder supports "deactivate()"+"activate()", with the standard JNDI provider exposed inbetween

Package org.springframework.orm
* HibernateTemplate detects Spring-managed transactional Session even with SessionFactory proxy and allowCreate=false
* HibernateTemplate's "loadAll" operation selects distinct root entities (avoiding duplicate entries in result list)
* HibernateTemplate translates Hibernate's DataException into a Spring DataIntegrityViolationException (for consistency)
* fixed HibernateTransactionManager's "earlyFlushBeforeCommit" feature to apply to the outermost transaction only
* added "packagesToScan" property to Hibernate AnnotationSessionFactoryBean, for autodetection of @Entity classes
* HibernateJpaDialect checks "EntityManager.getDelegate()" as well to find Hibernate Session (for Seam compatibility)
* added "persistenceXmlLocation" property to DefaultPersistenceUnitManager, as alternative to "persistenceXmlLocations"
* @PersistenceContext of type TRANSACTION allows returned Query objects to be parameterized and executed as well
* @PersistenceContext for default EntityManagerFactory lookup works even in an @Configurable Hibernate entity

Package org.springframework.remoting
* added "interceptors" property to RemoteExporter, allowing for registering custom AOP interceptors before the endpoint
* RmiClientInterceptor always logs connect failure at warn level, even when debug logging (incl. stacktrace) is active
* JndiRmiClientInterceptor skips narrowing for RmiInvocationHandler stubs (fixing a regression in 2.5.4)
* Hessian/Burlap service exporters explicitly close input and output streams now (not relying on servlet container)
* Simple/CommonsHttpInvokerRequestExecutor set the current locale according to LocaleContextHolder as HTTP lang header
* JaxWsPortProxyFactoryBean exposes the JAX-WS BindingProvider interface in the Spring-generated proxy as well

Package org.springframework.scheduling
* SchedulerFactoryBean populates scheduler context first before satisfying SchedulerContextAware on a given JobFactory
* SchedulerFactoryBean uses bean name as default scheduler name (when "schedulerName" property not explicitly specified)
* SchedulerFactoryBean does not accept a pre-registered Scheduler instance in the Quartz SchedulerRepository anymore
* SchedulerFactoryBean does not expose the Spring-created/managed Scheduler to the Quartz SchedulerRepository anymore
* added "exposeSchedulerInRepository" flag to SchedulerFactoryBean, for explicit exposure to the SchedulerRepository
* introduced SchedulerAccessorBean for registering jobs/triggers/listeners on an existing Quartz Scheduler instance
* ScheduledExecutorFactoryBean uses Runnable decorator for logging exceptions that lead to termination of execution

Package org.springframework.test
* SpringJUnit4ClassRunner skips execution of test classes with non-matching @IfProfileValue annotation completely

Package org.springframework.transaction
* AbstractPlatformTransactionManager resumes after any kind of inner begin failure (not just after TransactionException)
* TransactionSynchronizationManager interaction gets logged at trace level only (minimizing debug log per transaction)
* JotmFactoryBean sets "defaultTimeout" value as actual JOTM default (even if no transaction timeout specified at all)

Package org.springframework.util
* fixed "StringUtils.delete" to prevent an eternal loop in case of the pattern being empty
* "StringUtils.cleanPath" preserves leading slash if given in original path
* "FileSystemUtils.copyRecursively" ignores 'special' files (i.e. neither a regular file nor a directory)

Package org.springframework.web
* HttpRequestHandlerServlet propagates HTTP request locale into Spring's LocaleContextHolder
* revised "WebUtils.extractFilenameFromUrlPath" to search actual URI part only even when given a URL with query string
* Log4jNestedDiagnosticContextFilter/Interceptor explicitly remove the NDC stack if depth=0 after the "NDC.pop()" call
* fixed FacesWebRequest's "getParameterValues" implementation to use "ExternalContext.getRequestParameterValuesMap"
* PortletContextResource cleans given path (analogous to ServletContextResource)
* Servlet/PortletContextResource accept path with leading "/../" part as well (as accepted by most servlet containers)
* DispatcherServlet removes error-view-driven servlet request attributes after rendering (for Tomcat compatibility)
* exposed "getParamName()" method on LocaleChangeInterceptor and ThemeChangeInterceptor
* added "cacheSecondsForSessionAttributeHandlers" property to Servlet/Portlet AnnotationMethodHandlerAdapter
* AnnotationMethodHandlerAdapter exposes special ModelMap that removes BindingResult if target attribute gets replaced
* Servlet AnnotationMethodHandlerAdapter always takes first exact @RequestMapping path match as best path match
* @MVC handler methods, model attribute methods and init binder methods allow for overriding a generic superclass method
* @ModelAttribute annotated handler method arguments can resolve to a null value as well (when contained in the model)
* standard method argument subtypes (such as a Principal subclass) fail with a descriptive exception if incompatible
* Portlet AbstractCommandController falls back to lazy command creation if session timed out after action phase
* ByteArray/StringMultipartFileEditor do not log warning but rather include root cause in IllegalArgumentException
* InternalResourceView's "preventDispatchLoop" checks against the same request's URI only (for Portlet compatibility)
* made RedirectView's "renderMergedOutputModel" implementation non-final
* VelocityConfigurer exposes ServletContext as VelocityEngine attribute (analogous to the standard VelocityViewServlet)
* revised XsltView to specify full resource URI as StreamSource system id, for properly resolving relative paths
* officially deprecated AbstractXsltView in favor of XsltView and its more flexible "locateSource" mechanism
* revised error logging during XSLT processing to properly log compilation errors before an eventual fatal exception
* moved internal TransformerUtils helper class to generic "org.springframework.util.xml" package

오늘 ScottGu's의 Blog에 몇 가지 새로운 링크들이 올라왔다.
Microsoft의 최근의 많은 기술적 변화를 이끌고 있는 Scott Guthrie의 선택중에 가장 잘한 부분은 개발자들을 위한 새로운 툴들을 제공라려고 노력하고 있다는 것이다.
그리고, 새로운 기술들을 받아 들이고, 오픈 소스의 영향도 마다하지 않고 소화하려고 하고 있다. 물론 이는 기술적인 거대한 흐름의 하나이고 방향이기도 하지만, 이를 MS의 툴로 하나씩 만들어 가고 있다.

그중 잘하고 있는 것이 Dynamic Data에 대한 것이다. 그리고 앞으로도 가장 발전할 수 있는 기술이라고도 생각이 든다. 그리고 이러한 관전에서 보면, ASP.NET MVC도 역시 마찮가지이다. 앞으로 웹을 개발하고 기술을 익히려 한다면, 이부분을 사전에 공부하는 것도 많은 도움이 될것이다.

관련 링크는 다음과 같다.
           - http://www.asp.net/learn/3.5-SP1/

Elipse를 사용하다 보면, 단축키의 유용함을 알게될 것이다. 특히 마우스를 사용하지 않고 바로 원하는 메뉴로 이동하고, 새로운 클래스와 함수들을 만들때 이는 많은 편리함을 가져다 준다.

"Alt+Shift+N" 키를 이용하면, 아래와 같이 Eclipse의 메뉴의 단축메뉴가 나타난다. 이는 이클립스의 File메뉴를 마우스를 클릭하였을때, 나타는 하위 메뉴 항목에서 "New" 를 선택했을때 나타나는 메뉴 컨텍스트 항목들이다. (아래 이미지 참조)
 

그리고, "Ctrl+3"키를 누르면, 아래와 같이 "Quick Access"메뉴가 나타난다.
이는 기본적으로 최근에 사용했던 메뉴 항목들과 기능들이 나타나는데, 화면 상단에 입력난에 알파벳을 입력하면, 메뉴항목중에 입력된 키가 포함된 메뉴들을 추전해 준다. 메뉴항목과 위치가 기억이 나지 않을 때 상당히 유용하다.

마지막으로, "Ctrl+N"을 사용하면, Eclipse에서 새로 생성하고자 하는 파일과 프로젝트등에 쉽게 사용할 수 있다. 아래 이미지의 상단에 있는 "Wizards: "의 텍스트 입력란을 이용하면, 쉽게 Filtering해서 원하는 항목들을 찾을 수 있다.

 

얼마전에  "Silverlight 2.0 발표 즈음하여" 라는 제목의 글을 올린 적이 있었다.
Silverlight 1.0을 발표하고 많은 노력과 공을 들여 개발하고 최근에 2.0을 발표하였는데, MS가 전략적으로 집중하는 모습이 이전의 브라우져 전쟁때와 비슷하다. 
그때는 넷스케이브가 브라우져의 90% 이상의 점유율을 가졌을 때이기 때문에, 새로운 시작과 기술들은 넷스케이프를 중심으로 열릴것이라고 생각되었던 때이다. 

하지만 MS는 OS의 강점을 10분 이용하여, OS의 설치시 자신의 웹 브라우져인 IE 3를 기본적으로 윈도우의 설치해서 배포하였다. 이 당시에는 지금 생각하면 황당한 것은 새로운 브라우져를 설치하면, 내가 개발하던 프로그램이 갑자기 동작하지 않거나, 에러를 발생시키도 하였다. 이는 웹브라우져와 OS에서 사용하는 DLL의 인터페이스가 변경된 것이 원인인데, 브라우져를 통해서 OS의 기능을 변경했다는 이야기와 일맥 상통한다.  

하지만 결국, 이러한 전략적인 배포 방법으로 MS는 넷스케이프를 밀어내고, 그 자리를 자신의 브라우져인 IE를 대체하여 버렸다. 그 당시는 MS에서 브라우져 개발을 최우선으로 하고 약 3000명의 개발자를 할당하였었다. 넷스케이프는 약 200명 정도의 개발자들이 참여했었던 것으로 기억되는데, 이러한 공격적인 개발전략으로 넷스케이프는 역사속의 프라우져가 되었다.

최근에 Silverlight 2의 개발이 끝났는데, 역시 마이크로 소프트이다라고 할 만한 방법으로 Silverlight를 배포하고 있다. MS는 윈도우의 자동 업그레이드를 이용하여 패치를 진행하고 있는 것이다. 최근에 지인과 이야기를 했는데, 그는 Silverlight는 Flash에 비해서는 2수정도 부족하다고 평하였고, 상대가 안될거라 이야기를 했었다.
하지만 나는 실버라이트가 기술적 우수성을 떠나서, 전략적인 면에서는 더욱 우세할 거라는 의견에 한표를 실어주었다. 왜냐하면, MS는 어떤 식으로든 실버라이트를 기본적으로 OS에 탑재하여 배포할 것이기 때문이다.

그런데, 그러한 예측이 며칠전 부터 일어나기 시작하였다. 윈도우즈의 Software 자동 업데이트 기능을 이용하여 배포를 시작한 것이다.

이러한 MS의 공세에, Flash와 JavaFX는 어떤 식으로 방어와 수성을 할지 궁금하다.

아래는 며칠전에 내 PC의 자동 Update 되는 과정을 캡처한 화면이다.