axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Constantino Cronemberger (JIRA)" <>
Subject [jira] [Commented] (AXIS2-4903) ScriptModule logs the error "AxisConfiguration getRepository returns null, cannot deploy scripts"
Date Mon, 11 Feb 2013 19:07:13 GMT


Constantino Cronemberger commented on AXIS2-4903:


I managed to get it working by adding all modules and services to the corresponding list files:


I have tested is by setting unpackWAR="false" in the context.xml inside the WAR that was stored
on webapps directory with Tomcat 7.0.27.

> ScriptModule logs the error "AxisConfiguration getRepository returns null, cannot deploy
> -------------------------------------------------------------------------------------------------
>                 Key: AXIS2-4903
>                 URL:
>             Project: Axis2
>          Issue Type: Bug
>          Components: deployment
>    Affects Versions: 1.4.1, 1.5, 1.5.1, 1.5.2, 1.5.3, nightly
>         Environment: Debian 5.0.7, Tomcat 5.5.26
>            Reporter: Zsolt Müller
>   Original Estimate: 4h
>  Remaining Estimate: 4h
> Conditions for the error to occur:
> - use of the scripting module (ie. add "axis2-scripting-*.mar" to your modules/modules.list)
> - use of the "axis2.xml.url" web.xml parameter or packaging of the webapp into a WAR/EAR
> The problem is that during the initialization of the scripting module (ie. the call to
org.apache.axis2.scripting.ScriptModule.init()) it checks for the repository in the axisconfiguration
to be not null.
> The relevant code is:
>   AxisConfiguration axisConfig = configContext.getAxisConfiguration();
>   if (axisConfig.getRepository() == null) {
>     log.error("AxisConfiguration getRepository returns null, cannot deploy scripts");
>   } else {
>     ... // scripting module initialization
>   }
> If ConfigurationContext.getAxisConfiguration().getRepository() returns null, then the
scripting module logs an error and the module is not initialized.
> Now the problem causing this to happen is in org.apache.axis2.deployment.DeploymentEngine.loadRepositoryFromURL().
> The exact callstack will look like this (without line numbers, because I don't want to
get version-specific):
>   - DeploymentEngine.loadRepositoryFromURL(URL repoURL)
>   - WarBasedAxisConfigurator.getAxisConfiguration()
>   - ConfigurationContextFactory.createConfigurationContext(AxisConfigurator axisConfigurator)
>   - AxisServlet.initConfigContext(ServletConfig config)
>   - AxisServlet.init(ServletConfig config)
> If you take a look at WarBasedAxisConfigurator.getAxisConfiguration(), you'll see that
depeding on the configuration it executes one of the following to load the repository:
>   - DeploymentEngine.loadRepository(String repoDir)
>   - DeploymentEngine.loadRepositoryFromURL(URL repoURL)
>   - DeploymentEngine.loadFromClassPath()
> In case of loadRepository(String repoDir) there's a call to "axisConfig.setRepository(axisRepo.toURL())"
which sets the repository reference in the axis configuration.
> In case of loadRepositoryFromURL(URL repoURL) there's no such call, which results in
ScriptModule.init() in the error message I described earlier.
> The fix is easy: in org.apache.axis2.deployment.DeploymentEngine.loadRepositoryFromURL(URL
repoURL) put a axisConfig.setRepository(repoURL) call before the axisConfig.validateSystemPredefinedPhases()
> As for DeploymentEngine.loadFromClassPath(), I don't know how to set the repository URL.
> Any idea? Or any other way to use the scripting module without an axis2.xml?
> My guess is that ScriptModule should be modified to handle the case, when repository
is loaded from CLASSPATH. Ie. it should try to pick up the scriptServicesDirectory from the
CLASSPATH as well.
> Currently it's hard-coded to look for the scriptServicesDirectory within a filesystem
entry pointed to by a File object.
> P.S.: this bug is present in v1.4.1, v1.5.3 and in SVN trunk (at the moment of writing).
I guess this has been around from the beginning.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message