Problem call service Ofbiz from Liferay ...Help me Agent.
Dear DEV, I tried 3 day's to call one service ofbiz from Liferay, I have refer document name is "About OFBiz and Liferay.doc" but when call getOrderStatus, liferay server show error : "org.xml.sax.SAXException: SimpleDeserializer encountered a child element, which is NOT expected, in something it was trying to deserialize." Please help. Thank you!
We get a new green light on buildbot
Hi dev, I have done some changes to make working the creation of javadoc documentation during buildbot (step 4) and now there are no more any warning and the step is now green on buildbot. On my local laptop everything is ok instead on the buildbot server I get some OutOfMemory error: java.lang.OutOfMemoryError: GC overhead limit exceeded I could try to increase the parameter maxmemory of javadoc task (default-javadoc in macros.xml) but it seems to me a problem related to the buildbot server. Anyone of you having some information about the buildbot server or how to solve this issue ? Thanks Marco
[jira] [Commented] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active
[
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039660#comment-13039660
]
Martin Kreidenweis commented on OFBIZ-4296:
---
Another thing we noticed when we looked at the problem: Prior to
[r1090952|https://fisheye6.atlassian.com/changelog/ofbiz?cs=1090952] the DCC
was initialized before the ECA handlers. Now it is the other way round. Don't
know it this was intended and/or could be a problem.
> JmsTopicListener started twice when distributed-cache-clear is active
> -
>
> Key: OFBIZ-4296
> URL: https://issues.apache.org/jira/browse/OFBIZ-4296
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Martin Kreidenweis
>Assignee: Jacques Le Roux
>
> This is a follow up issue of OFBIZ-3987 and OFBIZ-4202. Apparently the
> problem was not properly fixed. The infinite loop during startup went away,
> but there still are other side effects.
> Log output excerpt:
> {code}
> 2011-05-26 09:43:56,336 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
> JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
> ...
> 2011-05-26 09:44:00,499 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
> JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
> 2011-05-26 09:44:01,076 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
> JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on
> [activemq]...
> 2011-05-26 09:44:01,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
> JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on
> [activemq]...
> ...
> 2011-05-26 09:44:21,081 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
> JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All
> listeners connected.
> 2011-05-26 09:44:21,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
> JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All
> listeners connected.
> {code}
> What happens is this:
> {{DelegatorFactory.getDelegator("default")}} is called during startup
> (CatalinaContainer init). After creating the delegator and putting it in the
> cache it calls {{delegator.initEntityEcaHandler()}}. Somewhere inside it
> tries to get a dispatcher, so the first ServiceDispatcher instance is
> initialized. Inside the constructor code the JobManager wants to access the
> database and somewhere inside the {{EntityExpr}} another call to
> {{DelegatorFactory.getDelegator("default")}} is done. As the ECAHandler is
> already initialized it now initializes the DCC using
> {{EntityCacheServices.setDelegator()}}. This creates the second
> {{ServiceDispatcher}} instance and starts up the first {{JmsListenerFactory}}
> thread. Further up the call stack, a little later the "outer"
> {{ServiceDispatcher}} now also creates a {{JmsListenerFactory}} thread. So we
> have two listeners and every JMS message is handled twice.
> As a workaround we broke the recursion in the {{ServiceDispatcher}}
> constructor by doing a lazy initialization of the dispatcher in
> {{EntityCacheServices}}: We moved the call to
> {{EntityServiceFactory.getLocalDispatcher(delegator)}} out from the
> {{setDelegator}} method to when it is first needed.
> This doesn't seem like the proper solution, though. Maybe someone with more
> insight on how all the initialization of the dispatcher and delegator works
> can contribute a proper fix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active
[
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux reassigned OFBIZ-4296:
--
Assignee: Jacques Le Roux
> JmsTopicListener started twice when distributed-cache-clear is active
> -
>
> Key: OFBIZ-4296
> URL: https://issues.apache.org/jira/browse/OFBIZ-4296
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Martin Kreidenweis
>Assignee: Jacques Le Roux
>
> This is a follow up issue of OFBIZ-3987 and OFBIZ-4202. Apparently the
> problem was not properly fixed. The infinite loop during startup went away,
> but there still are other side effects.
> Log output excerpt:
> {code}
> 2011-05-26 09:43:56,336 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
> JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
> ...
> 2011-05-26 09:44:00,499 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
> JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
> 2011-05-26 09:44:01,076 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
> JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on
> [activemq]...
> 2011-05-26 09:44:01,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
> JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on
> [activemq]...
> ...
> 2011-05-26 09:44:21,081 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
> JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All
> listeners connected.
> 2011-05-26 09:44:21,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
> JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All
> listeners connected.
> {code}
> What happens is this:
> {{DelegatorFactory.getDelegator("default")}} is called during startup
> (CatalinaContainer init). After creating the delegator and putting it in the
> cache it calls {{delegator.initEntityEcaHandler()}}. Somewhere inside it
> tries to get a dispatcher, so the first ServiceDispatcher instance is
> initialized. Inside the constructor code the JobManager wants to access the
> database and somewhere inside the {{EntityExpr}} another call to
> {{DelegatorFactory.getDelegator("default")}} is done. As the ECAHandler is
> already initialized it now initializes the DCC using
> {{EntityCacheServices.setDelegator()}}. This creates the second
> {{ServiceDispatcher}} instance and starts up the first {{JmsListenerFactory}}
> thread. Further up the call stack, a little later the "outer"
> {{ServiceDispatcher}} now also creates a {{JmsListenerFactory}} thread. So we
> have two listeners and every JMS message is handled twice.
> As a workaround we broke the recursion in the {{ServiceDispatcher}}
> constructor by doing a lazy initialization of the dispatcher in
> {{EntityCacheServices}}: We moved the call to
> {{EntityServiceFactory.getLocalDispatcher(delegator)}} out from the
> {{setDelegator}} method to when it is first needed.
> This doesn't seem like the proper solution, though. Maybe someone with more
> insight on how all the initialization of the dispatcher and delegator works
> can contribute a proper fix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OFBIZ-4294) Help - Please give me Steps and Patch to Upgrade to Tomcat 7.0.1 from 5.5.20 in Apache Ofbiz
[ https://issues.apache.org/jira/browse/OFBIZ-4294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4294. -- Resolution: Not A Problem Assignee: Jacques Le Roux I close this issue because we don't answer questions in Jira tickets. Please use rather user ML for questions, see why here : http://cwiki.apache.org/confluence/display/OFBADMIN/Mailing+Lists#MailingLists-DesignanddevelopmentList:dev@ofbiz.apache.org You will get a better support (lot less persons are aware of this issue) or at least better chances to get some support. Rememember we are all volunteers here and we support on our free time. If you need a fast and secured support you may have a look at https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Service+Providers > Help - Please give me Steps and Patch to Upgrade to Tomcat 7.0.1 from 5.5.20 > in Apache Ofbiz > > > Key: OFBIZ-4294 > URL: https://issues.apache.org/jira/browse/OFBIZ-4294 > Project: OFBiz > Issue Type: Wish > Components: ALL APPLICATIONS, framework >Affects Versions: Release 4.0 > Environment: Windows server 2008 >Reporter: Daniel Xzuberance >Assignee: Jacques Le Roux >Priority: Trivial > Fix For: Release Branch 4.0 > > > Please give me Steps and Patch to Upgrade to Tomcat 6.0.29 from 5.5.20 in > Apache Ofbiz. I am having urgent PCI compliance faliures due to an > old/vulnerable TOMCAT version and i am unable to see clear and concise steps > to upgrade. My site is www.xzuberance.com and please note i am a NOVICE to > Apache Ofbiz. I can also be reahced via email at xzubera...@gmail.com. Please > HELP ASAP. > Thanks -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4294) Help - Please give me Steps and Patch to Upgrade to Tomcat 7.0.1 from 5.5.20 in Apache Ofbiz
[ https://issues.apache.org/jira/browse/OFBIZ-4294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-4294: --- Priority: Trivial (was: Blocker) Issue Type: Wish (was: Bug) > Help - Please give me Steps and Patch to Upgrade to Tomcat 7.0.1 from 5.5.20 > in Apache Ofbiz > > > Key: OFBIZ-4294 > URL: https://issues.apache.org/jira/browse/OFBIZ-4294 > Project: OFBiz > Issue Type: Wish > Components: ALL APPLICATIONS, framework >Affects Versions: Release 4.0 > Environment: Windows server 2008 >Reporter: Daniel Xzuberance >Priority: Trivial > Fix For: Release Branch 4.0 > > > Please give me Steps and Patch to Upgrade to Tomcat 6.0.29 from 5.5.20 in > Apache Ofbiz. I am having urgent PCI compliance faliures due to an > old/vulnerable TOMCAT version and i am unable to see clear and concise steps > to upgrade. My site is www.xzuberance.com and please note i am a NOVICE to > Apache Ofbiz. I can also be reahced via email at xzubera...@gmail.com. Please > HELP ASAP. > Thanks -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active
JmsTopicListener started twice when distributed-cache-clear is active
-
Key: OFBIZ-4296
URL: https://issues.apache.org/jira/browse/OFBIZ-4296
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Martin Kreidenweis
This is a follow up issue of OFBIZ-3987 and OFBIZ-4202. Apparently the problem
was not properly fixed. The infinite loop during startup went away, but there
still are other side effects.
Log output excerpt:
{code}
2011-05-26 09:43:56,336 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
...
2011-05-26 09:44:00,499 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
2011-05-26 09:44:01,076 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on
[activemq]...
2011-05-26 09:44:01,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on
[activemq]...
...
2011-05-26 09:44:21,081 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [
JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All
listeners connected.
2011-05-26 09:44:21,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [
JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All
listeners connected.
{code}
What happens is this:
{{DelegatorFactory.getDelegator("default")}} is called during startup
(CatalinaContainer init). After creating the delegator and putting it in the
cache it calls {{delegator.initEntityEcaHandler()}}. Somewhere inside it tries
to get a dispatcher, so the first ServiceDispatcher instance is initialized.
Inside the constructor code the JobManager wants to access the database and
somewhere inside the {{EntityExpr}} another call to
{{DelegatorFactory.getDelegator("default")}} is done. As the ECAHandler is
already initialized it now initializes the DCC using
{{EntityCacheServices.setDelegator()}}. This creates the second
{{ServiceDispatcher}} instance and starts up the first {{JmsListenerFactory}}
thread. Further up the call stack, a little later the "outer"
{{ServiceDispatcher}} now also creates a {{JmsListenerFactory}} thread. So we
have two listeners and every JMS message is handled twice.
As a workaround we broke the recursion in the {{ServiceDispatcher}} constructor
by doing a lazy initialization of the dispatcher in {{EntityCacheServices}}: We
moved the call to {{EntityServiceFactory.getLocalDispatcher(delegator)}} out
from the {{setDelegator}} method to when it is first needed.
This doesn't seem like the proper solution, though. Maybe someone with more
insight on how all the initialization of the dispatcher and delegator works can
contribute a proper fix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4291) No method to remove a promo code from the shopping cart
[
https://issues.apache.org/jira/browse/OFBIZ-4291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039566#comment-13039566
]
Frank Kootte commented on OFBIZ-4291:
-
Current provided method of dealing with removal of promotions is a so called
brute force approach where removing all and adding not to be removed promotions
again. Unless there is a good reason to not expose functionality to offer
removal of a single promotions I would like to push the addition of such to
trunk.
@Glyton - do you have a patch against trunk to do so perhaps ?
> No method to remove a promo code from the shopping cart
> ---
>
> Key: OFBIZ-4291
> URL: https://issues.apache.org/jira/browse/OFBIZ-4291
> Project: OFBiz
> Issue Type: Improvement
> Components: order
>Affects Versions: Release Branch 10.04
>Reporter: Glyton Camilleri
>
> Hi,
> When working with promotions and promo codes in the shopping cart, it seems
> not possible to remove _one_ specific promo code from the cart neither
> through the ShoppingCart and its helpers and services, nor through the
> ProductPromoWorker.
> ShoppingCart has the method
> {{addProductPromoCode(String productPromoCodeId, LocalDispatcher dispatcher)}}
> but no method to remove the added PromoCode. Is there any other worker,
> service or event that can be called to do this? And if not, is there a
> specifc reason (maybe relating to promotions application rules) for not
> implementing this?
> Any response is appreciated.
> Thanks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4295) Deserialization of arrays with UtilObject.getObject() throws ClassNotFoundException
[
https://issues.apache.org/jira/browse/OFBIZ-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kreidenweis updated OFBIZ-4295:
--
Attachment: OFBIZ-4295-classloader.patch
This patch fixes the array deserialization issue in for UtilIO and UtilObject
by using {{Class.forName()}}.
> Deserialization of arrays with UtilObject.getObject() throws
> ClassNotFoundException
> ---
>
> Key: OFBIZ-4295
> URL: https://issues.apache.org/jira/browse/OFBIZ-4295
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Martin Kreidenweis
> Attachments: OFBIZ-4295-classloader.patch
>
>
> Deserialization of arrays with {{UtilObject.getObject()}} throws a
> {{ClassNotFoundException}}. This happened to us when we enabled the
> distributed cache clear feature and it was sending arrays of {{EntityExpr}}
> objects to other OFBiz instances.
> The reason is, that the {{org.ofbiz.base.util.ObjectInputStream}} calls
> {{classLoader.loadClass(name)}} directly instead of using
> {{Class.forName(name, init, classLoader)}}.
> According to java bug
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6446627
> {{ClassLoader.loadClass()}} is not intended to being used this way and
> doesn't support loading arrays.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4295) Deserialization of arrays with UtilObject.getObject() throws ClassNotFoundException
Deserialization of arrays with UtilObject.getObject() throws
ClassNotFoundException
---
Key: OFBIZ-4295
URL: https://issues.apache.org/jira/browse/OFBIZ-4295
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Martin Kreidenweis
Deserialization of arrays with {{UtilObject.getObject()}} throws a
{{ClassNotFoundException}}. This happened to us when we enabled the distributed
cache clear feature and it was sending arrays of {{EntityExpr}} objects to
other OFBiz instances.
The reason is, that the {{org.ofbiz.base.util.ObjectInputStream}} calls
{{classLoader.loadClass(name)}} directly instead of using {{Class.forName(name,
init, classLoader)}}.
According to java bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6446627
{{ClassLoader.loadClass()}} is not intended to being used this way and doesn't
support loading arrays.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
