Yes, Jacopo. That's the issue I was talking about. With all due respect, though, I don't think you got the point of my JIRA post. Perhaps I didn't write it clearly enough.
I uploaded this JIRA issue specifically for it to be committed to the trunk, after several people on the ML suggested I do so. It would benefit me as well, as it means less differences from the trunk for "my company's OFBiz". I made some specific requests for people more familiar with the codebase than I to review certain aspects, rather than simply "committing it and hope for the best", which seems to be the normal OFBiz approach (yes, I am in the camp that favours branching unless we have automated regression tests). Given how heavily OFBiz depends on beanshell, I think you can understand why I took this aproach. The alternative would be to commit and then wait for loads of screens to be broken for the next several weeks. The most obvious reviewer, David himself, was too busy the last time I contacted him and I am not going to hassle him about it! He has and continues to contribute an enormous amount of time, often thanklessly, to the project. This was a grungy piece of work to do. I had to do it because otherwise we couldn't use the UI framework we wanted, and I reckoned that the many benefits brought by ofbiz outweighed the costs of the grunge. Once I had achieved my goal, I then spent another several hours tidying up, testing and writing it up in JIRA. I would be quite happy if a commiter wrote back and said "we're not going to use this fix". Fair enough. But just leaving it sitting there?? To a certain extent this is the norm on any decentralized project. But projects do differ, and that is why I alter my contribution behaviour based on the "behaviour" of each project. anyway, cheers, cameron ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html |
Cameron,
I haven't been following this thread closely, but your last reply caught my attention - so I'm kind of jumping in at the last moment. I looked at the Jira issue Jacopo mentioned, and I agree with what was said in that issue and in Jacopo's reply. If you want to see anything in Jira included in the main project, then you have to follow certain standards. The same applies if you just want people to take a look at it and comment on it. I would like to evaluate your contribution, but I can't do it in the form it is in. I need the ability to download a patch and examine what files the patch affects. Annyone else in the community would evaluate your contribution in the same way. Not too long ago I was in the same position you're in. I had submitted contributions to Jira and they just sat there - for the same reason yours is. After David and others pointed out to me what was wrong with them, I took steps to get my contributions to follow OFBiz standards and then my work started making its way into the project. -Adrian Cameron Smith wrote: > Yes, Jacopo. That's the issue I was talking about. With all due respect, though, I don't think you got the point of my JIRA post. Perhaps I didn't write it clearly enough. > > I uploaded this JIRA issue specifically for it to be committed to the trunk, after several people on the ML suggested I do so. It would benefit me as well, as it means less differences from the trunk for "my company's OFBiz". > > I made some specific requests for people more familiar with the codebase than I to review certain aspects, rather than simply "committing it and hope for the best", which seems to be the normal OFBiz approach (yes, I am in the camp that favours branching unless we have automated regression tests). > > Given how heavily OFBiz depends on beanshell, I think you can understand why I took this aproach. The alternative would be to commit and then wait for loads of screens to be broken for the next several weeks. > > The most obvious reviewer, David himself, was too busy the last time I contacted him and I am not going to hassle him about it! He has and continues to contribute an enormous amount of time, often thanklessly, to the project. > > This was a grungy piece of work to do. I had to do it because otherwise we couldn't use the UI framework we wanted, and I reckoned that the many benefits brought by ofbiz outweighed the costs of the grunge. Once I had achieved my goal, I then spent another several hours tidying up, testing and writing it up in JIRA. > > I would be quite happy if a commiter wrote back and said "we're not going to use this fix". Fair enough. But just leaving it sitting there?? To a certain extent this is the norm on any decentralized project. But projects do differ, and that is why I alter my contribution behaviour based on the "behaviour" of each project. > > anyway, cheers, > cameron > > > > > ___________________________________________________________ > Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for > your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html > |
Adrian, Cameron,
I agree with Adrian that the "rest of us" should submit patches in a standard format, so that the "few of them (committers/reviewers)" can efficiently go through them. But I also agree with Cameron that his process of tidying up his patch, documenting it, etc, took too much time for no effect. Without going into arguing about whether Cameron's patch is really "standard digestible format" for the committers, I'd say in general that this is the way open source projects are. To be fair to OFBiz, I know many other open source projects that have bug reports (and submitted patches) sitting untouched for months, even years. At the end of the day, how fast OFBiz progresses depends on how fast it aligns itself with market demand, demand in this case meaning user requirements, users like Cameron and Adrian and myself. For some projects that are blazingly fast in progress, their core team even takes it upon themselves to rewrite submitted patches that are not readily digestible. A submitted/suggested patch is still better than a complaint alone. However, I do admit that we (users) sometimes submit invalid complaints or bug reports or infeasible feature requests. I guess the key is to politely turn away the "weird" users, and keep the good ones (those who are great testers, good market feelers, possibly even strong coders themselves). So, in conclusion, nobody is wrong here. OFBiz team has to make a choice about prioritizing our submitted JIRA issues or patches, since resources will always be limited. On the other hand, users (like Adrian, Cameron, etc) will have to "alter their contribution behavior" accordingly. All we can hope for is that those of us who were submitting suggestions wrongly will in time learn to do so correctly; and those who were reviewing suggestions wrongly could possibly learn too. Whatever our "altered behaviors" are, we face the consequences fairly. If I choose to drop OFBiz due to such "grunges", I must accept a big loss of a great platform. If OFBiz chooses to "drop" users like me, OFBiz must rely on the other 399 users to help spur OFBiz growth. (Just a hypothetical statement for illustration; I'm NOT dropping OFBiz!!) Like Cameron says, the benefits of OFBiz far outweighs such "grunges". :) Jonathon Adrian Crum wrote: > Cameron, > > I haven't been following this thread closely, but your last reply caught > my attention - so I'm kind of jumping in at the last moment. > > I looked at the Jira issue Jacopo mentioned, and I agree with what was > said in that issue and in Jacopo's reply. If you want to see anything in > Jira included in the main project, then you have to follow certain > standards. The same applies if you just want people to take a look at it > and comment on it. > > I would like to evaluate your contribution, but I can't do it in the > form it is in. I need the ability to download a patch and examine what > files the patch affects. Annyone else in the community would evaluate > your contribution in the same way. > > Not too long ago I was in the same position you're in. I had submitted > contributions to Jira and they just sat there - for the same reason > yours is. After David and others pointed out to me what was wrong with > them, I took steps to get my contributions to follow OFBiz standards and > then my work started making its way into the project. > > -Adrian > > > Cameron Smith wrote: >> Yes, Jacopo. That's the issue I was talking about. With all due >> respect, though, I don't think you got the point of my JIRA post. >> Perhaps I didn't write it clearly enough. >> >> I uploaded this JIRA issue specifically for it to be committed to the >> trunk, after several people on the ML suggested I do so. It would >> benefit me as well, as it means less differences from the trunk for >> "my company's OFBiz". >> >> I made some specific requests for people more familiar with the >> codebase than I to review certain aspects, rather than simply >> "committing it and hope for the best", which seems to be the normal >> OFBiz approach (yes, I am in the camp that favours branching unless we >> have automated regression tests). >> >> Given how heavily OFBiz depends on beanshell, I think you can >> understand why I took this aproach. The alternative would be to >> commit and then wait for loads of screens to be broken for the next >> several weeks. >> >> The most obvious reviewer, David himself, was too busy the last time I >> contacted him and I am not going to hassle him about it! He has and >> continues to contribute an enormous amount of time, often thanklessly, >> to the project. >> >> This was a grungy piece of work to do. I had to do it because >> otherwise we couldn't use the UI framework we wanted, and I reckoned >> that the many benefits brought by ofbiz outweighed the costs of the >> grunge. Once I had achieved my goal, I then spent another several >> hours tidying up, testing and writing it up in JIRA. >> >> I would be quite happy if a commiter wrote back and said "we're not >> going to use this fix". Fair enough. But just leaving it sitting >> there?? To a certain extent this is the norm on any decentralized >> project. But projects do differ, and that is why I alter my >> contribution behaviour based on the "behaviour" of each project. >> >> anyway, cheers, >> cameron >> >> >> >> >> ___________________________________________________________ >> Yahoo! Mail is the world's favourite email. Don't settle for less, >> sign up for >> your free account today >> http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html >> > > |
In reply to this post by Cameron Smith-6
All of the other fixes I committed, I submitted as patches. I am aware of the OFBiz coding guidelines. There is a specific reason why I did not submit the beanshell issue as a patch, at this point, which I explain on the JIRA post.
----- Original Message ---- From: "[hidden email]" <[hidden email]> To: [hidden email] Sent: Friday, 13 April, 2007 9:24:36 AM Subject: user Digest 13 Apr 2007 07:24:36 -0000 Issue 332 user Digest 13 Apr 2007 07:24:36 -0000 Issue 332 Topics (messages 5185 through 5214): Re: Error adding Text to a DataResource 5185 by: Michel Dielissen Re: Loading of Data 5186 by: Jacques Le Roux 5192 by: Adrian Crum 5195 by: Scott Gray am i going on a logical way about sitemap 5187 by: subhasis 5189 by: Jacques Le Roux Default User & Passwords 5188 by: Scott A 5191 by: Chris Howe 5193 by: Philip W. Dalrymple III 5194 by: Scott A Re: How to use JSP page instead of FTL page in OFBiz 5190 by: Adrian Crum Leaving OFBiz for a while 5196 by: Cameron Smith 5199 by: Adrian Crum 5202 by: Jonathon -- Improov Calling OFBiz from .NET 5197 by: Cameron Smith Java 1.6.0 5198 by: David Shere 5200 by: Vikrant.Rathore.bertelsmann.com.cn 5201 by: Jonathon -- Improov availability of a team from my side to help ofbiz 5203 by: Vikrant.Rathore.bertelsmann.com.cn MySQL connection times out, how about PostgreSQL? 5204 by: Jonathon -- Improov 5205 by: Jonathon -- Improov 5206 by: Chris Howe 5208 by: Jonathon -- Improov 5210 by: Chris Howe 5212 by: Hans Holmlund 5213 by: Jonathon -- Improov 5214 by: Jonathon -- Improov No source code provided for ofbiz-minerva.jar? 5207 by: Jonathon -- Improov Expression UiLabelMap Undefined 5209 by: chitrakala ramanujam 5211 by: Scott Gray Administrivia: --------------------------------------------------------------------- To post to the list, e-mail: [hidden email] To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] ---------------------------------------------------------------------- Hi Scott, Thanks very much for your quick response! It works fine now. You made my day :-)) Michel Scott Gray wrote: > > Hi Michel > > I had a look and there was a bug in the code, I've fixed this in rev. > 527866. > > Thanks > Scott > > On 12/04/07, Michel Dielissen <[hidden email]> wrote: >> >> >> Hello, I can use some help with the following. >> >> When I try to add Text (Content\DataResource\Search\Select my >> DataResource\Text tab) to a DataResource I just created I get the >> message: >> >> The Following Errors Occurred: >> * In set-nonpk-fields a value was not found with the specified valueAcsr: >> lookedUpValue, not setting fields >> >> I use a clean install of OFBiz (rev. 524772) which I build with "ant >> run-install" (on Windows XP). >> >> I created a new DataResource with the fields: >> - Data Resource Type Id = LongText >> - Data Template Type Id = No Template >> - Status ID = In Progress >> - Data Resource Name = MyDataResourceName >> - Locale String = en_US >> - Mime Type Id = text/html - HTML Text >> - Is Public = Yes >> The other fields which I not mentioned are empty. >> >> Maybe it has something to do with the Status ID field which is empty with >> the "store_policies" example (and which I can edit)? But I checked it and >> found the Status "In_Progress" exists in the StatusItem table. >> >> I want to make new Content just like the "store_policies" example so I: >> 1. create a DataResource >> 2. create a Text with that DataResource (which fails as described above) >> 3. Create a Content record >> 4. Create a Association to the DataResource >> Am I missing something? >> I red the documentation (Content Management Overview and Content Manager >> in >> the Manager References) >> >> Any ideas? >> Thanx a lot! >> >> Michel >> >> >> >> -- >> View this message in context: >> http://www.nabble.com/Error-adding-Text-to-a-DataResource-tf3564052.html#a9954867 >> Sent from the OFBiz - User mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Error-adding-Text-to-a-DataResource-tf3564052.html#a9957806 Sent from the OFBiz - User mailing list archive at Nabble.com. Interesting, thanks Scott ! Jacques De : "Scott Gray" <[hidden email]> > It looks like they've fixed it in Java 6, it appears to be a popular issue: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4212439 > > On 12/04/07, Jacques Le Roux <[hidden email]> wrote: > > > > My answer was from experience ;o) > > > > Is there a Jira issue for that, should we create one ? > > > > Jacques > > > > > > > > This would be true except that we use the ResourceBundle class of > > > Java API, and that class keeps its own cache that prevents reloading. > > > > > > So for now we are stuck with a restart to reload on properties files. > > > We've been talking about rewriting the UtilProperties stuff to not > > > use ResourceBundle (there are various notes in the java file on it), > > > but that hasn't been done yet. > > > > > > -David > > > > > > > > > On Apr 12, 2007, at 2:49 AM, Scott Gray wrote: > > > > > > > I was under the impression the properties are loaded and cached the > > > > first > > > > time the file is used and can be cleared via webtools > > > > > > > > Scott > > > > > > > > On 12/04/07, Jacques Le Roux <[hidden email]> wrote: > > > >> > > > >> > > > >> Deploying a classpath resource is similar to deploying a compiled > > > >> Java > > > >> class : you have to reload. > > > >> > > > >> This article may be of interest in this field : > > > >> http://www.javaworld.com/javaworld/javatips/jw-javatip125.html > > > >> > > > >> Jacques > > > >> > > > >> > > > >> > Hi, > > > >> > > > > >> > > > > >> > When you are working with files that are not using entity > > > >> > ("<entity-engine-xml>"), such as 'arithmetic.properties' is there > > a > > > >> method > > > >> > to load the data, or is the file called each time it is used. (I > > > >> did > > > >> clear > > > >> > the cache). > > > >> > > > > >> > I would like to understand this better, any guidance would be > > > >> appreciated. > > > >> > > > > >> > > > > >> > Thanks & Regards, > > > >> > > > > >> > Peter > > > >> > > > > >> > > > >> > > > > > > > > > > > So, where does that leave us? Do we just wait for Java 6 or make the change David suggested? Jacques Le Roux wrote: > Interesting, thanks Scott ! > > Jacques > > De : "Scott Gray" <[hidden email]> > >>It looks like they've fixed it in Java 6, it appears to be a popular > > issue: > >>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4212439 >> >>On 12/04/07, Jacques Le Roux <[hidden email]> wrote: >> >>>My answer was from experience ;o) >>> >>>Is there a Jira issue for that, should we create one ? >>> >>>Jacques >>> >>> >>>>This would be true except that we use the ResourceBundle class of > > the > >>>>Java API, and that class keeps its own cache that prevents > > reloading. > >>>>So for now we are stuck with a restart to reload on properties > > files. > >>>>We've been talking about rewriting the UtilProperties stuff to not >>>>use ResourceBundle (there are various notes in the java file on > > it), > >>>>but that hasn't been done yet. >>>> >>>>-David >>>> >>>> >>>>On Apr 12, 2007, at 2:49 AM, Scott Gray wrote: >>>> >>>> >>>>>I was under the impression the properties are loaded and cached > > the > >>>>>first >>>>>time the file is used and can be cleared via webtools >>>>> >>>>>Scott >>>>> >>>>>On 12/04/07, Jacques Le Roux <[hidden email]> > > wrote: > >>>>>> >>>>>>Deploying a classpath resource is similar to deploying a > > compiled > >>>>>>Java >>>>>>class : you have to reload. >>>>>> >>>>>>This article may be of interest in this field : >>>>>>http://www.javaworld.com/javaworld/javatips/jw-javatip125.html >>>>>> >>>>>>Jacques >>>>>> >>>>>> >>>>>> >>>>>>>Hi, >>>>>>> >>>>>>> >>>>>>>When you are working with files that are not using entity > > tags > >>>>>>>("<entity-engine-xml>"), such as 'arithmetic.properties' is > > there > >>>a >>> >>>>>>method >>>>>> >>>>>>>to load the data, or is the file called each time it is used. > > (I > >>>>>>did >>>>>>clear >>>>>> >>>>>>>the cache). >>>>>>> >>>>>>>I would like to understand this better, any guidance would be >>>>>> >>>>>>appreciated. >>>>>> >>>>>>> >>>>>>>Thanks & Regards, >>>>>>> >>>>>>>Peter >>>>>>> >>>>>> >>>>>> >>>> >>> > > All depends on whether it bothers someone enough to code the changes, I suspect it would be quite some time before OFBiz is using code specific to that version of java. Regards Scott On 13/04/07, Adrian Crum <[hidden email]> wrote: > > So, where does that leave us? Do we just wait for Java 6 or make the > change > David suggested? > > > Jacques Le Roux wrote: > > > Interesting, thanks Scott ! > > > > Jacques > > > > De : "Scott Gray" <[hidden email]> > > > >>It looks like they've fixed it in Java 6, it appears to be a popular > > > > issue: > > > >>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4212439 > >> > >>On 12/04/07, Jacques Le Roux <[hidden email]> wrote: > >> > >>>My answer was from experience ;o) > >>> > >>>Is there a Jira issue for that, should we create one ? > >>> > >>>Jacques > >>> > >>> > >>>>This would be true except that we use the ResourceBundle class of > > > > the > > > >>>>Java API, and that class keeps its own cache that prevents > > > > reloading. > > > >>>>So for now we are stuck with a restart to reload on properties > > > > files. > > > >>>>We've been talking about rewriting the UtilProperties stuff to not > >>>>use ResourceBundle (there are various notes in the java file on > > > > it), > > > >>>>but that hasn't been done yet. > >>>> > >>>>-David > >>>> > >>>> > >>>>On Apr 12, 2007, at 2:49 AM, Scott Gray wrote: > >>>> > >>>> > >>>>>I was under the impression the properties are loaded and cached > > > > the > > > >>>>>first > >>>>>time the file is used and can be cleared via webtools > >>>>> > >>>>>Scott > >>>>> > >>>>>On 12/04/07, Jacques Le Roux <[hidden email]> > > > > wrote: > > > >>>>>> > >>>>>>Deploying a classpath resource is similar to deploying a > > > > compiled > > > >>>>>>Java > >>>>>>class : you have to reload. > >>>>>> > >>>>>>This article may be of interest in this field : > >>>>>>http://www.javaworld.com/javaworld/javatips/jw-javatip125.html > >>>>>> > >>>>>>Jacques > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Hi, > >>>>>>> > >>>>>>> > >>>>>>>When you are working with files that are not using entity > > > > tags > > > >>>>>>>("<entity-engine-xml>"), such as 'arithmetic.properties' is > > > > there > > > >>>a > >>> > >>>>>>method > >>>>>> > >>>>>>>to load the data, or is the file called each time it is used. > > > > (I > > > >>>>>>did > >>>>>>clear > >>>>>> > >>>>>>>the cache). > >>>>>>> > >>>>>>>I would like to understand this better, any guidance would be > >>>>>> > >>>>>>appreciated. > >>>>>> > >>>>>>> > >>>>>>>Thanks & Regards, > >>>>>>> > >>>>>>>Peter > >>>>>>> > >>>>>> > >>>>>> > >>>> > >>> > > > > > i am new user of OFBiz,for create a sitemap all require things are not get from product table, totalTimesViewed is require from ProductCalculatedInfo. delegator = request.getAttribute("delegator"); persons = delegator.findAll("Product"); context.put("persons", persons); pro=person.getRelatedOne("ProductCalculatedInfo"); but with getRelated i cant access both entity. So i create a view entity in order/entitymodel_view named "ProductCalculatedInfoAndProduct" and rewrite the code following & get my needs delegator = request.getAttribute("delegator"); persons = delegator.findAll("ProductCalculatedInfoAndProduct"); context.put("persons", persons); is this a right way ,if not please guide me & if possible give the exact. -- View this message in context: http://www.nabble.com/am-i-going-on-a-logical-way-about-sitemap-tf3565246.html#a9958558 Sent from the OFBiz - User mailing list archive at Nabble.com. This is a right way to do it. Jacques De : "subhasis" <[hidden email]> > > i am new user of OFBiz,for create a sitemap all require things are not get > from product table, totalTimesViewed is require from ProductCalculatedInfo. > > > delegator = request.getAttribute("delegator"); > persons = delegator.findAll("Product"); > context.put("persons", persons); > pro=person.getRelatedOne("ProductCalculatedInfo"); > > but with getRelated i cant access both entity. > > So i create a view entity in order/entitymodel_view named > "ProductCalculatedInfoAndProduct" and rewrite the code following & get > needs > > delegator = request.getAttribute("delegator"); > persons = delegator.findAll("ProductCalculatedInfoAndProduct"); > context.put("persons", persons); > > is this a right way ,if not please guide me & if possible give the exact. > -- > View this message in context: http://www.nabble.com/am-i-going-on-a-logical-way-about-sitemap-tf3565246.html#a9958558 > Sent from the OFBiz - User mailing list archive at Nabble.com. Hiya All, I have a question about default user and passwords. Is there a way to change all of the default passwords at once or do you have to change each individual? I am talking about the accounts that were created with the initial ofbiz setup. The ones like BLOG_ADMIN, BIGAL, MADMAX, etc. Are there be any other users besides the ones found in Party Manager? We're just trying to close any back doors to our system. Thanks in advance. -- View this message in context: http://www.nabble.com/Default-User---Passwords-tf3565946.html#a9960968 Sent from the OFBiz - User mailing list archive at Nabble.com. all of the passwords should be "ofbiz" and should therefore encode to the same value, if you run an sql query, you can replace all of the ofbiz encoded value with another known encoded value --- Scott A <[hidden email]> wrote: > > Hiya All, > > I have a question about default user and passwords. > > Is there a way to change all of the default passwords at once or do > you have > to change each individual? I am talking about the accounts that were > created > with the initial ofbiz setup. The ones like BLOG_ADMIN, BIGAL, > MADMAX, etc. > > Are there be any other users besides the ones found in Party Manager? > We're > just trying to close any back doors to our system. > > Thanks in advance. > > > > -- > View this message in context: > > Sent from the OFBiz - User mailing list archive at Nabble.com. > > The way I do this is to have a data file that is loaded LATE in the "run-install" process that has all of the changed default passwords. (you can also run the same process from the import section of webtools) my file looks somthing like this <entity-engine-xml> <UserLogin userLoginId="1" partyId="admin" currentPassword="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" passwordHint="The Number One, Yeah, Literally" enabled="N" /> </entity-engine-xml> NOTE the number of XXX in the above is not correct you can set the password on a users and then go to the webtools to extract the necessary data. Chris Howe wrote: > all of the passwords should be "ofbiz" and should therefore encode to > the same value, if you run an sql query, you can replace all of the > ofbiz encoded value with another known encoded value > --- Scott A <[hidden email]> wrote: > >> Hiya All, >> >> I have a question about default user and passwords. >> >> Is there a way to change all of the default passwords at once or do >> you have >> to change each individual? I am talking about the accounts that were >> created >> with the initial ofbiz setup. The ones like BLOG_ADMIN, BIGAL, >> MADMAX, etc. >> >> Are there be any other users besides the ones found in Party Manager? >> We're >> just trying to close any back doors to our system. >> >> Thanks in advance. >> >> >> >> -- >> View this message in context: >> > http://www.nabble.com/Default-User---Passwords-tf3565946.html#a9960968 >> Sent from the OFBiz - User mailing list archive at Nabble.com. >> >> > -- It is MDT, Inc's policy to delete mail containing unsolicited file attachments. Please be sure to contact the MDT staff member BEFORE sending an e-mail with any file attachments; they will be able to arrange for the files to be received. This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please advise [hidden email] <mailto:[hidden email]>. Philip W. Dalrymple III <[hidden email]> MDT Software - The Change Management Company +1 678 297 1001 Fax +1 678 297 1003 Thanks guys. Much appreciated. Philip W. Dalrymple III wrote: > > The way I do this is to have a data file that is loaded LATE in the > "run-install" process that has all of the changed default passwords. > (you can also run the same process from the import section of webtools) > > my file looks somthing like this > > <entity-engine-xml> > <UserLogin > userLoginId="1" > partyId="admin" > currentPassword="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" > passwordHint="The Number One, Yeah, Literally" > enabled="N" > /> > </entity-engine-xml> > > NOTE the number of XXX in the above is not correct > > you can set the password on a users and then go to the webtools to > extract the necessary data. > > > Chris Howe wrote: >> all of the passwords should be "ofbiz" and should therefore encode to >> the same value, if you run an sql query, you can replace all of the >> ofbiz encoded value with another known encoded value >> --- Scott A <[hidden email]> wrote: >> >>> Hiya All, >>> >>> I have a question about default user and passwords. >>> >>> Is there a way to change all of the default passwords at once or do >>> you have >>> to change each individual? I am talking about the accounts that were >>> created >>> with the initial ofbiz setup. The ones like BLOG_ADMIN, BIGAL, >>> MADMAX, etc. >>> >>> Are there be any other users besides the ones found in Party Manager? >>> We're >>> just trying to close any back doors to our system. >>> >>> Thanks in advance. >>> >>> >>> >>> -- >>> View this message in context: >>> >> http://www.nabble.com/Default-User---Passwords-tf3565946.html#a9960968 >>> Sent from the OFBiz - User mailing list archive at Nabble.com. >>> >>> >> > > -- > It is MDT, Inc's policy to delete mail containing unsolicited > file attachments. Please be sure to contact the MDT staff > member BEFORE sending an e-mail with any file attachments; > they will be able to arrange for the files to be received. > > This email, and any files transmitted with it, is confidential > and intended solely for the use of the individual or entity to > whom they are addressed. If you have received this email in error, > please advise [hidden email] <mailto:[hidden email]>. > > Philip W. Dalrymple III <[hidden email]> > MDT Software - The Change Management Company > +1 678 297 1001 > Fax +1 678 297 1003 > > -- View this message in context: http://www.nabble.com/Default-User---Passwords-tf3565946.html#a9966657 Sent from the OFBiz - User mailing list archive at Nabble.com. JSP pages are not encouraged in OFBiz. OFBiz still supports their use however. You will have to specify a JSP view handler in controller.xml (using a <handler> entry), then have the page request routed through the JSP view handler via the <view-map> entry in controller.xml. Gokul_IFS wrote: > Hi, > > I am trying to create an application in OFBiz. I want to use JSP page > instead of .FTL page for view page. > > The sample application is running fine if made as FTL but shows > error when made as jsp. > > I would like to know how to run JSP page in OFBiz. > > > > > > Yes, Jacopo. That's the issue I was talking about. With all due respect, though, I don't think you got the point of my JIRA post. Perhaps I didn't write it clearly enough. I uploaded this JIRA issue specifically for it to be committed to the trunk, after several people on the ML suggested I do so. It would benefit me as well, as it means less differences from the trunk for "my company's OFBiz". I made some specific requests for people more familiar with the codebase than I to review certain aspects, rather than simply "committing it and hope for the best", which seems to be the normal OFBiz approach (yes, I am in the camp that favours branching unless we have automated regression tests). Given how heavily OFBiz depends on beanshell, I think you can understand why I took this aproach. The alternative would be to commit and then wait for loads of screens to be broken for the next several weeks. The most obvious reviewer, David himself, was too busy the last time I contacted him and I am not going to hassle him about it! He has and continues to contribute an enormous amount of time, often thanklessly, to the project. This was a grungy piece of work to do. I had to do it because otherwise we couldn't use the UI framework we wanted, and I reckoned that the many benefits brought by ofbiz outweighed the costs of the grunge. Once I had achieved my goal, I then spent another several hours tidying up, testing and writing it up in JIRA. I would be quite happy if a commiter wrote back and said "we're not going to use this fix". Fair enough. But just leaving it sitting there?? To a certain extent this is the norm on any decentralized project. But projects do differ, and that is why I alter my contribution behaviour based on the "behaviour" of each project. anyway, cheers, cameron ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html Cameron, I haven't been following this thread closely, but your last reply caught my attention - so I'm kind of jumping in at the last moment. I looked at the Jira issue Jacopo mentioned, and I agree with what was said in that issue and in Jacopo's reply. If you want to see anything in Jira included in the main project, then you have to follow certain standards. The same applies if you just want people to take a look at it and comment on it. I would like to evaluate your contribution, but I can't do it in the form it is in. I need the ability to download a patch and examine what files the patch affects. Annyone else in the community would evaluate your contribution in the same way. Not too long ago I was in the same position you're in. I had submitted contributions to Jira and they just sat there - for the same reason yours is. After David and others pointed out to me what was wrong with them, I took steps to get my contributions to follow OFBiz standards and then my work started making its way into the project. -Adrian Cameron Smith wrote: > Yes, Jacopo. That's the issue I was talking about. With all due respect, though, I don't think you got the point of my JIRA post. Perhaps I didn't write it clearly enough. > > I uploaded this JIRA issue specifically for it to be committed to the trunk, after several people on the ML suggested I do so. It would benefit me as well, as it means less differences from the trunk for "my company's OFBiz". > > I made some specific requests for people more familiar with the codebase than I to review certain aspects, rather than simply "committing it and hope for the best", which seems to be the normal OFBiz approach (yes, I am in the camp that favours branching unless we have automated regression tests). > > Given how heavily OFBiz depends on beanshell, I think you can understand why I took this aproach. The alternative would be to commit and then wait for loads of screens to be broken for the next several weeks. > > The most obvious reviewer, David himself, was too busy the last time I contacted him and I am not going to hassle him about it! He has and continues to contribute an enormous amount of time, often thanklessly, to the project. > > This was a grungy piece of work to do. I had to do it because otherwise we couldn't use the UI framework we wanted, and I reckoned that the many benefits brought by ofbiz outweighed the costs of the grunge. Once I had achieved my goal, I then spent another several hours tidying up, testing and writing it up in JIRA. > > I would be quite happy if a commiter wrote back and said "we're not going to use this fix". Fair enough. But just leaving it sitting there?? To a certain extent this is the norm on any decentralized project. But projects do differ, and that is why I alter my contribution behaviour based on the "behaviour" of each project. > > anyway, cheers, > cameron > > > > > ___________________________________________________________ > Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for > your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html > Adrian, Cameron, I agree with Adrian that the "rest of us" should submit patches in a standard format, so that the "few of them (committers/reviewers)" can efficiently go through them. But I also agree with Cameron that his process of tidying up his patch, documenting it, etc, took too much time for no effect. Without going into arguing about whether Cameron's patch is really "standard digestible format" for the committers, I'd say in general that this is the way open source projects are. To be fair to OFBiz, I know many other open source projects that have bug reports (and submitted patches) sitting untouched for months, even years. At the end of the day, how fast OFBiz progresses depends on how fast it aligns itself with market demand, demand in this case meaning user requirements, users like Cameron and Adrian and myself. For some projects that are blazingly fast in progress, their core team even takes it upon themselves to rewrite submitted patches that are not readily digestible. A submitted/suggested patch is still better than a complaint alone. However, I do admit that we (users) sometimes submit invalid complaints or bug reports or infeasible feature requests. I guess the key is to politely turn away the "weird" users, and keep the good ones (those who are great testers, good market feelers, possibly even strong coders themselves). So, in conclusion, nobody is wrong here. OFBiz team has to make a choice about prioritizing our submitted JIRA issues or patches, since resources will always be limited. On the other hand, users (like Adrian, Cameron, etc) will have to "alter their contribution behavior" accordingly. All we can hope for is that those of us who were submitting suggestions wrongly will in time learn to do so correctly; and those who were reviewing suggestions wrongly could possibly learn too. Whatever our "altered behaviors" are, we face the consequences fairly. If I choose to drop OFBiz due to such "grunges", I must accept a big loss of a great platform. If OFBiz chooses to "drop" users like me, OFBiz must rely on the other 399 users to help spur OFBiz growth. (Just a hypothetical statement for illustration; I'm NOT dropping OFBiz!!) Like Cameron says, the benefits of OFBiz far outweighs such "grunges". :) Jonathon Adrian Crum wrote: > Cameron, > > I haven't been following this thread closely, but your last reply caught > my attention - so I'm kind of jumping in at the last moment. > > I looked at the Jira issue Jacopo mentioned, and I agree with what was > said in that issue and in Jacopo's reply. If you want to see anything in > Jira included in the main project, then you have to follow certain > standards. The same applies if you just want people to take a look at it > and comment on it. > > I would like to evaluate your contribution, but I can't do it in the > form it is in. I need the ability to download a patch and examine what > files the patch affects. Annyone else in the community would evaluate > your contribution in the same way. > > Not too long ago I was in the same position you're in. I had submitted > contributions to Jira and they just sat there - for the same reason > yours is. After David and others pointed out to me what was wrong with > them, I took steps to get my contributions to follow OFBiz standards and > then my work started making its way into the project. > > -Adrian > > > Cameron Smith wrote: >> Yes, Jacopo. That's the issue I was talking about. With all due >> respect, though, I don't think you got the point of my JIRA post. >> Perhaps I didn't write it clearly enough. >> >> I uploaded this JIRA issue specifically for it to be committed to the >> trunk, after several people on the ML suggested I do so. It would >> benefit me as well, as it means less differences from the trunk for >> "my company's OFBiz". >> >> I made some specific requests for people more familiar with the >> codebase than I to review certain aspects, rather than simply >> "committing it and hope for the best", which seems to be the normal >> OFBiz approach (yes, I am in the camp that favours branching unless we >> have automated regression tests). >> >> Given how heavily OFBiz depends on beanshell, I think you can >> understand why I took this aproach. The alternative would be to >> commit and then wait for loads of screens to be broken for the next >> several weeks. >> >> The most obvious reviewer, David himself, was too busy the last time I >> contacted him and I am not going to hassle him about it! He has and >> continues to contribute an enormous amount of time, often thanklessly, >> to the project. >> >> This was a grungy piece of work to do. I had to do it because >> otherwise we couldn't use the UI framework we wanted, and I reckoned >> that the many benefits brought by ofbiz outweighed the costs of the >> grunge. Once I had achieved my goal, I then spent another several >> hours tidying up, testing and writing it up in JIRA. >> >> I would be quite happy if a commiter wrote back and said "we're not >> going to use this fix". Fair enough. But just leaving it sitting >> there?? To a certain extent this is the norm on any decentralized >> project. But projects do differ, and that is why I alter my >> contribution behaviour based on the "behaviour" of each project. >> >> anyway, cheers, >> cameron >> >> >> >> >> ___________________________________________________________ >> Yahoo! Mail is the world's favourite email. Don't settle for less, >> sign up for >> your free account today >> http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html >> > > On a different note, I think I have finally cracked this "old chestnut". I had another stab at it after a recent post by Marina (thanks Marina) about using the RPC style attribute. In fact, it turned out not to be so simple, as .NET explicitly doesn't support wrapped response params for RPC style messages. And for Document style, the attribute to tell it where to look for the response wrapper doesn't appear to work. Plus, the .NET-generated code has a large amount of unecessary tripe. So I ended up rolling my own in .NET/C#, turned out to be fairly simple. I didn't have to alter OFBiz /at all/ for basic non-authenticated service calling, including for passing back list and map params. However, for authenticated services, I added a token-passing scheme to SOAPEventHandler. However this is a very much an optional extra. On first tests over a 100Mb LAN it does not appear to be noticeable slower than calling a remote database. However I haven't done systematic performance tests yet. Anyway, we are still running some last tests, but if there is a level of interest in the community I will write up a tutorial on the Wiki over the next few weeks. cameron ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ I've been running OFBiz in Java 1.6.0 for a while now and I haven't noticed any major differences. I haven't seen any discussions here about pros/cons of switching. I've done little real testing -- does anyone have any problems they've run into that can be attributed to Java 6? -- David Shere Information Technology Services Steele Rubber Products www.SteeleRubber.com Hi David, Running on Java 1.6 the problem appears only in POS and some specific areas. I have been running on 1.6 for a while and after some errors rolled back to 1.5. Thanks with best regards, Vikrant -----Original Message----- From: news [mailto:[hidden email]] Sent: Friday, April 13, 2007 4:44 AM To: [hidden email] Subject: Java 1.6.0 I've been running OFBiz in Java 1.6.0 for a while now and I haven't noticed any major differences. I haven't seen any discussions here about pros/cons of switching. I've done little real testing -- does anyone have any problems they've run into that can be attributed to Java 6? -- David Shere Information Technology Services Steele Rubber Products www.SteeleRubber.com Vikrant, Thanks for the heads up. Just FYI for everybody else, I've been compiling and running with 1.5.0_11, no problems. Jonathon [hidden email] wrote: > Hi David, > > Running on Java 1.6 the problem appears only in POS and some specific > areas. I have been running on 1.6 for a while and after some errors > rolled back to 1.5. > > Thanks > with best regards, > Vikrant > > > -----Original Message----- > From: news [mailto:[hidden email]] > Sent: Friday, April 13, 2007 4:44 AM > To: [hidden email] > Subject: Java 1.6.0 > > I've been running OFBiz in Java 1.6.0 for a while now and I haven't > noticed any major differences. I haven't seen any discussions here > about pros/cons of switching. I've done little real testing -- does > anyone have any problems they've run into that can be attributed to Java > 6? > > -- > David Shere > Information Technology Services > Steele Rubber Products > www.SteeleRubber.com > > > Hi Everyone, As I mentioned we have been working on a pilot implementation of ofbiz for our own company and would see if it would fit with a pilot. In the same we have created a Team for ofbiz related work. So now as a result I can help to contribute few resources in the areas of documentation, testing (both functional as well unit testing) along with performance testing. The following is the area I have divided the teams: 1. CRM, Marketing, POS 2. Finance 3. Ecommerce 4. Supply Chain. Now from each team (i.e. above functional area) can provide 1 to 2 resources working on the documentation testing and configuration (including Seed data update) of the ofbiz. They will devote atleast 1-2 hours every day on ofbiz. Indeed from next week they will constantly be working on it. So please if David Jones and others could provide a outline or guide so that these resources can help ofbiz in a optimal way. As the people who would be coming are fairly new to this framework I would expect more contribution on the application testing and documentation side and slowly they would be able to help with core coding. These are all staffs paid to work on ofbiz in general. Thanks with best regards, Vikrant MySQL connections in the database connection pool time out (usually set to 8 hours). Possible workarounds(?): 1. Increase the time out value and hope that someone will connect to OFBiz before the connections time out. 2. Fix OFBiz to allow to a "validateQuery" mechanism. 3. Use PostgreSQL. In Tomcat, we usually use the "validateQuery" so the DBCP will test each connection before giving it to the application. If all connections in the pool has timed out (say no one has accessed OFBiz in 8 hours), the DBCP creates new connections for the pool. If someone will tell me that this doesn't happen for PostgreSQL, I'll simply make the switch to PostgreSQL rather than fix things in OFBiz for MySQL. Thanks. Jonathon Sorry, it's "validationQuery", not validateQuery. Jonathon Jonathon -- Improov wrote: > MySQL connections in the database connection pool time out (usually set > to 8 hours). Possible workarounds(?): > > 1. Increase the time out value and hope that someone will connect to OFBiz > before the connections time out. > > 2. Fix OFBiz to allow to a "validateQuery" mechanism. > > 3. Use PostgreSQL. > > In Tomcat, we usually use the "validateQuery" so the DBCP will test each > connection before giving it to the application. If all connections in > the pool has timed out (say no one has accessed OFBiz in 8 hours), the > DBCP creates new connections for the pool. > > If someone will tell me that this doesn't happen for PostgreSQL, I'll > simply make the switch to PostgreSQL rather than fix things in OFBiz for > MySQL. > > Thanks. > > Jonathon > This does not occur in PostgreSQL. It is a "feature" of MySQL and they (mysql) will smugly say that OFBiz doesn't handle the connection pool correctly. I don't know and don't really care to know if it's true or not. I switched over about 2 months ago and have had smooth sailing since (even seemingly eliminated that UserLoginHistory bug that you're aware of). Be warned, it's a bit of a pain to convert from MySQL to Postgres. Most of the issues seem to be of how lax MySQL with data and how stringent PostgreSQL is(at least the default installation). These were some of the issues I came across with my data using the export/import in webtools 1. the createdBy fields in the various entities weren't in the correct case (i believe this has been solved in OFBiz, I just had data that predated the fix) 2. UserLogin and Party entites end up with a circular dependency based on the partyId admin if the UserLogin admin created parties. Either load the single Party record for partyId before loading the UserLogin entity or remove the createdBy data from the Party entity 3. Heirarchial parent->child relationships. This occurs with the *Type entities. They simply need to be loaded in the correct order. There is a JIRA issue which solves this problem for about the *Type entities where the child is childId and the parent is parentChildId (e.g. partyTypeId -> parentPartyTypeId) There may have been other referential integrity issues, but I think they were self created and not created by OFBiz. --- Jonathon -- Improov <[hidden email]> wrote: > MySQL connections in the database connection pool time out (usually > set to 8 hours). Possible > workarounds(?): > > 1. Increase the time out value and hope that someone will connect to > OFBiz > before the connections time out. > > 2. Fix OFBiz to allow to a "validateQuery" mechanism. > > 3. Use PostgreSQL. > > In Tomcat, we usually use the "validateQuery" so the DBCP will test > each connection before giving > it to the application. If all connections in the pool has timed out > (say no one has accessed OFBiz > in 8 hours), the DBCP creates new connections for the pool. > > If someone will tell me that this doesn't happen for PostgreSQL, I'll > simply make the switch to > PostgreSQL rather than fix things in OFBiz for MySQL. > > Thanks. > > Jonathon > Chris, Wow, thanks. You sound like you've really been through it (the migration). Seems like quite a pain migrating to PostgreSQL from MySQL. But what if I don't have data to migrate? What if I just start over with PostgreSQL? Any problems? I'll take your advice regarding the migration gotchas. Thanks. Actually, about DBCPs. For RDBMSes, it's correct for database connections to time out after a set interval of inactivity. That's just prudence. When connections are used inside of DBCPs, it is the DBCP's responsibility to refresh timed out connections in the pool. I did my very first very own DBCP more than a decade ago, and that was one of the must-have functionalities for a DBCP. I was beaten up real bad for missing that out. :) The fix for this, in OFBiz, is in OFBiz's DBCP --- XAPoolDataSource. I posted another message asking for the source codes to ofbiz-minerva.jar. Jonathon Chris Howe wrote: > This does not occur in PostgreSQL. It is a "feature" of MySQL and they > (mysql) will smugly say that OFBiz doesn't handle the connection pool > correctly. I don't know and don't really care to know if it's true or > not. I switched over about 2 months ago and have had smooth sailing > since (even seemingly eliminated that UserLoginHistory bug that you're > aware of). > > Be warned, it's a bit of a pain to convert from MySQL to Postgres. > Most of the issues seem to be of how lax MySQL with data and how > stringent PostgreSQL is(at least the default installation). These were > some of the issues I came across with my data using the export/import > in webtools > > 1. the createdBy fields in the various entities weren't in the correct > case (i believe this has been solved in OFBiz, I just had data that > predated the fix) > 2. UserLogin and Party entites end up with a circular dependency based > on the partyId admin if the UserLogin admin created parties. Either > load the single Party record for partyId before loading the UserLogin > entity or remove the createdBy data from the Party entity > 3. Heirarchial parent->child relationships. This occurs with the *Type > entities. They simply need to be loaded in the correct order. There > is a JIRA issue which solves this problem for about the *Type entities > where the child is childId and the parent is parentChildId (e.g. > partyTypeId -> parentPartyTypeId) > > There may have been other referential integrity issues, but I think > they were self created and not created by OFBiz. > > --- Jonathon -- Improov <[hidden email]> wrote: > >> MySQL connections in the database connection pool time out (usually >> set to 8 hours). Possible >> workarounds(?): >> >> 1. Increase the time out value and hope that someone will connect to >> OFBiz >> before the connections time out. >> >> 2. Fix OFBiz to allow to a "validateQuery" mechanism. >> >> 3. Use PostgreSQL. >> >> In Tomcat, we usually use the "validateQuery" so the DBCP will test >> each connection before giving >> it to the application. If all connections in the pool has timed out >> (say no one has accessed OFBiz >> in 8 hours), the DBCP creates new connections for the pool. >> >> If someone will tell me that this doesn't happen for PostgreSQL, I'll >> simply make the switch to >> PostgreSQL rather than fix things in OFBiz for MySQL. >> >> Thanks. >> >> Jonathon >> > > Most of the data migration issues should be solvable by reading the migration data files (entity-engine-xml) into a Xindice XML database and running ofbiz services from there. This will allow XPath queries for the hierarchical stuff, and XUpdate of children elements for error messages and thus group error handling using XPath. I hope to be able to get some of this together shortly as we've been using OFBiz to slowly bring our legacy data in line with the OFBiz data model and the legacy data is still in MySQL (and much more critical and can't really take the risk that I "think" I changed the right data). If you don't have data, there shouldn't be any issue. Simply run the ant run-install with a delegator calling the postgres datasource. The impression I get is that most of the community in production is using postgres unless they've purchased a license to a mssql or oracle. My limited reading through mailing lists on mysql and postgres show that the timeout handling should be handled by the client (ofbiz) and that mysql decided to provided an additional safe gaurd by moving an excessive, configurable, "catch-all" timeout to the server. One of my favorite things about OFBiz is that you can get pretty far in developing something useful without ever knowing or worrying about database administration like this and can come back and address it when you're fine tuning your deployment for bottlenecks before going live. --- Jonathon -- Improov <[hidden email]> wrote: > Chris, > > Wow, thanks. You sound like you've really been through it (the > migration). > > Seems like quite a pain migrating to PostgreSQL from MySQL. But what > if I don't have data to > migrate? What if I just start over with PostgreSQL? Any problems? > I'll take your advice regarding > the migration gotchas. Thanks. > > Actually, about DBCPs. For RDBMSes, it's correct for database > connections to time out after a set > interval of inactivity. That's just prudence. When connections are > used inside of DBCPs, it is the > DBCP's responsibility to refresh timed out connections in the pool. I > did my very first very own > DBCP more than a decade ago, and that was one of the must-have > functionalities for a DBCP. I was > beaten up real bad for missing that out. :) > > The fix for this, in OFBiz, is in OFBiz's DBCP --- XAPoolDataSource. > I posted another message > asking for the source codes to ofbiz-minerva.jar. > > Jonathon > > Chris Howe wrote: > > This does not occur in PostgreSQL. It is a "feature" of MySQL and > they > > (mysql) will smugly say that OFBiz doesn't handle the connection > pool > > correctly. I don't know and don't really care to know if it's true > or > > not. I switched over about 2 months ago and have had smooth > sailing > > since (even seemingly eliminated that UserLoginHistory bug that > you're > > aware of). > > > > Be warned, it's a bit of a pain to convert from MySQL to Postgres. > > Most of the issues seem to be of how lax MySQL with data and how > > stringent PostgreSQL is(at least the default installation). These > were > > some of the issues I came across with my data using the > export/import > > in webtools > > > > 1. the createdBy fields in the various entities weren't in the > correct > > case (i believe this has been solved in OFBiz, I just had data that > > predated the fix) > > 2. UserLogin and Party entites end up with a circular dependency > based > > on the partyId admin if the UserLogin admin created parties. > Either > > load the single Party record for partyId before loading the > UserLogin > > entity or remove the createdBy data from the Party entity > > 3. Heirarchial parent->child relationships. This occurs with the > *Type > > entities. They simply need to be loaded in the correct order. > There > > is a JIRA issue which solves this problem for about the *Type > entities > > where the child is childId and the parent is parentChildId (e.g. > > partyTypeId -> parentPartyTypeId) > > > > There may have been other referential integrity issues, but I think > > they were self created and not created by OFBiz. > > > > --- Jonathon -- Improov <[hidden email]> wrote: > > > >> MySQL connections in the database connection pool time out > (usually > >> set to 8 hours). Possible > >> workarounds(?): > >> > >> 1. Increase the time out value and hope that someone will connect > to > >> OFBiz > >> before the connections time out. > >> > >> 2. Fix OFBiz to allow to a "validateQuery" mechanism. > >> > >> 3. Use PostgreSQL. > >> > >> In Tomcat, we usually use the "validateQuery" so the DBCP will > test > >> each connection before giving > >> it to the application. If all connections in the pool has timed > out > >> (say no one has accessed OFBiz > >> in 8 hours), the DBCP creates new connections for the pool. > >> > >> If someone will tell me that this doesn't happen for PostgreSQL, > I'll > >> simply make the switch to > >> PostgreSQL rather than fix things in OFBiz for MySQL. > >> > >> Thanks. > >> > >> Jonathon > >> > > > > > > Read this post: *http://www.nabble.com/MySQL-connection-problem-tf2486297.html#a9092103 / Hans * Jonathon -- Improov skrev: > MySQL connections in the database connection pool time out (usually > set to 8 hours). Possible workarounds(?): > > 1. Increase the time out value and hope that someone will connect to > OFBiz > before the connections time out. > > 2. Fix OFBiz to allow to a "validateQuery" mechanism. > > 3. Use PostgreSQL. > > In Tomcat, we usually use the "validateQuery" so the DBCP will test > each connection before giving it to the application. If all > connections in the pool has timed out (say no one has accessed OFBiz > in 8 hours), the DBCP creates new connections for the pool. > > If someone will tell me that this doesn't happen for PostgreSQL, I'll > simply make the switch to PostgreSQL rather than fix things in OFBiz > for MySQL. > > Thanks. > > Jonathon > > Hans, Thanks. That's the precise fix I needed. Why isn't it in the SVN trunk? Jonathon Hans Holmlund wrote: > Read this post: > *http://www.nabble.com/MySQL-connection-problem-tf2486297.html#a9092103 > > / Hans > * > Jonathon -- Improov skrev: >> MySQL connections in the database connection pool time out (usually >> set to 8 hours). Possible workarounds(?): >> >> 1. Increase the time out value and hope that someone will connect to >> OFBiz >> before the connections time out. >> >> 2. Fix OFBiz to allow to a "validateQuery" mechanism. >> >> 3. Use PostgreSQL. >> >> In Tomcat, we usually use the "validateQuery" so the DBCP will test >> each connection before giving it to the application. If all >> connections in the pool has timed out (say no one has accessed OFBiz >> in 8 hours), the DBCP creates new connections for the pool. >> >> If someone will tell me that this doesn't happen for PostgreSQL, I'll >> simply make the switch to PostgreSQL rather than fix things in OFBiz >> for MySQL. >> >> Thanks. >> >> Jonathon >> >> > > Chris, You mean go from MySQL to Xindice to PostgreSQL? Yeah, I know, data migration can be a pain, even without data-mapping efforts to go with it (ie, same structure migrated to same structure). > My limited reading through mailing lists on mysql and postgres show that the > timeout handling should be handled by the client (ofbiz) and that mysql > decided to provided an additional safe gaurd by moving an excessive, > configurable, "catch-all" timeout to the server. If you're saying that a DBCP should assume that a DB connection can never time out (always good), I rest my case. :) Personally, I think MySQL could've provided the option to drop the time out feature. FYI to all. If Hans is right, it appears OFBiz's DBCP XAPoolDataSource does handle connection time out after all! I'll check it out. Anyway, the fix, as mentioned by Hans, can be done in MinervaConnectionFactory. I'm gonna try just that. Problem solved. On with real work. You're right, OFBiz does abstract tons of infrastructure details away from application developers. Would be good if we can get our hands on the XAPoolDataSource source codes, just to confirm that the issue is fixed. Jonathon Chris Howe wrote: > Most of the data migration issues should be solvable by reading the > migration data files (entity-engine-xml) into a Xindice XML database > and running ofbiz services from there. This will allow XPath queries > for the hierarchical stuff, and XUpdate of children elements for error > messages and thus group error handling using XPath. I hope to be able > to get some of this together shortly as we've been using OFBiz to > slowly bring our legacy data in line with the OFBiz data model and the > legacy data is still in MySQL (and much more critical and can't really > take the risk that I "think" I changed the right data). > > If you don't have data, there shouldn't be any issue. Simply run the > ant run-install with a delegator calling the postgres datasource. The > impression I get is that most of the community in production is using > postgres unless they've purchased a license to a mssql or oracle. > > My limited reading through mailing lists on mysql and postgres show > that the timeout handling should be handled by the client (ofbiz) and > that mysql decided to provided an additional safe gaurd by moving an > excessive, configurable, "catch-all" timeout to the server. > > One of my favorite things about OFBiz is that you can get pretty far in > developing something useful without ever knowing or worrying about > database administration like this and can come back and address it when > you're fine tuning your deployment for bottlenecks before going live. > > --- Jonathon -- Improov <[hidden email]> wrote: > >> Chris, >> >> Wow, thanks. You sound like you've really been through it (the >> migration). >> >> Seems like quite a pain migrating to PostgreSQL from MySQL. But what >> if I don't have data to >> migrate? What if I just start over with PostgreSQL? Any problems? >> I'll take your advice regarding >> the migration gotchas. Thanks. >> >> Actually, about DBCPs. For RDBMSes, it's correct for database >> connections to time out after a set >> interval of inactivity. That's just prudence. When connections are >> used inside of DBCPs, it is the >> DBCP's responsibility to refresh timed out connections in the pool. I >> did my very first very own >> DBCP more than a decade ago, and that was one of the must-have >> functionalities for a DBCP. I was >> beaten up real bad for missing that out. :) >> >> The fix for this, in OFBiz, is in OFBiz's DBCP --- XAPoolDataSource. >> I posted another message >> asking for the source codes to ofbiz-minerva.jar. >> >> Jonathon >> >> Chris Howe wrote: >>> This does not occur in PostgreSQL. It is a "feature" of MySQL and >> they >>> (mysql) will smugly say that OFBiz doesn't handle the connection >> pool >>> correctly. I don't know and don't really care to know if it's true >> or >>> not. I switched over about 2 months ago and have had smooth >> sailing >>> since (even seemingly eliminated that UserLoginHistory bug that >> you're >>> aware of). >>> >>> Be warned, it's a bit of a pain to convert from MySQL to Postgres. >>> Most of the issues seem to be of how lax MySQL with data and how >>> stringent PostgreSQL is(at least the default installation). These >> were >>> some of the issues I came across with my data using the >> export/import >>> in webtools >>> >>> 1. the createdBy fields in the various entities weren't in the >> correct >>> case (i believe this has been solved in OFBiz, I just had data that >>> predated the fix) >>> 2. UserLogin and Party entites end up with a circular dependency >> based >>> on the partyId admin if the UserLogin admin created parties. >> Either >>> load the single Party record for partyId before loading the >> UserLogin >>> entity or remove the createdBy data from the Party entity >>> 3. Heirarchial parent->child relationships. This occurs with the >> *Type >>> entities. They simply need to be loaded in the correct order. >> There >>> is a JIRA issue which solves this problem for about the *Type >> entities >>> where the child is childId and the parent is parentChildId (e.g. >>> partyTypeId -> parentPartyTypeId) >>> >>> There may have been other referential integrity issues, but I think >>> they were self created and not created by OFBiz. >>> >>> --- Jonathon -- Improov <[hidden email]> wrote: >>> >>>> MySQL connections in the database connection pool time out >> (usually >>>> set to 8 hours). Possible >>>> workarounds(?): >>>> >>>> 1. Increase the time out value and hope that someone will connect >> to >>>> OFBiz >>>> before the connections time out. >>>> >>>> 2. Fix OFBiz to allow to a "validateQuery" mechanism. >>>> >>>> 3. Use PostgreSQL. >>>> >>>> In Tomcat, we usually use the "validateQuery" so the DBCP will >> test >>>> each connection before giving >>>> it to the application. If all connections in the pool has timed >> out >>>> (say no one has accessed OFBiz >>>> in 8 hours), the DBCP creates new connections for the pool. >>>> >>>> If someone will tell me that this doesn't happen for PostgreSQL, >> I'll >>>> simply make the switch to >>>> PostgreSQL rather than fix things in OFBiz for MySQL. >>>> >>>> Thanks. >>>> >>>> Jonathon >>>> >>> >> > > The fix to support validationQuery could be done in ofbiz-minerva.jar. Is the source code provided, or do we have to roll our own if we want things fixed or enhanced? The validationQuery feature refreshes timed out connections in a DBCP. Timing out inactive connections in a DBCP is common and correct behavior in RDBMSes, to prevent resource hogs. This issue is related to any RDBMS that times out inactive connections after a set interval of inactivity, not just MySQL. OT: Does PostgreSQL not time out inactive connections? Jonathon Hi All, I am getting the following error while creating the new user from the lcnewcustomer.ftl page. Expression uiLabelMap is undefined on line 112, column 39 in lcnewcustomer.ftl. The problematic instruction: ---------- ==> ${uiLabelMap.PartyFirstName} [on line 112, column 37 in lcnewcustomer.ftl] ---------- Java backtrace for programmers: ---------- freemarker.core.InvalidReferenceException: Expression uiLabelMap is undefined on line 112 ........ Dont have idea to resolve this. Someone please help me regarding this issue. Thanks. chitrkala You need to have this in your main-decorator screen: <property-map resource="PartyUiLabels" map-name="uiLabelMap" global="true"/> Regards Scott On 13 Apr 2007 05:27:58 -0000, chitrakala ramanujam < [hidden email]> wrote: > > > Hi All, > > I am getting the following error while creating the new user from the > lcnewcustomer.ftl page. > > > Expression uiLabelMap is undefined on line 112, column 39 in > lcnewcustomer.ftl. The problematic instruction: ---------- ==> ${ > uiLabelMap.PartyFirstName} [on line 112, column 37 in lcnewcustomer.ftl] > ---------- Java backtrace for programmers: ---------- > freemarker.core.InvalidReferenceException: Expression uiLabelMap is > undefined on line 112 > ........ > > Dont have idea to resolve this. > > Someone please help me regarding this issue. > > Thanks. > chitrkala ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html |
In reply to this post by jonwimp
Jonathon -- Improov wrote:
> For some projects that are blazingly fast in progress, their core team > even takes it upon themselves to rewrite submitted patches that are not > readily digestible. A submitted/suggested patch is still better than a > complaint alone. The reality of the OFBiz community is this: it is a community of volunteers. Those volunteers have limited time. If anyone wants to contribute to the project, they need to do so in a way that will not consume an unneccesary amount of the volunteer's time. I think Cameron's contribution has value. I would like to see it committed to the project. I am willing to evaluate his work, but I DO NOT have the time to rewrite his submission. That's the cold, hard reality of it. |
In reply to this post by jonwimp
It might be more helpful for everyone to consider a couple of things: 1. there is no such thing as an OFBiz team that drives the project; OFBiz is a community-driven project and there is no core team that serves the users of the software, only a smaller group that acts as moderators for the community, and anyone with sufficient experience and involvement in the project can become part of that group 2. OFBiz is a very large software project with lots of people involved that covers complicated requirements, and uses some very complex infrastructure; the direct result of this is that it takes a lot of commitment and effort for anyone to participate in the project... I don't believe there is any way around this In general very few people, even among the OFBiz committers, work on the priorities of other people. We are all here to collaborate and work together, each pushing our own priorities as they arise. The responsibility of the committers is to moderate these efforts to align with a bigger picture so that the project doesn't devolve into total chaos. As for the BSH contribution in question, that is a tough one because even though there are various committers only 2-3 of the group are really qualified to evaluate and commit this. Hopefully it will get in sooner or later, but until it becomes a priority or of interest to one of the few, keeping in mind it competes with dozens of other outstanding issues and efforts at any given time, that just won't happen. Hopefully this helps people understand and come to terms with the reality of the project a bit more. -David On Apr 12, 2007, at 8:31 PM, Jonathon -- Improov wrote: > Adrian, Cameron, > > I agree with Adrian that the "rest of us" should submit patches in > a standard format, so that the "few of them (committers/reviewers)" > can efficiently go through them. > > But I also agree with Cameron that his process of tidying up his > patch, documenting it, etc, took too much time for no effect. > > Without going into arguing about whether Cameron's patch is really > "standard digestible format" for the committers, I'd say in general > that this is the way open source projects are. To be fair to OFBiz, > I know many other open source projects that have bug reports (and > submitted patches) sitting untouched for months, even years. > > At the end of the day, how fast OFBiz progresses depends on how > fast it aligns itself with market demand, demand in this case > meaning user requirements, users like Cameron and Adrian and myself. > > For some projects that are blazingly fast in progress, their core > team even takes it upon themselves to rewrite submitted patches > that are not readily digestible. A submitted/suggested patch is > still better than a complaint alone. > > However, I do admit that we (users) sometimes submit invalid > complaints or bug reports or infeasible feature requests. I guess > the key is to politely turn away the "weird" users, and keep the > good ones (those who are great testers, good market feelers, > possibly even strong coders themselves). > > So, in conclusion, nobody is wrong here. OFBiz team has to make a > choice about prioritizing our submitted JIRA issues or patches, > since resources will always be limited. On the other hand, users > (like Adrian, Cameron, etc) will have to "alter their contribution > behavior" accordingly. All we can hope for is that those of us who > were submitting suggestions wrongly will in time learn to do so > correctly; and those who were reviewing suggestions wrongly could > possibly learn too. > > Whatever our "altered behaviors" are, we face the consequences > fairly. If I choose to drop OFBiz due to such "grunges", I must > accept a big loss of a great platform. If OFBiz chooses to "drop" > users like me, OFBiz must rely on the other 399 users to help spur > OFBiz growth. (Just a hypothetical statement for illustration; I'm > NOT dropping OFBiz!!) > > Like Cameron says, the benefits of OFBiz far outweighs such > "grunges". :) > > Jonathon > > Adrian Crum wrote: >> Cameron, >> I haven't been following this thread closely, but your last reply >> caught my attention - so I'm kind of jumping in at the last moment. >> I looked at the Jira issue Jacopo mentioned, and I agree with what >> was said in that issue and in Jacopo's reply. If you want to see >> anything in Jira included in the main project, then you have to >> follow certain standards. The same applies if you just want people >> to take a look at it and comment on it. >> I would like to evaluate your contribution, but I can't do it in >> the form it is in. I need the ability to download a patch and >> examine what files the patch affects. Annyone else in the >> community would evaluate your contribution in the same way. >> Not too long ago I was in the same position you're in. I had >> submitted contributions to Jira and they just sat there - for the >> same reason yours is. After David and others pointed out to me >> what was wrong with them, I took steps to get my contributions to >> follow OFBiz standards and then my work started making its way >> into the project. >> -Adrian >> Cameron Smith wrote: >>> Yes, Jacopo. That's the issue I was talking about. With all due >>> respect, though, I don't think you got the point of my JIRA post. >>> Perhaps I didn't write it clearly enough. >>> >>> I uploaded this JIRA issue specifically for it to be committed to >>> the trunk, after several people on the ML suggested I do so. It >>> would benefit me as well, as it means less differences from the >>> trunk for "my company's OFBiz". >>> >>> I made some specific requests for people more familiar with the >>> codebase than I to review certain aspects, rather than simply >>> "committing it and hope for the best", which seems to be the >>> normal OFBiz approach (yes, I am in the camp that favours >>> branching unless we have automated regression tests). >>> >>> Given how heavily OFBiz depends on beanshell, I think you can >>> understand why I took this aproach. The alternative would be to >>> commit and then wait for loads of screens to be broken for the >>> next several weeks. >>> >>> The most obvious reviewer, David himself, was too busy the last >>> time I contacted him and I am not going to hassle him about it! >>> He has and continues to contribute an enormous amount of time, >>> often thanklessly, to the project. >>> >>> This was a grungy piece of work to do. I had to do it because >>> otherwise we couldn't use the UI framework we wanted, and I >>> reckoned that the many benefits brought by ofbiz outweighed the >>> costs of the grunge. Once I had achieved my goal, I then spent >>> another several hours tidying up, testing and writing it up in JIRA. >>> >>> I would be quite happy if a commiter wrote back and said "we're >>> not going to use this fix". Fair enough. But just leaving it >>> sitting there?? To a certain extent this is the norm on any >>> decentralized project. But projects do differ, and that is why I >>> alter my contribution behaviour based on the "behaviour" of each >>> project. >>> >>> anyway, cheers, >>> cameron >>> >>> >>> >>> >>> ___________________________________________________________ >>> Yahoo! Mail is the world's favourite email. Don't settle for >>> less, sign up for >>> your free account today http://uk.rd.yahoo.com/evt=44106/*http:// >>> uk.docs.yahoo.com/mail/winter07.html > smime.p7s (3K) Download Attachment |
Free forum by Nabble | Edit this page |