Re: HTTP Caching in OFBiz
Hi Chinmay, thanks for your input! Just a brief thought: we have an Apache Webserver in front of every productive system, connected with the integrated OFBiz Tomcat through ajp. This allows fine grained configuration for the rendering of static resources, caches, compression, request redirects etc.. This might not cover all of your points but should be in mind. Best regards, Michael Am 04.12.19 um 13:09 schrieb Chinmay Patidar: Hi All, I wanted to bring attention to the handling of HTTP caching in OFBiz. We can segregate three different areas(possibly more) which involve the cache. These are listed below: 1. Cache Web resources in CMS. 2. View Rendering. 3. Request Redirects. Furthermore, details are listed down below which includes the current implementation, possible improvements, and other related information. *Cache Web resources in CMS* In CMS Events, cache headers are set as no-cache. This prevents the browsers to cache various web resources which are rendered using CMS. In my opinion, here is a scope of improvement needed. Possibly using the mimeType or by any other method, the system must be configured to cache the resources. *View Rendering* In the current system, a view can be configured so that it can't be cached. Also, in the absence of this configuration, the system is not setting any cache headers. It's up to the browser to handle it. *Request Redirects* Currently, there is no way to configure the cache of the requests being redirected. I am not sure whether this is the desired behavior. On research, I have found that browsers do cache such requests as well. But need more inputs on this. Summarizing the above, we can conclude that the current system is lacking adequate support for handling the cache headers. In existing implementation, few areas can be configured only to set no-cache. There is no mechanism to set the cache on them. The best practices regarding setting the cache headers can be determined and implemented. Also, I would like to have your thoughts on the appropriate ways of caching the request redirects. Kind Regards, Chinmay Patidar smime.p7s Description: S/MIME Cryptographic Signature
Re: OFBizDebug and OFBIZ-11302
Le 03/12/2019 à 20:06, Mathieu Lirzin a écrit : Jacques Le Roux writes: With OFBIZ-11302 Mathieu removed the ofbizDebug Gradle task, because "ofbiz --debug-jvm" can be used instead. This is now ‘gradlew "ofbiz" --debug-jvm’ with the --debug-jvm outside of the double quotes. g ofbiz --debug-jvm (no quotes at all) works on Windows (I use g as shortcut to gradlew) Yes that works with Bash too. But if you want to pass options to ofbiz you need to add the quotes in order for the gradle template tasks to match, like ‘gradlew "ofbiz --start" --debug-jvm’. IMHO the fact that someone like you which is a seasoned OFBiz contributor is getting confused by the syntax of the syntactic sugar provided by task templates is a strong sign we should*not* use this kind of obscure black magic and use the standard and*documented* ‘run’ task instead [1] which would read like the following: gradlew run --args="--start" --debug-jvm gradlew run --debug-jvm works also. I'd not like to complicate too much the syntax. For what purpose,a part maybe a theoretical one? Also now we need to differentiate gradlew from "gradlew build" because the last run check and not the 1st. Is that well documented, I mean the difference between the 2? Jacques
Re: Github PRs and Jira
Hello, > > > I guess that using existent Github should be ok for official pull > > request, if not, it's always ok to have and attached patch or > > other gitlab reference. > > You mean "Github reference" I guess ? > For this one a really mean gitlab reference like the nereide public gitlab project we already shared (one or two time) in the past :). Gil
HTTP Caching in OFBiz
Hi All, I wanted to bring attention to the handling of HTTP caching in OFBiz. We can segregate three different areas(possibly more) which involve the cache. These are listed below: 1. Cache Web resources in CMS. 2. View Rendering. 3. Request Redirects. Furthermore, details are listed down below which includes the current implementation, possible improvements, and other related information. *Cache Web resources in CMS* In CMS Events, cache headers are set as no-cache. This prevents the browsers to cache various web resources which are rendered using CMS. In my opinion, here is a scope of improvement needed. Possibly using the mimeType or by any other method, the system must be configured to cache the resources. *View Rendering* In the current system, a view can be configured so that it can't be cached. Also, in the absence of this configuration, the system is not setting any cache headers. It's up to the browser to handle it. *Request Redirects* Currently, there is no way to configure the cache of the requests being redirected. I am not sure whether this is the desired behavior. On research, I have found that browsers do cache such requests as well. But need more inputs on this. Summarizing the above, we can conclude that the current system is lacking adequate support for handling the cache headers. In existing implementation, few areas can be configured only to set no-cache. There is no mechanism to set the cache on them. The best practices regarding setting the cache headers can be determined and implemented. Also, I would like to have your thoughts on the appropriate ways of caching the request redirects. Kind Regards, Chinmay Patidar
Re: OFBizDebug and OFBIZ-11302
Jacques Le Roux writes: > Le 02/12/2019 à 18:18, Mathieu Lirzin a écrit : >> >> Jacques Le Roux writes: >> >>> With OFBIZ-11302 Mathieu removed the ofbizDebug Gradle task, because "ofbiz >>> --debug-jvm" can be used instead. >> This is now ‘gradlew "ofbiz" --debug-jvm’ with the --debug-jvm outside >> of the double quotes. > > g ofbiz --debug-jvm (no quotes at all) works on Windows (I use g as shortcut > to gradlew) Yes that works with Bash too. But if you want to pass options to ofbiz you need to add the quotes in order for the gradle template tasks to match, like ‘gradlew "ofbiz --start" --debug-jvm’. IMHO the fact that someone like you which is a seasoned OFBiz contributor is getting confused by the syntax of the syntactic sugar provided by task templates is a strong sign we should *not* use this kind of obscure black magic and use the standard and *documented* ‘run’ task instead [1] which would read like the following: gradlew run --args="--start" --debug-jvm [1] https://docs.gradle.org/current/userguide/application_plugin.html >> >>> I have no problem with this change, it's easy to remember. Though I >>> like the idea of having syntax sugar to easy remember commands, like >>> ofbizDebug and ofbizBackground >>> >>> BTW ofbizDebug still appears when you run "gradlew tasks". And don't we >>> lose the "" part? >> On my machine ‘gradlew tasks’ do not include ofbizDebug on trunk. > > Right, I must have tested before pulling or something > > So, if nobody is against this change, I'll create a new shortcut for the > whole command, et voilà :) Not a problem with me. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Github PRs and Jira
Hello, As far as I am concerned, I will never be enthousiastic regarding adopting yet another proprietary platform. Gil Portenseigne writes: > +1 to use gitlab features to work around code, that will help > collaboration. > > I don't know if there is an Apache alternative to get the features without > Microsoft. But having two official tools to get contribution is not desired. I agree that we should not have multiple workflow because contributing process is already complex enough to not add yet another option. I think that I we adopt Github workflow, we should abandon Jira. In term of ethics, we would just replace an evil proprietary software with another one, so I won't oppose. :-) > I guess that using existent Github should be ok for official pull > request, if not, it's always ok to have and attached patch or > other gitlab reference. You mean "Github reference" I guess ? > > Le 11:55 - mardi 03 déc., Jacques Le Roux a écrit : >> Le 03/12/2019 à 08:21, Jacopo Cappellato a écrit : >> > Now that we have migrated to Git, in my opinion we should really consider >> > to adopt the workflow based on PR as our primary method for accepting >> > contributions. I understand that it is a relevant change for the community, >> > but I also see many advantages and a more natural (for Git) workflow for >> > contributors and committers. Contributors would fork from the official repo >> > and would submit pull requests that the committers would merge into the >> > official branches. >> > >> I tend to agree, it's simple to merge and commit. We will still maybe need >> Jiras when discussions are needed, or in all cases to fill the blog monthly >> posts? >> >> I guess using Github (ie Microsoft :D) is not a problem for the community? >> >> Opinions are welcome >> >> Jacques >> -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
