[jira] [Comment Edited] (OFBIZ-5037) ControlServlet - Exception thrown for requests not defined by controller.xml
[
https://issues.apache.org/jira/browse/OFBIZ-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459382#comment-13459382
]
Jacques Le Roux edited comment on OFBIZ-5037 at 9/20/12 5:33 PM:
-
== TYPO ==
I don't see which if would be missing, maybe you missed it because I inlined?
{code}
-// still not found so stop
+// if no matching request is found in the controller, depending on
THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST
+// we throw a RequestHandlerException or
RequestHandlerExceptionAllowExternalRequests
if (requestMap == null) {
-throw new RequestHandlerException(requestMissingErrorMessage);
-}
+if (THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST)
throw new RequestHandlerException(requestMissingErrorMessage);
+else throw new RequestHandlerExceptionAllowExternalRequests();
+ }
{code}
Let me explain the solution:
THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST value (Boolean) is
defined following the throwRequestHandlerExceptionOnMissingLocalRequest
properties. THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST is used
when requestMap is null which is the case when no request-map is defined
(because it's an external request). At this point
THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST decides if you want to
throw a RequestHandlerException with a requestMissingErrorMessage or if you
want to continue with a possible external request. If you go the external
request way, you can't use return, else nothing will be rendered, you can't
also continue because you have no requestMap (though I tried but then your only
solution would be to use ConfigXMLReader.emptyNoneRequestResponse which leads
nowhere). So you have to use an exception to let the process continue. You also
need to feed an error page for a RequestDispatcher to be created and the
default error page to be included (used by RequestDispatcher.include()). Then
your external ControlServlet can handle the response just fine. As I said this
has beeen tested and works in both cases without side effects.
In the new patch I have just added this line
{code}
Debug.logInfo("Going to external page: " + request.getPathInfo(), module);
{code}
was (Author: jacques.le.roux):
I don't see which if would be missing, maybe you missed it because I
inlined?
{code}
-// still not found so stop
+// if no matching request is found in the controller, depending on
THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST
+// we throw a RequestHandlerException or
RequestHandlerExceptionAllowExternalRequests
if (requestMap == null) {
-throw new RequestHandlerException(requestMissingErrorMessage);
-}
+if (THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST)
throw new RequestHandlerException(requestMissingErrorMessage);
+else throw new RequestHandlerExceptionAllowExternalRequests();
+ }
{code}
Let me explain the solution:
THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST value (Boolean) is
defined following the throwRequestHandlerExceptionOnMissingLocalRequest
properties. THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST is used
when requestMap is null which is the case when no request-map is defined
(because it's an external request). At this point
THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST decides if you want to
throw a RequestHandlerException with a requestMissingErrorMessage or if you
want to continue with a possible external request. If you go the external
request way, you can't use return, else nothing will be rendered, you can't
also continue because you have no requestMap (though I tried but then your only
solution would be to use ConfigXMLReader.emptyNoneRequestResponse which leads
nowhere). So you have to use an exception to let the process continue. You also
need to feed an error page for a RequestDispatcher to be created and the
default error page to be included (used by RequestDispatcher.include()). Then
your external ControlServlet can handle the response just fine. As I said this
has beeen tested and works in both cases without side effect ;)
In the new patch I have just added this line
{code}
Debug.logInfo("Going to external page: " + request.getPathInfo(), module);
{code}
> ControlServlet - Exception thrown for requests not defined by controller.xml
>
>
> Key: OFBIZ-5037
> URL: https://issues.apache.org/jira/browse/OFBIZ-5037
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS
>Reporter: Paul Piper
>Assignee: Jacques Le Roux
>
[jira] [Updated] (OFBIZ-5037) ControlServlet - Exception thrown for requests not defined by controller.xml
[
https://issues.apache.org/jira/browse/OFBIZ-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-5037:
---
Attachment: OFBIZ-5037.patch
I don't see which if would be missing, maybe you missed it because I inlined?
{code}
-// still not found so stop
+// if no matching request is found in the controller, depending on
THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST
+// we throw a RequestHandlerException or
RequestHandlerExceptionAllowExternalRequests
if (requestMap == null) {
-throw new RequestHandlerException(requestMissingErrorMessage);
-}
+if (THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST)
throw new RequestHandlerException(requestMissingErrorMessage);
+else throw new RequestHandlerExceptionAllowExternalRequests();
+ }
{code}
Let me explain the solution:
THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST value (Boolean) is
defined following the throwRequestHandlerExceptionOnMissingLocalRequest
properties. THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST is used
when requestMap is null which is the case when no request-map is defined
(because it's an external request). At this point
THROW_REQUEST_HANDLER_EXCEPTION_ON_MISSING_LOCAL_REQUEST decides if you want to
throw a RequestHandlerException with a requestMissingErrorMessage or if you
want to continue with a possible external request. If you go the external
request way, you can't use return, else nothing will be rendered, you can't
also continue because you have no requestMap (though I tried but then your only
solution would be to use ConfigXMLReader.emptyNoneRequestResponse which leads
nowhere). So you have to use an exception to let the process continue. You also
need to feed an error page for a RequestDispatcher to be created and the
default error page to be included (used by RequestDispatcher.include()). Then
your external ControlServlet can handle the response just fine. As I said this
has beeen tested and works in both cases without side effect ;)
In the new patch I have just added this line
{code}
Debug.logInfo("Going to external page: " + request.getPathInfo(), module);
{code}
> ControlServlet - Exception thrown for requests not defined by controller.xml
>
>
> Key: OFBIZ-5037
> URL: https://issues.apache.org/jira/browse/OFBIZ-5037
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS
>Reporter: Paul Piper
>Assignee: Jacques Le Roux
>Priority: Trivial
> Labels: ControlServlet, exception, log
> Attachments: OFBIZ-5037.patch, OFBIZ-5037.patch
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> The current rendering within OFBiz expects the following setup:
> * Request is always submit against /control
> * /control will pickup the request and handle by ControlServlet
> * ControlServlet will check within controller.xml for an entry
> Because of it, the ControlServlet will intercept any request coming towards
> the application, except for requests that are mapped against similar servlets
> (/cms or alike). ControlServlet will throw an exception if no request is
> found and try to redirect towards an error page.
> The underlying assumption here is that ControlServlet is always in the lead
> for rendering pages, unless the internal CMS is used. This does not have to
> be the case, however, since in practice it is also possible for users to
> implement a replacing cms or other means for rendering the pages. In those
> cases ControlServlet will still throw an error, albeit the request may
> already have been handled by a wrapping system:
> {code}
> 2012-09-18 09:54:22,869 (http-0.0.0.0-8080-13) [ ControlServlet.java:141:INFO
> ] [[[fm1] Request Begun, encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
> 2012-09-18 09:54:22,870 (http-0.0.0.0-8080-13) [
> ControlServlet.java:227:ERROR] exception report
> -- Error in request
> handler: Exception: org.ofbiz.webapp.control.RequestHandlerException Message:
> Unknown request [fm1]; this request does not exist or cannot be called
> directly. stack trace
> ---
> org.ofbiz.webapp.control.RequestHandlerException: Unknown request [fm1]; this
> request does not exist or cannot be called directly.
> org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:146)
> org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:224)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> {code}
> Since this is a minor i
[jira] [Commented] (OFBIZ-5040) Widget & Application HTML clean-up
[ https://issues.apache.org/jira/browse/OFBIZ-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459379#comment-13459379 ] Deepak Dixit commented on OFBIZ-5040: - Paul could you please let us which pattern will use for widget rendering? First will have to decide the new pattern for widget rendering then will change the ftl and form widget macros to use that pattern. As per current pattern ofbiz using table for rendering the back-office. > Widget & Application HTML clean-up > -- > > Key: OFBIZ-5040 > URL: https://issues.apache.org/jira/browse/OFBIZ-5040 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Reporter: Paul Piper > Labels: html, webapp, widget, widgetrendering > > I am sure that this is a common thing to know: the current backoffice > application relies heavily on widgets. This is good, but the current > standard-html-structure is not flexible enough and often lacks proper w3c > implementation. > To make matters worse, you can often find applications avoiding widgets at > all and rather overriding the standards with custom ftl implementations. It > is these customizations that break the html on numerous screens and make it > difficult, if not tedious to create new themes for the backoffice. > This task is hence to: > * Find a consensus on a new widget standard > * Go over each of the application ftls and convert these to the new standard > * Recreate the themes and simplify/clean-up special rules > Since redoing the theme is a rather large task, we should consider to add an > additional css for now which stylises the replacement html instead of working > with the old. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-3993) Build and run in openjdk 1.6
[
https://issues.apache.org/jira/browse/OFBIZ-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459092#comment-13459092
]
Jacques Le Roux commented on OFBIZ-3993:
Thanks Christian!
> Build and run in openjdk 1.6
>
>
> Key: OFBIZ-3993
> URL: https://issues.apache.org/jira/browse/OFBIZ-3993
> Project: OFBiz
> Issue Type: Bug
>Affects Versions: Release Branch 10.04
> Environment: Fedora 10 + OpenJDK 1.6.0 (build 14.0-16) + OFBiz 10.04
>Reporter: Shi Yusen
>Assignee: Christian Geisert
> Fix For: Release Branch 10.04
>
> Attachments: ofbiz-10.04-openjdk1.6-patach.txt,
> ofbiz-11.04-openjdk1.6-patch.txt
>
>
> OFBiz cannot be built in OpenJDK 1.6.0 reported by f...@free.fr:
> build:
> [echo] [build] == Start Building Framework (Compile) ==
> .../...
> classes:
> [javac16] /srv/www/Ofbiz-10.04/common.xml:93: warning:
> 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set
> to false for repeatable builds
> [javac16] Compiling 55 source files to
> /srv/www/Ofbiz-10.04/applications/product/build/classes
> [javac16]
> /srv/www/Ofbiz-10.04/applications/product/src/org/ofbiz/product/product/ProductSearchSession.java:1231:
> cannot find symbol
> [javac16] symbol : method
> add(java.util.Map)
> [javac16] location: interface
> java.util.List>
> [javac16]
> featureCountList.add(UtilMisc.toMap("productFeatureId", (String)
> searchResult.get("pfacProductFeatureId"), "productFeatureTypeId", (String)
> searchResult.get("pfcProductFeatureTypeId"), "description", (String)
> searchResult.get("pfcDescription"), "featureCount", Long.toString((Long)
> searchResult.get("featureCount";
> [javac16] ^
> [javac16] 1 error
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OFBIZ-3993) Build and run in openjdk 1.6
[
https://issues.apache.org/jira/browse/OFBIZ-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux closed OFBIZ-3993.
--
Assignee: Christian Geisert
> Build and run in openjdk 1.6
>
>
> Key: OFBIZ-3993
> URL: https://issues.apache.org/jira/browse/OFBIZ-3993
> Project: OFBiz
> Issue Type: Bug
>Affects Versions: Release Branch 10.04
> Environment: Fedora 10 + OpenJDK 1.6.0 (build 14.0-16) + OFBiz 10.04
>Reporter: Shi Yusen
>Assignee: Christian Geisert
> Fix For: Release Branch 10.04
>
> Attachments: ofbiz-10.04-openjdk1.6-patach.txt,
> ofbiz-11.04-openjdk1.6-patch.txt
>
>
> OFBiz cannot be built in OpenJDK 1.6.0 reported by f...@free.fr:
> build:
> [echo] [build] == Start Building Framework (Compile) ==
> .../...
> classes:
> [javac16] /srv/www/Ofbiz-10.04/common.xml:93: warning:
> 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set
> to false for repeatable builds
> [javac16] Compiling 55 source files to
> /srv/www/Ofbiz-10.04/applications/product/build/classes
> [javac16]
> /srv/www/Ofbiz-10.04/applications/product/src/org/ofbiz/product/product/ProductSearchSession.java:1231:
> cannot find symbol
> [javac16] symbol : method
> add(java.util.Map)
> [javac16] location: interface
> java.util.List>
> [javac16]
> featureCountList.add(UtilMisc.toMap("productFeatureId", (String)
> searchResult.get("pfacProductFeatureId"), "productFeatureTypeId", (String)
> searchResult.get("pfcProductFeatureTypeId"), "description", (String)
> searchResult.get("pfcDescription"), "featureCount", Long.toString((Long)
> searchResult.get("featureCount";
> [javac16] ^
> [javac16] 1 error
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-5037) ControlServlet - Exception thrown for requests not defined by controller.xml
[
https://issues.apache.org/jira/browse/OFBIZ-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459032#comment-13459032
]
Paul Piper commented on OFBIZ-5037:
---
I think you are missing an if statement. You are adding a replacementexception
just fine (though I am not certain it is required here). Apart from that, you
also load the properties but don't seem to do anything with it, or am I missing
something?
> ControlServlet - Exception thrown for requests not defined by controller.xml
>
>
> Key: OFBIZ-5037
> URL: https://issues.apache.org/jira/browse/OFBIZ-5037
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS
>Reporter: Paul Piper
>Assignee: Jacques Le Roux
>Priority: Trivial
> Labels: ControlServlet, exception, log
> Attachments: OFBIZ-5037.patch
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> The current rendering within OFBiz expects the following setup:
> * Request is always submit against /control
> * /control will pickup the request and handle by ControlServlet
> * ControlServlet will check within controller.xml for an entry
> Because of it, the ControlServlet will intercept any request coming towards
> the application, except for requests that are mapped against similar servlets
> (/cms or alike). ControlServlet will throw an exception if no request is
> found and try to redirect towards an error page.
> The underlying assumption here is that ControlServlet is always in the lead
> for rendering pages, unless the internal CMS is used. This does not have to
> be the case, however, since in practice it is also possible for users to
> implement a replacing cms or other means for rendering the pages. In those
> cases ControlServlet will still throw an error, albeit the request may
> already have been handled by a wrapping system:
> {code}
> 2012-09-18 09:54:22,869 (http-0.0.0.0-8080-13) [ ControlServlet.java:141:INFO
> ] [[[fm1] Request Begun, encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
> 2012-09-18 09:54:22,870 (http-0.0.0.0-8080-13) [
> ControlServlet.java:227:ERROR] exception report
> -- Error in request
> handler: Exception: org.ofbiz.webapp.control.RequestHandlerException Message:
> Unknown request [fm1]; this request does not exist or cannot be called
> directly. stack trace
> ---
> org.ofbiz.webapp.control.RequestHandlerException: Unknown request [fm1]; this
> request does not exist or cannot be called directly.
> org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:146)
> org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:224)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> {code}
> Since this is a minor issue, I propose to remove the underlying exception and
> rather throw a warning instead. This would allow the users to extend the
> Servlet by their own means and yet allow the purpose to remain unchanged
> (clearly a logged message is wanted here). I will attach a patch to fix the
> issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OFBIZ-3993) Build and run in openjdk 1.6
[
https://issues.apache.org/jira/browse/OFBIZ-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Geisert resolved OFBIZ-3993.
--
Resolution: Fixed
Fix Version/s: Release Branch 10.04
> Build and run in openjdk 1.6
>
>
> Key: OFBIZ-3993
> URL: https://issues.apache.org/jira/browse/OFBIZ-3993
> Project: OFBiz
> Issue Type: Bug
>Affects Versions: Release Branch 10.04
> Environment: Fedora 10 + OpenJDK 1.6.0 (build 14.0-16) + OFBiz 10.04
>Reporter: Shi Yusen
> Fix For: Release Branch 10.04
>
> Attachments: ofbiz-10.04-openjdk1.6-patach.txt,
> ofbiz-11.04-openjdk1.6-patch.txt
>
>
> OFBiz cannot be built in OpenJDK 1.6.0 reported by f...@free.fr:
> build:
> [echo] [build] == Start Building Framework (Compile) ==
> .../...
> classes:
> [javac16] /srv/www/Ofbiz-10.04/common.xml:93: warning:
> 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set
> to false for repeatable builds
> [javac16] Compiling 55 source files to
> /srv/www/Ofbiz-10.04/applications/product/build/classes
> [javac16]
> /srv/www/Ofbiz-10.04/applications/product/src/org/ofbiz/product/product/ProductSearchSession.java:1231:
> cannot find symbol
> [javac16] symbol : method
> add(java.util.Map)
> [javac16] location: interface
> java.util.List>
> [javac16]
> featureCountList.add(UtilMisc.toMap("productFeatureId", (String)
> searchResult.get("pfacProductFeatureId"), "productFeatureTypeId", (String)
> searchResult.get("pfcProductFeatureTypeId"), "description", (String)
> searchResult.get("pfcDescription"), "featureCount", Long.toString((Long)
> searchResult.get("featureCount";
> [javac16] ^
> [javac16] 1 error
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-3993) Build and run in openjdk 1.6
[
https://issues.apache.org/jira/browse/OFBIZ-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458983#comment-13458983
]
Christian Geisert commented on OFBIZ-3993:
--
I just checked http://svn.apache.org/repos/asf/ofbiz/branches/release10.04
(Revision: 1387138) with
java version "1.6.0_24", OpenJDK Runtime Environment (IcedTea6 1.11.4)
(6b24-1.11.4-1ubuntu0.11.10.1)
and it did build and run the tests without problems
> Build and run in openjdk 1.6
>
>
> Key: OFBIZ-3993
> URL: https://issues.apache.org/jira/browse/OFBIZ-3993
> Project: OFBiz
> Issue Type: Bug
>Affects Versions: Release Branch 10.04
> Environment: Fedora 10 + OpenJDK 1.6.0 (build 14.0-16) + OFBiz 10.04
>Reporter: Shi Yusen
> Attachments: ofbiz-10.04-openjdk1.6-patach.txt,
> ofbiz-11.04-openjdk1.6-patch.txt
>
>
> OFBiz cannot be built in OpenJDK 1.6.0 reported by f...@free.fr:
> build:
> [echo] [build] == Start Building Framework (Compile) ==
> .../...
> classes:
> [javac16] /srv/www/Ofbiz-10.04/common.xml:93: warning:
> 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set
> to false for repeatable builds
> [javac16] Compiling 55 source files to
> /srv/www/Ofbiz-10.04/applications/product/build/classes
> [javac16]
> /srv/www/Ofbiz-10.04/applications/product/src/org/ofbiz/product/product/ProductSearchSession.java:1231:
> cannot find symbol
> [javac16] symbol : method
> add(java.util.Map)
> [javac16] location: interface
> java.util.List>
> [javac16]
> featureCountList.add(UtilMisc.toMap("productFeatureId", (String)
> searchResult.get("pfacProductFeatureId"), "productFeatureTypeId", (String)
> searchResult.get("pfcProductFeatureTypeId"), "description", (String)
> searchResult.get("pfcDescription"), "featureCount", Long.toString((Long)
> searchResult.get("featureCount";
> [javac16] ^
> [javac16] 1 error
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-5037) ControlServlet - Exception thrown for requests not defined by controller.xml
[
https://issues.apache.org/jira/browse/OFBIZ-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458917#comment-13458917
]
Jacques Le Roux commented on OFBIZ-5037:
Note: the solution is using a specific exception but does not log any errors.
Of course for this to work when using
throwRequestHandlerExceptionOnMissingLocalRequest=N you need to have the
external requests ready to handle the flow. Else you will simply get an error
in the browser but nothing in log, since it's supposed to be handled
externally. I think I will put a Debug.logInfo with the name of the external
request in the RequestHandlerExceptionAllowExternalRequests catch... later...
> ControlServlet - Exception thrown for requests not defined by controller.xml
>
>
> Key: OFBIZ-5037
> URL: https://issues.apache.org/jira/browse/OFBIZ-5037
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS
>Reporter: Paul Piper
>Assignee: Jacques Le Roux
>Priority: Trivial
> Labels: ControlServlet, exception, log
> Attachments: OFBIZ-5037.patch
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> The current rendering within OFBiz expects the following setup:
> * Request is always submit against /control
> * /control will pickup the request and handle by ControlServlet
> * ControlServlet will check within controller.xml for an entry
> Because of it, the ControlServlet will intercept any request coming towards
> the application, except for requests that are mapped against similar servlets
> (/cms or alike). ControlServlet will throw an exception if no request is
> found and try to redirect towards an error page.
> The underlying assumption here is that ControlServlet is always in the lead
> for rendering pages, unless the internal CMS is used. This does not have to
> be the case, however, since in practice it is also possible for users to
> implement a replacing cms or other means for rendering the pages. In those
> cases ControlServlet will still throw an error, albeit the request may
> already have been handled by a wrapping system:
> {code}
> 2012-09-18 09:54:22,869 (http-0.0.0.0-8080-13) [ ControlServlet.java:141:INFO
> ] [[[fm1] Request Begun, encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
> 2012-09-18 09:54:22,870 (http-0.0.0.0-8080-13) [
> ControlServlet.java:227:ERROR] exception report
> -- Error in request
> handler: Exception: org.ofbiz.webapp.control.RequestHandlerException Message:
> Unknown request [fm1]; this request does not exist or cannot be called
> directly. stack trace
> ---
> org.ofbiz.webapp.control.RequestHandlerException: Unknown request [fm1]; this
> request does not exist or cannot be called directly.
> org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:146)
> org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:224)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> {code}
> Since this is a minor issue, I propose to remove the underlying exception and
> rather throw a warning instead. This would allow the users to extend the
> Servlet by their own means and yet allow the purpose to remain unchanged
> (clearly a logged message is wanted here). I will attach a patch to fix the
> issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4946) Getting error when uploading a file after creating a data resource.
[ https://issues.apache.org/jira/browse/OFBIZ-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458913#comment-13458913 ] Jacques Le Roux commented on OFBIZ-4946: Who cares? > Getting error when uploading a file after creating a data resource. > --- > > Key: OFBIZ-4946 > URL: https://issues.apache.org/jira/browse/OFBIZ-4946 > Project: OFBiz > Issue Type: Bug > Components: content >Affects Versions: Release Branch 11.04, SVN trunk >Reporter: Ashish Ambulkar >Assignee: Jacques Le Roux > Attachments: OFBIZ-4946 labels.patch, OFBIZ-4946.patch, > OFBIZ-4946.patch, OFBIZ-4946.patch > > > Steps to generate error - > * Content -> DataResource -> Create New > Case 1 - > * Create a data resource of type '*_FILE' and remain objectInfo field empty. > * Then go to upload tab, here getting an error in the file preview section - > "java.lang.NullPointerException". > * Browse and upload a file. > - It throws an error - > "Error in Service [persistContentAndAssoc]: > org.ofbiz.service.GenericServiceException: Service [updateFile] target threw > an unexpected exception (null)". > Case 2 - > * While creating a data resource with non-empty objectInfo field. > * Then go to upload tab, here getting an error in the file preview section - > "org.ofbiz.webapp.view.ViewHandlerException: No file found". > * Browse and upload a file. > - It throws an error - > "Error in Service [updateFile]: Unable to open file for writing: > /home/.../xyz.pdf". > on upload, 'persistContentAndAssoc' service called which calls > 'persistDataResourceAndDataMethod'. This method then call 'createFile' or > 'updateFile' services after checking that data resource is already existed or > newly created. While the screen flow in OFBiz CMS is such that, you will get > an upload tab(to upload files) only after the creation of data resource. And > in this case 'updateFile' service called and gives error. > * Found that 'createFile' service also gives error - > "Error in Service [createFile]: Unable to obtain a reference to file". > The reason, I have found is that both services 'createFile' and 'updateFile' > gets the path as per the objectInfo specified, and then create/update a file > at that location. While creating a new data resource, how can anybody specify > the location at which file will place after uploading? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-5037) ControlServlet - Exception thrown for requests not defined by controller.xml
[
https://issues.apache.org/jira/browse/OFBIZ-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-5037:
---
Attachment: OFBIZ-5037.patch
Before committing, here is the solution I came with. It has been tested, but
please review.
> ControlServlet - Exception thrown for requests not defined by controller.xml
>
>
> Key: OFBIZ-5037
> URL: https://issues.apache.org/jira/browse/OFBIZ-5037
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS
>Reporter: Paul Piper
>Assignee: Jacques Le Roux
>Priority: Trivial
> Labels: ControlServlet, exception, log
> Attachments: OFBIZ-5037.patch
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> The current rendering within OFBiz expects the following setup:
> * Request is always submit against /control
> * /control will pickup the request and handle by ControlServlet
> * ControlServlet will check within controller.xml for an entry
> Because of it, the ControlServlet will intercept any request coming towards
> the application, except for requests that are mapped against similar servlets
> (/cms or alike). ControlServlet will throw an exception if no request is
> found and try to redirect towards an error page.
> The underlying assumption here is that ControlServlet is always in the lead
> for rendering pages, unless the internal CMS is used. This does not have to
> be the case, however, since in practice it is also possible for users to
> implement a replacing cms or other means for rendering the pages. In those
> cases ControlServlet will still throw an error, albeit the request may
> already have been handled by a wrapping system:
> {code}
> 2012-09-18 09:54:22,869 (http-0.0.0.0-8080-13) [ ControlServlet.java:141:INFO
> ] [[[fm1] Request Begun, encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
> 2012-09-18 09:54:22,870 (http-0.0.0.0-8080-13) [
> ControlServlet.java:227:ERROR] exception report
> -- Error in request
> handler: Exception: org.ofbiz.webapp.control.RequestHandlerException Message:
> Unknown request [fm1]; this request does not exist or cannot be called
> directly. stack trace
> ---
> org.ofbiz.webapp.control.RequestHandlerException: Unknown request [fm1]; this
> request does not exist or cannot be called directly.
> org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:146)
> org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:224)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> {code}
> Since this is a minor issue, I propose to remove the underlying exception and
> rather throw a warning instead. This would allow the users to extend the
> Servlet by their own means and yet allow the purpose to remain unchanged
> (clearly a logged message is wanted here). I will attach a patch to fix the
> issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OFBIZ-5040) Widget & Application HTML clean-up
[ https://issues.apache.org/jira/browse/OFBIZ-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458720#comment-13458720 ] Adrian Crum edited comment on OFBIZ-5040 at 9/20/12 1:31 AM: - Maybe a good start would be to just delete the deprecated styles from the style sheets - which will break the layout, and hopefully compel everyone to use the correct styles. As long as the deprecated styles can be found, someone will use them in new code. The FTL code you are referring to might be files that were never touched in the previous cleanup. So yes, fixing those files would be a worthwhile effort. was (Author: adri...@hlmksw.com): Maybe a good start would be to just delete the deprecated styles from the style sheets - which will break the layout, and hopefully compel everyone to use the correct styles. As long as the deprecated styles can be found, someone will use them in new code. > Widget & Application HTML clean-up > -- > > Key: OFBIZ-5040 > URL: https://issues.apache.org/jira/browse/OFBIZ-5040 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Reporter: Paul Piper > Labels: html, webapp, widget, widgetrendering > > I am sure that this is a common thing to know: the current backoffice > application relies heavily on widgets. This is good, but the current > standard-html-structure is not flexible enough and often lacks proper w3c > implementation. > To make matters worse, you can often find applications avoiding widgets at > all and rather overriding the standards with custom ftl implementations. It > is these customizations that break the html on numerous screens and make it > difficult, if not tedious to create new themes for the backoffice. > This task is hence to: > * Find a consensus on a new widget standard > * Go over each of the application ftls and convert these to the new standard > * Recreate the themes and simplify/clean-up special rules > Since redoing the theme is a rather large task, we should consider to add an > additional css for now which stylises the replacement html instead of working > with the old. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-5040) Widget & Application HTML clean-up
[ https://issues.apache.org/jira/browse/OFBIZ-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458720#comment-13458720 ] Adrian Crum commented on OFBIZ-5040: Maybe a good start would be to just delete the deprecated styles from the style sheets - which will break the layout, and hopefully compel everyone to use the correct styles. As long as the deprecated styles can be found, someone will use them in new code. > Widget & Application HTML clean-up > -- > > Key: OFBIZ-5040 > URL: https://issues.apache.org/jira/browse/OFBIZ-5040 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Reporter: Paul Piper > Labels: html, webapp, widget, widgetrendering > > I am sure that this is a common thing to know: the current backoffice > application relies heavily on widgets. This is good, but the current > standard-html-structure is not flexible enough and often lacks proper w3c > implementation. > To make matters worse, you can often find applications avoiding widgets at > all and rather overriding the standards with custom ftl implementations. It > is these customizations that break the html on numerous screens and make it > difficult, if not tedious to create new themes for the backoffice. > This task is hence to: > * Find a consensus on a new widget standard > * Go over each of the application ftls and convert these to the new standard > * Recreate the themes and simplify/clean-up special rules > Since redoing the theme is a rather large task, we should consider to add an > additional css for now which stylises the replacement html instead of working > with the old. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-5040) Widget & Application HTML clean-up
[ https://issues.apache.org/jira/browse/OFBIZ-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458716#comment-13458716 ] Paul Piper commented on OFBIZ-5040: --- Thanks for the feedback. Those are the ones that I am refering to. The biggest issue is that apps often introduce new html rather than rehashing the available. This is probably due to the fact that most are not really using the existing macros and rather reinvent everything, which makes it all the more difficult to work with. So my idea was to go over the application ftls at some point and reworking them to use the proper macros instead. Otherwise I fear that we will never get to fix this beast. > Widget & Application HTML clean-up > -- > > Key: OFBIZ-5040 > URL: https://issues.apache.org/jira/browse/OFBIZ-5040 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Reporter: Paul Piper > Labels: html, webapp, widget, widgetrendering > > I am sure that this is a common thing to know: the current backoffice > application relies heavily on widgets. This is good, but the current > standard-html-structure is not flexible enough and often lacks proper w3c > implementation. > To make matters worse, you can often find applications avoiding widgets at > all and rather overriding the standards with custom ftl implementations. It > is these customizations that break the html on numerous screens and make it > difficult, if not tedious to create new themes for the backoffice. > This task is hence to: > * Find a consensus on a new widget standard > * Go over each of the application ftls and convert these to the new standard > * Recreate the themes and simplify/clean-up special rules > Since redoing the theme is a rather large task, we should consider to add an > additional css for now which stylises the replacement html instead of working > with the old. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-5040) Widget & Application HTML clean-up
[ https://issues.apache.org/jira/browse/OFBIZ-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458711#comment-13458711 ] Adrian Crum commented on OFBIZ-5040: By the way, there are deprecated CSS styles still left over from the previous cleanup. Look in the Flat Grey theme, maincss.css file, line 1913. > Widget & Application HTML clean-up > -- > > Key: OFBIZ-5040 > URL: https://issues.apache.org/jira/browse/OFBIZ-5040 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Reporter: Paul Piper > Labels: html, webapp, widget, widgetrendering > > I am sure that this is a common thing to know: the current backoffice > application relies heavily on widgets. This is good, but the current > standard-html-structure is not flexible enough and often lacks proper w3c > implementation. > To make matters worse, you can often find applications avoiding widgets at > all and rather overriding the standards with custom ftl implementations. It > is these customizations that break the html on numerous screens and make it > difficult, if not tedious to create new themes for the backoffice. > This task is hence to: > * Find a consensus on a new widget standard > * Go over each of the application ftls and convert these to the new standard > * Recreate the themes and simplify/clean-up special rules > Since redoing the theme is a rather large task, we should consider to add an > additional css for now which stylises the replacement html instead of working > with the old. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-5040) Widget & Application HTML clean-up
[ https://issues.apache.org/jira/browse/OFBIZ-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458701#comment-13458701 ] Adrian Crum commented on OFBIZ-5040: This type of cleanup has been done before - around 2007. The current HTML structures and CSS styles were the result of that cleanup. New HTML structures and CSS styles are always welcome, and the success of the effort will depend on rallying support for them. For reference, here are the Wiki pages that describe the current widget markup: https://cwiki.apache.org/OFBADMIN/html-and-css-best-practices.html https://cwiki.apache.org/OFBIZ/ofbiz-maincsscss-html-element-collection-styles.html > Widget & Application HTML clean-up > -- > > Key: OFBIZ-5040 > URL: https://issues.apache.org/jira/browse/OFBIZ-5040 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Reporter: Paul Piper > Labels: html, webapp, widget, widgetrendering > > I am sure that this is a common thing to know: the current backoffice > application relies heavily on widgets. This is good, but the current > standard-html-structure is not flexible enough and often lacks proper w3c > implementation. > To make matters worse, you can often find applications avoiding widgets at > all and rather overriding the standards with custom ftl implementations. It > is these customizations that break the html on numerous screens and make it > difficult, if not tedious to create new themes for the backoffice. > This task is hence to: > * Find a consensus on a new widget standard > * Go over each of the application ftls and convert these to the new standard > * Recreate the themes and simplify/clean-up special rules > Since redoing the theme is a rather large task, we should consider to add an > additional css for now which stylises the replacement html instead of working > with the old. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-5040) Widget & Application HTML clean-up
Paul Piper created OFBIZ-5040: - Summary: Widget & Application HTML clean-up Key: OFBIZ-5040 URL: https://issues.apache.org/jira/browse/OFBIZ-5040 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Reporter: Paul Piper I am sure that this is a common thing to know: the current backoffice application relies heavily on widgets. This is good, but the current standard-html-structure is not flexible enough and often lacks proper w3c implementation. To make matters worse, you can often find applications avoiding widgets at all and rather overriding the standards with custom ftl implementations. It is these customizations that break the html on numerous screens and make it difficult, if not tedious to create new themes for the backoffice. This task is hence to: * Find a consensus on a new widget standard * Go over each of the application ftls and convert these to the new standard * Recreate the themes and simplify/clean-up special rules Since redoing the theme is a rather large task, we should consider to add an additional css for now which stylises the replacement html instead of working with the old. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Job Manager
Brett, Thank you for the update. I will look into this. -Adrian On 9/19/2012 6:02 AM, Brett Palmer wrote: Adrian, I'll have to setup a load test to verify that a large number of pending jobs in the JobSandbox do not saturate the server. I'll also work with the thread counts to see what works for us. Before I read your reply I had configured the service engine to use a "send-to-pool=poolX" but did not configure any "run-from-pool" names that matched "poolX". I then use the webtools interface to run a service. The default pool displayed was "poolX" in the form. I entered the service name and executed the service. The service ran but I didn't expect it to run because there wasn't a "send-to-pool" with a matching name. This functionality seems to disagree with what you said about "If you don't have a element somewhere, then jobs sent to the "pool" pool will not be serviced.", but maybe I am missing something. I'll post the results of my load test as soon as it is completed. Brett On Tue, Sep 18, 2012 at 2:38 AM, wrote: Quoting Brett Palmer : *Adrian, I ported our code over to the newest ofbiz trunk and tried out the changes for the new service engine. The changes that you made are working very well. I configured our server to use multiple pools and then scheduled various jobs to those pools. Servers that were not configured to service the pools left the jobs dormant and servers that were configured to service the new pools did so as expected. To be clear, that has always been the behavior of the Job Scheduler. I did not change that. These new changes will work for us in our production environment. Thanks for implementing them. I now need to work on tuning the configuration settings based on the particular jobs and the capacity of our servers. The changes were intended to prevent the Job Scheduler from saturating the server under heavy load. So, those are the results I would be interested in hearing about. I did have another question on the thread-pool configuration. Here is a sample configuration that I was using to do some of the testing. Is the “send-to-pool” attribute the default pool that is used by the service engine for any sync and async requests through the service engine API? Correct. Is there a relationship between the “send-to-pool” attribute and the “run-from-pool” names or are they independent of each other? For example, if I don't have a run-from-pool element with a name="pool" will the default "pool" still work? They are not related. If you don't have a element somewhere, then jobs sent to the "pool" pool will not be serviced. Thanks again for you work on the service engine. We really appreciate it. Let me know if you need more feedback on the new changes. Brett* snip
[jira] [Commented] (OFBIZ-5037) ControlServlet - Exception thrown for requests not defined by controller.xml
[
https://issues.apache.org/jira/browse/OFBIZ-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458484#comment-13458484
]
Jacques Le Roux commented on OFBIZ-5037:
I suggest to add a throwExceptionOnMissingLocalRequest properties in
general.properties which will continue with the current behaviour (throwing
exception) if true (by default). If false no exception will be raised and only
a warning and return will be used.
Hence no functional changes by default and possiblity to hide when using
external requests: best of both worlds :)
I will commit something in trunk later
> ControlServlet - Exception thrown for requests not defined by controller.xml
>
>
> Key: OFBIZ-5037
> URL: https://issues.apache.org/jira/browse/OFBIZ-5037
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS
>Reporter: Paul Piper
>Priority: Trivial
> Labels: ControlServlet, exception, log
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> The current rendering within OFBiz expects the following setup:
> * Request is always submit against /control
> * /control will pickup the request and handle by ControlServlet
> * ControlServlet will check within controller.xml for an entry
> Because of it, the ControlServlet will intercept any request coming towards
> the application, except for requests that are mapped against similar servlets
> (/cms or alike). ControlServlet will throw an exception if no request is
> found and try to redirect towards an error page.
> The underlying assumption here is that ControlServlet is always in the lead
> for rendering pages, unless the internal CMS is used. This does not have to
> be the case, however, since in practice it is also possible for users to
> implement a replacing cms or other means for rendering the pages. In those
> cases ControlServlet will still throw an error, albeit the request may
> already have been handled by a wrapping system:
> {code}
> 2012-09-18 09:54:22,869 (http-0.0.0.0-8080-13) [ ControlServlet.java:141:INFO
> ] [[[fm1] Request Begun, encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
> 2012-09-18 09:54:22,870 (http-0.0.0.0-8080-13) [
> ControlServlet.java:227:ERROR] exception report
> -- Error in request
> handler: Exception: org.ofbiz.webapp.control.RequestHandlerException Message:
> Unknown request [fm1]; this request does not exist or cannot be called
> directly. stack trace
> ---
> org.ofbiz.webapp.control.RequestHandlerException: Unknown request [fm1]; this
> request does not exist or cannot be called directly.
> org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:146)
> org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:224)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> {code}
> Since this is a minor issue, I propose to remove the underlying exception and
> rather throw a warning instead. This would allow the users to extend the
> Servlet by their own means and yet allow the purpose to remain unchanged
> (clearly a logged message is wanted here). I will attach a patch to fix the
> issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OFBIZ-5037) ControlServlet - Exception thrown for requests not defined by controller.xml
[
https://issues.apache.org/jira/browse/OFBIZ-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux reassigned OFBIZ-5037:
--
Assignee: Jacques Le Roux
> ControlServlet - Exception thrown for requests not defined by controller.xml
>
>
> Key: OFBIZ-5037
> URL: https://issues.apache.org/jira/browse/OFBIZ-5037
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS
>Reporter: Paul Piper
>Assignee: Jacques Le Roux
>Priority: Trivial
> Labels: ControlServlet, exception, log
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> The current rendering within OFBiz expects the following setup:
> * Request is always submit against /control
> * /control will pickup the request and handle by ControlServlet
> * ControlServlet will check within controller.xml for an entry
> Because of it, the ControlServlet will intercept any request coming towards
> the application, except for requests that are mapped against similar servlets
> (/cms or alike). ControlServlet will throw an exception if no request is
> found and try to redirect towards an error page.
> The underlying assumption here is that ControlServlet is always in the lead
> for rendering pages, unless the internal CMS is used. This does not have to
> be the case, however, since in practice it is also possible for users to
> implement a replacing cms or other means for rendering the pages. In those
> cases ControlServlet will still throw an error, albeit the request may
> already have been handled by a wrapping system:
> {code}
> 2012-09-18 09:54:22,869 (http-0.0.0.0-8080-13) [ ControlServlet.java:141:INFO
> ] [[[fm1] Request Begun, encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
> 2012-09-18 09:54:22,870 (http-0.0.0.0-8080-13) [
> ControlServlet.java:227:ERROR] exception report
> -- Error in request
> handler: Exception: org.ofbiz.webapp.control.RequestHandlerException Message:
> Unknown request [fm1]; this request does not exist or cannot be called
> directly. stack trace
> ---
> org.ofbiz.webapp.control.RequestHandlerException: Unknown request [fm1]; this
> request does not exist or cannot be called directly.
> org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:146)
> org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:224)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> {code}
> Since this is a minor issue, I propose to remove the underlying exception and
> rather throw a warning instead. This would allow the users to extend the
> Servlet by their own means and yet allow the purpose to remain unchanged
> (clearly a logged message is wanted here). I will attach a patch to fix the
> issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4041) Materialized views
[ https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458478#comment-13458478 ] Jacques Le Roux commented on OFBIZ-4041: Thanks Daniel, I think it's a very interesting feature, I wish I would have more time to work in it. This will come one day :) > Materialized views > -- > > Key: OFBIZ-4041 > URL: https://issues.apache.org/jira/browse/OFBIZ-4041 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: Marc Morin >Assignee: Jacques Le Roux > Attachments: OFBIZ-4041.patch, OFBIZ-4041-V2.patch > > > We make extensive use of view entities in our ofbiz application. We have > noticed that when there is a large dataset and under some complex views, the > query performance was not the best (not a index issue, just complex joins, > etc...). > With some commercial databases like Oracle, etc... we would have used > materialized view semantics available for these dbms, but we are using > PostgreSQL. > So, we have extended the entity layer in Ofbiz to perform the > materialization. This is pretty slick as all you need to do is the following: > ... > and the system will do the following: > - create a backing entity called "myView" that has the same fields as the view > - backing entity has all the indexes inherited from the component entities > - relations (fk,...) inherited from the component entities. > - perform all the ECA actions automatically on all entities used in the view > (direct members and nested members if case of view on views). (This is an > eager update strategy only). > So, the application doesn't change, it still accesses "myView", but now, it's > result is returned from the backing entity instead of the complex SQL > statement. > We're pretty excited about this feature!!! Really pushes Ofbiz framework to > next level and allows materialized views to be more broadly used on dbms that > don't naturally support it. > We are prepared to contribute this feature back to the community if desired. > A note of caution about it though we have added a visitor pattern to the > model entities and this feature makes use of it. It would need to come with > it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
