[JAVASERVERFACES_SPEC_PUBLIC-947] Relative Resources Created: 09/Mar/11  Updated: 04/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 24
Labels: None
Σ Remaining Estimate: 5 days Remaining Estimate: 5 days
Σ Time Spent: 2 hours Time Spent: Not Specified
Σ Original Estimate: 5 days Original Estimate: 5 days

Attachments: Zip Archive sample.zip     Zip Archive sample_broken.zip    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-884 Support library prefix in resource URLs Reopened
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900 Images resources in css with relative... Closed
is duplicated by JAVASERVERFACES-1189 #{resource['...']} not usable in <ui:... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1079 Add method ResourceHandler.isResource... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-548 Resource localization is too rigid an... Sub-task Closed Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-884 Support library prefix in resource URLs Sub-task Reopened Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-996 The resources folder should be either... Sub-task Closed Ed Burns  
Status Whiteboard:

size_small importance_medium


 Description   

https://issues.apache.org/jira/browse/MFCOMMONS-29

The features of this ResourceHandler include the following:

  • relative paths between resources (css files referencing images
    without using #resource['..'])
  • caching resources in the client (disabled if ProjectStage == Development)
  • GZIP compression and local cache in tmp dir (disabled if
    ProjectStage == Development)
  • i18n (supporting country code and language).

In addition, it does NOT support ValueExpressions in resource files
for performance reasons.

The most important feature, in my opinion, is how the resource URL is
built, e.g. /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css

... because it permits resources referencing other resources without
#

{resource['...']}

(e.g. css files referencing images or other css
files). With the standard ResourceHandler this is 1) annoying if you
have to change the files you get from your designer and 2) a
performance bottleneck, because resources with ValueExpressions are
not cached and also regenerated for each request.

Furthermore, the resource URL contains the locale and thus you have no
problems with cached resources if a users changes the locale, because
he/she will get a new URL and thus a new resource (the right one).



 Comments   
Comment by Jakob Korherr [ 15/Apr/11 ]

add duplicate links.

Comment by Jakob Korherr [ 13/Jun/11 ]

Just found out that ICEFaces actually provides a tool for processing url() references in css files which are served by JSF 2.0. For example, this tool creates url(#

{resource['org.site.lib/images/background.png']}

) out of url(../images/background.png).

This shows the big impact of this issue, I think.

See http://wiki.icefaces.org/display/ICE/ACE+CSS+URL+Mapping for more details!

We seriously need to fix this with JSF 2.2! Such (annoying) preprocessing should not be necessary.

Comment by Hanspeter Duennenberger [ 26/Aug/11 ]

Hi Jakob,

it would be usefull if there was a way to specify resources depending on the active ProjectStage - e.g. for css and Javascript files, to allow using packaged resources normally but uncompressed css/javascript when ProjectStage is set to Development.

I was discussing this once with someone and we ended up in a possible solution for that to put additional includeProjectStage/excludeProjectStage condition attributes on @ResourceDependency annotation and probably also same attributes on outputStylesheet/outputScript tags.

Might be this ends up in an additional independent issue, but as you are going to work on ResourceHandling anyway I feel adding it here is ok.

regards
Hanspeter

Comment by lu4242 [ 29/Aug/11 ]

In MyFaces and Tomahawk a custom hack is used to check if the project stage is Development and if a resource under META-INF/internal-resources (or in tomahawk META-INF/uncompressed-js-resources), just take this instead the compressed version used in Production stage.

I believe that it could be more simple to assume a "mirror uncompressed" location, and in practice use some plugin to compress the resources, and add the logic on the default (or custom) ResourceHandler algorithm.

EB> This approach breaks down when there is not a 1:1 mapping between
EB> compressed and non-comporessed resources. For example, when you
EB> want all your JS in one compressed file at Production time, and want
EB> several smaller, non-compressed files, at Development time.

Comment by Jakob Korherr [ 04/Sep/11 ]

Hi Hanspeter,

This is a very, very nice idea! I will prototype that in my relative-resource-handler at apache-extras (see http://code.google.com/a/apache-extras.org/p/relative-resource-handler/).

Also: Since I will have more time in the next two weeks, I really do hope to get some work done for the spec!

Regards,
Jakob

Comment by Hanspeter Duennenberger [ 03/Oct/11 ]

Hi Jakob,

any progress here?

I wanted to add something about the ProjectStage dependent resources. There might be two options for it:

1. use a project stage dependent resource path in the jar (similar to Locale handling with fallback). This is useful if the resource is the same name but only compressed for production, e.g.

myJs/some.js
myJs/production/some.js             (compressed some.js)

2. because the JS files may get pretty big, we would like to use multiple JS files for development but combine/compress a number of such JS files to one for production. This means the number of resource dependencies change depending on project stage.

myJs/funct-a.js
myJs/funct-b.js
myJs/funct-c.js
myJs/{production/}funct-all.js      (compressed combination of funct-*.js files)

So for example, it should be possible to state one component needs funct-a.js and funct-b.js when in project stage Development and only funct-all.js when in project stage Production.

I think possibility 1 is a little closer to what Leonardo mentioned about the MyFaces specific hack.
I really would like to have a specified way to handle project-stage specific resources, this might need some discussion in expert group though.

Cheers
Hanspeter

Comment by Jakob Korherr [ 06/Oct/11 ]

Hi Hanspeter,

Currently I am trying to convince a professor at Vienna university of technology to let me write about the relative resource handler for my bachelor thesis. If this will be accepted, I will have a lot more time for the resource handler.

The idea is really very, very great and I'd like to do some prototyping here. However, I don't know if we should really follow a convention-over-configuration approach. I am actually not sure if we can find a convention for the resource name that will fit in most scenarios. Maybe we need some configuration mechanism here...

Regards,
Jakob

Comment by Hanspeter Duennenberger [ 09/Feb/12 ]

Hi all.

For multiple skins or theme support it will be necessary that the resource path may contain an optional skin or theme-path part.

 Skin-one
 /resources/skin-one/css/main.css

 Skin-two
 /resources/skin-two/css/main.css

The reference to this resource could be:

 <h:outputStylesheet name="main.css" library="css" />

I have kind of such an implementation, but it is probably to much integrated with our Skin interface. It should be a more general solution.

Regards
Hanspeter

Comment by Jakob Korherr [ 14/Feb/12 ]

Hi hanspeter,

You are totally right! In my resource handler I called it "support for multi-tenancy", however, this is not implemented yet.

Actually you need to add every information you need to determine the correct resource into the resource path, thus it somehow is a REST url. I also added a resource-version to the path in order to deal with resource-update-browser-cache problems.

Regards,
Jakob

Comment by Ed Burns [ 27/Feb/12 ]

Jakob, can you please hack upon this sample war to make it show the problem? The current war does use relative resources, but the browser is able to resolve them. Can you make it so the browser cannot resolve them?

Comment by Jakob Korherr [ 29/Feb/12 ]

Hi Ed,

Your sample is somehow funny. You use a css file in webapp/resources/library/style.css using relative paths like this: url(../../included.css) and url(../../expert-draft-bg.png). The two referenced resources, of course, are located two folders up in the directory tree (directly in webapp).

Now as it would seem to be logical that this works, it really is a coincidence. You see, style.css is loaded via the following url:

http://localhost:8080/faces/javax.faces.resource/style.css?ln=library

Thus, included.css and expert-draft-bg.png are loaded by the browser using the following urls:

http://localhost:8080/included.css
http://localhost:8080/expert-draft-bg.png

The 1st ".." removed "javax.faces.resource" and the 2nd ".." removed "faces" (however, you would actually think that the 1st ".." removes library and the 2nd ".." removes "resources"). This, of course, only works because tomcat (or any other servlet container) serves the two files directly, and it has nothing to do with the JSF resource handler (e.g. ValueExpressions won't work!).

Now, there are a number of possibilities to break the example:
1) use .jsf instead of /faces/ FacesServlet mapping
2) locate the two resources in the same folder as style.css (while removing the ".." sequences in style.css)
3) locate the two resources in the classpath (META-INF/resources)
...

I used the 2nd of the above options in my sample_broken.zip.

Here, style.css still gets loaded via:

http://localhost:8080/faces/javax.faces.resource/style.css?ln=library

But now the browser tries to locate included.css and expert-draft-bg.png using these urls:

http://localhost:8080/faces/javax.faces.resource/included.css
http://localhost:8080/faces/javax.faces.resource/expert-draft-bg.png

Which does NOT work, because the library request parameter is missing. My approach (http://code.google.com/a/apache-extras.org/p/relative-resource-handler/) creates an url in which the library is included in the url path, thus this will work.

If you have any further questions, please ask!

Regards,
Jakob

Comment by Jakob Korherr [ 29/Feb/12 ]

Added sample_broken.zip

Comment by Ed Burns [ 29/Feb/12 ]

Thanks for demonstrating to me exactly how this is broken.

Now I can proceed to better see how to fix it!

Comment by Ed Burns [ 29/Feb/12 ]

Looking at your relative-resource handler, it is immediately apparent that the ability for the relative resources to even work is based on how you are encoding the library name differently from what is specified. As stated in the javadocs for RelativeResourceHandler, you have to use

META-INF/relative-resources.xml

to declare libraries and we can't accept that requirement in the spec. Also, the stated limitation of only being able to work with prefix mapped JSF runtimes is unacceptable.

I can see why you made these decisions and how they enable the nice features of your Relative ResourceHandler, but we need to figure out how to do what you request without making unacceptable compromises.

Comment by Ed Burns [ 29/Feb/12 ]

Jakob, what is the main reason for being dissatisfied with this syntax for relative resources?

css_master.css:

@import url(#

{resource['this:layout.css']}

);

Is it performance?

Comment by Jakob Korherr [ 29/Feb/12 ]

The need to have the libraryName configured in relative-resources.xml does only exist, because I needed a way to enable the RelativeResourceHandler only for certain libraries. This would not be necessary if the standard ResourceHandler already uses the "relative-mechanism" (for all libraries).

There are many reasons:

1) Acceptance: There is no other framework (at least which I know of), in which you cannot use relative paths between resources as they would work in the file system. Nearly every IDE supports "resource-exists-checks" in css files with relative paths in the file system, and these IDEs will mark #

{resource[]}

url references as errors. Every server (http or servlet container), CDN,... supports relative paths in the URLs like a normal file system, why should JSF do this differently?

2) Effort: You need quite a lot of time to change a big CSS framework (which you will get from your designers) into a working JSF version. And remember, next day the designer may change something, then you will get a new version of the whole CSS framework, and the work starts again...

3) Performance: Actually, having ValueExpressions in resource files is not only a performance killer, it also gives the developer the impression as if she could change resource file contents in every request, whereas she really cannot, because the resource will get cached by the browser/proxy.

I actually would not use the current JSF ResourceHandler because of these points and instead let tomcat (or even weblets) handle my resources, because they both support relative paths like a calm.

Comment by Ed Burns [ 20/Mar/12 ]

A resource path from Jakob's impl looks like
"/javax.faces.resource/1.0.0/en_US/css/style.css". Does that 1.0.0
refer to library version or resource version?

Here's a clue, from RelativeResourceHandler#132.

// skip version in url (first part, only there to avoid cache problems on updates)
final int versionSlash = resourceName.indexOf('/');

But that still doesn't answer my question. What does the 1.0.0 mean?

Jakob's ResourceHandler.createResource() allows the entire resourceId to
be in the "resourceName", which it re-interprets according to its own
rules if it determines that the library is not a JSF 2.0 style resource
library.

JK> The need to have the libraryName configured in
JK> relative-resources.xml does only exist, because I needed a way to
JK> enable the RelativeResourceHandler only for certain libraries. This
JK> would not be necessary if the standard ResourceHandler already uses
JK> the "relative-mechanism" (for all libraries).

Ok, let's say we make relative libraries the default for prefix mapped
applications. If we have a jar in the classpath that contains a library
that is arranged according to the JSF 2.0 spec for resource libraries,
we now we need some way to detect that case and use the JSF 2.0 style
arrangement, right?

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





Relative Resources (JAVASERVERFACES_SPEC_PUBLIC-947)

[JAVASERVERFACES_SPEC_PUBLIC-884] Support library prefix in resource URLs Created: 17/Sep/10  Updated: 09/Sep/15

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.0
Fix Version/s: None

Type: Sub-task Priority: Critical
Reporter: cayhorstmann Assignee: Ed Burns
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Duplicate
duplicates JAVASERVERFACES_SPEC_PUBLIC-947 Relative Resources Open
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900 Images resources in css with relative... Closed
Issuezilla Id: 884
Status Whiteboard:

size_small importance_medium


 Description   

Consider a stylesheet

<h:outputStylesheet library="styles" name="skin.css"/>

Resources are loaded with URLs such as

/context path/faces/javax.faces.resource/skin.css?ln=styles

(when prefix mapping is used).

CSS files commonly contain url(...) expressions such as

.ui-icon

{ width: 16px; height: 16px; background-image: url(myicon.png); }

These url(...) expressions fail to locate the dependent resources.

This discussion further explains the problem:
http://forums.sun.com/thread.jspa?threadID=5447194.

It is not reasonable to ask the users to rewrite the URLs in the style sheet
since style sheets are often auto-generated.

While it might be possible for JSF to automatically rewrite the URLs in a style
sheet as it is loaded, that would not work for other files (e.g. JavaScript).

If instead the library name is added as a prefix, then the problem goes away:

/context path/faces/javax.faces.resource/styles/skin.css

(NB. I believe the ?ln=xxx is a vestige of an earlier time
when the version and resource prefix were also specified as request
parameters, see
http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature.)

In the interest of backward compatibility, we can to provide an application
configuration parameter

javax.faces.RESOURCE_URL_MAPPING with options prefix and param

Then
http://download-llnw.oracle.com/javaee/6/api/javax/faces/application/Resource.html#getRequestPath%28%29
needs to be changed as follows:

  1. If getLibraryName() returns non-null, discover if the resources are prefix or
    param mapped, by consulting the application configuration parameter
    javax.faces.RESOURCE_URL_MAPPING. If prefix mapped, insert "/" +
    getLibraryName() after ResourceHandler#RESOURCE_IDENTIFIER. If param mapped, ...


 Comments   
Comment by Ed Burns [ 26/Oct/10 ]

2.2

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by ramiromagalhaes [ 14/Apr/11 ]

This is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900.

Comment by lamine_ba [ 14/Apr/11 ]

It seems that someone has reported this issue since a long time . It was one of the first issue I have to deal with JSF 2.0. How to load with css an image stored in my images folder?
If my faces servlet is mapped to .faces, I can overcome this problem by doing this

background-image: url(myicon.png.faces?ln=images)

If my faces servlet is mapped to /faces/*, I can overcome this problem by doing this

background-image: url(myicon.png?ln=images)

If would be nice if we could come back to this

background-image: url(images/myicon.png)

Comment by Jakob Korherr [ 15/Apr/11 ]

The problem described by lamine_ba is exactly why I created the MyFaces commons resourcehandler module (see [1]). Fortunately I already talked with Ed about it, and we will try to address this issue by re-using some of the code/concepts from MyFaces commons resourcehandler!

[1] https://svn.apache.org/repos/asf/myfaces/commons/branches/jsf_20/myfaces-commons-resourcehandler/

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1435] getViewResources method(s) to get list of physical view resources and logical views Created: 03/Jan/17  Updated: 03/Jan/17

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: None
Fix Version/s: 2.3

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: arjan tijms
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The ServletContext has a method to acquire all paths to resources within a web application; getResourcePaths().

In JSF resources are handled by the ResourceHandler This has a method createViewResource that takes a path and effectively returns a URL, just like ServletContext has a getResource method taking a path and returning a URL.

In both cases, the usage is to abstract the actual location of resources, which could therefor transparently be on a local or remote filesystem, in a database, custom jar location, or whatever.

The JSF specific ResourceHandler however does not have a getResourcePaths() equivalent.

I'd like to propose to rectify this by introducing such method for JSF view resources.

Care should be taken that it can both physical and logical views, and both views that can be requested for a top level request only, and all views (including those for includes).






[JAVASERVERFACES_SPEC_PUBLIC-946] Provide internal server path of resources from Resource API via EL Created: 20/Feb/11  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: EL, Resources
Affects Version/s: 2.0, 2.1
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Jakob Korherr Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_medium


 Description   

Currently JSF 2 provides #

{resource['libraryName:resourceName']}

to get the request path of the specified resource for the browser (e.g. /context-root/faces/javax.faces.resource/libraryName/resourceName). Thus #

{resource[...]}

is mostly used for css or js files.

Unfortunately there is no way to use the Resource API directly in EL to get the server path to internal resources, e.g. when using <ui:include src="..."> and referrencing a xhtml (facelet) page.

Of course, as a workaround, you can use this method in a managed bean:

public String getMyResourcePath()
{
FacesContext facesContext = FacesContext.getCurrentInstance();

Resource resource = facesContext.getApplication().getResourceHandler()
.createResource("myresource.xhtml", "mylibrary");
URL url = resource.getURL();

return url.toExternalForm();
}

However, this really only is a workaround.

I'd like to propose using #

{serverresource['...']}

or #

{internalresource['...']}

or #

{resoure['...'].serverPath}

(or something similar) to provide a convenient way for getting the server-path to the resource. This way users can use the facelets templating mechanism in combination with the Resource API, e.g.:

<ui:include src="#

{serverresource['templates:headInclude.xhtml']}

" />
<ui:component template="#

{serverresource['templates:componentTemplate.xhtml']}

">
...

See also the user-discussion from the MyFaces mailing list (showing that users are confused why #

{resource['']}

isn't working for facelets stuff): http://www.mail-archive.com/users@myfaces.apache.org/msg56907.html



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-962] Configurable resource file extensions eligible for EL evaluation Created: 01/Apr/11  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Mathias Werlitz Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium


 Description   

At the moment only CSS resources are allowed to contain EL expressions that will be evaluated when served as a resource. An application my serve other resources that could contain dynamic content. The spec should allow configuring file extensions eligible for EL evaluation when served as resources.



 Comments   
Comment by Mathias Werlitz [ 01/Apr/11 ]

Priority should be trivial, sorry.

Comment by Hanspeter Duennenberger [ 18/Apr/11 ]

I think resources containing EL expressions (do we really need that?) that must be processed should be handled separately from pure static resources to allow fastes possible delivery of static resources.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1330] Allow flexible resource mapping for .js or .css or other files served by ResourceHandler Created: 23/Oct/14  Updated: 31/Oct/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: lu4242 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From EG list discussion:

I just wanted to note an issue that has been around for some time and
it is related. Sometimes you have a bunch of .js or .css files and you
want to group all of them into a single file. To do that, you can
create a custom ResourceHandler and redirect the resource requests to
the suggested resource that joins all the files or use some library
that has already that logic.

It would be great if JSF by default could handle that "alias" logic.
If the project stage is Development then load the uncompressed files,
but if it is Production use this compressed javascript. That would
improve performance and has been mentioned in the past. Some people
has already provided solutions.

Please note this logic can be made to override jsf.js javascript as
well. But from design perspective I don't feel very good about have
alternate versions of jsf.js, instead I would like to make jsf.js work
even with portlets.

It is a fact that JSF is very pluggable from the java perspective, but
the fact that you cannot customize the behavior of jsf.js (pass config
params on initialization like project stage and others) becomes a
problem.

In MyFaces for example, there is a code
that according to the project stage (dev or prod) it uses the
uncompressed or the compressed version of the file.

In MyFaces we have two paths:

/META-INF/internal-resources (for uncompressed versions of the js files)
/META-INF/resources (for compressed and production-ready versions of
the js files)

and a custom resource handler that uses internal-resources if project
stage is development.

The central point is sometimes you need to override the resources, and to
do that you need to create custom implementations of ResourceHandler,
so you end with a similar logic scattered across multiple libraries.

Suppose this example:

a.css
b.css

And you create

a_b.css

Now you have these lines:

<h:outputStylesheet name="a.css"/>
<h:outputStylesheet name="b.css"/>

The idea is when a.css or b.css is resolved, it returns a Resource
instance that represents a.css or b.css, but in fact it is holding
a_b.css, so it should be only one link entry rendered on the
response.






[JAVASERVERFACES_SPEC_PUBLIC-1261] inconsistent behavior with absolute contracts references like /contracts_dir/contract_name/resource.xhtml Created: 03/Feb/14  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3146 absolute contract reference (e.g. tem... Closed

 Description   

See also https://java.net/jira/browse/JAVASERVERFACES-3146.

Absolute references to resources in contracts is not supported by design. However, with contracts deployed in /webapp_root/contracts_dir/contract_name it is possible to reference such resources using the absolute reference /contracts_dir/contract_name/resource.xhtml. Moving the same contract out to a separate jar this reference cannot be resolved anymore.

Since such absolute references are not supported by design such absolute contracts references must be prevented no mather if the contract is deployed into /webapp_root/contracts_dir or in META-INF/contracts within a jar.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-1252] It should be possible to specify Resource Dependencies via XML Created: 14/Jan/14  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From the portlet EG mailing list (Neil Griffin and Ed Burns)

NG> @Ed Burns: When you get a chance, could you please shed some light
NG> on why resource dependencies can only be done via JSF annotations,
NG> and not by faces-config.xml? Thx.

EB> I suppose it could be. It turned out to be easier to implement with
EB> annotations. I think you have discovered a wrinkle where our stated
EB> goal of having complete parity of functionality between annotations and
EB> XML is not met.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1208] Allow page authors to define ordering of resources in the <head> Created: 10/Jul/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers, Facelets/VDL, Resources
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Right now, developers have no control over the ordering of resources loaded in the HEAD of the document. This can cause problems with ordering of CSS, JavaScript resources, or browser behavior. Something like PrimeFaces' solution (http://blog.primefaces.org/?p=1433) is definitely needed.

I ran into this requirement trying to force IE to use "IE 8 Standards Mode". This requires a <meta> header, but it must be the first element in the <head>. This isn't possible without a custom component or a third-party library like PrimeFaces.. See http://social.msdn.microsoft.com/Forums/ie/en-US/afb57ce6-d149-4a09-8811-63c0645c92e6/force-ie8-to-render-in-ie8-standard-mode.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1144] ResourceWrapper should implement Externalizable to enable wrapper extensions to retain resource wrapper instance hierarchy Created: 13/Nov/12  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.0, 2.1, 2.2 Sprint 13
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: kfinnigan Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently ResourceWrapper has no way to handle being Serialized/Externalized by JSF State management, as it neither implements Serializable or Externalizable.

Implementation of Externalizable resides on ResourceImpl only.

This situation presents a problem when extending ResourceWrapper, as for the state management to work as expected the new class that extends ResourceWrapper needs to implement Externalizable.

In theory that seems fine, but then in readExternal() whatever class hierarchy was present through, possibly several, ResourceWrapper instances is not able to be re built (without writing code to save it all in writeExternal()).

This is a problem as losing all those classes in the hierarchy will have adverse affects to calls such as getRequestPath() or any methods that those classes may have customized.



 Comments   
Comment by kfinnigan [ 13/Nov/12 ]

Suggest modifying ResourceWrapper to implement Externalizable and alter the class javadoc to be something like:

Provides a simple implementation of Resource that can be subclassed by developers wishing to provide specialized behavior to an existing Resource instance. The default implementation of all Resource methods is to call through to the wrapped Resource.

Usage: extend this class, override getWrapped() to return the instance we are wrapping and implement Externalizable methods by calling their super equivalents.

Method javadoc for writeExternal():

Write the wrapped Resource to ObjectOutput such that it can be read by readExternal().

Method javadoc for readExternal():

Read the ObjectInput to recreate the wrapped Resource.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-820] Resolve Resource URLs in UIComponents Created: 20/Jun/10  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: razib Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.java.net/jive/thread.jspa?messageID=395511


Issuezilla Id: 820
Status Whiteboard:

size_medium importance_medium


 Description   

The purpose of this enhancement request is to make it easier to reference
resource URLs in custom components.

In JSF 2, a great EL shortcut was introduced to get the url for resources using
the resource implicit object (e.g. #resource['/library/image.jpg']). But there
is no easy programmatic way of resolving resource URLs inside a custom
component. For example if an image resource lies inside
META-INF/resources/library/image.jpg, there is no convenient way of referencing
the path of the image when writing an "img" tag inside my UIComponent.

Ideally such method should exist in ResourceHandler and users can invoke it
using
facesContext.getApplication().getResourceHandler().getRequestPath("image.jpg","library"),
but resource handler has no such method to find a resource in META-INF/resources.

In lieu of this, you can do the following (Suggested by Ed Burns):

ResourceHandler rh = facesContext.getApplication.getResourceHandler();
Resource r = rh.createResource("image.jpg", "library");
rh.getRequestPath();

This would work, but it is not as nice as getResourceHandler().getRequestPath().

This will give Component developers some ease, especially when there are
implementing components that deal with javascript extensively.

Thanks.



 Comments   
Comment by razib [ 20/Jun/10 ]

This is an enhancement request.

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-598] Allow a URL target for outputScript and outputStylesheet Created: 30/Jul/09  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.1
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: driscoll Assignee: Unassigned
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 598
Status Whiteboard:

cat2 vdldoc javadoc size_small importance_small


 Description   

both outputStylesheet and outputScript should be able to take a URL instead of a
resource target - there are times when you want to serve things from someone
else's machine, such as Yahoo or Google.

One use case for this change: You are writing a composite component, which uses
Google's service to load CSS (such as when you use the YUI components). This
means that you currently must either require users to put a <link> tag in the
header, which is clearly undesirable, or that you need to use only local files,
which can in many cases offer worse performance.



 Comments   
Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 24/Feb/10 ]

I agree with the intent of the issue, but it's too big for 2.0 Rev a

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 04/Mar/10 ]
      • Issue 706 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 22/Mar/10 ]

vdldoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Ed Burns [ 04/Aug/14 ]

Leave unchanged.





Generated at Tue Jan 24 23:14:34 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.