You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Christian Nutz (JIRA)" <de...@tapestry.apache.org> on 2008/03/18 11:11:25 UTC

[jira] Created: (TAPESTRY-2273) Websphere 6.1 ear asset problem

Websphere 6.1 ear asset problem
-------------------------------

                 Key: TAPESTRY-2273
                 URL: https://issues.apache.org/jira/browse/TAPESTRY-2273
             Project: Tapestry
          Issue Type: Bug
          Components: Framework
    Affects Versions: 4.1.5, 4.1.3, 4.1.2
         Environment: WinXP SP2, Java 1.5.14, Tapestry 4.1.2 (also  4.1.5), IBM Websphere 6.1
            Reporter: Christian Nutz
            Priority: Critical
             Fix For: 4.1.6


We are using Tapestry 4.0 for our project and all works fine.
Now we want migrate to Tapestry 4.1.5 but in our Websphere environment css-assets are not loaded (The css is embedded via Asset in the html header of our page).
In the source of the generated html page the css is not correct resolved and looks like this:

<head>
  <title>XYZ</title>	
  <link href="/xyz/app?digest=xxxxx&amp;service=asset&amp;path=%2Fpage_x%2Fpage_x.css" type="text/css" rel="stylesheet" id="Any_0"></link>
</head>

The correspondending java class creates the css link via "AbstractComponent.getAsset("pageCss").buildURL()".


The Websphere log says:

SRTServletRes W   WARNING: Cannot set header. Response already committed.



After debugging, we found the reason for this issue.

If you deploy an war file in Websphere application server, Websphere creates an ear file with the war included. The classpath is:

C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\classes;
C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-annotations-4.1.5.jar;
C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-contrib-4.1.5.jar;
C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-framework-4.1.5.jar;
C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war

And our directory structure looks like this:

demoApp
demoApp/styles
demoApp/html
demoApp/WEB-INF


Tapestry tries to load an Asset with an AssetFactory.
In the class org.apache.tapestry.assetAssetSourceImpl the method findAssetFactory(IComponentSpecification spec, Resource baseResource, String path, Locale locale) is used for this.

It looks up the factory in this way:

AssetFactory findAssetFactory(IComponentSpecification spec, Resource baseResource, String path, Locale locale) {
   // need to check these two core factories in order first

   if (_classpathAssetFactory.assetExists(spec, baseResource, path, locale))
       return _classpathAssetFactory;

   if (_contextAssetFactory.assetExists(spec, baseResource, path, locale))
       return _contextAssetFactory;
            
   ....
        
}

As you can see for the ear file, the styles directory is visble from classpath and _classpathAssetFactory.assetExists() will return true.
And this is the problem.
Like in Tapestry 4.0, you have to check first _contextAssetFactory.assetExists() and then _classpathAssetFactory.assetExists().

After applying the patch (changing the order to return the assetFactory), the problem was solved for us.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


[jira] Updated: (TAPESTRY-2273) Websphere 6.1 ear asset problem

Posted by "Christian Nutz (JIRA)" <de...@tapestry.apache.org>.
     [ https://issues.apache.org/jira/browse/TAPESTRY-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Nutz updated TAPESTRY-2273:
-------------------------------------

    Environment: WinXP SP2, Java 1.5.0_14, Tapestry 4.1.2 (also  4.1.5), IBM Websphere 6.1  (was: WinXP SP2, Java 1.5.14, Tapestry 4.1.2 (also  4.1.5), IBM Websphere 6.1)

> Websphere 6.1 ear asset problem
> -------------------------------
>
>                 Key: TAPESTRY-2273
>                 URL: https://issues.apache.org/jira/browse/TAPESTRY-2273
>             Project: Tapestry
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: 4.1.2, 4.1.3, 4.1.5
>         Environment: WinXP SP2, Java 1.5.0_14, Tapestry 4.1.2 (also  4.1.5), IBM Websphere 6.1
>            Reporter: Christian Nutz
>            Priority: Critical
>             Fix For: 4.1.6
>
>
> We are using Tapestry 4.0 for our project and all works fine.
> Now we want migrate to Tapestry 4.1.5 but in our Websphere environment css-assets are not loaded (The css is embedded via Asset in the html header of our page).
> In the source of the generated html page the css is not correct resolved and looks like this:
> <head>
>   <title>XYZ</title>	
>   <link href="/xyz/app?digest=xxxxx&amp;service=asset&amp;path=%2Fpage_x%2Fpage_x.css" type="text/css" rel="stylesheet" id="Any_0"></link>
> </head>
> The correspondending java class creates the css link via "AbstractComponent.getAsset("pageCss").buildURL()".
> The Websphere log says:
> SRTServletRes W   WARNING: Cannot set header. Response already committed.
> After debugging, we found the reason for this issue.
> If you deploy an war file in Websphere application server, Websphere creates an ear file with the war included. The classpath is:
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\classes;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-annotations-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-contrib-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-framework-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war
> And our directory structure looks like this:
> demoApp
> demoApp/styles
> demoApp/html
> demoApp/WEB-INF
> Tapestry tries to load an Asset with an AssetFactory.
> In the class org.apache.tapestry.assetAssetSourceImpl the method findAssetFactory(IComponentSpecification spec, Resource baseResource, String path, Locale locale) is used for this.
> It looks up the factory in this way:
> AssetFactory findAssetFactory(IComponentSpecification spec, Resource baseResource, String path, Locale locale) {
>    // need to check these two core factories in order first
>    if (_classpathAssetFactory.assetExists(spec, baseResource, path, locale))
>        return _classpathAssetFactory;
>    if (_contextAssetFactory.assetExists(spec, baseResource, path, locale))
>        return _contextAssetFactory;
>             
>    ....
>         
> }
> As you can see for the ear file, the styles directory is visble from classpath and _classpathAssetFactory.assetExists() will return true.
> And this is the problem.
> Like in Tapestry 4.0, you have to check first _contextAssetFactory.assetExists() and then _classpathAssetFactory.assetExists().
> After applying the patch (changing the order to return the assetFactory), the problem was solved for us.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


[jira] Commented: (TAPESTRY-2273) Websphere 6.1 ear asset problem

Posted by "Christian Nutz (JIRA)" <de...@tapestry.apache.org>.
    [ https://issues.apache.org/jira/browse/TAPESTRY-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586396#action_12586396 ] 

Christian Nutz commented on TAPESTRY-2273:
------------------------------------------

Thanks for the tip....I didn't know that this is possible. Now it works (again)

> Websphere 6.1 ear asset problem
> -------------------------------
>
>                 Key: TAPESTRY-2273
>                 URL: https://issues.apache.org/jira/browse/TAPESTRY-2273
>             Project: Tapestry
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: 4.1.2, 4.1.3, 4.1.5
>         Environment: WinXP SP2, Java 1.5.0_14, Tapestry 4.1.2 (also  4.1.5), IBM Websphere 6.1
>            Reporter: Christian Nutz
>             Fix For: 4.1.6
>
>
> We are using Tapestry 4.0 for our project and all works fine.
> Now we want migrate to Tapestry 4.1.5 but in our Websphere environment css-assets are not loaded (The css is embedded via Asset in the html header of our page).
> In the source of the generated html page the css is not correct resolved and looks like this:
> <head>
>   <title>XYZ</title>	
>   <link href="/xyz/app?digest=xxxxx&amp;service=asset&amp;path=%2Fpage_x%2Fpage_x.css" type="text/css" rel="stylesheet" id="Any_0"></link>
> </head>
> The correspondending java class creates the css link via "AbstractComponent.getAsset("pageCss").buildURL()".
> The Websphere log says:
> SRTServletRes W   WARNING: Cannot set header. Response already committed.
> After debugging, we found the reason for this issue.
> If you deploy an war file in Websphere application server, Websphere creates an ear file with the war included. The classpath is:
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\classes;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-annotations-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-contrib-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-framework-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war
> And our directory structure looks like this:
> demoApp
> demoApp/styles
> demoApp/html
> demoApp/WEB-INF
> Tapestry tries to load an Asset with an AssetFactory.
> In the class org.apache.tapestry.assetAssetSourceImpl the method findAssetFactory(IComponentSpecification spec, Resource baseResource, String path, Locale locale) is used for this.
> It looks up the factory in this way:
> AssetFactory findAssetFactory(IComponentSpecification spec, Resource baseResource, String path, Locale locale) {
>    // need to check these two core factories in order first
>    if (_classpathAssetFactory.assetExists(spec, baseResource, path, locale))
>        return _classpathAssetFactory;
>    if (_contextAssetFactory.assetExists(spec, baseResource, path, locale))
>        return _contextAssetFactory;
>             
>    ....
>         
> }
> As you can see for the ear file, the styles directory is visble from classpath and _classpathAssetFactory.assetExists() will return true.
> And this is the problem.
> Like in Tapestry 4.0, you have to check first _contextAssetFactory.assetExists() and then _classpathAssetFactory.assetExists().
> After applying the patch (changing the order to return the assetFactory), the problem was solved for us.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


[jira] Updated: (TAPESTRY-2273) Websphere 6.1 ear asset problem

Posted by "Andreas Andreou (JIRA)" <de...@tapestry.apache.org>.
     [ https://issues.apache.org/jira/browse/TAPESTRY-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andreas Andreou updated TAPESTRY-2273:
--------------------------------------

    Priority: Major  (was: Critical)

> Websphere 6.1 ear asset problem
> -------------------------------
>
>                 Key: TAPESTRY-2273
>                 URL: https://issues.apache.org/jira/browse/TAPESTRY-2273
>             Project: Tapestry
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: 4.1.2, 4.1.3, 4.1.5
>         Environment: WinXP SP2, Java 1.5.0_14, Tapestry 4.1.2 (also  4.1.5), IBM Websphere 6.1
>            Reporter: Christian Nutz
>             Fix For: 4.1.6
>
>
> We are using Tapestry 4.0 for our project and all works fine.
> Now we want migrate to Tapestry 4.1.5 but in our Websphere environment css-assets are not loaded (The css is embedded via Asset in the html header of our page).
> In the source of the generated html page the css is not correct resolved and looks like this:
> <head>
>   <title>XYZ</title>	
>   <link href="/xyz/app?digest=xxxxx&amp;service=asset&amp;path=%2Fpage_x%2Fpage_x.css" type="text/css" rel="stylesheet" id="Any_0"></link>
> </head>
> The correspondending java class creates the css link via "AbstractComponent.getAsset("pageCss").buildURL()".
> The Websphere log says:
> SRTServletRes W   WARNING: Cannot set header. Response already committed.
> After debugging, we found the reason for this issue.
> If you deploy an war file in Websphere application server, Websphere creates an ear file with the war included. The classpath is:
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\classes;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-annotations-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-contrib-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-framework-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war
> And our directory structure looks like this:
> demoApp
> demoApp/styles
> demoApp/html
> demoApp/WEB-INF
> Tapestry tries to load an Asset with an AssetFactory.
> In the class org.apache.tapestry.assetAssetSourceImpl the method findAssetFactory(IComponentSpecification spec, Resource baseResource, String path, Locale locale) is used for this.
> It looks up the factory in this way:
> AssetFactory findAssetFactory(IComponentSpecification spec, Resource baseResource, String path, Locale locale) {
>    // need to check these two core factories in order first
>    if (_classpathAssetFactory.assetExists(spec, baseResource, path, locale))
>        return _classpathAssetFactory;
>    if (_contextAssetFactory.assetExists(spec, baseResource, path, locale))
>        return _contextAssetFactory;
>             
>    ....
>         
> }
> As you can see for the ear file, the styles directory is visble from classpath and _classpathAssetFactory.assetExists() will return true.
> And this is the problem.
> Like in Tapestry 4.0, you have to check first _contextAssetFactory.assetExists() and then _classpathAssetFactory.assetExists().
> After applying the patch (changing the order to return the assetFactory), the problem was solved for us.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


[jira] Updated: (TAPESTRY-2273) Websphere 6.1 ear asset problem

Posted by "Marcus Schulte (JIRA)" <de...@tapestry.apache.org>.
     [ https://issues.apache.org/jira/browse/TAPESTRY-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcus Schulte updated TAPESTRY-2273:
-------------------------------------

    Fix Version/s:     (was: 4.1.6)
                   4.1.7

> Websphere 6.1 ear asset problem
> -------------------------------
>
>                 Key: TAPESTRY-2273
>                 URL: https://issues.apache.org/jira/browse/TAPESTRY-2273
>             Project: Tapestry
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: 4.1.2, 4.1.3, 4.1.5
>         Environment: WinXP SP2, Java 1.5.0_14, Tapestry 4.1.2 (also  4.1.5), IBM Websphere 6.1
>            Reporter: Christian Nutz
>             Fix For: 4.1.7
>
>
> We are using Tapestry 4.0 for our project and all works fine.
> Now we want migrate to Tapestry 4.1.5 but in our Websphere environment css-assets are not loaded (The css is embedded via Asset in the html header of our page).
> In the source of the generated html page the css is not correct resolved and looks like this:
> <head>
>   <title>XYZ</title>	
>   <link href="/xyz/app?digest=xxxxx&amp;service=asset&amp;path=%2Fpage_x%2Fpage_x.css" type="text/css" rel="stylesheet" id="Any_0"></link>
> </head>
> The correspondending java class creates the css link via "AbstractComponent.getAsset("pageCss").buildURL()".
> The Websphere log says:
> SRTServletRes W   WARNING: Cannot set header. Response already committed.
> After debugging, we found the reason for this issue.
> If you deploy an war file in Websphere application server, Websphere creates an ear file with the war included. The classpath is:
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\classes;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-annotations-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-contrib-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-framework-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war
> And our directory structure looks like this:
> demoApp
> demoApp/styles
> demoApp/html
> demoApp/WEB-INF
> Tapestry tries to load an Asset with an AssetFactory.
> In the class org.apache.tapestry.assetAssetSourceImpl the method findAssetFactory(IComponentSpecification spec, Resource baseResource, String path, Locale locale) is used for this.
> It looks up the factory in this way:
> AssetFactory findAssetFactory(IComponentSpecification spec, Resource baseResource, String path, Locale locale) {
>    // need to check these two core factories in order first
>    if (_classpathAssetFactory.assetExists(spec, baseResource, path, locale))
>        return _classpathAssetFactory;
>    if (_contextAssetFactory.assetExists(spec, baseResource, path, locale))
>        return _contextAssetFactory;
>             
>    ....
>         
> }
> As you can see for the ear file, the styles directory is visble from classpath and _classpathAssetFactory.assetExists() will return true.
> And this is the problem.
> Like in Tapestry 4.0, you have to check first _contextAssetFactory.assetExists() and then _classpathAssetFactory.assetExists().
> After applying the patch (changing the order to return the assetFactory), the problem was solved for us.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


[jira] Commented: (TAPESTRY-2273) Websphere 6.1 ear asset problem

Posted by "Andreas Andreou (JIRA)" <de...@tapestry.apache.org>.
    [ https://issues.apache.org/jira/browse/TAPESTRY-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583248#action_12583248 ] 

Andreas Andreou commented on TAPESTRY-2273:
-------------------------------------------

You may have a point here, but how are you defining the pageCss asset?
Won't it work if you prefix its definition with "context:" ?

> Websphere 6.1 ear asset problem
> -------------------------------
>
>                 Key: TAPESTRY-2273
>                 URL: https://issues.apache.org/jira/browse/TAPESTRY-2273
>             Project: Tapestry
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: 4.1.2, 4.1.3, 4.1.5
>         Environment: WinXP SP2, Java 1.5.0_14, Tapestry 4.1.2 (also  4.1.5), IBM Websphere 6.1
>            Reporter: Christian Nutz
>            Priority: Critical
>             Fix For: 4.1.6
>
>
> We are using Tapestry 4.0 for our project and all works fine.
> Now we want migrate to Tapestry 4.1.5 but in our Websphere environment css-assets are not loaded (The css is embedded via Asset in the html header of our page).
> In the source of the generated html page the css is not correct resolved and looks like this:
> <head>
>   <title>XYZ</title>	
>   <link href="/xyz/app?digest=xxxxx&amp;service=asset&amp;path=%2Fpage_x%2Fpage_x.css" type="text/css" rel="stylesheet" id="Any_0"></link>
> </head>
> The correspondending java class creates the css link via "AbstractComponent.getAsset("pageCss").buildURL()".
> The Websphere log says:
> SRTServletRes W   WARNING: Cannot set header. Response already committed.
> After debugging, we found the reason for this issue.
> If you deploy an war file in Websphere application server, Websphere creates an ear file with the war included. The classpath is:
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\classes;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-annotations-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-contrib-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war\WEB-INF\lib\tapestry-framework-4.1.5.jar;
> C:\Programme\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ws-product03Node01Cell\demoApp.ear\demoApp.war
> And our directory structure looks like this:
> demoApp
> demoApp/styles
> demoApp/html
> demoApp/WEB-INF
> Tapestry tries to load an Asset with an AssetFactory.
> In the class org.apache.tapestry.assetAssetSourceImpl the method findAssetFactory(IComponentSpecification spec, Resource baseResource, String path, Locale locale) is used for this.
> It looks up the factory in this way:
> AssetFactory findAssetFactory(IComponentSpecification spec, Resource baseResource, String path, Locale locale) {
>    // need to check these two core factories in order first
>    if (_classpathAssetFactory.assetExists(spec, baseResource, path, locale))
>        return _classpathAssetFactory;
>    if (_contextAssetFactory.assetExists(spec, baseResource, path, locale))
>        return _contextAssetFactory;
>             
>    ....
>         
> }
> As you can see for the ear file, the styles directory is visble from classpath and _classpathAssetFactory.assetExists() will return true.
> And this is the problem.
> Like in Tapestry 4.0, you have to check first _contextAssetFactory.assetExists() and then _classpathAssetFactory.assetExists().
> After applying the patch (changing the order to return the assetFactory), the problem was solved for us.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org