archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: from plexus to spring...
Date Thu, 28 Feb 2008 21:16:05 GMT
It's a bit of a hack, but if a bean lookup fails for  
Something#something, can you just remove the trailing #something and  
try again? I assume this is the problem?

- Brett

On 29/02/2008, at 3:46 AM, nicolas de loof wrote:

> That beeing said, with xwork xml files converted I can start archiva  
> and register my admin account RUNNING ON SPRING !
>
> Hey Rahul, seems you can start using plexus-spring on Continuum !
>
> Nicolas
>
>
> 2008/2/28, nicolas de loof <nicolas@apache.org>:
> Support for plexus <property> to Properties added in plexus-spring,
>
> Now have the following error when first access to /archiva webapp :
>
> Caused by: java.lang.ClassNotFoundException:  
> redbackEnvironmentCheckInterceptor
>     at  
> org 
> .apache 
> .catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java: 
> 1352)
>     at  
> org 
> .apache 
> .catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java: 
> 1198)
>     at  
> com.opensymphony.util.ClassLoaderUtil.loadClass(ClassLoaderUtil.java: 
> 104)
>     at  
> com 
> .opensymphony 
> .xwork.ObjectFactory.getClassInstance(ObjectFactory.java:88)
>     at  
> com 
> .opensymphony 
> .xwork 
> .spring 
> .SpringObjectFactory.getClassInstance(SpringObjectFactory.java:175)
>     at  
> com 
> .opensymphony 
> .xwork.spring.SpringObjectFactory.buildBean(SpringObjectFactory.java: 
> 116)
>
>
> The expected component is declared in redback-xwork-integration-1.0- 
> alpha-4.jar :
>
>  <component>
>       <role>com.opensymphony.xwork.interceptor.Interceptor</role>
>       <role-hint>redbackForceAdminUserInterceptor</role-hint>
>       ...
>
> Using the convention used to convert plexus rold+hint to spring IDs,  
> this result in a spring bean
> id="interceptor#redbackForceAdminUserInterceptor".
>
> Editing xwork-security to use the expected IDs is not a valid  
> solution as this file comes from the war overlay.
>
> Any suggestion ?
>
> Nicolas.
>
>
>
> 2008/2/28, nicolas de loof <nicolas@apache.org>:
> PlexusConfiguration support is now fixed.
>
> archiva-configuration tests pass with no change required, except :
>
> PlexusTestCase --> PlexusInSpringTestCase
> add getSpringConfigLocation() to return path to the new spring- 
> context.xml test resource
>
> [INFO]  
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESSFUL
> [INFO]  
> ------------------------------------------------------------------------
>
> I've also created a PlexusWebApplicationContext and tried to start  
> archiva webapp with spring... but this is not so easy :
>
>   change webwork.properties for : webwork.objectFactory = spring
>   change web.xml to remove PlexusLifecycleListener
>   use spring applicationContext to expose the PlexusContainerAdapter  
> as "webwork.plexus.container"
>
> The web application starts and initialize many beans, but fails  
> during security framework setup :
>
> "The JdoFactory property 'org.jpox.rdbms.dateTimezone' MUST BE Set  
> to 'JDK_DEFAULT_TIMEZONE' in order for jpox and JdoKeyManager to  
> operate correctly."
>
> The AbstractConfigurableJdoFactory requires conversion from plexus  
> <configuration> elements to Properties...
>
>
> Nicolas.
>
>
>
>
> 2008/2/27, nicolas de loof <nicolas@apache.org>:
> I just committed partial support for PlexusConfiguration :
>
> - as XML validation is disabled the XML configuration doesn't  
> require to be in a CDATA section
> - the namespaceHandler detects structured configuration and creates  
> a DomPlexusConfiguration for it.
> - Still have to implement DomPlexusConfiguration  as  
> XmlPlexusConfiguration requires Xpp3Dom.
>
> Still some work on this feature and I expect to pass archiva- 
> configuration tests.
>
> Nico.
>
>
> 2008/2/27, nicolas de loof <nicolas@apache.org>:
> I've solved the main issues, added some tiny doc and unit tests.
>
> Still early alpha code but now stable and ready for review if you  
> want to test it on Continuum.
>
> Some tests (like DefaultPathParserTest) migrate succesfully to  
> spring context execution using the PlexusInSpringTestCase without  
> any change.
>
> Many other archiva tests fails as the XSLT translation cannot  
> convert XML formated "configuration" to be injected in  
> CommonsConfigurationRegistry as a PlexusConfiguration :
>
>     <component>
>       <role>org.codehaus.plexus.registry.Registry</role>
>       <role-hint>configured</role-hint>       
> < 
> implementation 
> >org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry</ 
> implementation>
>       <configuration>
>         <properties>
>           <system/>
>           <xml fileName="${basedir}/src/test/conf/repository- 
> manager.xml"
>                config-name="org.apache.maven.archiva" config- 
> at="org.apache.maven.archiva"/>
>         </properties>
>       </configuration>
>     </component>
>
> The current stylesheet converts such <configuration> to a blank value.
>
> To support such configuration, we need
>
> 1.  a String2PlexusConfiguration PropertyEditor (maybe not  trivial,  
> but should be possible)
> 2.  a XSL way to store the configuration child nodes as XML  
> attributes.
>
> I'm a XSL newbee so have no idea how to output the current node and  
> all it's children as a text content.
> I've tested <xsl:copy-of slect="."> but without the expected result.
>
> I also tried to set the configuration value as a nested CDATA  
> content, but cannot find how to create the plexus:configuration  
> content as as CDATA element.  <xsl:output cdata-section- 
> elements="plexus:configuration"> didn't fix this.
>
>
>
>
>
>
>
>
> 2008/2/26, nicolas de loof <nicolas@apache.org>:
> For your information, plexus-spring no handle plexus requirement  
> without filed-name set.
>
> The -Dplexus-spring.debug=true option can be used to dump the  
> translated spring XML (using dom4j)
>
> PlexusInSpringTestCase as been used as replacement for  
> PlexusTestCase in archiva-policies with no other change required in  
> the test class (only a new spring context file required to declare  
> the LoggerManager)
>
> Some debugging logs have been added to trace the filed-injection and  
> dependencies resolution.
>
>
> .. but still not ready as  
> CacheFailuresTransferTest.testGetWithCacheFailuresOff pass run  
> alone, but not if ran after testGetWithCacheFailuresOn!
> Seems there is some incomplete support on context cleanup / dispose
>
> Please be patient, Rahul ;-)
>
> Nico.
>
>
>
> 2008/2/26, Joakim Erdfelt <joakim@erdfelt.com>:
> nicolas,
>
> This is way cool!
> A very slick way of helping the transition.
> I'm looking forward to some free time to dive into it.
>
>
> - Joakim
>
>
>
> nicolas de loof wrote:
> > Hi Rahul,
> >
> > Thanks for yout interest for this plexus-to-spring migration helper.
> > The code is still early experimental and requires some more  
> testing : it
> > only has been tested on 2 archiva testcases and requires many  
> fixes and
> > testcases to get stable.
> >
> > Please give me one week to test it more, add debugging logs and  
> better error
> > handling / reporting : The current code is not really easy to  
> debug when
> > some unexpected IoC occur... I also may improve support for plexus  
> lifecycle
> > and specificities, as long as I discover requirements from archiva  
> codebase.
> >
> > It is allready isolated from archiva for reuse, and can move to  
> plexus when
> > ready (I've no access to plexus svn).
> >
> > I promise to inform you about progress ;-)
> >
> > Nicolas.
> >
> > 2008/2/25, Rahul Thakur <rahul.thakur.xdev@gmail.com>:
> >
> >> Hi Nicolas,
> >>
> >> Sorry, I have looked at the recent updates to the code, hence my
> >> question. Is this 'ready' enough to be used outside Archiva? I'd  
> like to
> >> integrate this into Continuum.
> >>
> >> I think it might make sense to have this module in Plexus SVN  
> repo - wdyt?
> >>
> >> Good stuff!
> >>
> >> Cheers,
> >> Rahul
> >>
> >> nicolas de loof wrote:
> >>
> >>> Hello,
> >>>
> >>> I've repackaged and improved the spring support for plexus  
> components in
> >>>
> >> a
> >>
> >>> dedicated poject
> >>> -->
> >>>
> >>>
> >> https://svn.apache.org/repos/asf/maven/archiva/branches/springy/plexus-spring/
> >>
> >>> This new module provides runtime translation from plexus component
> >>> descriptors to a Spring XML context, using a simple XSL file and a
> >>>
> >> custom
> >>
> >>> ApplicationContext. Any existing plexus jars can then be used in a
> >>>
> >> spring
> >>
> >>> context.
> >>>
> >>> It defines a custom <plexus:> spring-namespace. Under the hood a 

> custom
> >>> FactoryBean handles plexus components field-injection and (some)
> >>>
> >> lifecycle
> >>
> >>> interfaces. As I discover plexus features by testing on archiva,  
> I'd be
> >>> pleased to get more infos on plexus IoC specificities.
> >>>
> >>> It also provides a PlexusInSpringTestCase that is a replacement  
> class
> >>>
> >> for
> >>
> >>> PlexusTestCase, providing equivalent methods and behavior.
> >>>
> >>> I've applied this (in springy branch) on archiva-policies and
> >>>
> >> archiva-proxy
> >>
> >>> (with some test failures in latest I have to investigate)
> >>>
> >>> On this basis and with the required improvements, I thing this  
> is a nice
> >>>
> >> way
> >>
> >>> to move archiva (or other plexus-based app) to spring and then  
> gradually
> >>> refactor plexus components, either using Spring annotation or XML
> >>>
> >> context
> >>
> >>> files (my +1 for context files).
> >>>
> >>> Nicolas.
> >>>
> >>>
> >>>
> >
> >
>
>
>
>
>
>
>

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message