You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Musachy Barroso <mu...@gmail.com> on 2009/09/30 19:30:05 UTC
Re: Convention Plugin - "Unable to find a result type for extension
[svn/]"
convention uses the extension to figure out the result type, so it is
getting confused and assuming that "svn" is a type. I think it is safe
to ignore any file that starts with "." as it will have no file name,
so no result could ever map to it (by convention at least). I fixed it
in trunk, Jira is down at the moment, I will create a ticket when it
comes back up.
thanks for reporting
musachy
On Wed, Sep 30, 2009 at 10:00 AM, Christian Bockermann <ch...@dorf.de> wrote:
> Hi,
>
> I am a big fan of the struts-convention plugin, but have errors getting it
> to
> ignore my .svn-files. If I start my web-app using the maven-jetty plugin
> (mvn jetty:run), it starts processing the resource-paths until it hits the
> first
> .svn-directory:
>
>
> Caused by: Unable to find a result type for extension [svn/] in location
> attribute [/WEB-INF/content/.svn/]. - [unknown location]
> at
> org.apache.struts2.convention.DefaultResultMapBuilder$ResultInfo.determineType(DefaultResultMapBuilder.java:452)
> at
> org.apache.struts2.convention.DefaultResultMapBuilder$ResultInfo.<init>(DefaultResultMapBuilder.java:415)
> at
> org.apache.struts2.convention.DefaultResultMapBuilder.makeResults(DefaultResultMapBuilder.java:310)
> at
> org.apache.struts2.convention.DefaultResultMapBuilder.createFromResources(DefaultResultMapBuilder.java:234)
> at
> org.apache.struts2.convention.DefaultResultMapBuilder.build(DefaultResultMapBuilder.java:183)
> at
> org.apache.struts2.convention.PackageBasedActionConfigBuilder.createActionConfig(PackageBasedActionConfigBuilder.java:680)
> at
> org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildConfiguration(PackageBasedActionConfigBuilder.java:493)
> at
> org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildActionConfigs(PackageBasedActionConfigBuilder.java:278)
> at
> org.apache.struts2.convention.ClasspathPackageProvider.loadPackages(ClasspathPackageProvider.java:52)
> at
> com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:200)
> at
> com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:55)
> ... 43 more
>
>
> Is there any way to ignore these .svn-directories?
> I thought about patching the DefaultResultMapBuilder and adding a
> "exclude"-config, but
> am not sure if this would be the right way...
>
> (Sorry, if this has been asked before, I didn't find any good results in the
> list archive)
>
> Best regards,
> Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Convention Plugin - "Unable to find a result type for extension
[svn/]"
Posted by Musachy Barroso <mu...@gmail.com>.
boo :). I wrote a test and all with a file like ".xyz" and forgot about dirs.
musachy
On Thu, Oct 1, 2009 at 7:55 AM, Christian Bockermann <ch...@dorf.de> wrote:
> Hi Musachy,
>
> I'm sorry to say that your patch didn't work. In the '.svn' case, '.svn' is
> a directory and the value of "path" will be ".../.svn/".
> In you patch you check
>
> String fileName = StringUtils.substringAfterLast( path, "/" )
>
> which in the '.svn'-directory-case will result in an empty string, which of
> course does not start with a ".".
>
> I attached a patch which solves this problem. You may want to adjust the
> code.
>
> Best regards,
> Chris
>
>
>
>
>
>
> Am 30.09.2009 um 19:30 schrieb Musachy Barroso:
>
>> convention uses the extension to figure out the result type, so it is
>> getting confused and assuming that "svn" is a type. I think it is safe
>> to ignore any file that starts with "." as it will have no file name,
>> so no result could ever map to it (by convention at least). I fixed it
>> in trunk, Jira is down at the moment, I will create a ticket when it
>> comes back up.
>>
>> thanks for reporting
>> musachy
>>
>> On Wed, Sep 30, 2009 at 10:00 AM, Christian Bockermann <ch...@dorf.de>
>> wrote:
>>>
>>> Hi,
>>>
>>> I am a big fan of the struts-convention plugin, but have errors getting
>>> it
>>> to
>>> ignore my .svn-files. If I start my web-app using the maven-jetty plugin
>>> (mvn jetty:run), it starts processing the resource-paths until it hits
>>> the
>>> first
>>> .svn-directory:
>>>
>>>
>>> Caused by: Unable to find a result type for extension [svn/] in location
>>> attribute [/WEB-INF/content/.svn/]. - [unknown location]
>>> at
>>>
>>> org.apache.struts2.convention.DefaultResultMapBuilder$ResultInfo.determineType(DefaultResultMapBuilder.java:452)
>>> at
>>>
>>> org.apache.struts2.convention.DefaultResultMapBuilder$ResultInfo.<init>(DefaultResultMapBuilder.java:415)
>>> at
>>>
>>> org.apache.struts2.convention.DefaultResultMapBuilder.makeResults(DefaultResultMapBuilder.java:310)
>>> at
>>>
>>> org.apache.struts2.convention.DefaultResultMapBuilder.createFromResources(DefaultResultMapBuilder.java:234)
>>> at
>>>
>>> org.apache.struts2.convention.DefaultResultMapBuilder.build(DefaultResultMapBuilder.java:183)
>>> at
>>>
>>> org.apache.struts2.convention.PackageBasedActionConfigBuilder.createActionConfig(PackageBasedActionConfigBuilder.java:680)
>>> at
>>>
>>> org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildConfiguration(PackageBasedActionConfigBuilder.java:493)
>>> at
>>>
>>> org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildActionConfigs(PackageBasedActionConfigBuilder.java:278)
>>> at
>>>
>>> org.apache.struts2.convention.ClasspathPackageProvider.loadPackages(ClasspathPackageProvider.java:52)
>>> at
>>>
>>> com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:200)
>>> at
>>>
>>> com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:55)
>>> ... 43 more
>>>
>>>
>>> Is there any way to ignore these .svn-directories?
>>> I thought about patching the DefaultResultMapBuilder and adding a
>>> "exclude"-config, but
>>> am not sure if this would be the right way...
>>>
>>> (Sorry, if this has been asked before, I didn't find any good results in
>>> the
>>> list archive)
>>>
>>> Best regards,
>>> Chris
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Convention Plugin - "Unable to find a result type for extension [svn/]"
Posted by Christian Bockermann <ch...@dorf.de>.
Hi Musachy,
I'm sorry to say that your patch didn't work. In the '.svn' case,
'.svn' is
a directory and the value of "path" will be ".../.svn/".
In you patch you check
String fileName = StringUtils.substringAfterLast( path, "/" )
which in the '.svn'-directory-case will result in an empty string,
which of
course does not start with a ".".
I attached a patch which solves this problem. You may want to adjust
the code.
Best regards,
Chris