Leaving OFBiz for a while

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Leaving OFBiz for a while

Cameron Smith-6
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 
Reply | Threaded
Open this post in threaded view
|

Re: Leaving OFBiz for a while

Adrian Crum
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 
>
Reply | Threaded
Open this post in threaded view
|

Re: Leaving OFBiz for a while

jonwimp
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 
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Leaving OFBiz for a while

Cameron Smith-6
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
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
> > > >> >
> > > >>
> > > >>
> > >
> > >
> >
> >
>


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
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.



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:
>
http://www.nabble.com/Default-User---Passwords-tf3565946.html#a9960968
> 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 
Reply | Threaded
Open this post in threaded view
|

Re: Leaving OFBiz for a while

Adrian Crum
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.
Reply | Threaded
Open this post in threaded view
|

Re: Leaving OFBiz for a while

David E Jones
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