[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
[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] [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-tabpanelfocusedCommentId=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] [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] [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] [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] [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] [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-tabpanelfocusedCommentId=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
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
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!
