[jira] [Created] (OFBIZ-4243) Caching is used by org.ofbiz.webapp.control.ProtectViewWorker(line 68) for UserLoginAndProtectedView (since changeset r1075350), but the view has set never-cache=true
Caching is used by org.ofbiz.webapp.control.ProtectViewWorker(line 68) for UserLoginAndProtectedView (since changeset r1075350), but the view has set never-cache=true Key: OFBIZ-4243 URL: https://issues.apache.org/jira/browse/OFBIZ-4243 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Jonas Hoef In changeset r1075350, org.ofbiz.webapp.control.ProtectViewWorker was changed to use caching for UserLoginAndProtectedView (line 68), but the view has set never-cache=true Either, the view should allow caching, or caching should not be used when accessing the view. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4244) EditCategory.ftl is missing a screenlet-body-part showing the summery of an image-upload.
EditCategory.ftl is missing a screenlet-body-part showing the summery of an image-upload. --- Key: OFBIZ-4244 URL: https://issues.apache.org/jira/browse/OFBIZ-4244 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: SVN trunk Reporter: Andreas König Priority: Minor Fix For: SVN trunk Attachments: EditCategory_ftl.patch After uploading a product-category-image, you receive the result of the upload-process in a screenlet. Up to now, the screenlet has a div of the class screenlet-title-bar, but no screenlet-body. To be consitent and to ensure a clear rendering, we should have the result-message in a div of the class screenlet-body. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4244) EditCategory.ftl is missing a screenlet-body-part showing the summery of an image-upload.
[ https://issues.apache.org/jira/browse/OFBIZ-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas König updated OFBIZ-4244: - Attachment: EditCategory_ftl.patch The patch provides the changes to solve the described problem. EditCategory.ftl is missing a screenlet-body-part showing the summery of an image-upload. --- Key: OFBIZ-4244 URL: https://issues.apache.org/jira/browse/OFBIZ-4244 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: SVN trunk Reporter: Andreas König Priority: Minor Labels: category, image, patch, product, trunk Fix For: SVN trunk Attachments: EditCategory_ftl.patch After uploading a product-category-image, you receive the result of the upload-process in a screenlet. Up to now, the screenlet has a div of the class screenlet-title-bar, but no screenlet-body. To be consitent and to ensure a clear rendering, we should have the result-message in a div of the class screenlet-body. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4245) OFBiz generated WSDL are not WS-I Basic Profile compliant
OFBiz generated WSDL are not WS-I Basic Profile compliant - Key: OFBIZ-4245 URL: https://issues.apache.org/jira/browse/OFBIZ-4245 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0, Release Branch 10.04, SVN trunk Reporter: Jacques Le Roux Assignee: Jacques Le Roux Priority: Minor I think, as it has been already reported by Alexander Graf on user ML, it's related to http://www.ws-i.org/profiles/basicprofile-1.1.html#R2735, but this have to be checked... Following recommendations and example there should allow us to deliver WS-I Basic Profile compliant WSDLs. A temporary solution for clients using CXF underneath is to follow the [point 2 here|http://mail-archives.apache.org/mod_mbox/cxf-users/200901.mbox/%3c200901231332.03818.dk...@apache.org%3E] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: My vision for the OFBiz Framework
On Apr 4, 2011, at 11:06 PM, Sam Hamilton wrote: Hi David, Congats on the beta release! You were asking for feature requests and today I ran across a java framework called Play they have a few of things that might be interesting: - they get their framework to compile java sources directly and then hot-reloads the JVM [1] Taking a quick look at things I wonder if they are using Groovy to treat .java files as .groovy files. In Moqui the recommendation is to just use Groovy anytime you need a script for a service or other things. Of course, Moqui isn't so Java-centric as it seems like Play is, so runtime reloading during development is more of an inherent part of the framework and recommended tools as opposed to something that has to be added. - their logging seems to be very clear and would speed up bug finding [1] [2] Yes, that is interesting. In OFBiz this is a HUGE problem because there is so much use of the hideous log rethrow pattern which results in the same, or very similar, stack trace being logged half a dozen times. One thing I've noticed about the use of Groovy in Moqui is that they do a good job of putting locations of things like scriptlets (including screen actions, etc) in the stack trace. On the other hand, the stack traces are HUGE because of all of the groovy proxy calls and such, and I've thought about writing something to filter those out... just haven't done it yet. I agree trimming out redundant stuff from the stack trace would be helpful, in addition to avoiding the redundant stack traces. - they have a module repo to specify third party hosted module repos [3] I'd like to do this sooner or later with Moqui and list addons or plugins, plus a document about how to create them (I couldn't find a doc like that for Play, maybe I didn't look hard enough). That framework has various means of supporting this right now, but I like the idea of creating a page to list addons/plugins, even if it starts out empty... ;) -David [1] - http://www.playframework.org/documentation/1.1.1/overview [2] - http://www.playframework.org/documentation/1.1.1/usability#aBetterusabilityisnotjustfornormalpeoplea [3] - http://www.playframework.org/documentation/1.1.1/modules#repository Sam On 3 Apr 2011, at 12:57, David E Jones wrote: The Introduction to Moqui Framework document is now ready and available do download through SourceForge: https://sourceforge.net/projects/moqui/files/ This document is meant for application developers, ie for the same people who would use Moqui. It is 12 pages with 2 diagrams and should be a quick read, but describes where everything is in the framework and from a high level how to do various things. BTW, feedback on this document and on the framework itself would both be most helpful... -David On Apr 2, 2011, at 12:17 PM, David E Jones wrote: That is a good question. The best way to get an idea of how things would look is to look at the example component (in runtime/component/example), the configuration files (default: framework/api/conf-default/MoquiDefaultConf.xml, environment-specific: runtime/conf/...), and the interface definitions for the API (framework/api/src/org/moqui/...). I'm working on a document now that describes the different parts of the framework and how the API is organized (Introduction to Moqui Framework) and hopefully I'll have that posted this weekend. -David On Apr 2, 2011, at 11:22 AM, Brett Palmer wrote: David, We are interested in this project. Let us know the best way to start playing with the framework and see how we could use it. We do a lot of custom applications and moqui sounds like a framework that could be used for this. Thanks again for your efforts. Brett On Sat, Apr 2, 2011 at 12:09 AM, David E Jones d...@me.com wrote: I still don't know if or how all of this will turn out, but here is the latest on the changes I've been wanting to make in the OFBiz Framework, but gave up on doing directly in OFBiz about a year and a half ago. The redesigned framework is a separate project that is now in beta (I just did the release today): http://www.moqui.org/ The Moqui Framework is now feature-complete for the planned feature set of the 1.0 version. There are details about this in the release notes, including everything in this release and the previous 3 releases, plus a list of features not to be included in 1.0. At this point the framework is far enough along that it is a clear demonstration of the changes that I would like to see in OFBiz, but that are difficult to do in a project with such a mature community and a large set of software that depends on it. Some of the main things are how the security and authorization are done, how the API is organized, the separation between framework and non-framework runtime artifacts, the deployment model (described in detail in the
Re: My vision for the OFBiz Framework
Hi David, I downloaded the beta and seen a great work! Looks like we will have soon a very good option to the actual OFBiz framework to think about. BTW, I couldn't find any implementation or plans regarding a portal/portlet feature. Will the moqui framework include this, or what? Regards, Bruno 2011/4/5 David E Jones d...@me.com On Apr 4, 2011, at 11:06 PM, Sam Hamilton wrote: Hi David, Congats on the beta release! You were asking for feature requests and today I ran across a java framework called Play they have a few of things that might be interesting: - they get their framework to compile java sources directly and then hot-reloads the JVM [1] Taking a quick look at things I wonder if they are using Groovy to treat .java files as .groovy files. In Moqui the recommendation is to just use Groovy anytime you need a script for a service or other things. Of course, Moqui isn't so Java-centric as it seems like Play is, so runtime reloading during development is more of an inherent part of the framework and recommended tools as opposed to something that has to be added. - their logging seems to be very clear and would speed up bug finding [1] [2] Yes, that is interesting. In OFBiz this is a HUGE problem because there is so much use of the hideous log rethrow pattern which results in the same, or very similar, stack trace being logged half a dozen times. One thing I've noticed about the use of Groovy in Moqui is that they do a good job of putting locations of things like scriptlets (including screen actions, etc) in the stack trace. On the other hand, the stack traces are HUGE because of all of the groovy proxy calls and such, and I've thought about writing something to filter those out... just haven't done it yet. I agree trimming out redundant stuff from the stack trace would be helpful, in addition to avoiding the redundant stack traces. - they have a module repo to specify third party hosted module repos [3] I'd like to do this sooner or later with Moqui and list addons or plugins, plus a document about how to create them (I couldn't find a doc like that for Play, maybe I didn't look hard enough). That framework has various means of supporting this right now, but I like the idea of creating a page to list addons/plugins, even if it starts out empty... ;) -David [1] - http://www.playframework.org/documentation/1.1.1/overview [2] - http://www.playframework.org/documentation/1.1.1/usability#aBetterusabilityisnotjustfornormalpeoplea [3] - http://www.playframework.org/documentation/1.1.1/modules#repository Sam On 3 Apr 2011, at 12:57, David E Jones wrote: The Introduction to Moqui Framework document is now ready and available do download through SourceForge: https://sourceforge.net/projects/moqui/files/ This document is meant for application developers, ie for the same people who would use Moqui. It is 12 pages with 2 diagrams and should be a quick read, but describes where everything is in the framework and from a high level how to do various things. BTW, feedback on this document and on the framework itself would both be most helpful... -David On Apr 2, 2011, at 12:17 PM, David E Jones wrote: That is a good question. The best way to get an idea of how things would look is to look at the example component (in runtime/component/example), the configuration files (default: framework/api/conf-default/MoquiDefaultConf.xml, environment-specific: runtime/conf/...), and the interface definitions for the API (framework/api/src/org/moqui/...). I'm working on a document now that describes the different parts of the framework and how the API is organized (Introduction to Moqui Framework) and hopefully I'll have that posted this weekend. -David On Apr 2, 2011, at 11:22 AM, Brett Palmer wrote: David, We are interested in this project. Let us know the best way to start playing with the framework and see how we could use it. We do a lot of custom applications and moqui sounds like a framework that could be used for this. Thanks again for your efforts. Brett On Sat, Apr 2, 2011 at 12:09 AM, David E Jones d...@me.com wrote: I still don't know if or how all of this will turn out, but here is the latest on the changes I've been wanting to make in the OFBiz Framework, but gave up on doing directly in OFBiz about a year and a half ago. The redesigned framework is a separate project that is now in beta (I just did the release today): http://www.moqui.org/ The Moqui Framework is now feature-complete for the planned feature set of the 1.0 version. There are details about this in the release notes, including everything in this release and the previous 3 releases, plus a list of features not to be included in 1.0. At this point the framework is far enough along that it is a clear demonstration of the changes that I would like
