[jira] [Created] (OFBIZ-4276) ProductWorker#getSelectableProductFeaturesByTypesAndSeq() returns duplicate entries
ProductWorker#getSelectableProductFeaturesByTypesAndSeq() returns duplicate
entries
---
Key: OFBIZ-4276
URL: https://issues.apache.org/jira/browse/OFBIZ-4276
Project: OFBiz
Issue Type: Bug
Components: product
Affects Versions: SVN trunk
Reporter: Rene Scheibe
Priority: Minor
Calling ProductWorker#getSelectableProductFeaturesByTypesAndSeq() returns
duplicate entries.
Example:
A virtual product with 2 variants:
* variant 1 features
** COLOR: blau
** SIZE: XXL
** MATERIAL: Holz
* variant 2 features:
** COLOR: rot
** SIZE: L
** MATERIAL: Stahl
Actual output:
{code}
{
{{productFeatureTypeId=COLOR, description=Farbbezeichnung},
{productFeatureId=COLOR_BLAU, description=blau}, {productFeatureId=COLOR_ROT,
description=rot}},
{{productFeatureTypeId=COLOR, description=Farbbezeichnung},
{productFeatureId=COLOR_BLAU, description=blau}, {productFeatureId=COLOR_ROT,
description=rot}},
{{productFeatureTypeId=COLOR, description=Farbbezeichnung},
{productFeatureId=COLOR_BLAU, description=blau}, {productFeatureId=COLOR_ROT,
description=rot}},
{{productFeatureTypeId=SIZE, description=Größe}, {productFeatureId=SIZE_XXL,
description=XXL}, {productFeatureId=SIZE_L, description=L}},
{{productFeatureTypeId=SIZE, description=Größe}, {productFeatureId=SIZE_XXL,
description=XXL}, {productFeatureId=SIZE_L, description=L}}
{{productFeatureTypeId=SIZE, description=Größe}, {productFeatureId=SIZE_XXL,
description=XXL}, {productFeatureId=SIZE_L, description=L}},
{{productFeatureTypeId=MATERIAL, description=Material},
{productFeatureId=MATERIAL_HOLZ, description=Holz},
{productFeatureId=MATERIAL_STAHL, description=Stahl}},
{{productFeatureTypeId=MATERIAL, description=Material},
{productFeatureId=MATERIAL_HOLZ, description=Holz},
{productFeatureId=MATERIAL_STAHL, description=Stahl}}
}
{code}
Expected output:
{code}
{
{{productFeatureTypeId=COLOR, description=Farbbezeichnung},
{productFeatureId=COLOR_BLAU, description=blau}, {productFeatureId=COLOR_ROT,
description=rot}},
{{productFeatureTypeId=SIZE, description=Größe}, {productFeatureId=SIZE_XXL,
description=XXL}, {productFeatureId=SIZE_L, description=L}},
{{productFeatureTypeId=MATERIAL, description=Material},
{productFeatureId=MATERIAL_HOLZ, description=Holz},
{productFeatureId=MATERIAL_STAHL, description=Stahl}}
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4276) ProductWorker#getSelectableProductFeaturesByTypesAndSeq() returns duplicate entries
[
https://issues.apache.org/jira/browse/OFBIZ-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Scheibe updated OFBIZ-4276:
Attachment: OFBIZ-4276_ProductWorker.patch
Patch: Moved a statement out of a for loop to the correct place.
> ProductWorker#getSelectableProductFeaturesByTypesAndSeq() returns duplicate
> entries
> ---
>
> Key: OFBIZ-4276
> URL: https://issues.apache.org/jira/browse/OFBIZ-4276
> Project: OFBiz
> Issue Type: Bug
> Components: product
>Affects Versions: SVN trunk
>Reporter: Rene Scheibe
>Priority: Minor
> Attachments: OFBIZ-4276_ProductWorker.patch
>
>
> Calling ProductWorker#getSelectableProductFeaturesByTypesAndSeq() returns
> duplicate entries.
> Example:
> A virtual product with 2 variants:
> * variant 1 features
> ** COLOR: blau
> ** SIZE: XXL
> ** MATERIAL: Holz
> * variant 2 features:
> ** COLOR: rot
> ** SIZE: L
> ** MATERIAL: Stahl
> Actual output:
> {code}
> {
> {{productFeatureTypeId=COLOR, description=Farbbezeichnung},
> {productFeatureId=COLOR_BLAU, description=blau}, {productFeatureId=COLOR_ROT,
> description=rot}},
> {{productFeatureTypeId=COLOR, description=Farbbezeichnung},
> {productFeatureId=COLOR_BLAU, description=blau}, {productFeatureId=COLOR_ROT,
> description=rot}},
> {{productFeatureTypeId=COLOR, description=Farbbezeichnung},
> {productFeatureId=COLOR_BLAU, description=blau}, {productFeatureId=COLOR_ROT,
> description=rot}},
> {{productFeatureTypeId=SIZE, description=Größe},
> {productFeatureId=SIZE_XXL, description=XXL}, {productFeatureId=SIZE_L,
> description=L}},
> {{productFeatureTypeId=SIZE, description=Größe},
> {productFeatureId=SIZE_XXL, description=XXL}, {productFeatureId=SIZE_L,
> description=L}}
> {{productFeatureTypeId=SIZE, description=Größe},
> {productFeatureId=SIZE_XXL, description=XXL}, {productFeatureId=SIZE_L,
> description=L}},
> {{productFeatureTypeId=MATERIAL, description=Material},
> {productFeatureId=MATERIAL_HOLZ, description=Holz},
> {productFeatureId=MATERIAL_STAHL, description=Stahl}},
> {{productFeatureTypeId=MATERIAL, description=Material},
> {productFeatureId=MATERIAL_HOLZ, description=Holz},
> {productFeatureId=MATERIAL_STAHL, description=Stahl}}
> }
> {code}
> Expected output:
> {code}
> {
> {{productFeatureTypeId=COLOR, description=Farbbezeichnung},
> {productFeatureId=COLOR_BLAU, description=blau}, {productFeatureId=COLOR_ROT,
> description=rot}},
> {{productFeatureTypeId=SIZE, description=Größe},
> {productFeatureId=SIZE_XXL, description=XXL}, {productFeatureId=SIZE_L,
> description=L}},
> {{productFeatureTypeId=MATERIAL, description=Material},
> {productFeatureId=MATERIAL_HOLZ, description=Holz},
> {productFeatureId=MATERIAL_STAHL, description=Stahl}}
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4277) Performance : In TransactionUtil StackTrace begining tracing should not be enabled by default
Performance : In TransactionUtil StackTrace begining tracing should not be enabled by default - Key: OFBIZ-4277 URL: https://issues.apache.org/jira/browse/OFBIZ-4277 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Hello, Currently, TransactionUtil creates a new Exception() to trace start of a transaction + all associated mechanism in suspend. This has a big CPU cost in heavy load, I think this should be an option disabled by default and that can be enabled through dynadmin. Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Search Products in webpos
Hi hmalovekar, please ask further OFBiz usage question in the user list. This is one of the areas in webpos that needs to be improved before use. The reason for the slow response I believe is due to the fact that it searches all the product in the system, i.e. there is no filtering by store, catalog, category... Also this exposes products that are not supposed the displayed to the user (expired products, configurable product components...). Another thing to fix is restrict the number of results returned in the response, as currently it returns all of the found products. Bilgin Ibryam On Tue, May 10, 2011 at 8:26 AM, hmalovekar wrote: > > in Webpos Main Screen > search products say by product name it is very Slow > i must wait about 1 minute then i start writing to make autocomplete > > how can i make it operate faster? > > > -- > View this message in context: > http://ofbiz.135035.n4.nabble.com/Search-Products-in-webpos-tp3511179p3511179.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. >
[jira] [Created] (OFBIZ-4278) ModelScreen does not rollback transaction when ScreenRenderException occurs
ModelScreen does not rollback transaction when ScreenRenderException occurs --- Key: OFBIZ-4278 URL: https://issues.apache.org/jira/browse/OFBIZ-4278 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Hello, Is there any reason why ModelScreen#renderScreenString() does not call TransactionUtil#rollback when ScreenRenderException occurs. It does so when Exception or RuntimeException occur. Furthermore, what's the point in duplicating code for Exception and RuntimeException ? As I am not sure if there is a reason , I ask, if you confirm it is useless I will provide a patch. Regards Philippe -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4279) Inevitable InvocationTarget exception in JmsQueueListener.init<>()
Inevitable InvocationTarget exception in JmsQueueListener.init<>()
--
Key: OFBIZ-4279
URL: https://issues.apache.org/jira/browse/OFBIZ-4279
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Ilya A. Pimenov
Priority: Critical
First call in the constructor refers to
super(dispatcher);
which is:
protected AbstractJmsListener(ServiceDispatcher serviceDispatcher) {
this.dispatcher = GenericDispatcher.getLocalDispatcher("JMSDispatcher",
null, null, this.getClass().getClassLoader(), serviceDispatcher);
}
And in GenericDispatcher you can see:
public static LocalDispatcher getLocalDispatcher(String dispatcherName,
Delegator delegator, Collection readerURLs, ClassLoader loader,
ServiceDispatcher serviceDispatcher) {
if (dispatcherName == null) {
dispatcherName = "default";
Debug.logWarning("Got a getGenericDispatcher call with a null
dispatcherName, assuming default for the name.", module);
}
//NB! This line will obviosly fail with "NullPointer" on delegator
if (UtilValidate.isNotEmpty(delegator.getDelegatorTenantId())) {
dispatcherName += "#" + delegator.getDelegatorTenantId();
}
So, It will always result in InvocationTargetException.
Replacing AbstractJmsListener constructor with this:
--
protected AbstractJmsListener(ServiceDispatcher serviceDispatcher) {
this.dispatcher = GenericDispatcher.getLocalDispatcher("JMSDispatcher",
serviceDispatcher.getDelegator(), null, this.getClass().getClassLoader(),
serviceDispatcher);
}
--
Will do the trick.
Since this bug blocks implementing JMS-service, I believe it is atleast
critical; since there is a workaround, but it's not very nice one.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4280) Obsolete code in GenericDispatcher, which leads to NullPointer when such Dispatcher was not created earlier
Obsolete code in GenericDispatcher, which leads to NullPointer when such
Dispatcher was not created earlier
---
Key: OFBIZ-4280
URL: https://issues.apache.org/jira/browse/OFBIZ-4280
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Ilya A. Pimenov
Priority: Critical
Please consider this method getLocalDispatcher(String.class, Delegator.class,
Collection.class, ClassLoader.class, ServiceDispatcher.class).
And take a look at this piece of code:
--
ServiceDispatcher sd = serviceDispatcher != null ?
serviceDispatcher : ServiceDispatcher.getInstance(dispatcherName, delegator);
LocalDispatcher thisDispatcher = null;
if (sd != null) {
dispatcher = sd.getLocalDispatcher(dispatcherName);
}
if (thisDispatcher == null) {
dispatcher = new GenericDispatcher(dispatcherName,
delegator, readerURLs, loader, sd);
}
--
The if-block "if (sd != null)" is obsolete, since thisDispatcher will always be
null in if-block "if (thisDispatcher == null)". But due to
sd.getLocalDispatcher(dispatcherName) implementation:
--
return localContext.get(name).getDispatcher();
--
It may cause NullPointer exception, whenever localContext.get(name) returns
null. For example this happens in case of using default JmsQueueListener
implementation, while implementing jms-service in OFBiz-way.
Just removing the if-block
--
if (sd != null) {
dispatcher = sd.getLocalDispatcher(dispatcherName);
}
--
Will fix the problem.
Since this bug blocks implementing JMS-service, I believe it is atleast
critical; since there is a workaround, but it's not very nice one.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
CompressHTML buffer
Hi, By default Freemarker StandardCompress is using a 2KB buffer. I'd like to increase to 10K. Note: this is not used OOTB, compressHTML being false in all web.xml by default To clean things a bit, I'd like also to remove the related commented out compress.HTML properties in widget.properties (I did not unsderstand "example screen.compress", seems deprecated) Agreed? (No answer being an agreement) Jacques
Freemarker update
Hi, It's a while we did not update Freemarker. We use version 2.3.10 (2007-04-20), soon (16th of May) 2.3.17 will be released with some interesting features and numerous bug fixes. http://freemarker.org/docs-rc/versions_2_3_11.html (?c) only used in geolocation.ftl, I don't expect much problems there Interesting: A new model interface, TemplateDirectiveModel provides an easier paradigm for implementing user-defined directives than TemplateTransformModel did previously. TemplateTransformModel will be deprecated. So should still work, cases could be updated, and easier way to do it now http://freemarker.org/docs-rc/versions_2_3_12.html In the templates, now you can conveniently call Java methods that use the Java 5 varargs feature (variable-length argument lists). http://freemarker.org/docs-rc/versions_2_3_13.html New built-ins for rounding numbers: round, floor, ceiling. Reworked template caching mechanism for radically improved concurrent performance (Achieved 20x speedup) http://freemarker.org/docs-rc/versions_2_3_14.html New built-in: xhtml http://freemarker.org/docs-rc/versions_2_3_17rc1.html ?seq_index_of and ?seq_last_index_of now works on collections ?long now works for date, date-time and time values, and returns the milliseconds since the epoch (as java.util.Date.getTime()). New special variable, now. This returns the current date-time. ?sort and ?sort_by now supports sorting boolean values. FreeMarker now can log its messages directly using SLF4J or Apache Commons Logging. So I'd like to update soon using 2.3.17. Someone is currently testing the RC1 in a custome application (based on OFBiz of course) Jacques
Re: Freemarker update
Sorry I completly forgot about it but had a doubt in mind, that's why I send a message before doing anything In http://markmail.org/message/uswj4i54iczwothh you suggested some possible progresses I guess related to http://svn.apache.org/viewvc?view=revision&revision=986577 I'd not prefer to stay forever stuck with 2.3.10 when everybody is going ahead. Someone I know which needs to works on an OFBIz based CMS is investigating. Maybe we could share the efforts? Jacques From: "Hans Bakker" remember that the new version was slowing down the ecommerce significantly On Wed, 2011-05-11 at 14:15 +0200, Jacques Le Roux wrote: Hi, It's a while we did not update Freemarker. We use version 2.3.10 (2007-04-20), soon (16th of May) 2.3.17 will be released with some interesting features and numerous bug fixes. http://freemarker.org/docs-rc/versions_2_3_11.html (?c) only used in geolocation.ftl, I don't expect much problems there Interesting: A new model interface, TemplateDirectiveModel provides an easier paradigm for implementing user-defined directives than TemplateTransformModel did previously. TemplateTransformModel will be deprecated. So should still work, cases could be updated, and easier way to do it now http://freemarker.org/docs-rc/versions_2_3_12.html In the templates, now you can conveniently call Java methods that use the Java 5 varargs feature (variable-length argument lists). http://freemarker.org/docs-rc/versions_2_3_13.html New built-ins for rounding numbers: round, floor, ceiling. Reworked template caching mechanism for radically improved concurrent performance (Achieved 20x speedup) http://freemarker.org/docs-rc/versions_2_3_14.html New built-in: xhtml http://freemarker.org/docs-rc/versions_2_3_17rc1.html ?seq_index_of and ?seq_last_index_of now works on collections ?long now works for date, date-time and time values, and returns the milliseconds since the epoch (as java.util.Date.getTime()). New special variable, now. This returns the current date-time. ?sort and ?sort_by now supports sorting boolean values. FreeMarker now can log its messages directly using SLF4J or Apache Commons Logging. So I'd like to update soon using 2.3.17. Someone is currently testing the RC1 in a custome application (based on OFBiz of course) Jacques -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates.
Re: Freemarker update
Hans, BTW inr986577 you said <>. Could you be more specific and explain a bit the issues you crossed, only those in http://markmail.org/message/ppie7riv2i3cwlku ? Also it seems there have been several bug fixes between 15 and 17RC1, I think it's worth trying this new version, could you give it a try? I'd like to have Scott's opininon also because he wrote the directive https://fisheye6.atlassian.com/changelog/ofbiz?cs=956484 Thanks Jacques From: "Jacques Le Roux" Sorry I completly forgot about it but had a doubt in mind, that's why I send a message before doing anything In http://markmail.org/message/uswj4i54iczwothh you suggested some possible progresses I guess related to http://svn.apache.org/viewvc?view=revision&revision=986577 I'd not prefer to stay forever stuck with 2.3.10 when everybody is going ahead. Someone I know which needs to works on an OFBIz based CMS is investigating. Maybe we could share the efforts? Jacques From: "Hans Bakker" remember that the new version was slowing down the ecommerce significantly On Wed, 2011-05-11 at 14:15 +0200, Jacques Le Roux wrote: Hi, It's a while we did not update Freemarker. We use version 2.3.10 (2007-04-20), soon (16th of May) 2.3.17 will be released with some interesting features and numerous bug fixes. http://freemarker.org/docs-rc/versions_2_3_11.html (?c) only used in geolocation.ftl, I don't expect much problems there Interesting: A new model interface, TemplateDirectiveModel provides an easier paradigm for implementing user-defined directives than TemplateTransformModel did previously. TemplateTransformModel will be deprecated. So should still work, cases could be updated, and easier way to do it now http://freemarker.org/docs-rc/versions_2_3_12.html In the templates, now you can conveniently call Java methods that use the Java 5 varargs feature (variable-length argument lists). http://freemarker.org/docs-rc/versions_2_3_13.html New built-ins for rounding numbers: round, floor, ceiling. Reworked template caching mechanism for radically improved concurrent performance (Achieved 20x speedup) http://freemarker.org/docs-rc/versions_2_3_14.html New built-in: xhtml http://freemarker.org/docs-rc/versions_2_3_17rc1.html ?seq_index_of and ?seq_last_index_of now works on collections ?long now works for date, date-time and time values, and returns the milliseconds since the epoch (as java.util.Date.getTime()). New special variable, now. This returns the current date-time. ?sort and ?sort_by now supports sorting boolean values. FreeMarker now can log its messages directly using SLF4J or Apache Commons Logging. So I'd like to update soon using 2.3.17. Someone is currently testing the RC1 in a custome application (based on OFBiz of course) Jacques -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates.
Re: Discussion: REST support in OFBiz
Hi,
On 10.05.2011 13:07, Adrian Crum wrote:
> After thinking about this for a while, I came to the conclusion that the REST
> servlet should have
> its own request config file. REST request elements will be kept in their own
> config file and that
> file will be specified in web.xml.
Why reinvent the wheel? We integrated Enunciate in OFBiz for our REST API. It
adheres to the REST
principles, is actually quite comfortable to use and was not hard to integrate
into OFBiz.
And it generates a nice documentation for the API from your JavaDoc. :)
Have a look at it here: http://enunciate.codehaus.org/getting_started.html
I'll paste some code snippets to get you started. Just ask if you need more
details.
Enunciate brings its own web app, which is actually generated.
So we put it in hot-deploy/api/build/web-app. We just added the webapp to
ofbiz-component.xml:
In the enunciate config file we configured enunciate not to do the actual build
itself, but let the
OFBiz build system do this:
We also have a servlet filter for authorization configured.
And our Enunciate Services all inherit from a BaseService class which provides
the OFBiz delegator
and dispatcher:
protected Delegator delegator = DelegatorFactory.getDelegator("default");
protected LocalDispatcher dispatcher =
GenericDispatcher.getLocalDispatcher("api", delegator);
In the Enunciate methods we can then call OFBiz services with
dispatcher.runSync() and access the
OFBiz database using the usual Delegator.
So our mapping from OFBiz services to the REST paradigm is done in Java code,
no XML configuration
necessary here :-)
Regards
Martin
Re: Discussion: REST support in OFBiz
Martin,
Thank you for the feedback! Another alternative that was mentioned
earlier was Apache CXF. Apache CXF and
Enunciate have one thing in common - REST services are implemented in
Java. Some people prefer to work in Java, others prefer configuring
things in XML. I'm the latter.
Btw, I have created a Jira issue where the design is taking place. I
encourage anyone who is interested to check it out. I believe the
solution proposed there makes implementing REST services trivial, and no
Java coding is needed.
https://issues.apache.org/jira/browse/OFBIZ-4274
-Adrian
On 5/11/2011 7:40 AM, Martin Kreidenweis wrote:
Hi,
On 10.05.2011 13:07, Adrian Crum wrote:
After thinking about this for a while, I came to the conclusion that the REST
servlet should have
its own request config file. REST request elements will be kept in their own
config file and that
file will be specified in web.xml.
Why reinvent the wheel? We integrated Enunciate in OFBiz for our REST API. It
adheres to the REST
principles, is actually quite comfortable to use and was not hard to integrate
into OFBiz.
And it generates a nice documentation for the API from your JavaDoc. :)
Have a look at it here: http://enunciate.codehaus.org/getting_started.html
I'll paste some code snippets to get you started. Just ask if you need more
details.
Enunciate brings its own web app, which is actually generated.
So we put it in hot-deploy/api/build/web-app. We just added the webapp to
ofbiz-component.xml:
In the enunciate config file we configured enunciate not to do the actual build
itself, but let the
OFBiz build system do this:
We also have a servlet filter for authorization configured.
And our Enunciate Services all inherit from a BaseService class which provides
the OFBiz delegator
and dispatcher:
protected Delegator delegator = DelegatorFactory.getDelegator("default");
protected LocalDispatcher dispatcher =
GenericDispatcher.getLocalDispatcher("api", delegator);
In the Enunciate methods we can then call OFBiz services with
dispatcher.runSync() and access the
OFBiz database using the usual Delegator.
So our mapping from OFBiz services to the REST paradigm is done in Java code,
no XML configuration
necessary here :-)
Regards
Martin
[jira] [Updated] (OFBIZ-4274) Implement a REST Servlet
[ https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Crum updated OFBIZ-4274: --- Attachment: (was: RestConfig.patch) > Implement a REST Servlet > > > Key: OFBIZ-4274 > URL: https://issues.apache.org/jira/browse/OFBIZ-4274 > Project: OFBiz > Issue Type: New Feature > Components: framework >Reporter: Adrian Crum >Priority: Minor > Attachments: RestConfig.patch > > > Implement a REST servlet that will map REST requests to OFBiz services. > Details are in the comments. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4274) Implement a REST Servlet
[ https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Crum updated OFBIZ-4274: --- Attachment: RestConfig.patch Updated POC config patch. > Implement a REST Servlet > > > Key: OFBIZ-4274 > URL: https://issues.apache.org/jira/browse/OFBIZ-4274 > Project: OFBiz > Issue Type: New Feature > Components: framework >Reporter: Adrian Crum >Priority: Minor > Attachments: RestConfig.patch > > > Implement a REST servlet that will map REST requests to OFBiz services. > Details are in the comments. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (OFBIZ-4274) Implement a REST Servlet
[ https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031517#comment-13031517 ] Adrian Crum edited comment on OFBIZ-4274 at 5/11/11 4:08 PM: - By default, request payloads (HTTP entity) are basically the target service's parameters wrapped in the resource name. In an XML payload the service parameters are child elements of the resource element (whose tag name is the resource name). This approach leverages the existing service definitions to define a REST resource API. By default, response payloads are the service results. The service result Map is converted to the requested media type. In cases where the request payload is controlled by an external application, a custom media handler can be provided for conversion. See the attached patch for an example. The servlet will support media handlers that convert payloads to/from media types (XML, JSON). See the attached patch for an example. was (Author: adri...@hlmksw.com): By default, request payloads (HTTP entity) are basically the target service's parameters wrapped in the resource name. In an XML payload the service parameters are child elements of the resource element (whose tag name is the resource name). This approach leverages the existing service definitions to define a REST resource API. By default, response payloads are the service results. The service result Map is converted to the requested media type. In cases where the request payload is controlled by an external application, the REST resource configuration could map the requests to a service that performs a data conversion (or translation) and then calls OFBiz services with the converted data. The method of converting service results into a response an external application expects is undefined at this time. Supporting this type of functionality (client-defined API) is beyond the scope of the initial implementation. Installations requiring that kind of support could use an ESB for translation. The servlet will support pluggable converters that convert payloads to/from media types (XML, JSON). > Implement a REST Servlet > > > Key: OFBIZ-4274 > URL: https://issues.apache.org/jira/browse/OFBIZ-4274 > Project: OFBiz > Issue Type: New Feature > Components: framework >Reporter: Adrian Crum >Priority: Minor > Attachments: RestConfig.patch > > > Implement a REST servlet that will map REST requests to OFBiz services. > Details are in the comments. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4279) Inevitable InvocationTarget exception in JmsQueueListener.init<>()
[
https://issues.apache.org/jira/browse/OFBIZ-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031857#comment-13031857
]
Jacques Le Roux commented on OFBIZ-4279:
I guess you use an "old" revision. I fixed a bug there in r1090961. Please
check at http://svn.apache.org/viewvc?rev=1090961&view=rev and close if it's ok
with you
Thanks
> Inevitable InvocationTarget exception in JmsQueueListener.init<>()
> --
>
> Key: OFBIZ-4279
> URL: https://issues.apache.org/jira/browse/OFBIZ-4279
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Ilya A. Pimenov
>Priority: Critical
>
> First call in the constructor refers to
> super(dispatcher);
> which is:
> protected AbstractJmsListener(ServiceDispatcher serviceDispatcher) {
> this.dispatcher =
> GenericDispatcher.getLocalDispatcher("JMSDispatcher", null, null,
> this.getClass().getClassLoader(), serviceDispatcher);
> }
> And in GenericDispatcher you can see:
> public static LocalDispatcher getLocalDispatcher(String dispatcherName,
> Delegator delegator, Collection readerURLs, ClassLoader loader,
> ServiceDispatcher serviceDispatcher) {
> if (dispatcherName == null) {
> dispatcherName = "default";
> Debug.logWarning("Got a getGenericDispatcher call with a null
> dispatcherName, assuming default for the name.", module);
> }
> //NB! This line will obviosly fail with "NullPointer" on delegator
> if (UtilValidate.isNotEmpty(delegator.getDelegatorTenantId())) {
> dispatcherName += "#" + delegator.getDelegatorTenantId();
> }
> So, It will always result in InvocationTargetException.
> Replacing AbstractJmsListener constructor with this:
> --
> protected AbstractJmsListener(ServiceDispatcher serviceDispatcher) {
> this.dispatcher =
> GenericDispatcher.getLocalDispatcher("JMSDispatcher",
> serviceDispatcher.getDelegator(), null, this.getClass().getClassLoader(),
> serviceDispatcher);
> }
> --
> Will do the trick.
> Since this bug blocks implementing JMS-service, I believe it is atleast
> critical; since there is a workaround, but it's not very nice one.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4280) Obsolete code in GenericDispatcher, which leads to NullPointer when such Dispatcher was not created earlier
[
https://issues.apache.org/jira/browse/OFBIZ-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031927#comment-13031927
]
Jacques Le Roux commented on OFBIZ-4280:
Same comment than in OFBIZ-4279: Please check at
http://svn.apache.org/viewvc?rev=1090961&view=rev and close if it's ok with you
> Obsolete code in GenericDispatcher, which leads to NullPointer when such
> Dispatcher was not created earlier
> ---
>
> Key: OFBIZ-4280
> URL: https://issues.apache.org/jira/browse/OFBIZ-4280
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Ilya A. Pimenov
>Priority: Critical
>
> Please consider this method getLocalDispatcher(String.class, Delegator.class,
> Collection.class, ClassLoader.class, ServiceDispatcher.class).
> And take a look at this piece of code:
> --
> ServiceDispatcher sd = serviceDispatcher != null ?
> serviceDispatcher : ServiceDispatcher.getInstance(dispatcherName, delegator);
> LocalDispatcher thisDispatcher = null;
> if (sd != null) {
> dispatcher = sd.getLocalDispatcher(dispatcherName);
> }
> if (thisDispatcher == null) {
> dispatcher = new GenericDispatcher(dispatcherName,
> delegator, readerURLs, loader, sd);
> }
> --
> The if-block "if (sd != null)" is obsolete, since thisDispatcher will always
> be null in if-block "if (thisDispatcher == null)". But due to
> sd.getLocalDispatcher(dispatcherName) implementation:
> --
> return localContext.get(name).getDispatcher();
> --
> It may cause NullPointer exception, whenever localContext.get(name) returns
> null. For example this happens in case of using default JmsQueueListener
> implementation, while implementing jms-service in OFBiz-way.
> Just removing the if-block
> --
> if (sd != null) {
> dispatcher = sd.getLocalDispatcher(dispatcherName);
> }
> --
> Will fix the problem.
> Since this bug blocks implementing JMS-service, I believe it is atleast
> critical; since there is a workaround, but it's not very nice one.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: CompressHTML buffer
OK, I had a closer look at the "example screen.compress" thing It seems to me that both are used compress.HTML in ScreenWidgetViewHandler.java used by RequestHandler so still active screen.compress in MacroScreenViewHandler.java So why is compress.HTML annotated as deprecated? Thanks Jacques From: "Jacques Le Roux" Hi, By default Freemarker StandardCompress is using a 2KB buffer. I'd like to increase to 10K. Note: this is not used OOTB, compressHTML being false in all web.xml by default To clean things a bit, I'd like also to remove the related commented out compress.HTML properties in widget.properties (I did not unsderstand "example screen.compress", seems deprecated) Agreed? (No answer being an agreement) Jacques
Re: sonar analysis on ASF servers
Le 07/05/2011 14:39, Jacques Le Roux a écrit : We could maybe change default ports in test-containers.xml? Jacques Hi Jacques, I just changed the port for the http-connector, and tests are failing because of duplicated values in database. Very strange from my POW, I'm just running clean-all run-install run-tests. Do I need to change something else ? Cheers, -- Erwan de FERRIERES www.nereide.biz
Re: Search Products in webpos
Thanks -- View this message in context: http://ofbiz.135035.n4.nabble.com/Search-Products-in-webpos-tp3511179p3516603.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: sonar analysis on ASF servers
I ran test with both HTTP and HTTPS changed and it worked fine Jacques From: "Erwan de FERRIERES" Le 07/05/2011 14:39, Jacques Le Roux a écrit : We could maybe change default ports in test-containers.xml? Jacques Hi Jacques, I just changed the port for the http-connector, and tests are failing because of duplicated values in database. Very strange from my POW, I'm just running clean-all run-install run-tests. Do I need to change something else ? Cheers, -- Erwan de FERRIERES www.nereide.biz
