Hi Nicolas,
I just did an SVN update. It seems this is missing from sources:
org.apache.maven.archiva.common.spring.PlexusFactory
Cheers,
Rahul
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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
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
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
>
>> 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.
>>>
>>>
>>>
>
>
