[JAWR-236] Jawr maven bundle doesn't generate sprites the same as when an application server starts up Created: 06/Jul/12  Updated: 06/Jul/12

Status: Open
Project: jawr
Component/s: Bundling Tools
Affects Version/s: 3.3.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Binary_00 Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: bundle, smartsprite, sprite

 Description   

When using the smartsprites preprocessor a server can generate sprites differently than using the maven jawr:bundle task. This leads the css to use different background positioning and inevitably different css hash codes.

Versions:
jawr : 3.3.3
jawr-bundle-processor : 1.4.2
smartsprites : 0.2.8

I believe it has to do with the smart sprites builder which builds the sprite based on the order of the files passed in. The server startup and maven task pass in the same files but in different order.



 Comments   
Comment by icefox [ 06/Jul/12 ]

Hi Binary_00,

Thanks for reporting this issue.
I'll take a look at it.

Cheers,





[JAWR-188] Dependencies in post processors not always respected. Created: 02/May/11  Updated: 06/Jun/11

Status: Open
Project: jawr
Component/s: None
Affects Version/s: 3.3.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: TimDGSL Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: dependencies, postprocessor

 Description   

Hi,

I've run into the following issue:

In my jawr.properties, I defined a custom post processor like this:

jawr.custom.postprocessors.localeFilter.class=com.company.client.web.jawr.JawrImageLocalePostProcessor

I then created several bundles, one of them had the following postprocessors:

jawr.css.bundle.bundle1.filepostprocessors=localeFilter

Another had these:

jawr.css.bundle.bundle2.filepostprocessors=localeFilter,base64ImageEncoder

However, the CSS files in bundle1 also contained base64 encoded images.

As a work-around, I defined my post-processor twice: once for where I need to use base64 encoding and once for where I don't.

**Note: these are anonymized, if necessary, I can e-mail you the complete jawr.properties file that gave us these problems.



 Comments   
Comment by icefox [ 02/Jun/11 ]

Hi TimDSL

Sorry for my late reply, but I only got time now to take a look at your issue.
Can you please send me you jawr.preoperties by mail so I can investigate.

Cheers,

Comment by TimDGSL [ 06/Jun/11 ]

I'll need a way to contact you off-board for that (since I'm not allowed to post it publicly). You can contact me through tim.dg@softlution.com





[JAWR-364] Upgrade DWR 3 extension to use the latest DWR 3.0-RELEASE version Created: 10/Sep/15  Updated: 10/Sep/15

Status: Open
Project: jawr
Component/s: DWR3 Plugin
Affects Version/s: None
Fix Version/s: None

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


 Description   

Upgrade DWR 3 extension to use the latest DWR 3.0-RELEASE version






[JAWR-363] Allow parallel bundle processing Created: 10/Sep/15  Updated: 10/Sep/15

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

For the time being, Jawr process bundles one after the other.
The goal of this feature is to allow parallel bundle processing, which could speed up processing time






[JAWR-360] Allow configuration of Jawr with application code Created: 09/Sep/15  Updated: 09/Sep/15

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: icefox Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It would be great to be able to implement a simple component that can be configured with java configuration, like how one configures Spring http security.

Here is an exmaple of SecurityConfig class:

SecurityConfig .java

protected void configure(HttpSecurity http) throws Exception {


  http.authorizeRequests()
    .antMatchers("/partner/**", "/embed/**", "/", "/signout*").permitAll()
    .antMatchers("/**").authenticated();

   ...
}

It would be great to be able to configure Jawr the same way, something like :

MyJawrConfig.java

public JawrConfig getJawrConfig() {

  JawrConfigBuilder jawr = new JawrConfigBuilder ();

  jawr.bundle("core")
    .match("/resources/js/jquery-1.11.min/js")
    .match("/resources/js/modernizer.min.js")
    .prefix("/resources/");

  return jawr.getConfig();
}

Then this configuration could be passed to a servlet :

InitApplication.java

ServletRegistration.Dynamic sr = ctx.addServlet("CSSServlet", new JawrServlet(myJawrConfig.getJawrConfig()));

sr.addMapping("*.css");

This issue has been reported by tveimo.






[JAWR-361] In Jawr configuration, allow use of created bean instead of classname for generators, processors, ... Created: 09/Sep/15  Updated: 09/Sep/15

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: icefox Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

For the time being, Jawr use classname to instanciate custom generators, processors, configuration property resolvers, ...
This can be a limitation for application using bean management Framework like Spring, where it is more complicated to inject bean which has already been initialized by the bean lifecycle manager.
This issue can have a dependency with JAWR-360






[JAWR-359] For JAWR.loader, the property jawr.debug.use.random.parameter is not taken in account Created: 08/Sep/15  Updated: 08/Sep/15

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: icefox Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There is an issue in the JAWR.loader, where the property jawr.debug.use.random.parameter is not taken in account.

The property jawr.debug.use.random.parameter should be initialized and synchronised with te JS property JAWR.loader.disableRandomParam.

This issue has been raised in the discussion forum by SopFlo
https://java.net/projects/jawr/forums/discussion-forum/topics/229795-Cache-in-debug-mode






[JAWR-358] Add support for JSX resource Created: 04/Sep/15  Updated: 04/Sep/15

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

Jawr should be able to handle JSX resource generation






[JAWR-357] Support AMD loader API in Jawr Created: 04/Sep/15  Updated: 04/Sep/15

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

The goal of this feature is to add support to AMD loader API in Jawr so the loading system of AMD works properly with Jawr.
See https://github.com/amdjs/amdjs-api/wiki/AMD for more detail






[JAWR-316] Add sourcemap to JSmin compressor Created: 13/Nov/14  Updated: 13/Nov/14

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

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





[JAWR-313] Add smart bundling feature to Jawr Created: 11/Nov/14  Updated: 25/Sep/15

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

The idea here is to improve Jawr in such a way that it's able to determine which bundle has change and must be rebundled.

This will greatly improve the startup time of Jawr when only few bundle have changed.



 Comments   
Comment by icefox [ 12/Nov/14 ]

The solution which I've come to is to use the watch service introduced in Java 7.
There is another implementation called jpathwatch which is available for Java 5 and Java 6.
The idea is to watch the file modification or creation and mark as dirty the bundles impacted.
This can be done if the server is started up.
If the server is down and the user publish a new version of the files, we need to detect the changes.
For this part, I'm not sure about the best solution (calculating the hash for every file, storing the last modification date for each file, ...)
This part needs to be dug a little bit.

Comment by iampivot [ 25/Sep/15 ]

If you keep a map in a file indicating which files each bundle depend on, then on webapp restart, you can check if any of these has a more recent timestamp than the corresponding bundle cache file in the jawrTmp directory. I presume such a map could use a file format similar to the old makedepend tool, eg a simple bundlename: resourcename, resourcename, ... etc.

If you maintain this map also runtime, then you don't strictly need a watch service, since you can check file timestamps on each bundle request. Granted there's a small penalty on each request, but this would be expected in debug mode. (JSPs have the same access time check penalty.)





[JAWR-253] Support an onload attribute for JavaScript bundles Created: 14/Oct/13  Updated: 15/Oct/13

Status: Open
Project: jawr
Component/s: Jawr Core
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: artemfinland Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: javascript

 Description   

After JAWR-251 is done async and defer attributes are possible for JavaScript bundles and after playing with the home grown clone of it, I figured you also need to know when the asynchronously loaded bundle is actually ready to use (other scripts may very well depend on it). So onload handler is also needed.

Ideally it would include the following:
1. onload tag property
2. Some sort of decision (or enforced rule?) about the quotes/double quotes as in plain HTML technically any can be used inside onload handler depending on which one is used to delimit the attribute value
3. A global config property (or yet another tag attribute? or just an enforced rule?) on what to do in the debug mode. Should all of the scripts call the same onload code or shall the last bundle script specified do it only (and just hope that earlier ones are loaded first).

https://java.net/jira/browse/JAWR-251



 Comments   
Comment by icefox [ 14/Oct/13 ]

Hi

I think that we need to figure out what is the best way to introduce this new feature.
There are some questions to address :

How to handle global bundle?
How does it play with the debug mode?
Should we make it browser independent with a javascript code to load async bundle if the browser doesn't support async or defer?

I'm preparing a release and I don't have time to work on this,
but I'll be glad if you could share your findings and your ideas.

Don't hesitate to let a comment on this issue.

Cheers,

icefox

Comment by artemfinland [ 15/Oct/13 ]

My understanding on JAWR isn't good enough to suggest real good answers, I can share what I think we are going to do for a local fork (oh well, more like extension on top of JAWR).

General approach:

  • Async loading to me is a production oriented technique that is in general hard to emulate for debugging as, well, with async loading you want to have onload handlers, understand when exactly and what exactly is being loaded and that is going to be radically different when loading a bundle or many bundle sub-components.

So far we lean towards removing async qualifies in debug mode (possibly keeping defer ones). That should make it not precisely the same as production code, but quite similar to what's expected in production if the JS is written more or less OK. Keeping "defer" will preserve the execution order I think.

onload handler is more difficult. Ideally, you would have only one onload handler per bundle and in debug mode it is the last script that should generate it. In practice I don't really know how to modify exactly the last script code, so we'll probably generate same onload handler for all of them and will make sure our onload code is ready for multiple calls in the debug mode.





[JAWR-242] Javascript source map support Created: 24/Jan/13  Updated: 26/Sep/15

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: rhuynh Assignee: icefox
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Any plans for javascript source map support?

http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/



 Comments   
Comment by tecgoblin [ 05/Aug/15 ]

This is super useful feature that works without jawr but is broken with jawr. Source maps are used already by plenty of languages (coffeescript, typescript, less etc). They rely in having a .map file mapping the original file to the generated one.
Without jawr, the browser reads a comment in the generated file and this comment tells where to look for the mapping, which in turn leads to the original file.
In my example, I have a .js with the following automatically generated comment: //# sourceMappingURL=MyFile.js.map
With jawr, the .map file cannot be put in the js bundle, so it has to be treated as an orphan resource. The .js file served is NOT anymore in the same path as the .map file, so the browser cannot find the .map file.
Other bundling frameworks (see asp.net built-in bundling) are completely transparent on debug (by not changing the urls), so they manage to overcome this issue.

Comment by paranoiabla [ 24/Sep/15 ]

I tried mapping all the //.js.map to the jawr controller and now when I run jawr in debug=true it all works great, but when I try it in debug=false I get StackOverflow errors. The reason is that JAWR is trying to load this .map file gzip_1463943825/solarapparel/NORMAL/slick.css.map and it hits JawrRequestHandler:86

					if (LOGGER.isDebugEnabled()) {
						LOGGER.debug("Path '" + requestedPath
								+ "' does not belong to a bundle. Forwarding request to the server. ");
					}
					request.getRequestDispatcher(requestedPath).forward(request, response);
					processed = true;

and because it does not belong to a bundle it delegates the request to the server, which calls JAWR again, and again and again. So i guess simply mapping the map file to jawr will not really work.

Comment by icefox [ 25/Sep/15 ]

Hi,

The integration of map support in Jawr is not an easy task.
Some files are linked to map files (less, coffeescript, ...)
But these files can be incorporated in bundles, which can be minified.
The processors can have impact on the map files too...

So make it work with the different components is not easy.
This feature is not currently in the top priorities, but it still is considered in the roadmap.

Any help on this feature is more than welcome.

Cheers,

Comment by tecgoblin [ 25/Sep/15 ]

@paranoiabla Can you explain what do you mean by 'I tried mapping all the //.js.map to the jawr controller and now when I run jawr in debug=true it all works great'? It might be sufficient for us if it works with debug=true, but in our case we cannot manage to even add the .js.map files to a bundle.

Comment by icefox [ 26/Sep/15 ]

Hi tecgoblin,

Can you elaborate your use case?
How would you like it to work in debug mode?

Handling sourcemap in debug mode could be a first step to achieve this feature.

Cheers,

Comment by paranoiabla [ 26/Sep/15 ]

What I mean is that I simply map the spring jawr controller to map to /*/.js.also. And for that I don't see any exceptions in debug mode. In production mode however I get the exceptions (I think it's because in debug mode my javascript files are not including the .map file)

Comment by tecgoblin [ 26/Sep/15 ]

Hi @icefox and thanks for caring! Ideally I would like that in debug mode the page points directly to the original Js paths, as they are in the folder structure. Ex js/thatpage/file1.js instead of /jawr/mybundleforthatpage/file1.js This would allow the browser to find the source.map and source files which are in the same folder.
If this is not possible, I would like to have jawr doing something similar by searching itself for the sourcemapping comment in the source file, understand there is a source file and expose the source file and the mapping file in a path coherent to what the comment says. So, if the comment points to a Js.map in the same folder as the .js, I would need /jawr/mybundleforthatpage/file1.js, /jawr/mybundleforthatpage/file1.js.map and /jawr/mybundleforthatpage/file1.ts (in this example the source is typescript, but it could be anything). In this case as well the browser will be able to find the source.





[JAWR-248] Add support for a LESS postprocessor Created: 10/Sep/13  Updated: 11/Dec/14

Status: Open
Project: jawr
Component/s: None
Affects Version/s: 3.3.3
Fix Version/s: None

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


 Description   

This goal of this feature is to add support for a Less Postprocessor in Jawr
(see : https://java.net/projects/jawr/forums/discussion-forum/topics/74729-Is-JAWR-an-active-project-#p105196)



 Comments   
Comment by janningvygen [ 11/Dec/14 ]

I came across this issue too.

In my opinion it does not make sense to call a less processor before bundling.

If I bundle a few files from a jar, the less process is not called anyway (see https://java.net/jira/browse/JAWR-247). One can argue, that less variables might be conflicting in different less files. But I guess this should be rather rare situation. And you still can use composite bundles. I guess with composite each bundle is post processed on its own.

Usually you have split your files across many different css/less files and want to share some less variables for all of them. This is only possible with a LessPostProcessor

So I think best would be to remove the LessCssGenerator and replace it with a LessCssPostProcessor.





[JAWR-247] Allow LESS generator to generate LESS resources from classpath Created: 10/Sep/13  Updated: 27/Aug/15

Status: Reopened
Project: jawr
Component/s: Jawr Core
Affects Version/s: 3.5
Fix Version/s: None

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


 Description   

The goal of this feature is to allow the LESS generator to retrieve LESS files from classpath.
(see https://java.net/projects/jawr/forums/discussion-forum/topics/74729-Is-JAWR-an-active-project-#p105196)



 Comments   
Comment by icefox [ 17/Jun/15 ]

This issue has been fixed in the master branch.

Comment by icefox [ 27/Aug/15 ]

The fix used doesn't handle every case.
The changes will be rolled back and the target for this fix will be set to 3.9





[JAWR-366] non gzip bundle not found if bundle.prefix defined Created: 26/Sep/15  Updated: 26/Sep/15

Status: Open
Project: jawr
Component/s: Jawr Core
Affects Version/s: 3.8
Fix Version/s: None

Type: Bug Priority: Major
Reporter: H.Schulz Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In ResourceBundlesHandlerImpl.getBundleHashcodeType(String requestedPath) the array generated by
String[] pathInfos = PathNormalizer
.extractBundleInfoFromPath(requestedPath);
contains wrong entries if bundle.prefix was defined in jawr.properties.

pathInfos[0] is null (should contain bundelPrefix)
pathInfos[1] contains "/145037411/all.css" instead of "/all.css"
pathInfos[2] conatins null (ok)
pathInfos[3] contains the bundelPrefix ("dtest2") instead of the hashCode "145037411"

If the request header contains accept-encoding (ok):
pathInfos[0] = "/test2/"
pathInfos[1] = "/all.css"
pathInfos[2] = null
pathInfos[3] = "145037411"

Without accept-encoding (404 error):
pathInfos[0] = null
pathInfos[1] = "/145037411/all.css"
pathInfos[2] = null
pathInfos[3] = "dtest2"

jawr.properties:
jawr.debug.on=false
jawr.gzip.on=true
jawr.gzip.ie6.on=false
jawr.charset.name=UTF-8
jawr.css.bundle.dtt.mappings=/css/test.css
jawr.css.bundle.dtest.global=false
jawr.css.bundle.dtest.composite=true
jawr.css.bundle.dtest.id=/all.css
jawr.css.bundle.dtest.child.names=dtt
jawr.css.bundle.dtest.bundle.prefix=/dtest2






[JAWR-362] Use JRuby sass compiler for Sass Generator Created: 10/Sep/15  Updated: 10/Sep/15

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: icefox Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The vaadin sass compiler, which is used by the Sass generator is behind in term of feature compared to the JRuby Sass compiler.

The goal of this improvement is to switch from the vaadin sass compiler to the JRuby one






[JAWR-371] Orphan less bnudle don't work in production mode Created: 10/Dec/15  Updated: 10/Dec/15

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: icefox Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This issue has been raised in the discussion forum

https://java.net/projects/jawr/forums/discussion-forum/topics/248782-Orphan-less-bundles#p251569






[JAWR-373] Clear RendererContext on forward Dispatch Created: 04/Jan/16  Updated: 04/Jan/16

Status: Open
Project: jawr
Component/s: None
Affects Version/s: 3.8
Fix Version/s: None

Type: Bug Priority: Major
Reporter: icefox Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This issue has been raised by dtrunk90 in a comment of JAWR-331






[JAWR-375] Jawr spring-extension doesn't work on Java 6 Created: 12/Jan/16  Updated: 12/Jan/16

Status: Open
Project: jawr
Component/s: None
Affects Version/s: 3.8
Fix Version/s: None

Type: Bug Priority: Major
Reporter: icefox Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 6



 Description   

There jawr-spring extension can't be used on java 6.
The issue has been raised from github ([issue #2https://github.com/ic3fox/jawr-spring/issues/2

java.lang.UnsupportedClassVersionError: net/jawr/web/servlet/JawrSpringController : Unsupported major.minor version 51.0 (unable to load class net.jawr.web.servlet.JawrSpringController)






[JAWR-379] Allow file post processing in debug mode Created: 23/Jan/16  Updated: 23/Jan/16

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: icefox Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A new requirement has been raised in the issue #16, which is the ability to define the file post processor which will be executed on a bundle in debug mode.

One way to do this is to provide a new bundle property which will store the file post processor to execute

For example :

jawr.js.bundle.mybundle.id=/myBudmle.js
jawr.js.bundle.mybundle.debug.file.postprocessors=processor1





[JAWR-378] Saas compiler is not working in websphere 8.5 Created: 23/Jan/16  Updated: 23/Jan/16

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: icefox Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The saas compiler is not working with websphere 8.5 in debug and in production mode.

This issue has been raised from github : issue #17






[JAWR-381] Issue with duplicate resource bundling Created: 02/Feb/16  Updated: 02/Feb/16

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: icefox Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Bundles are processed twice when it should just be processed once.

This issue has raised by diocerty which provide a pull request #17.






[JAWR-382] Issue with bundle preprocessing when configuration path contains space character Created: 03/Feb/16  Updated: 03/Feb/16

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: icefox Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This issue has been raised by zefling from github.
The pull request #25 has been proposed to fix this issue.






[JAWR-207] i18n: unit testing javascript when using "messages" Created: 13/Sep/11  Updated: 20/Sep/11

Status: Open
Project: jawr
Component/s: Jawr Core
Affects Version/s: None
Fix Version/s: None

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

Tags: javascript, message, resource, unit-testing

 Description   


Sorry if this is not the usual way to submit improvement ideas, I didn't know where else to go. Please move it to a more appropriate area if needed.


When using JAWR i18n, it generates the following javascript object:

function MyJsModule() {

    var text = messages.my.message(1, 2);

}

This means this javascript code is hard to unit test, unless the tests also define a global messages variable with the right nested objects.

  • Is there a way to control how JAWR generates the messages object to make it more test-friendly?
  • Could JAWR have an option to generate a messages function/module instead, that could easily be mocked when needed?

My current workaround is:

function getMessage() {
    var args = Array.prototype.slice.call(arguments);
    var messageId = args.shift();
    var messageFunc = window.messages;        
    messageId.split('.').forEach(function(part) {
        messageFunc = messageFunc[part];
    });
    return messageFunc(args);
}

This allows me to re-write the first code sample like this.

function MyJsModule(getMessage) {

    var text = getMessage('my.message', 1, 2);

}

Here the module is easily testable by injecting a stub getMessage function. However it seems strange to have to re-process an OGNL-like notation to find the right message every time. Could JAWR generate a hashmap of messages, and provide a function to access them? Something like

window.messages = {
    map: {
      'my.message': 'this is a message',
      'my.other.message': 'and another {0}',
    },
    get: function() {
      // get the right message and do the token processing
    }
}

Or are we missing an existing way to unit test JS code that uses window.messages?



 Comments   
Comment by icefox [ 20/Sep/11 ]

Hi Romain,

I think that the forum is the better place to post such thing.

Anyway, it's true that the Jawr messages are not easy to unit test in JS.
But Jawr allows you to define you own message generator.
You can define your own generator which generate the message as you like.
You can take a look to the following link to check how to create your own generator :
http://jawr.java.net/docs/generators.html

You can take a look to the net.jawr.web.resource.bundle.locale.ResourceBundleMessagesGenerator as an example of generator and also to
net.jawr.web.resource.bundle.locale.message.MessageBundleScriptCreator, which generates the javascript content.

Cheers,





[JAWR-190] JAWR & DWR2 when global = false Created: 01/Jun/11  Updated: 19/Jul/11

Status: Open
Project: jawr
Component/s: None
Affects Version/s: 3.3.3
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: leokom Assignee: icefox
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I'd like to use DWR not on all pages but only on some of them.
So I tried to set up
jawr.js.bundle.dwr.global = false

In this case pages that don't include DWR bundle, currently anyway include JAWR dwr initialization script like this:

<script type="text/javascript">if(!JAWR){var JAWR = {};};;JAWR.jawr_dwr_path='/dwr';JAWR.dwr_scriptSessionId='BE9A4806FB86454EFF2F7BA39244B080';JAWR.app_context_path='';</script>

Is it intended behaviour? /or configuration with DWR bundle global=false isn't supported?
Looks like DWR works fine on our main page in this case



 Comments   
Comment by icefox [ 14/Jul/11 ]

Hi,

In the current version of Jawr, the configuration property jawr.js.bundle.dwr.global is not supported.

How would you like it to work?
Is it an issue for you to have the initialisation script in your pages?

Cheers,

Comment by leokom [ 19/Jul/11 ]

1) Well, I expected if that flag=false, that should mean the initialization script will be included in 'lazy' way - only when first bundle that is dwr-related, is loaded on the page.

2) My task is to minify several pages to make them faster for customers with bad internet channel - that's why I'd prefer that init script would be absent (for sure it's not critical for me).





[JAWR-324] Hashing jars or directories Created: 30/Dec/14  Updated: 30/Dec/14

Status: Open
Project: jawr
Component/s: Jawr Core
Affects Version/s: 3.7
Fix Version/s: None

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


 Description   

Some JavaScript libs like ckeditor are loading additional JavaScript or CSS files relative to their own path. The approach of ckeditor is described here:

http://stackoverflow.com/questions/15301099/ckeditor-4-build-minify-and-uglify

With jawr a hash code is inserted into the URL as a path element. When the module tries to load a file relative to its own URL the hash code of the original file is still part of the newly created URL. The URL does not have a valid hash code.

There might be two ways to fix it:

1. Append the hash code to the filename, so instead of "/assets/js/cb12345678/script.js" you can add the hashcode to the filename like "/assets/js/script-cb12345678.js". This way the module is generating urls without a hashcode which is bad for caching. And thats what jawr is all about.

2. You can advise jawr to hash the complete jar or directory, so the hash code is not only valid for one file in this directory, but for all files in this jar or directory. Updating one file results in a new hash code for all files.

The generated URL would be just fine and can be cached aggressively.

This is just an idea. I don't yet know if it s wise to implement such a feature but I stumbled across this issue when integrating ckeditor with jawr.






[JAWR-369] Add semicolon between JavaScript files if necessary Created: 01/Oct/15  Updated: 01/Oct/15

Status: Open
Project: jawr
Component/s: Jawr Core
Affects Version/s: 3.8
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: H.Schulz Assignee: icefox
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Everything works fine in debug mode but on the server JavaScript didn't work.
I found out that i just had to add a semicolon at the end of one JavaScript file.
When you join two JavaScript files it can be necessary to insert a semicolon between them to keep the code valid.
It would be great if JAWR would do this automatically.

I think this is a realy mean problem because you may not realize that you have a serious bug online because everything works fine on your devoloper pc.






[JAWR-370] CDN fallback mechanism Created: 15/Oct/15  Updated: 22/Oct/15

Status: Open
Project: jawr
Component/s: Jawr Core
Affects Version/s: 3.9
Fix Version/s: None

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


 Description   

The goal is to allow the user to use CDNs in production mode but to provide a fallback mechanism to local libraries scripts if CDN are not available/reachable. Here is an use case:

Current configuration to use CDN in production:
```
jawr.js.bundle.jquery.id=/bundles/jquery.js
jawr.js.bundle.jquery.mappings=/libs/js/jquery/jquery-1.11.3.js
jawr.js.bundle.jquery.productionURL=//code.jquery.com/jquery-1.11.3.min.js

jawr.js.bundle.bootstrap.id=/bundles/bootstrap.js
jawr.js.bundle.bootstrap.dependencies=jquery
jawr.js.bundle.bootstrap.mappings=/libs/js/bootstrap/bootstrap.min.js
jawr.js.bundle.bootstrap.productionURL=//maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.min.js
```
```
<jwr:script src="/bundles/jquery.js"/>
<jwr:script src="/bundles/bootstrap.js"/>
```

Configuration with a fallback mechanism:
```
jawr.js.bundle.jquery.id=/bundles/jquery.js
jawr.js.bundle.jquery.mappings=/libs/js/jquery/jquery-1.11.3.js
jawr.js.bundle.jquery.productionURL=//code.jquery.com/jquery-1.11.3.min.js
jawr.js.bundle.jquery.fallback=/libs/js/jquery/jquery-1.11.3.min.js

jawr.js.bundle.bootstrap.id=/bundles/bootstrap.js
jawr.js.bundle.bootstrap.dependencies=jquery
jawr.js.bundle.bootstrap.mappings=/libs/js/bootstrap/bootstrap.js
jawr.js.bundle.bootstrap.productionURL=//maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.min.js
jawr.js.bundle.bootstrap.fallback=/libs/js/bootstrap/bootstrap.min.js
```
```
<jwr:script src="/bundles/jquery.js" fallback="typeof jQuery == undefined"/>
<jwr:script src="/bundles/bootstrap.js" fallback="typeof $.fn.Alert == undefined"/>
```

What must be done:

  • If a fallback resource is provided (jawr.js.bundle.bootstrap.fallback=/libs/js/bootstrap/bootstrap.min.js) and evaluating the fallback condition (fallback="typeof $.fn.Alert == undefined") jawr should return the local dependency or not
  • In debug mode no change, just use the standard mapping (jawr.js.bundle.bootstrap.mappings=/libs/js/bootstrap/bootstrap.js)
  • On top of that, a property to enable/disable CDN would be great (jawr.enable.cdn=true/false, if true use the mechanism describe else use the fallback resources without evaluating CDN or fallback conditions)

> This mechanism would be usefull when using CDNs where client may not be able to reach them for example in china.



 Comments   
Comment by icefox [ 22/Oct/15 ]

Hi,

Thanks for declaring this feature.
Don't hesitate to attach a patch, or to provide a pull request through github if you have one available.

Cheers,





[JAWR-383] Provide Spring Boot auto-configuration Created: 09/Feb/16  Updated: 10/Feb/16

Status: Open
Project: jawr
Component/s: None
Affects Version/s: None
Fix Version/s: None

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

Tags: spring, spring-boot

 Description   

It would be great if Jawr Spring Extension would provide a Spring Boot auto-configuration as described here: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-developing-auto-configuration.html



 Comments   
Comment by dtrunk90 [ 09/Feb/16 ]

Maybe adding these classes/files is enough:

src/main/resources/META-INF/spring.factories
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
net.jawr.web.autoconfigure.JawrAutoConfiguration
JawrAutoConfiguration.java
package net.jawr.web.autoconfigure;

import java.util.HashMap;
import java.util.Map;
import java.util.Properties;

import net.jawr.web.JawrConstant;
import net.jawr.web.servlet.JawrSpringController;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.autoconfigure.AutoConfigureAfter;
import org.springframework.boot.autoconfigure.condition.ConditionalOnClass;
import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean;
import org.springframework.boot.autoconfigure.web.WebMvcAutoConfiguration;
import org.springframework.boot.context.properties.EnableConfigurationProperties;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.DependsOn;
import org.springframework.web.servlet.HandlerMapping;
import org.springframework.web.servlet.handler.SimpleUrlHandlerMapping;

@Configuration
@EnableConfigurationProperties(JawrProperties.class)
@ConditionalOnClass(JawrSpringController.class)
@AutoConfigureAfter(WebMvcAutoConfiguration.class)
public class JawrAutoConfiguration {
	@Autowired
	private JawrProperties jawrProperties;

	@Bean
	public Properties jawrProperties() {
		Properties jawrProperties = new Properties();
		jawrProperties.putAll(this.jawrProperties.getJawr());
		return jawrProperties;
	}

	@Configuration
	@ConditionalOnMissingBean(name = "jawrBinaryController")
	public static class JawrBinaryControllerConfiguration {
		@Autowired
		private Properties jawrProperties;

		@Bean
		public JawrSpringController jawrBinaryController() {
			JawrSpringController jawrBinaryController = new JawrSpringController();
			jawrBinaryController.setConfiguration(jawrProperties);
			jawrBinaryController.setType(JawrConstant.BINARY_TYPE);
			return jawrBinaryController;
		}
	}

	@Configuration
	@ConditionalOnMissingBean(name = "jawrCssController")
	public static class JawrCssControllerConfiguration {
		@Autowired
		private Properties jawrProperties;

		@Bean
		@DependsOn("jawrBinaryController")
		public JawrSpringController jawrCssController() {
			JawrSpringController jawrCssController = new JawrSpringController();
			jawrCssController.setConfiguration(jawrProperties);
			jawrCssController.setType(JawrConstant.CSS_TYPE);
			return jawrCssController;
		}
	}

	@Configuration
	@ConditionalOnMissingBean(name = "jawrJsController")
	public static class JawrJsControllerConfiguration {
		@Autowired
		private Properties jawrProperties;

		@Bean
		public JawrSpringController jawrJsController() {
			JawrSpringController jawrJsController = new JawrSpringController();
			jawrJsController.setConfiguration(jawrProperties);
			jawrJsController.setType(JawrConstant.JS_TYPE);
			return jawrJsController;
		}
	}

	@Configuration
	@ConditionalOnMissingBean(name = "jawrHandlerMapping")
	public static class jawrHandlerMappingConfiguration {
		@Autowired
		private JawrSpringController jawrJsController;

		@Autowired
		private JawrSpringController jawrCssController;

		@Autowired
		private JawrSpringController jawrBinaryController;

		@Bean
		public HandlerMapping jawrHandlerMapping() {
			SimpleUrlHandlerMapping handlerMapping = new SimpleUrlHandlerMapping();
			Map<String, Object> urlMap = new HashMap<String, Object>();
			urlMap.put("/**/**.css", jawrCssController);
			urlMap.put("/**/**.eot", jawrBinaryController);
			urlMap.put("/**/**.gif", jawrBinaryController);
			urlMap.put("/**/**.ico", jawrBinaryController);
			urlMap.put("/**/**.jpg", jawrBinaryController);
			urlMap.put("/**/**.jpeg", jawrBinaryController);
			urlMap.put("/**/**.js", jawrJsController);
			urlMap.put("/**/**.png", jawrBinaryController);
			urlMap.put("/**/**.ttf", jawrBinaryController);
			urlMap.put("/**/**.woff", jawrBinaryController);
			handlerMapping.setUrlMap(urlMap);
			return handlerMapping;
		}
	}
}
JawrProperties.java
package net.jawr.web.autoconfigure;

import java.util.HashMap;
import java.util.Map;

import org.springframework.boot.context.properties.ConfigurationProperties;

@ConfigurationProperties
public class JawrProperties {
	private Map<String, String> jawr = new HashMap<String, String>();

	public Map<String, String> getJawr() {
		return jawr;
	}

	public void setJawr(Map<String, String> jawr) {
		this.jawr = jawr;
	}
}




Generated at Thu Feb 11 09:38:40 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.