[jira] [Commented] (OFBIZ-6271) build management with maven
[ https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14528535#comment-14528535 ] Adam Heath commented on OFBIZ-6271: --- Um, do you fully understand maven? This is not the right approach. Maven has a distribute mirror network; your suggestion of an ofbiz-hosted private repo would preclude that. Ofbiz is no different than any other big project, why do you think INFRA would allow us to host this repo? When defining a dependency in a pom, it's possible to tell maven to *not* pull in *any* transitive deps, or to override the version of a dep, or to exclude just one transitive dep. Also, a private external repo is not needed. I already have the currently-checked-in jar files being used, without defining a top-level repository in a pom. Plus, having a top-level repository defined is very much bad form. There are so many things wrong with your paragraph, do you actually understand what maven can actually do? build management with maven --- Key: OFBIZ-6271 URL: https://issues.apache.org/jira/browse/OFBIZ-6271 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Reporter: Adam Heath Priority: Minor Attachments: console.log This is a new build system; the primary goal will be to not require any changes to existing ofbiz layouts(for backwards compatibility, at least initially). These pom.xml files are completely new; the existing build.xml infrastructure will continue to exist. The existing build.xml will never call into maven(which is what processes the pom.xml), and maven will never call into build.xml either. I have already committed a working pom.xml for the top level, and framework/start. Shortly, I will be adding framework/base and framework/entity, but into this branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6271) build management with maven
[ https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14528552#comment-14528552 ] Adam Heath commented on OFBIZ-6271: --- Hahaha. That guy is an idiot. Seriously. Don't blame the tool for bad developers. I gave a talk at ApacheCon just recently, showing how to use ofbiz and docker together. Do you think I just randomly download stuff from the internet, every single time? I don't, because I understand the point of trusted build, and security. Docker itself is really really really bad for security on downloaded image layers. It has a message that says verified when it has fetched remote data, but the data was retrieved over http, and the hashsum in the metadata is *not* checked. All that verified message means is that the metadata was syntactically correct! I rebuild my base image layers using debootstrap(I don't trust the debian or ubuntu image flavors). This is all based on apt-get stuff. The only thing I download is wp-cli, but that's not being fully utilized, and I don't actually download it automatically(it's a manual step, so could be verified by the developer). So, I've taken this tool(docker), and used the parts that are good, and not the parts that are bad. ps: This is not a rant at you, Jacques. pps: I'm close to having my docker+ofbiz scripts ready. I have a repo already with most of my stuff on github, it just needs a bit of documentation. build management with maven --- Key: OFBIZ-6271 URL: https://issues.apache.org/jira/browse/OFBIZ-6271 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Reporter: Adam Heath Priority: Minor Attachments: console.log This is a new build system; the primary goal will be to not require any changes to existing ofbiz layouts(for backwards compatibility, at least initially). These pom.xml files are completely new; the existing build.xml infrastructure will continue to exist. The existing build.xml will never call into maven(which is what processes the pom.xml), and maven will never call into build.xml either. I have already committed a working pom.xml for the top level, and framework/start. Shortly, I will be adding framework/base and framework/entity, but into this branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6271) build management with maven
[ https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14526790#comment-14526790 ] Adam Heath commented on OFBIZ-6271: --- What Jacques is asking about, are all the other non-build targets in the build.xml. Aka, load-demo, start, etc. I've been struggling(not with the implementation, but with the where) on how to deal with those targets in a maven world. Maven is a *build system*, while ant's build.xml is just a series of commands(targets) that have names and do something, and might also require other things to run first(depends). There really isn't a simple way to just add callable commands to maven's pom.xml structures. I've played with making each called target from ant by a non-default-activated profile. I then attempted to inline each target body using maven-antrun-plugin, but that was ugly. I then have switched to moving the special targets to a separate external build.xml snippet, which is then called by both ant and maven. This latter method actually seems like it would be generally useful, even without maven in use. Aka, the top-level build.xml, and all the internal component build.xml, should just be for building/deploying ofbiz. The extra cli targets at the top-level should be in a separate location(similar to how we have that top-level tools folder). For backwards compatibility, top-level would need to call the external targets for a time being. Does that make sense? build management with maven --- Key: OFBIZ-6271 URL: https://issues.apache.org/jira/browse/OFBIZ-6271 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Reporter: Adam Heath Priority: Minor Attachments: console.log This is a new build system; the primary goal will be to not require any changes to existing ofbiz layouts(for backwards compatibility, at least initially). These pom.xml files are completely new; the existing build.xml infrastructure will continue to exist. The existing build.xml will never call into maven(which is what processes the pom.xml), and maven will never call into build.xml either. I have already committed a working pom.xml for the top level, and framework/start. Shortly, I will be adding framework/base and framework/entity, but into this branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6271) build management with maven
[ https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14527418#comment-14527418 ] Adam Heath commented on OFBIZ-6271: --- Yes, no, both. I want maven to be have the ability to call load-demo, create-tenant, etc. I want ant to be able to call into maven, for the actual build. So, as a plan, the special non-build targets in the top-level build.xml get extracted out, to be placed into a single file, shared by both build systems. Then, both systems can call into this shared file. For a time, both build systems are maintained in parallel, with mostly identical features. This to give developers a time to acclimate. After a time, switch ant to call into maven for the build targets, but still leave the targets in build.xml. Add a deprecation message. Even more time, remove the build.xml from all of ofbiz. build management with maven --- Key: OFBIZ-6271 URL: https://issues.apache.org/jira/browse/OFBIZ-6271 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Reporter: Adam Heath Priority: Minor Attachments: console.log This is a new build system; the primary goal will be to not require any changes to existing ofbiz layouts(for backwards compatibility, at least initially). These pom.xml files are completely new; the existing build.xml infrastructure will continue to exist. The existing build.xml will never call into maven(which is what processes the pom.xml), and maven will never call into build.xml either. I have already committed a working pom.xml for the top level, and framework/start. Shortly, I will be adding framework/base and framework/entity, but into this branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6271) build management with maven
[ https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14527421#comment-14527421 ] Adam Heath commented on OFBIZ-6271: --- I also struggled with moving the list of tasks from top-level build.xml into some piece of compiled code. However, those top-level tasks are really short scriptlets, batch files, shell scripts, whatever. So, making full-on java code doesn't really work either, and would be harder to maintain(in theory). This is still a bit of an open-ended issue. And, honestly, now that I am here, I'm actually kind of curious about that other elephant, aka, gradle. build management with maven --- Key: OFBIZ-6271 URL: https://issues.apache.org/jira/browse/OFBIZ-6271 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Reporter: Adam Heath Priority: Minor Attachments: console.log This is a new build system; the primary goal will be to not require any changes to existing ofbiz layouts(for backwards compatibility, at least initially). These pom.xml files are completely new; the existing build.xml infrastructure will continue to exist. The existing build.xml will never call into maven(which is what processes the pom.xml), and maven will never call into build.xml either. I have already committed a working pom.xml for the top level, and framework/start. Shortly, I will be adding framework/base and framework/entity, but into this branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6271) build management with maven
[ https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14524204#comment-14524204 ] Adam Heath commented on OFBIZ-6271: --- Ok, quick update. Building a single component is not possible, by going into applications/product, and doing a mvn clean compile. However, there is a maven way to do it: == mvn -pl org.apache.ofbiz:ofbiz-product compile == Doing this from the top-level will then deal with just the list of artifacts(you can give several). Also, you can use -am which will also run the goals against everything the project list *depends* on, which is actually way cool. == mvn -am -pl org.apache.ofbiz:ofbiz-product clean package == The above command will not only deal with product, but base, entity, security, service, common, content, party, webapp. Note, that widget and entityext(and others) are not included. build management with maven --- Key: OFBIZ-6271 URL: https://issues.apache.org/jira/browse/OFBIZ-6271 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Reporter: Adam Heath Priority: Minor Attachments: console.log This is a new build system; the primary goal will be to not require any changes to existing ofbiz layouts(for backwards compatibility, at least initially). These pom.xml files are completely new; the existing build.xml infrastructure will continue to exist. The existing build.xml will never call into maven(which is what processes the pom.xml), and maven will never call into build.xml either. I have already committed a working pom.xml for the top level, and framework/start. Shortly, I will be adding framework/base and framework/entity, but into this branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6271) build management with maven
[
https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14519855#comment-14519855
]
Adam Heath commented on OFBIZ-6271:
---
THANK YOU ADRIAN!
So, this seems to work. All those scary warnings at the top about the
systemPath are normal; maven does *not* like using pre-installed files, and it
doesn't know that ${user.home} ends up being in the local checkout. The
warnings will go away once the jars are actually downloaded.
build management with maven
---
Key: OFBIZ-6271
URL: https://issues.apache.org/jira/browse/OFBIZ-6271
Project: OFBiz
Issue Type: Improvement
Components: ALL COMPONENTS
Reporter: Adam Heath
Priority: Minor
Attachments: console.log
This is a new build system; the primary goal will be to not require any
changes to existing ofbiz layouts(for backwards compatibility, at least
initially).
These pom.xml files are completely new; the existing build.xml infrastructure
will continue to exist. The existing build.xml will never call into
maven(which is what processes the pom.xml), and maven will never call into
build.xml either.
I have already committed a working pom.xml for the top level, and
framework/start. Shortly, I will be adding framework/base and
framework/entity, but into this branch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6217) fix warnings in trunk on java source code
[ https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14514269#comment-14514269 ] Adam Heath commented on OFBIZ-6217: --- And, be very very very careful about anything to do with generics. Use of the UtilGenerics.cast() should be *extremely* minimized. fix warnings in trunk on java source code - Key: OFBIZ-6217 URL: https://issues.apache.org/jira/browse/OFBIZ-6217 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Taher Alkhateeb Assignee: Adrian Crum Priority: Minor Labels: java, warning Fix For: Upcoming Branch Attachments: OFBIZ-6217-patch-4.patch, remove_unused_imports.patch, warnings_patch_2.patch, warnings_patch_2.patch Right now, we have 528 warnings on trunk out of which 238 are about raw types and 118 never used imports. So we can already eliminate most of the warning quite quickly. I will issue multiple patches to resolve most of these warnings. It might be a bit of a challenge to eliminate the raw types because the generics are not always deducable from the code especially when relying on external APIs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6217) fix warnings in trunk on java source code
[ https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14514317#comment-14514317 ] Adam Heath commented on OFBIZ-6217: --- Don't use UtilGenerics.cast() on an external lib call, if there is an update for that external lib that adds generics support. Upgrading that external lib to a new generics-capable version is outside the scope of this issue, so in that case, just ignore the warnings. File a separate issue, asking to get that external lib upgraded. Cross-link the 2 issues. When the lib is upgraded, then proceed with fixing the warnings(if they exist). But, in theory, the other new issue would hit upon changes to the generics markup, so would need to fix it there. As for the deprecation warnings, I've fixed all simple ones, except for any non-macro widget rendering. I've made a branch with all my changes. Please see the OFBIZ_6275 issue that Jacques mentioned. fix warnings in trunk on java source code - Key: OFBIZ-6217 URL: https://issues.apache.org/jira/browse/OFBIZ-6217 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Taher Alkhateeb Assignee: Adrian Crum Priority: Minor Labels: java, warning Fix For: Upcoming Branch Attachments: OFBIZ-6217-patch-4.patch, remove_unused_imports.patch, warnings_patch_2.patch, warnings_patch_2.patch Right now, we have 528 warnings on trunk out of which 238 are about raw types and 118 never used imports. So we can already eliminate most of the warning quite quickly. I will issue multiple patches to resolve most of these warnings. It might be a bit of a challenge to eliminate the raw types because the generics are not always deducable from the code especially when relying on external APIs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8
[ https://issues.apache.org/jira/browse/OFBIZ-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-6300: - Assignee: Adam Heath Compiler-Error with JDK 1.8 and source compatibility 1.8 Key: OFBIZ-6300 URL: https://issues.apache.org/jira/browse/OFBIZ-6300 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk Reporter: Martin Becker Assignee: Adam Heath I just found another error compiling the code with JDK 1.8 with source code compatibility switched to 1.8 in my eclipse workspace. The external ant build is working because there is java version 1.7 defined as target in the macros.xml. The error is an issue regarding generics in EntityFieldMap.java. I will provide a patch her soon. The code is the same in the release branches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8
[ https://issues.apache.org/jira/browse/OFBIZ-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511204#comment-14511204 ] Adam Heath commented on OFBIZ-6300: --- I have been getting additional generics warnings when using 1.8 to compile in 1.7 mode; I'm not surprised if there are actual errors in 1.8 mode as well. I had been meaning to create a 1.8 compile target top-level issue, but hadn't yet gotten to it. So, before the patch promised is accepted, I'd like to create a top-level catch-all, and link this into it, maybe. Compiler-Error with JDK 1.8 and source compatibility 1.8 Key: OFBIZ-6300 URL: https://issues.apache.org/jira/browse/OFBIZ-6300 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk Reporter: Martin Becker Assignee: Adam Heath I just found another error compiling the code with JDK 1.8 with source code compatibility switched to 1.8 in my eclipse workspace. The external ant build is working because there is java version 1.7 defined as target in the macros.xml. The error is an issue regarding generics in EntityFieldMap.java. I will provide a patch her soon. The code is the same in the release branches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6291) Update code to check for types rather than throw ClassCastException
[ https://issues.apache.org/jira/browse/OFBIZ-6291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509305#comment-14509305 ] Adam Heath commented on OFBIZ-6291: --- int i = foo... isn't the part that is slower. The instanceOf pattern is slower. Good debuggers can check the return value of the expression before returnning, without the need for a local variable. It introduces additional noise. Also, I'm differing to Adrian here, who has a bit more familiarity with that code; I have added this to my list of things to check, but I'm working on several other branches right now against trunk, so please be patient. Update code to check for types rather than throw ClassCastException --- Key: OFBIZ-6291 URL: https://issues.apache.org/jira/browse/OFBIZ-6291 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Gareth Carter Priority: Trivial Attachments: LocalizedConverters.patch, minilang_compare.patch, minilang_compare_r1675655.patch framework/minilang/src/org/ofbiz/minilang/method/conditional/Compare.java framework/base/src/org/ofbiz/base/util/ObjectType.java framework/minilang/src/org/ofbiz/minilang/MiniLangUtil.java all throw ClassCastExceptions and are ignored instead of checking types This caused issues in debugging when adding a ClassCastException breakpoint -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6291) Update code to check for types rather than throw ClassCastException
[ https://issues.apache.org/jira/browse/OFBIZ-6291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509267#comment-14509267 ] Adam Heath commented on OFBIZ-6291: --- * The patch introduces new blank lines; that should be done separately. * int i = foo.compareTo(baz); return i = 0; this is an anti-pattern. Remove the use of the local variable. Also, doing if (foo instanceof Bar), then casting with (Bar), is slower, than just attempting the cast, and catching an exception. If the fast-path items are done first, then no throw ever happens, and you don't waste cycles on the instanceOf operator, and the jump that happens. I haven't attempted to apply the patch, I was just reading it, but a smell test seems to say -1. Also, I have done some unit tests against ObjectType in the past; I don't know how current they still are. The change to an instanceOf condiitional needs to pass those tests, and, should also be done with cobertura, and the code coverage should stay the same before and after. But that all hinges on the currentness of the unit testing. Update code to check for types rather than throw ClassCastException --- Key: OFBIZ-6291 URL: https://issues.apache.org/jira/browse/OFBIZ-6291 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Gareth Carter Priority: Trivial Attachments: LocalizedConverters.patch, minilang_compare.patch framework/minilang/src/org/ofbiz/minilang/method/conditional/Compare.java framework/base/src/org/ofbiz/base/util/ObjectType.java framework/minilang/src/org/ofbiz/minilang/MiniLangUtil.java all throw ClassCastExceptions and are ignored instead of checking types This caused issues in debugging when adding a ClassCastException breakpoint -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6290) ButtonEventConfig uses getXmlRootElement which has been deprecated
[ https://issues.apache.org/jira/browse/OFBIZ-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507350#comment-14507350 ] Adam Heath commented on OFBIZ-6290: --- [javac17] /srv/ofbiz/apache-git/specialpurpose/pos/src/org/ofbiz/pos/config/ButtonEventConfig.java:55: warning: [deprecation] getXmlRootElement(String) in ResourceLoader has been deprecated [javac17] Element root = ResourceLoader.getXmlRootElement(ButtonEventConfig.BUTTON_EVENT_CONFIG); [javac17] ^ ButtonEventConfig uses getXmlRootElement which has been deprecated -- Key: OFBIZ-6290 URL: https://issues.apache.org/jira/browse/OFBIZ-6290 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/pos Reporter: Adam Heath Assignee: Adam Heath Priority: Minor ResourceLoader.getXmlRootElement() caches its return value; however, DOM elements are memory intensive, and the returned value tends to only be used once. So, this is a poor pattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6289) Oagis classes are making use of the deprecated html rendering system
Adam Heath created OFBIZ-6289: - Summary: Oagis classes are making use of the deprecated html rendering system Key: OFBIZ-6289 URL: https://issues.apache.org/jira/browse/OFBIZ-6289 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/oagis Reporter: Adam Heath Priority: Minor More of the same; oagis classes are using the deprecated html rendering system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6289) Oagis classes are making use of the deprecated html rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507321#comment-14507321 ] Adam Heath commented on OFBIZ-6289: --- [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:67: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:67: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:67: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:76: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17]^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:76: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:193: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] ScreenRenderer screens = new ScreenRenderer(writer, bodyParameters, new HtmlScreenRenderer()); [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:74: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17]^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:74: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17] ^ Oagis classes are making use of the deprecated html rendering system Key: OFBIZ-6289 URL: https://issues.apache.org/jira/browse/OFBIZ-6289 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/oagis Reporter: Adam Heath Priority: Minor More of the same; oagis classes are using the deprecated html rendering system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6290) ButtonEventConfig uses getXmlRootElement which has been deprecated
Adam Heath created OFBIZ-6290: - Summary: ButtonEventConfig uses getXmlRootElement which has been deprecated Key: OFBIZ-6290 URL: https://issues.apache.org/jira/browse/OFBIZ-6290 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/pos Reporter: Adam Heath Assignee: Adam Heath Priority: Minor ResourceLoader.getXmlRootElement() caches its return value; however, DOM elements are memory intensive, and the returned value tends to only be used once. So, this is a poor pattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6270) base/json/JSON has been removed, with no deprecation window
[ https://issues.apache.org/jira/browse/OFBIZ-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507330#comment-14507330 ] Adam Heath commented on OFBIZ-6270: --- Because I plan on also adding test cases(which were also removed); they will probably even be based on the removed test case classes. And, since I haven't yet done the work, and I am following the release-first/release-often workflow, I created a branch early, and committed code early, in case anyone else wants to work with me. base/json/JSON has been removed, with no deprecation window --- Key: OFBIZ-6270 URL: https://issues.apache.org/jira/browse/OFBIZ-6270 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk, 12.04.04 Reporter: Adam Heath Assignee: Adam Heath Priority: Critical The antlr-based json parser(at org.ofbiz.base.json.JSON.cc) was removed last October(2014-10-27). However, no backwards-compatible class was left in place, with a proper @Deprecation tag applied. The proper approach should have been to leave the class in place, adding @Deprecation, and leaving the json-lib.jar in place. Then, after one successful release, removing the actual code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6289) Oagis classes are making use of the deprecated html rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507342#comment-14507342 ] Adam Heath commented on OFBIZ-6289: --- These need to be switched to a macro system. Oagis classes are making use of the deprecated html rendering system Key: OFBIZ-6289 URL: https://issues.apache.org/jira/browse/OFBIZ-6289 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/oagis Reporter: Adam Heath Priority: Minor More of the same; oagis classes are using the deprecated html rendering system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6290) ButtonEventConfig uses getXmlRootElement which has been deprecated
[ https://issues.apache.org/jira/browse/OFBIZ-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507352#comment-14507352 ] Adam Heath commented on OFBIZ-6290: --- Same problem, don't use a cached version of this method. ButtonEventConfig uses getXmlRootElement which has been deprecated -- Key: OFBIZ-6290 URL: https://issues.apache.org/jira/browse/OFBIZ-6290 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/pos Reporter: Adam Heath Assignee: Adam Heath Priority: Minor ResourceLoader.getXmlRootElement() caches its return value; however, DOM elements are memory intensive, and the returned value tends to only be used once. So, this is a poor pattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6276) Fix deprecation issues in framework/entity
Adam Heath created OFBIZ-6276: - Summary: Fix deprecation issues in framework/entity Key: OFBIZ-6276 URL: https://issues.apache.org/jira/browse/OFBIZ-6276 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor It appears that the storeAll() variants are being refactor; basically, the useCache parameter is being removed. However, this has caused the entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-6278) JNDIConfigUtil makes use of deprecated getXmlRootElement
[ https://issues.apache.org/jira/browse/OFBIZ-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-6278: - Assignee: Adam Heath JNDIConfigUtil makes use of deprecated getXmlRootElement Key: OFBIZ-6278 URL: https://issues.apache.org/jira/browse/OFBIZ-6278 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath ResourceLoader.getXmlRootElement caches it's return value; this has been deprecated, because DOM objects are memory intensive, and generally are only needed once. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6278) JNDIConfigUtil makes use of deprecated getXmlRootElement
Adam Heath created OFBIZ-6278: - Summary: JNDIConfigUtil makes use of deprecated getXmlRootElement Key: OFBIZ-6278 URL: https://issues.apache.org/jira/browse/OFBIZ-6278 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath ResourceLoader.getXmlRootElement caches it's return value; this has been deprecated, because DOM objects are memory intensive, and generally are only needed once. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6281) Many classes in framework/widget are still using html-based renderers, instead of macro-based
[ https://issues.apache.org/jira/browse/OFBIZ-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507256#comment-14507256 ] Adam Heath commented on OFBIZ-6281: --- [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/ScreenFopViewHandler.java:46: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/ScreenFopViewHandler.java:46: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/ScreenFopViewHandler.java:46: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/FoFormRenderer.java:82: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] writer.append(FoScreenRenderer.getFoStyle(widgetStyle)); [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/FoFormRenderer.java:208: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] writer.append(FoScreenRenderer.getFoStyle(areaStyle)); [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/FoFormRenderer.java:290: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] writer.append(FoScreenRenderer.getFoStyle(areaStyle)); [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/ScreenFopViewHandler.java:132: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] ScreenRenderer screens = new ScreenRenderer(writer, null, new HtmlScreenRenderer()); [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/html/HtmlTreeRenderer.java:337: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated
[jira] [Updated] (OFBIZ-6278) JNDIConfigUtil makes use of deprecated getXmlRootElement
[ https://issues.apache.org/jira/browse/OFBIZ-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath updated OFBIZ-6278: -- Priority: Minor (was: Major) JNDIConfigUtil makes use of deprecated getXmlRootElement Key: OFBIZ-6278 URL: https://issues.apache.org/jira/browse/OFBIZ-6278 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor ResourceLoader.getXmlRootElement caches it's return value; this has been deprecated, because DOM objects are memory intensive, and generally are only needed once. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6279) UtilDateTime has an ImmutableDate inner class that has deprecation warnings
[ https://issues.apache.org/jira/browse/OFBIZ-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath updated OFBIZ-6279: -- Component/s: framework UtilDateTime has an ImmutableDate inner class that has deprecation warnings --- Key: OFBIZ-6279 URL: https://issues.apache.org/jira/browse/OFBIZ-6279 Project: OFBiz Issue Type: Sub-task Components: ALL COMPONENTS, framework Reporter: Adam Heath Assignee: Adam Heath When extending/implementing a class/interface, where methods in the parent have been marked deprecated, sub-instances also get deprecation warnings. The fix here is to also mark the sub-instances deprecated(with @Deprecated or /** @deprecated */ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6280) SecurityFactory implements methods that have been deprecated
[ https://issues.apache.org/jira/browse/OFBIZ-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath updated OFBIZ-6280: -- Priority: Minor (was: Major) SecurityFactory implements methods that have been deprecated Key: OFBIZ-6280 URL: https://issues.apache.org/jira/browse/OFBIZ-6280 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor This class implements Security, which has methods that have been deprecated. As such, it gets deprecation warnings when implementing those methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6279) UtilDateTime has an ImmutableDate inner class that has deprecation warnings
[ https://issues.apache.org/jira/browse/OFBIZ-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath updated OFBIZ-6279: -- Component/s: (was: ALL COMPONENTS) UtilDateTime has an ImmutableDate inner class that has deprecation warnings --- Key: OFBIZ-6279 URL: https://issues.apache.org/jira/browse/OFBIZ-6279 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath When extending/implementing a class/interface, where methods in the parent have been marked deprecated, sub-instances also get deprecation warnings. The fix here is to also mark the sub-instances deprecated(with @Deprecated or /** @deprecated */ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6285) OutputServices uses the deprecated fo widget rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507279#comment-14507279 ] Adam Heath commented on OFBIZ-6285: --- Same type of problems. OutputServices uses the deprecated fo widget rendering system - Key: OFBIZ-6285 URL: https://issues.apache.org/jira/browse/OFBIZ-6285 Project: OFBiz Issue Type: Sub-task Components: content Reporter: Adam Heath Priority: Minor Yet again, another instance of hard-coded rendering being used instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6279) UtilDateTime has an ImmutableDate inner class that has deprecation warnings
[
https://issues.apache.org/jira/browse/OFBIZ-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507250#comment-14507250
]
Adam Heath commented on OFBIZ-6279:
---
[javac17]
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1197:
warning: [deprecation] setYear(int) in Date has been deprecated
[javac17] public void setYear(int year) {
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1202:
warning: [deprecation] setMonth(int) in Date has been deprecated
[javac17] public void setMonth(int month) {
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1207:
warning: [deprecation] setDate(int) in Date has been deprecated
[javac17] public void setDate(int date) {
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1212:
warning: [deprecation] setHours(int) in Date has been deprecated
[javac17] public void setHours(int hours) {
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1217:
warning: [deprecation] setMinutes(int) in Date has been deprecated
[javac17] public void setMinutes(int minutes) {
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1222:
warning: [deprecation] setSeconds(int) in Date has been deprecated
[javac17] public void setSeconds(int seconds) {
[javac17] ^
UtilDateTime has an ImmutableDate inner class that has deprecation warnings
---
Key: OFBIZ-6279
URL: https://issues.apache.org/jira/browse/OFBIZ-6279
Project: OFBiz
Issue Type: Sub-task
Components: ALL COMPONENTS
Reporter: Adam Heath
Assignee: Adam Heath
When extending/implementing a class/interface, where methods in the parent
have been marked deprecated, sub-instances also get deprecation warnings.
The fix here is to also mark the sub-instances deprecated(with @Deprecated or
/** @deprecated */
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OFBIZ-6280) SecurityFactory implements methods that have been deprecated
Adam Heath created OFBIZ-6280: - Summary: SecurityFactory implements methods that have been deprecated Key: OFBIZ-6280 URL: https://issues.apache.org/jira/browse/OFBIZ-6280 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath This class implements Security, which has methods that have been deprecated. As such, it gets deprecation warnings when implementing those methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6284) ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
[
https://issues.apache.org/jira/browse/OFBIZ-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507268#comment-14507268
]
Adam Heath commented on OFBIZ-6284:
---
[javac17]
/srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/artifactinfo/ServiceArtifactInfo.java:96:
warning: [deprecation] getAllEntityNamesUsed() in SimpleMethod has been
deprecated
[javac17] SetString allEntityNameSet =
simpleMethodToCall.getAllEntityNamesUsed();
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/artifactinfo/ServiceArtifactInfo.java:156:
warning: [deprecation] getAllServiceNamesCalled() in SimpleMethod has been
deprecated
[javac17] SetString allServiceNameSet =
simpleMethodToCall.getAllServiceNamesCalled();
[javac17] ^
ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
-
Key: OFBIZ-6284
URL: https://issues.apache.org/jira/browse/OFBIZ-6284
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Adam Heath
Priority: Minor
I can't comment to much on this; the methods that have been marked deprecated
have no javadocs, nothing to indicate why they should no longer be used. I
haven't checked the commit log, however.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6287) BirtEmailServices uses the deprecated html rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507284#comment-14507284 ] Adam Heath commented on OFBIZ-6287: --- [javac17] /srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:54: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:54: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:54: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:61: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17]^ [javac17] /srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:61: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17] ^ BirtEmailServices uses the deprecated html rendering system --- Key: OFBIZ-6287 URL: https://issues.apache.org/jira/browse/OFBIZ-6287 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/birt Reporter: Adam Heath Priority: Minor Yet another instance of html rendering being used instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6287) BirtEmailServices uses the deprecated html rendering system
Adam Heath created OFBIZ-6287: - Summary: BirtEmailServices uses the deprecated html rendering system Key: OFBIZ-6287 URL: https://issues.apache.org/jira/browse/OFBIZ-6287 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/birt Reporter: Adam Heath Priority: Minor Yet another instance of html rendering being used instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity
[
https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507231#comment-14507231
]
Adam Heath commented on OFBIZ-6276:
---
[javac17]
/srv/ofbiz/apache-git/framework/entity/src/org/ofbiz/entity/GenericDelegator.java:1415:
warning: [deprecation] storeAll(ListGenericValue,boolean,boolean) in
Delegator has been deprecated
[javac17] public int storeAll(ListGenericValue values, boolean
doCacheClear, boolean createDummyFks) throws GenericEntityException {
[javac17]^
[javac17]
/srv/ofbiz/apache-git/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:329:
warning: [deprecation] storeAll(ListGenericValue,boolean,boolean) in
Delegator has been deprecated
[javac17] delegator.storeAll(valuesToWrite, doCacheClear,
createDummyFks);
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:498:
warning: [deprecation] removeAll(List? extends GenericEntity,boolean) in
Delegator has been deprecated
[javac17]
delegator.removeAll(valuesToDelete, doCacheClear);
[javac17] ^
Fix deprecation issues in framework/entity
--
Key: OFBIZ-6276
URL: https://issues.apache.org/jira/browse/OFBIZ-6276
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Adam Heath
Priority: Minor
It appears that the storeAll() variants are being refactor; basically, the
useCache parameter is being removed. However, this has caused the
entity engine to have deprecation with itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6278) JNDIConfigUtil makes use of deprecated getXmlRootElement
[ https://issues.apache.org/jira/browse/OFBIZ-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507248#comment-14507248 ] Adam Heath commented on OFBIZ-6278: --- [javac17] /srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/config/JNDIConfigUtil.java:39: warning: [deprecation] getXmlRootElement(String) in ResourceLoader has been deprecated [javac17] return ResourceLoader.getXmlRootElement(JNDIConfigUtil.JNDI_CONFIG_XML_FILENAME); [javac17] ^ JNDIConfigUtil makes use of deprecated getXmlRootElement Key: OFBIZ-6278 URL: https://issues.apache.org/jira/browse/OFBIZ-6278 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath ResourceLoader.getXmlRootElement caches it's return value; this has been deprecated, because DOM objects are memory intensive, and generally are only needed once. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6281) Many classes in framework/widget are still using html-based renderers, instead of macro-based
Adam Heath created OFBIZ-6281: - Summary: Many classes in framework/widget are still using html-based renderers, instead of macro-based Key: OFBIZ-6281 URL: https://issues.apache.org/jira/browse/OFBIZ-6281 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor The html renderers had hard-coded output. A new system had been developed, which uses macros; this allowed for swapping the output with something more or less advanced, without having to change the code. However, many classes are still using the old rendering system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6283) A few classes in webtools make use of the html widget rendering system
Adam Heath created OFBIZ-6283: - Summary: A few classes in webtools make use of the html widget rendering system Key: OFBIZ-6283 URL: https://issues.apache.org/jira/browse/OFBIZ-6283 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor The html rendering system is deprecated in favor of a macro-based approach. These classes should be updated to use the new system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6286) SagePay classes make use of deprecated httpclient features
Adam Heath created OFBIZ-6286: - Summary: SagePay classes make use of deprecated httpclient features Key: OFBIZ-6286 URL: https://issues.apache.org/jira/browse/OFBIZ-6286 Project: OFBiz Issue Type: Sub-task Components: accounting Reporter: Adam Heath Priority: Minor I have not checked httpclient upstream to see what should be used in place of the deprecated classes/methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6286) SagePay classes make use of deprecated httpclient features
[ https://issues.apache.org/jira/browse/OFBIZ-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507282#comment-14507282 ] Adam Heath commented on OFBIZ-6286: --- [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:41: warning: [deprecation] DefaultHtt pClient in org.apache.http.impl.client has been deprecated [javac17] import org.apache.http.impl.client.DefaultHttpClient; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:43: warning: [deprecation] BasicHttpP arams in org.apache.http.params has been deprecated [javac17] import org.apache.http.params.BasicHttpParams; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:44: warning: [deprecation] HttpParams in org.apache.http.params has been deprecated [javac17] import org.apache.http.params.HttpParams; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:41: warning: [deprecation] DefaultHttpClient in org.apache.http.impl.client has been deprecated [javac17] import org.apache.http.impl.client.DefaultHttpClient; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:43: warning: [deprecation] BasicHttpParams in org.apache.http.params has been deprecated [javac17] import org.apache.http.params.BasicHttpParams; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:44: warning: [deprecation] HttpParams in org.apache.http.params has been deprecated [javac17] import org.apache.http.params.HttpParams; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:41: warning: [deprecation] DefaultHttpClient in org.apache.http.impl.client has been deprecated [javac17] import org.apache.http.impl.client.DefaultHttpClient; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:43: warning: [deprecation] BasicHttpParams in org.apache.http.params has been deprecated [javac17] import org.apache.http.params.BasicHttpParams; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:44: warning: [deprecation] HttpParams in org.apache.http.params has been deprecated [javac17] import org.apache.http.params.HttpParams; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:282: warning: [deprecation] getConnectionManager() in HttpClient has been deprecated [javac17] httpClient.getConnectionManager().shutdown(); [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:378: warning: [deprecation] getConnectionManager() in HttpClient has been deprecated [javac17] httpClient.getConnectionManager().shutdown(); [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:472: warning: [deprecation] getConnectionManager() in HttpClient has been deprecated [javac17] httpClient.getConnectionManager().shutdown(); [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:564: warning: [deprecation] getConnectionManager() in HttpClient has been deprecated [javac17] httpClient.getConnectionManager().shutdown(); [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:675: warning: [deprecation] getConnectionManager() in HttpClient has been deprecated [javac17] httpClient.getConnectionManager().shutdown(); [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:164: warning: [deprecation] HttpParams in org.apache.http.params has been deprecated [javac17] HttpParams params = new BasicHttpParams(); [javac17] ^ [javac17]
[jira] [Commented] (OFBIZ-6277) framework/entity makes use of deprecated class Configuration
[ https://issues.apache.org/jira/browse/OFBIZ-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507239#comment-14507239 ] Adam Heath commented on OFBIZ-6277: --- [javac17] /srv/ofbiz/apache-git/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:379: warning: [deprecation] Configuration() in Configuration has been deprecated [javac17] Configuration config = new Configuration(); [javac17]^ framework/entity makes use of deprecated class Configuration Key: OFBIZ-6277 URL: https://issues.apache.org/jira/browse/OFBIZ-6277 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor EntitySaxReader makes use of freemarker.template.Configuration, which seems to be deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6277) framework/entity makes use of deprecated class Configuration
Adam Heath created OFBIZ-6277: - Summary: framework/entity makes use of deprecated class Configuration Key: OFBIZ-6277 URL: https://issues.apache.org/jira/browse/OFBIZ-6277 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor EntitySaxReader makes use of freemarker.template.Configuration, which seems to be deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6282) EmailServices is making use the html widget rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507260#comment-14507260 ] Adam Heath commented on OFBIZ-6282: --- These 2 issues have similar problems. EmailServices is making use the html widget rendering system Key: OFBIZ-6282 URL: https://issues.apache.org/jira/browse/OFBIZ-6282 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor The html rendering system has been replaced by a macro version; EmailServices still uses the old form. This should be fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6282) EmailServices is making use the html widget rendering system
Adam Heath created OFBIZ-6282: - Summary: EmailServices is making use the html widget rendering system Key: OFBIZ-6282 URL: https://issues.apache.org/jira/browse/OFBIZ-6282 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor The html rendering system has been replaced by a macro version; EmailServices still uses the old form. This should be fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6283) A few classes in webtools make use of the html widget rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507264#comment-14507264 ] Adam Heath commented on OFBIZ-6283: --- [javac17] /srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:40: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:40: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:40: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:49: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] private static HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17]^ [javac17] /srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:49: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] private static HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17]^ A few classes in webtools make use of the html widget rendering system -- Key: OFBIZ-6283 URL: https://issues.apache.org/jira/browse/OFBIZ-6283 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor The html rendering system is deprecated in favor of a macro-based approach. These classes should be updated to use the new system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6285) OutputServices uses the deprecated fo widget rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507277#comment-14507277 ] Adam Heath commented on OFBIZ-6285: --- [javac17] /srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:66: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] import org.ofbiz.widget.renderer.fo.FoScreenRenderer; [javac17]^ [javac17] /srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:66: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] import org.ofbiz.widget.renderer.fo.FoScreenRenderer; [javac17]^ [javac17] /srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:66: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] import org.ofbiz.widget.renderer.fo.FoScreenRenderer; [javac17]^ [javac17] /srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:77: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] protected static final FoScreenRenderer foScreenRenderer = new FoScreenRenderer(); [javac17]^ [javac17] /srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:77: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] protected static final FoScreenRenderer foScreenRenderer = new FoScreenRenderer(); [javac17]^ OutputServices uses the deprecated fo widget rendering system - Key: OFBIZ-6285 URL: https://issues.apache.org/jira/browse/OFBIZ-6285 Project: OFBiz Issue Type: Sub-task Components: content Reporter: Adam Heath Priority: Minor Yet again, another instance of hard-coded rendering being used instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6287) BirtEmailServices uses the deprecated html rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507285#comment-14507285 ] Adam Heath commented on OFBIZ-6287: --- More instances BirtEmailServices uses the deprecated html rendering system --- Key: OFBIZ-6287 URL: https://issues.apache.org/jira/browse/OFBIZ-6287 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/birt Reporter: Adam Heath Priority: Minor Yet another instance of html rendering being used instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6288) ExamplePrintServices uses the deprecated html rendering system
Adam Heath created OFBIZ-6288: - Summary: ExamplePrintServices uses the deprecated html rendering system Key: OFBIZ-6288 URL: https://issues.apache.org/jira/browse/OFBIZ-6288 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/example Reporter: Adam Heath Priority: Minor Another case of html rendering in use instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6279) UtilDateTime has an ImmutableDate inner class that has deprecation warnings
Adam Heath created OFBIZ-6279: - Summary: UtilDateTime has an ImmutableDate inner class that has deprecation warnings Key: OFBIZ-6279 URL: https://issues.apache.org/jira/browse/OFBIZ-6279 Project: OFBiz Issue Type: Sub-task Reporter: Adam Heath Assignee: Adam Heath When extending/implementing a class/interface, where methods in the parent have been marked deprecated, sub-instances also get deprecation warnings. The fix here is to also mark the sub-instances deprecated(with @Deprecated or /** @deprecated */ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6280) SecurityFactory implements methods that have been deprecated
[
https://issues.apache.org/jira/browse/OFBIZ-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507252#comment-14507252
]
Adam Heath commented on OFBIZ-6280:
---
[javac17]
/srv/ofbiz/apache-git/framework/security/src/org/ofbiz/security/SecurityFactory.java:264:
warning: [deprecation] securityGroupPermissionExists(String,String) in
Security has been deprecated
[javac17] public boolean securityGroupPermissionExists(String
groupId, String permission) {
[javac17]^
[javac17]
/srv/ofbiz/apache-git/framework/security/src/org/ofbiz/security/SecurityFactory.java:105:
warning: [deprecation] findUserLoginSecurityGroupByUserLoginId(String) in
Security has been deprecated
[javac17] public IteratorGenericValue
findUserLoginSecurityGroupByUserLoginId(String userLoginId) {
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/security/src/org/ofbiz/security/SecurityFactory.java:274:
warning: [deprecation] setDelegator(Delegator) in Security has been deprecated
[javac17] public void setDelegator(Delegator delegator) {
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/security/src/org/ofbiz/security/SecurityFactory.java:116:
warning: [deprecation] getDelegator() in Security has been deprecated
[javac17] public Delegator getDelegator() {
[javac17] ^
SecurityFactory implements methods that have been deprecated
Key: OFBIZ-6280
URL: https://issues.apache.org/jira/browse/OFBIZ-6280
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Adam Heath
Assignee: Adam Heath
This class implements Security, which has methods that have been deprecated.
As such, it gets deprecation warnings when implementing those methods.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6283) A few classes in webtools make use of the html widget rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507265#comment-14507265 ] Adam Heath commented on OFBIZ-6283: --- Again, similar problems. A few classes in webtools make use of the html widget rendering system -- Key: OFBIZ-6283 URL: https://issues.apache.org/jira/browse/OFBIZ-6283 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor The html rendering system is deprecated in favor of a macro-based approach. These classes should be updated to use the new system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6284) ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
Adam Heath created OFBIZ-6284:
-
Summary: ServiceArtifactInfo uses deprecated
getAll{Object}Names{Verb}
Key: OFBIZ-6284
URL: https://issues.apache.org/jira/browse/OFBIZ-6284
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Adam Heath
Priority: Minor
I can't comment to much on this; the methods that have been marked deprecated
have no javadocs, nothing to indicate why they should no longer be used. I
haven't checked the commit log, however.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OFBIZ-6285) OutputServices uses the deprecated fo widget rendering system
Adam Heath created OFBIZ-6285: - Summary: OutputServices uses the deprecated fo widget rendering system Key: OFBIZ-6285 URL: https://issues.apache.org/jira/browse/OFBIZ-6285 Project: OFBiz Issue Type: Sub-task Components: content Reporter: Adam Heath Priority: Minor Yet again, another instance of hard-coded rendering being used instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6288) ExamplePrintServices uses the deprecated html rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507293#comment-14507293 ] Adam Heath commented on OFBIZ-6288: --- [javac17] /srv/ofbiz/apache-git/specialpurpose/example/src/org/ofbiz/example/ExamplePrintServices.java:52: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/example/src/org/ofbiz/example/ExamplePrintServices.java:52: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/example/src/org/ofbiz/example/ExamplePrintServices.java:52: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/example/src/org/ofbiz/example/ExamplePrintServices.java:58: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] private static HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17]^ [javac17] /srv/ofbiz/apache-git/specialpurpose/example/src/org/ofbiz/example/ExamplePrintServices.java:58: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] private static HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17]^ ExamplePrintServices uses the deprecated html rendering system -- Key: OFBIZ-6288 URL: https://issues.apache.org/jira/browse/OFBIZ-6288 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/example Reporter: Adam Heath Priority: Minor Another case of html rendering in use instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6288) ExamplePrintServices uses the deprecated html rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507313#comment-14507313 ] Adam Heath commented on OFBIZ-6288: --- Old(html) rendering system instead of macro rendering. ExamplePrintServices uses the deprecated html rendering system -- Key: OFBIZ-6288 URL: https://issues.apache.org/jira/browse/OFBIZ-6288 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/example Reporter: Adam Heath Priority: Minor Another case of html rendering in use instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OFBIZ-6278) JNDIConfigUtil makes use of deprecated getXmlRootElement
[ https://issues.apache.org/jira/browse/OFBIZ-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath resolved OFBIZ-6278. --- Resolution: Fixed Fixed in branch OFBIZ-6275, r1675465 JNDIConfigUtil makes use of deprecated getXmlRootElement Key: OFBIZ-6278 URL: https://issues.apache.org/jira/browse/OFBIZ-6278 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor ResourceLoader.getXmlRootElement caches it's return value; this has been deprecated, because DOM objects are memory intensive, and generally are only needed once. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OFBIZ-6280) SecurityFactory implements methods that have been deprecated
[ https://issues.apache.org/jira/browse/OFBIZ-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath resolved OFBIZ-6280. --- Resolution: Fixed Fixed in branch OFBIZ-6275, r1675463 SecurityFactory implements methods that have been deprecated Key: OFBIZ-6280 URL: https://issues.apache.org/jira/browse/OFBIZ-6280 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor This class implements Security, which has methods that have been deprecated. As such, it gets deprecation warnings when implementing those methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OFBIZ-6290) ButtonEventConfig uses getXmlRootElement which has been deprecated
[ https://issues.apache.org/jira/browse/OFBIZ-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath resolved OFBIZ-6290. --- Resolution: Fixed Fixed in branch OFBIZ-6275, r1675466 ButtonEventConfig uses getXmlRootElement which has been deprecated -- Key: OFBIZ-6290 URL: https://issues.apache.org/jira/browse/OFBIZ-6290 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/pos Reporter: Adam Heath Assignee: Adam Heath Priority: Minor ResourceLoader.getXmlRootElement() caches its return value; however, DOM elements are memory intensive, and the returned value tends to only be used once. So, this is a poor pattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OFBIZ-6279) UtilDateTime has an ImmutableDate inner class that has deprecation warnings
[ https://issues.apache.org/jira/browse/OFBIZ-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath resolved OFBIZ-6279. --- Resolution: Fixed Fixed in branch OFBIZ-6275, r1675462 UtilDateTime has an ImmutableDate inner class that has deprecation warnings --- Key: OFBIZ-6279 URL: https://issues.apache.org/jira/browse/OFBIZ-6279 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath When extending/implementing a class/interface, where methods in the parent have been marked deprecated, sub-instances also get deprecation warnings. The fix here is to also mark the sub-instances deprecated(with @Deprecated or /** @deprecated */ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OFBIZ-6284) ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
[
https://issues.apache.org/jira/browse/OFBIZ-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Heath resolved OFBIZ-6284.
---
Resolution: Fixed
This is resolved in branch OFBIZ-6275, r1675520
ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
-
Key: OFBIZ-6284
URL: https://issues.apache.org/jira/browse/OFBIZ-6284
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Adam Heath
Assignee: Adam Heath
Priority: Minor
I can't comment to much on this; the methods that have been marked deprecated
have no javadocs, nothing to indicate why they should no longer be used. I
haven't checked the commit log, however.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6270) base/json/JSON has been removed, with no deprecation window
[ https://issues.apache.org/jira/browse/OFBIZ-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508221#comment-14508221 ] Adam Heath commented on OFBIZ-6270: --- Also, just because ofbiz upstream has changed things, and between 1 official release, has deprecated something(and/or removed the code), external vendors might need to support extensions that have to run against multiple versions of ofbiz. Having the ability to run this external code on both versions of ofbiz at the same time makes it easier to slowly upgrade the client systems, without having a flag day across everything. base/json/JSON has been removed, with no deprecation window --- Key: OFBIZ-6270 URL: https://issues.apache.org/jira/browse/OFBIZ-6270 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk, 12.04.04 Reporter: Adam Heath Assignee: Adam Heath Priority: Critical The antlr-based json parser(at org.ofbiz.base.json.JSON.cc) was removed last October(2014-10-27). However, no backwards-compatible class was left in place, with a proper @Deprecation tag applied. The proper approach should have been to leave the class in place, adding @Deprecation, and leaving the json-lib.jar in place. Then, after one successful release, removing the actual code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-6277) framework/entity makes use of deprecated class Configuration
[ https://issues.apache.org/jira/browse/OFBIZ-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-6277: - Assignee: Adam Heath framework/entity makes use of deprecated class Configuration Key: OFBIZ-6277 URL: https://issues.apache.org/jira/browse/OFBIZ-6277 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor EntitySaxReader makes use of freemarker.template.Configuration, which seems to be deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-6276) Fix deprecation issues in framework/entity
[ https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-6276: - Assignee: Adam Heath Fix deprecation issues in framework/entity -- Key: OFBIZ-6276 URL: https://issues.apache.org/jira/browse/OFBIZ-6276 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor It appears that the storeAll() variants are being refactor; basically, the useCache parameter is being removed. However, this has caused the entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-6284) ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
[
https://issues.apache.org/jira/browse/OFBIZ-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Heath reassigned OFBIZ-6284:
-
Assignee: Adam Heath
ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
-
Key: OFBIZ-6284
URL: https://issues.apache.org/jira/browse/OFBIZ-6284
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Adam Heath
Assignee: Adam Heath
Priority: Minor
I can't comment to much on this; the methods that have been marked deprecated
have no javadocs, nothing to indicate why they should no longer be used. I
haven't checked the commit log, however.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity
[ https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508164#comment-14508164 ] Adam Heath commented on OFBIZ-6276: --- When I first saw this deprecation warning, I thought it would be something simple. Even when I filed this issue, I held back on deep thought. However, the refactor that is being attempted around storeAll is very back for backwards compatibility. A parameter is being removed, that has critical meaning. I don't really think this is something that can safely be implemented. A new method name would need to be created to do that refactor. Fix deprecation issues in framework/entity -- Key: OFBIZ-6276 URL: https://issues.apache.org/jira/browse/OFBIZ-6276 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor It appears that the storeAll() variants are being refactor; basically, the useCache parameter is being removed. However, this has caused the entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OFBIZ-6277) framework/entity makes use of deprecated class Configuration
[ https://issues.apache.org/jira/browse/OFBIZ-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath resolved OFBIZ-6277. --- Resolution: Fixed This is resolved in branch OFBIZ-6275, r1675521 framework/entity makes use of deprecated class Configuration Key: OFBIZ-6277 URL: https://issues.apache.org/jira/browse/OFBIZ-6277 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor EntitySaxReader makes use of freemarker.template.Configuration, which seems to be deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-6276) Fix deprecation issues in framework/entity
[ https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-6276: - Assignee: (was: Adam Heath) Fix deprecation issues in framework/entity -- Key: OFBIZ-6276 URL: https://issues.apache.org/jira/browse/OFBIZ-6276 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor It appears that the storeAll() variants are being refactor; basically, the useCache parameter is being removed. However, this has caused the entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6271) build management with maven
[ https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14506028#comment-14506028 ] Adam Heath commented on OFBIZ-6271: --- Well, I just committed a bunch to this branch. Feature summary: * Dependencies are being listed. This is a big plus! * Some things done directly inside ant are now external; namely, the building of META-INF/services. * There are some src/main/resources and src/test/resources added to the project; existing tooling(aka, build.xml) needs might break; if so, then this particular item might have to be revisited. * Any kind of javadoc targets have not been attempted; this is a WIP. * I had done an ofbiz run with start and base compiled by maven, but hadn't yet attempted with entity, geronimo, and catalina. It might work, I'll check that. * I'd like to split out ofbiz-parent:pom into ofbiz-component:pom; this would reside at the same level as ofbiz-parent, and would more closely reflect the macros.xml/common.xml split. It also would allow for other children to be included without having to inherit the same kind of build process. Also, here are some commands to get everyone started: == mvn clean mvn clean package -DskipTests == build management with maven --- Key: OFBIZ-6271 URL: https://issues.apache.org/jira/browse/OFBIZ-6271 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Reporter: Adam Heath Priority: Minor This is a new build system; the primary goal will be to not require any changes to existing ofbiz layouts(for backwards compatibility, at least initially). These pom.xml files are completely new; the existing build.xml infrastructure will continue to exist. The existing build.xml will never call into maven(which is what processes the pom.xml), and maven will never call into build.xml either. I have already committed a working pom.xml for the top level, and framework/start. Shortly, I will be adding framework/base and framework/entity, but into this branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6270) base/json/JSON has been removed, with no deprecation window
[ https://issues.apache.org/jira/browse/OFBIZ-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14506007#comment-14506007 ] Adam Heath commented on OFBIZ-6270: --- When an external developer compiles their code, there is no class at that point in the tree. Nothing to mention that a deprecation has taken place. With this file added back(and with further documentation, which needs to be added), such a warning message will be shown. The entity system has gone through this deprecation cycle for many of its methods. Plus, this isn't some minor change to the name of a method, nor the addition or removal of some method parameter. This class was completely removed. No attempt at all was made to provide support for outside vendors. And this new class really is super simple. ps: I didn't implement all ways of using the previously existing code; namely, the resolve() logic is no longer valid, there is no way(I think) to request any of the available json object types(where calling code doesn't care if a map, list, number, string, boolean is returned), or some of the other features that were supported. base/json/JSON has been removed, with no deprecation window --- Key: OFBIZ-6270 URL: https://issues.apache.org/jira/browse/OFBIZ-6270 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk, 12.04.04 Reporter: Adam Heath Assignee: Adam Heath Priority: Critical The antlr-based json parser(at org.ofbiz.base.json.JSON.cc) was removed last October(2014-10-27). However, no backwards-compatible class was left in place, with a proper @Deprecation tag applied. The proper approach should have been to leave the class in place, adding @Deprecation, and leaving the json-lib.jar in place. Then, after one successful release, removing the actual code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6270) base/json/JSON has been removed, with no deprecation window
Adam Heath created OFBIZ-6270: - Summary: base/json/JSON has been removed, with no deprecation window Key: OFBIZ-6270 URL: https://issues.apache.org/jira/browse/OFBIZ-6270 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: 12.04.04, Trunk Reporter: Adam Heath Assignee: Adam Heath Priority: Critical The antlr-based json parser(at org.ofbiz.base.json.JSON.cc) was removed last October(2014-10-27). However, no backwards-compatible class was left in place, with a proper @Deprecation tag applied. The proper approach should have been to leave the class in place, adding @Deprecation, and leaving the json-lib.jar in place. Then, after one successful release, removing the actual code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6271) build management with maven
Adam Heath created OFBIZ-6271: - Summary: build management with maven Key: OFBIZ-6271 URL: https://issues.apache.org/jira/browse/OFBIZ-6271 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Reporter: Adam Heath Priority: Minor This is a new build system; the primary goal will be to not require any changes to existing ofbiz layouts(for backwards compatibility, at least initially). These pom.xml files are completely new; the existing build.xml infrastructure will continue to exist. The existing build.xml will never call into maven(which is what processes the pom.xml), and maven will never call into build.xml either. I have already committed a working pom.xml for the top level, and framework/start. Shortly, I will be adding framework/base and framework/entity, but into this branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14050267#comment-14050267
]
Adam Heath commented on OFBIZ-4053:
---
I'm leaning towards delegator.one()/delegator.list(), with list() being able to
have multiple result methods(I don't care on the name). This can be done
without adding any new methods to the Delegator interface, by making use of a
groovy Category. This will allow new methods to be mixed in automatically when
in a groovy file.
If you are in java, you'd have to be a bit more verbose, something like this:
{code:title=Query.java|BorderStyle=solid}
class Query {
private Query() {}
static Query use(Delegator delegator) { }
One one(String entityName) { }
List list(String entityName) { }
class QueryOne {
QueryOne where(String name, Object value) { }
QueryOne where(MapString, ? extends Object map) { }
QueryOne cache(String cache) { }
}
class QueryList {
QueryList where(String name, Object value) { }
QueryList where(MapString, ? extends Object map) { }
QueryList cache(String cache) { }
}
}
{code}
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14050636#comment-14050636
]
Adam Heath commented on OFBIZ-4053:
---
You don't want a find()/findList() call to cache when you are going to update
the value, so how do you suppose we would implement that?
And, if cache is not an option, how do you see the annotated calls being cached?
Plus, there are currently issues with view caching; These are the things I know
don't work:
* entity-conditon on a view
* entity-condition on a view-link
* nested views, to any depth(it's close, but broken by the above 2 items)
* complex alias
* not certain about function/group-by
Here's a rough example of a complex view:
{code}
ContactMechView
member:ContactMech
optional-member:TelecomNumber
optional-member:PostalAddress
PartyView:
member: Party
optional-member:Person
optional-member:PartyGroup
PartyContactMechView:
member:ContactMechView
member:PartyContactMech
optional-member:PartyContactMechPurpose
ProfileView:
member:PartyView
optional-member:PartyAttribute
condition: attrName: 'BF_TOKEN'
optional-member:PartyContactMechView
condition: contactMechPurposeTypeId: 'PRIMARY_EMAIL'
optional-member:PartyContactMechView
condition: contactMechPurposeTypeId: 'HOME_PHONE'
OrderView:
member:OrderHeader
member:OrderItems
ProfileAndOrderView:
member:ProfileView
member:OrderView
{code}
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14050699#comment-14050699
]
Adam Heath commented on OFBIZ-4053:
---
It's on my list to add many more test cases to the entity engine; view testing
is almost non-existent at that level.
Basically, a condition defined on a link or view level, in the model, won't be
dealt with properly. Each of the nested real member entities need to cascade
events outwards whenever they are updated, and they match some other cached
result.
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14050748#comment-14050748
]
Adam Heath commented on OFBIZ-4053:
---
I don't see it. ModelViewEntity.populateReverseLinks() walks all view-link,
but does nothing with any entity-condition that was defined. It only deals
with key-map.
A condition can reference a lhs or rhs field that is not mentioned in a key
map, nor in the available field aliases. This means it would be hidden from
the conversion code, so an update of a member entity row would not clear the
view cache.
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OFBIZ-5565) FinAccountHelper.getFinAccountFromCode() no longer returns financial account
[ https://issues.apache.org/jira/browse/OFBIZ-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047811#comment-14047811 ] Adam Heath commented on OFBIZ-5565: --- If the code is in order, then the test case should be in order. If the code is in accounting, then place the test case there. Since this method exists in order, the test case was placed there. And, the test case I committed tests *just* that method, not any high-level stuff that might use it. IE, it doesn't test the high-level stuff in accounting. FinAccountHelper.getFinAccountFromCode() no longer returns financial account Key: OFBIZ-5565 URL: https://issues.apache.org/jira/browse/OFBIZ-5565 Project: OFBiz Issue Type: Bug Components: accounting, order Affects Versions: SVN trunk, Release Branch 13.07 Environment: Primarily tested on Ubuntu, but affects all OS. Reporter: Vyom Jain Assignee: Adam Heath Fix For: SVN trunk Attachments: OFBIZ-5565.patch FinAccountHelper.getFinAccountFromCode() in trunk as well as in some of the released versions is no longer able to fetch the Financial Account ID. So all features dependent on this method would no longer work (an example being paying by gift card during order entry process). Per my research, this stopped working method post some changes related to how data is encrypted (two strings will not have similar encrypted string). I had tried this on a fresh SVN trunk checkout with absolutely no changes (had been using Derby database). Furthermore, the ant target gen-kek references old jars and that needs fixing as well. Steps to test - 1. Create a new Financial account (gift certificate) for DemoCustomer - https://demo-trunk.ofbiz.apache.org/accounting/control/FindFinAccount?ownerPartyId=DemoCustomer and deposit some funds into it. 2. Create an order for DemoCustomer from the Order Manager application. 3. Use Quick Finalize Order, try paying by the gift card created in step #1. Observations - 1. Returns an error This gift card does not exist Related User ML post - http://mail-archives.apache.org/mod_mbox/ofbiz-user/201403.mbox/%3CCAKuEJqZChmJaWF=rzn1z-vudnzbnsdulj4j6pxjtd5ijynu...@mail.gmail.com%3E Thanks. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (OFBIZ-5210) view-entity cannot be extended
[ https://issues.apache.org/jira/browse/OFBIZ-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reopened OFBIZ-5210: --- This is a valid feature request. view-entity cannot be extended -- Key: OFBIZ-5210 URL: https://issues.apache.org/jira/browse/OFBIZ-5210 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 12.04 Environment: Windows / Linux Reporter: Skip Dever Assignee: Adam Heath Priority: Minor Fix For: Release Branch 12.04 For example, add the following to the bottom of entitymodel_view.xml in applications\workeffort\entitydef extend-entity entity-name=WorkEffortAndPartyAssign relation type=one-nofk title=Current rel-entity-name=StatusItem key-map field-name=currentStatusId rel-field-name=statusId/ /relation relation type=one-nofk rel-entity-name=WorkEffortType key-map field-name=workEffortTypeId/ /relation relation type=one-nofk rel-entity-name=WorkEffortPurposeType key-map field-name=workEffortPurposeTypeId/ /relation /extend-entity Then, start Ofbiz and you will get an error in the log that WorkEffortAndPartyAssign does not exist. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-5534) Dirty reads from entity cache
[ https://issues.apache.org/jira/browse/OFBIZ-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14044784#comment-14044784 ] Adam Heath commented on OFBIZ-5534: --- Well, to do what you would need, would be rather difficult(I think). Here's what would have to happen. * Allow any pre-existing cached results to be returned. * Allow new values to be stored into the cache. * Any values modified during a transaction place a 'whiteout' entry * Whiteout entries will prevent reading of cached items that match. * Whiteout entries will prevent storing of items that match into the cache. * Whiteout entries will clear the cache at the end of the transaction. Altho, maybe not so difficult. The changes I have I did entirely last night. Dirty reads from entity cache - Key: OFBIZ-5534 URL: https://issues.apache.org/jira/browse/OFBIZ-5534 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04, Release Branch 13.07 Reporter: Jacopo Cappellato Assignee: Adam Heath Attachments: unittest-dirtyreadsfromcache.patch Even if database transaction isolation level is set to ReadCommitted, a transaction can get uncommitted records from the entity cache, under certain circumstances. Here is a test case: 1) transaction T1 creates a record 2) T1 calls findOne to retrieve it: the read will be successful (because T1 can read data generated in T1 even if not committed) and the record will be added to the cache 3) T1 calls another service with requireNewTransaction set to true: this will run the second service in a new transaction T2 4) T2 calls findOne to retrieve the record created by T1: if useCache is set to false it should fail; if useCache is set to true it will succeed (getting the record from cache, even if the data is not committed to the db) The result in #4 is wrong because T2 should not see the uncommitted record We should never add uncommitted records to the entity cache. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-5534) Dirty reads from entity cache
[ https://issues.apache.org/jira/browse/OFBIZ-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14044834#comment-14044834 ] Adam Heath commented on OFBIZ-5534: --- Not just entities. Lists of entities. With different orderings. And objects stored into the condition cache. And removals of other items from the cache. The best place to do this change is in the actual Cache class. Dirty reads from entity cache - Key: OFBIZ-5534 URL: https://issues.apache.org/jira/browse/OFBIZ-5534 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04, Release Branch 13.07 Reporter: Jacopo Cappellato Assignee: Adam Heath Attachments: unittest-dirtyreadsfromcache.patch Even if database transaction isolation level is set to ReadCommitted, a transaction can get uncommitted records from the entity cache, under certain circumstances. Here is a test case: 1) transaction T1 creates a record 2) T1 calls findOne to retrieve it: the read will be successful (because T1 can read data generated in T1 even if not committed) and the record will be added to the cache 3) T1 calls another service with requireNewTransaction set to true: this will run the second service in a new transaction T2 4) T2 calls findOne to retrieve the record created by T1: if useCache is set to false it should fail; if useCache is set to true it will succeed (getting the record from cache, even if the data is not committed to the db) The result in #4 is wrong because T2 should not see the uncommitted record We should never add uncommitted records to the entity cache. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-5534) Dirty reads from entity cache
[ https://issues.apache.org/jira/browse/OFBIZ-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14044864#comment-14044864 ] Adam Heath commented on OFBIZ-5534: --- Keeping the list of entities from being polluted is the same as keeping the findOne cache clean as well. The code inside the first transaction may update a value, then call findList(), and the results get cached, and now another thread will see it. Trust me, the place for these changes is in the Cache object. I've already been playing around with XAResource and Synchronization. And I already have the cache mutations being delayed and replayed at the end of the transaction. I just don't allow for any cache reads while inside the transaction, which does cause a slowdown. Dirty reads from entity cache - Key: OFBIZ-5534 URL: https://issues.apache.org/jira/browse/OFBIZ-5534 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04, Release Branch 13.07 Reporter: Jacopo Cappellato Assignee: Adam Heath Attachments: unittest-dirtyreadsfromcache.patch Even if database transaction isolation level is set to ReadCommitted, a transaction can get uncommitted records from the entity cache, under certain circumstances. Here is a test case: 1) transaction T1 creates a record 2) T1 calls findOne to retrieve it: the read will be successful (because T1 can read data generated in T1 even if not committed) and the record will be added to the cache 3) T1 calls another service with requireNewTransaction set to true: this will run the second service in a new transaction T2 4) T2 calls findOne to retrieve the record created by T1: if useCache is set to false it should fail; if useCache is set to true it will succeed (getting the record from cache, even if the data is not committed to the db) The result in #4 is wrong because T2 should not see the uncommitted record We should never add uncommitted records to the entity cache. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-5534) Dirty reads from entity cache
[ https://issues.apache.org/jira/browse/OFBIZ-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14044913#comment-14044913 ] Adam Heath commented on OFBIZ-5534: --- What don't you like about it? We can't modify the delegator; external code uses the Cache class directly. This is the only way to store built-up objects into the entity condition list classes. I don't think you are understanding my approach, because what you outlined as the way to do things, is how it is being done. I'm just doing it in Cache, not GenericDelegator. ps: Currently, my implementation has issues if transactions are suspended and resumed. The only way to fix that would be to use XAResource, but there is no way to prevent duplication enlistResource calls that is not hackish. pps: I know that my impl isn't visible yet anywhere. I don't have time to place it someplace that is easy to look at right now. Dirty reads from entity cache - Key: OFBIZ-5534 URL: https://issues.apache.org/jira/browse/OFBIZ-5534 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04, Release Branch 13.07 Reporter: Jacopo Cappellato Assignee: Adam Heath Attachments: unittest-dirtyreadsfromcache.patch Even if database transaction isolation level is set to ReadCommitted, a transaction can get uncommitted records from the entity cache, under certain circumstances. Here is a test case: 1) transaction T1 creates a record 2) T1 calls findOne to retrieve it: the read will be successful (because T1 can read data generated in T1 even if not committed) and the record will be added to the cache 3) T1 calls another service with requireNewTransaction set to true: this will run the second service in a new transaction T2 4) T2 calls findOne to retrieve the record created by T1: if useCache is set to false it should fail; if useCache is set to true it will succeed (getting the record from cache, even if the data is not committed to the db) The result in #4 is wrong because T2 should not see the uncommitted record We should never add uncommitted records to the entity cache. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-5534) Dirty reads from entity cache
[ https://issues.apache.org/jira/browse/OFBIZ-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14044958#comment-14044958 ] Adam Heath commented on OFBIZ-5534: --- Blocking aspect? Dirty reads from entity cache - Key: OFBIZ-5534 URL: https://issues.apache.org/jira/browse/OFBIZ-5534 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04, Release Branch 13.07 Reporter: Jacopo Cappellato Assignee: Adam Heath Attachments: unittest-dirtyreadsfromcache.patch Even if database transaction isolation level is set to ReadCommitted, a transaction can get uncommitted records from the entity cache, under certain circumstances. Here is a test case: 1) transaction T1 creates a record 2) T1 calls findOne to retrieve it: the read will be successful (because T1 can read data generated in T1 even if not committed) and the record will be added to the cache 3) T1 calls another service with requireNewTransaction set to true: this will run the second service in a new transaction T2 4) T2 calls findOne to retrieve the record created by T1: if useCache is set to false it should fail; if useCache is set to true it will succeed (getting the record from cache, even if the data is not committed to the db) The result in #4 is wrong because T2 should not see the uncommitted record We should never add uncommitted records to the entity cache. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-5534) Dirty reads from entity cache
[ https://issues.apache.org/jira/browse/OFBIZ-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14044989#comment-14044989 ] Adam Heath commented on OFBIZ-5534: --- Except I really really really don't want to use svn branches. Dirty reads from entity cache - Key: OFBIZ-5534 URL: https://issues.apache.org/jira/browse/OFBIZ-5534 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04, Release Branch 13.07 Reporter: Jacopo Cappellato Assignee: Adam Heath Attachments: unittest-dirtyreadsfromcache.patch Even if database transaction isolation level is set to ReadCommitted, a transaction can get uncommitted records from the entity cache, under certain circumstances. Here is a test case: 1) transaction T1 creates a record 2) T1 calls findOne to retrieve it: the read will be successful (because T1 can read data generated in T1 even if not committed) and the record will be added to the cache 3) T1 calls another service with requireNewTransaction set to true: this will run the second service in a new transaction T2 4) T2 calls findOne to retrieve the record created by T1: if useCache is set to false it should fail; if useCache is set to true it will succeed (getting the record from cache, even if the data is not committed to the db) The result in #4 is wrong because T2 should not see the uncommitted record We should never add uncommitted records to the entity cache. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (OFBIZ-5670) findList(options(offset|limit)) can corrupt the cache
Adam Heath created OFBIZ-5670: - Summary: findList(options(offset|limit)) can corrupt the cache Key: OFBIZ-5670 URL: https://issues.apache.org/jira/browse/OFBIZ-5670 Project: OFBiz Issue Type: Bug Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor In findList, there is an optional EntityFindOptions. If this is specified, and it has a non-default offset or limit, then the EntityListIerator used internally will only return a subset of the values. This subset is then stored as the *full* cached list. Later, if another findList call happens, that has the same entityName/condition, the partial list stored previously will be used. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-5331) Change EntityComparisonOperator to use compareTo()
[ https://issues.apache.org/jira/browse/OFBIZ-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043633#comment-14043633 ] Adam Heath commented on OFBIZ-5331: --- Ok, bad news. Can't apply this patch at this time. But not for the reasons you might think. The method it is updating is too buggy, and needs to be fixed first. The first bug fouind was that doing compareRelationalOperator(abc, null) will throw an NPE. This is because that's how compareTo is defined. This is an obvious bug, but it does *not* have an obvious fix. See the next issue. In SQL, a NULL is special. NULLs are not like anything. NULL = NULL returns NULL, NULL != NULL returns NULL, and the same goes for all the other operators. It's not exactly intuitive. For instance, in ORDER BY, one can request NULLs to be first, or last. So, you might think they have a sensible place in a comparison operator. However, in SQL, a NULL on any side of the operator will make the operation return NULL. This kind of SQL handling of NULL is not the way the condition system in ofbiz works. It expects a boolean(not Boolean). This could cause subtle issues, and I want to fix those first. Change EntityComparisonOperator to use compareTo() -- Key: OFBIZ-5331 URL: https://issues.apache.org/jira/browse/OFBIZ-5331 Project: OFBiz Issue Type: Improvement Components: framework Reporter: Joe Eckard Priority: Trivial Attachments: patch.txt The methods compareEqual() and compareNotEqual() both use equals() instead of compareTo() which can be problematic when used to compare BigDecimal objects. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (OFBIZ-5331) Change EntityComparisonOperator to use compareTo()
[ https://issues.apache.org/jira/browse/OFBIZ-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-5331: - Assignee: Adam Heath Change EntityComparisonOperator to use compareTo() -- Key: OFBIZ-5331 URL: https://issues.apache.org/jira/browse/OFBIZ-5331 Project: OFBiz Issue Type: Improvement Components: framework Reporter: Joe Eckard Assignee: Adam Heath Priority: Trivial Attachments: patch.txt The methods compareEqual() and compareNotEqual() both use equals() instead of compareTo() which can be problematic when used to compare BigDecimal objects. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (OFBIZ-4331) trival update to EntityFieldValue.java in case the entityAlias is empty
[
https://issues.apache.org/jira/browse/OFBIZ-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Heath reassigned OFBIZ-4331:
-
Assignee: Adam Heath
trival update to EntityFieldValue.java in case the entityAlias is empty
---
Key: OFBIZ-4331
URL: https://issues.apache.org/jira/browse/OFBIZ-4331
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Leon
Assignee: Adam Heath
Priority: Trivial
Fix For: SVN trunk
Attachments: EntityFieldValue.patch
Sometimes, there's only one member entity in a view. In such case, you can
omit the entity-alias in entity condition setting. In this situation, the
entityAlias is not null but an emtpty string.
===
--- framework/entity/src/org/ofbiz/entity/condition/EntityFieldValue.java
(revision 1513)
+++ framework/entity/src/org/ofbiz/entity/condition/EntityFieldValue.java
(working copy)
@@ -124,7 +124,7 @@
@Override
public ModelField getModelField(ModelEntity modelEntity) {
if (this.modelViewEntity != null) {
-if (this.entityAlias != null) {
+if (UtilValidate.isNotEmpty(this.entityAlias)) {
ModelEntity memberModelEntity =
modelViewEntity.getMemberModelEntity(entityAlias);
return getField(memberModelEntity, fieldName);
} else {
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OFBIZ-4331) trival update to EntityFieldValue.java in case the entityAlias is empty
[
https://issues.apache.org/jira/browse/OFBIZ-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043649#comment-14043649
]
Adam Heath commented on OFBIZ-4331:
---
More details on this bug. In entitymodel.xsd, the entity-alias attribute for
condition-type elements is not required. This means that when the value is not
specified, it'll be returned as an empty string, not a null.
Then, when ViewConditionExpr is used against the primary entity(not in a
view-link), to restrict the view, the empty string gets passed to
EntityFieldValue.makeFieldValue(). Eventually, the code-path above will be
hit, and the wrong branch will be taken. Namely, that the empty string will be
passed to getMemberModelEntity.
trival update to EntityFieldValue.java in case the entityAlias is empty
---
Key: OFBIZ-4331
URL: https://issues.apache.org/jira/browse/OFBIZ-4331
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Leon
Assignee: Adam Heath
Priority: Trivial
Fix For: SVN trunk
Attachments: EntityFieldValue.patch
Sometimes, there's only one member entity in a view. In such case, you can
omit the entity-alias in entity condition setting. In this situation, the
entityAlias is not null but an emtpty string.
===
--- framework/entity/src/org/ofbiz/entity/condition/EntityFieldValue.java
(revision 1513)
+++ framework/entity/src/org/ofbiz/entity/condition/EntityFieldValue.java
(working copy)
@@ -124,7 +124,7 @@
@Override
public ModelField getModelField(ModelEntity modelEntity) {
if (this.modelViewEntity != null) {
-if (this.entityAlias != null) {
+if (UtilValidate.isNotEmpty(this.entityAlias)) {
ModelEntity memberModelEntity =
modelViewEntity.getMemberModelEntity(entityAlias);
return getField(memberModelEntity, fieldName);
} else {
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (OFBIZ-3767) Enhance UtilProperties.getMessage to support a default message when the resource key is not found in the bundle
[ https://issues.apache.org/jira/browse/OFBIZ-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-3767: - Assignee: Adam Heath Enhance UtilProperties.getMessage to support a default message when the resource key is not found in the bundle --- Key: OFBIZ-3767 URL: https://issues.apache.org/jira/browse/OFBIZ-3767 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Bob Morley Assignee: Adam Heath Priority: Trivial This is related to OFBIZ-3749 where it was noted that it would be nice to have an overload of the methods in UtilProperties related to getMessage so that the caller can pass in a default message to be returned in the key is not found. The default will remain returning the name of the key; but other callers (such as OFBIZ-3749) that want to do special logic on a missing key can handle this nicely. Since there is no real issue with OFBIZ-3749 this ticket is marked as trivial; we can fix on a best efforts basis. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (OFBIZ-829) Add createjks.sh under /framework/base/config/
[ https://issues.apache.org/jira/browse/OFBIZ-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-829: Assignee: Adam Heath Add createjks.sh under /framework/base/config/ -- Key: OFBIZ-829 URL: https://issues.apache.org/jira/browse/OFBIZ-829 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: Fedora 5, JDK 1.5 Reporter: Shi Yusen Assignee: Adam Heath Priority: Trivial Attachments: ofbiz-20070320-shiys-createjks.patch The createjks.sh is for building develop environment only. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (OFBIZ-255) Improve error message handling/hiding
[ https://issues.apache.org/jira/browse/OFBIZ-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-255: Assignee: Adam Heath Improve error message handling/hiding -- Key: OFBIZ-255 URL: https://issues.apache.org/jira/browse/OFBIZ-255 Project: OFBiz Issue Type: Improvement Components: specialpurpose/ecommerce Reporter: David N. Welton Assignee: Adam Heath Priority: Trivial This is a copy of OFBIZ-673, from the old JIRA system: Error handling ought to be configurable. Currently, the template file framework/common/webcommon/includes/messages.ftl lets you customize the look and feel, but there are a couple of other things that could be done, in my opinion. 1) Depending on whether a variable (production/testing system) is set somewhere (where is the best place?), either print all the debug information, or simply print a nice, simple messsage that there has been an error and the administrators have been contacted to resolve the problem. 2) Actually send some email to an email address defined somewhere (where is the best place?). I think that would happen in ServiceEventHandler.java, but perhaps (well, probably), I'm mistaken. Where is the right place? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-829) Add createjks.sh under /framework/base/config/
[ https://issues.apache.org/jira/browse/OFBIZ-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043656#comment-14043656 ] Adam Heath commented on OFBIZ-829: -- Not applying the patch, but nice idea. This should be ported to ant-compatible syntax. Even if it still calls an external keytool. This will allow for such development-based keys to be created on all platforms, not just those with a shell interpeter. Add createjks.sh under /framework/base/config/ -- Key: OFBIZ-829 URL: https://issues.apache.org/jira/browse/OFBIZ-829 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: Fedora 5, JDK 1.5 Reporter: Shi Yusen Assignee: Adam Heath Priority: Trivial Attachments: ofbiz-20070320-shiys-createjks.patch The createjks.sh is for building develop environment only. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (OFBIZ-5363) Add Support For Tomcat JDBC Connection Pool
[ https://issues.apache.org/jira/browse/OFBIZ-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-5363: - Assignee: Adam Heath Add Support For Tomcat JDBC Connection Pool --- Key: OFBIZ-5363 URL: https://issues.apache.org/jira/browse/OFBIZ-5363 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Adrian Crum Assignee: Adam Heath Priority: Minor Attachments: OFBIZ-5363.patch, tomcat-7.0.42-tomcat-jdbc.jar According to Tomcat, their JDBC connection pool is a better implementation than DBCP (http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html). This issue adds the Tomcat JDBC Connection Pool as an option. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-5363) Add Support For Tomcat JDBC Connection Pool
[ https://issues.apache.org/jira/browse/OFBIZ-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043669#comment-14043669 ] Adam Heath commented on OFBIZ-5363: --- That patch is interesting, but does more than it sets out to do. It should *only* add support for this new pool impl; for instance, it moves the select string into a static constant on the interface. Additionally, there is an ordering issue in the build. the entity/build/.xml references catalina/lib, which comes after it. Also, the linked page menitions that dbcp 1.x is poor, that 2.x is better, but that tomcat jdbc pool is better. It doesn't say if it is better than 1.x, or 2.x, or how 2.x is different, really. And, since ofbiz uses 1.x, why can't we also compare that new version? Add Support For Tomcat JDBC Connection Pool --- Key: OFBIZ-5363 URL: https://issues.apache.org/jira/browse/OFBIZ-5363 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Adrian Crum Assignee: Adam Heath Priority: Minor Attachments: OFBIZ-5363.patch, tomcat-7.0.42-tomcat-jdbc.jar According to Tomcat, their JDBC connection pool is a better implementation than DBCP (http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html). This issue adds the Tomcat JDBC Connection Pool as an option. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (OFBIZ-5315) view-entity complex-alias field name bug when view-entities reference other view-entities
[ https://issues.apache.org/jira/browse/OFBIZ-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-5315: - Assignee: Adam Heath view-entity complex-alias field name bug when view-entities reference other view-entities - Key: OFBIZ-5315 URL: https://issues.apache.org/jira/browse/OFBIZ-5315 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 11.04 Reporter: Christian Carlow Assignee: Adam Heath Priority: Minor Fix For: Release Branch 11.04 Attachments: ModelViewEntity.java.patch Field names used in complex-alias are named incorrectly when SQL statements are generated. The following complex alias: alias name=quantity complex-alias operator=- complex-alias-field entity-alias=A field=field1/ complex-alias-field entity-alias=B field=field2/ /complex-alias /alias Will result with the following generated SQL when A and B are also view-entities: SELECT (C.A.field1 + C.B.field2) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (OFBIZ-5280) fieldtypemodel.dtd incomplete. There is not definition for inner validation element
[ https://issues.apache.org/jira/browse/OFBIZ-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-5280: - Assignee: Adam Heath fieldtypemodel.dtd incomplete. There is not definition for inner validation element --- Key: OFBIZ-5280 URL: https://issues.apache.org/jira/browse/OFBIZ-5280 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 12.04 Reporter: Roberto Benítez Monje Assignee: Adam Heath Priority: Minor Labels: dtd There is not defined completely the field-type-def element in fieldtypemodel.dtd It misses the validate element (with its name attribute) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (OFBIZ-5210) view-entity cannot be extended
[ https://issues.apache.org/jira/browse/OFBIZ-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-5210: - Assignee: Adam Heath view-entity cannot be extended -- Key: OFBIZ-5210 URL: https://issues.apache.org/jira/browse/OFBIZ-5210 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 12.04 Environment: Windows / Linux Reporter: Skip Dever Assignee: Adam Heath Priority: Minor Fix For: Release Branch 12.04 For example, add the following to the bottom of entitymodel_view.xml in applications\workeffort\entitydef extend-entity entity-name=WorkEffortAndPartyAssign relation type=one-nofk title=Current rel-entity-name=StatusItem key-map field-name=currentStatusId rel-field-name=statusId/ /relation relation type=one-nofk rel-entity-name=WorkEffortType key-map field-name=workEffortTypeId/ /relation relation type=one-nofk rel-entity-name=WorkEffortPurposeType key-map field-name=workEffortPurposeTypeId/ /relation /extend-entity Then, start Ofbiz and you will get an error in the log that WorkEffortAndPartyAssign does not exist. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (OFBIZ-5199) Complex Alias is not working with default value.
[ https://issues.apache.org/jira/browse/OFBIZ-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-5199: - Assignee: Adam Heath Complex Alias is not working with default value. Key: OFBIZ-5199 URL: https://issues.apache.org/jira/browse/OFBIZ-5199 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release 10.04, Release Branch 11.04, SVN trunk, Release Branch 12.04 Reporter: Deepak Dixit Assignee: Adam Heath Priority: Minor Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk, Release Branch 12.04 Attachments: OFBIZ-5199-R.patch, OFBIZ-5199.patch If we pass the default value then complex alias is broken and throwing exception while executing the query. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-5280) fieldtypemodel.dtd incomplete. There is not definition for inner validation element
[ https://issues.apache.org/jira/browse/OFBIZ-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043696#comment-14043696 ] Adam Heath commented on OFBIZ-5280: --- And no entity definitions in ofbiz use it. And the only thing that uses ModelField.getValidators is the the entity-data-maintenance screens. fieldtypemodel.dtd incomplete. There is not definition for inner validation element --- Key: OFBIZ-5280 URL: https://issues.apache.org/jira/browse/OFBIZ-5280 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 12.04 Reporter: Roberto Benítez Monje Assignee: Adam Heath Priority: Minor Labels: dtd There is not defined completely the field-type-def element in fieldtypemodel.dtd It misses the validate element (with its name attribute) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-5210) view-entity cannot be extended
[ https://issues.apache.org/jira/browse/OFBIZ-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043702#comment-14043702 ] Adam Heath commented on OFBIZ-5210: --- Extending views just to add relations should be rather trivial to support. Changing a view by adding additional members, aliases, links, and conditions, would change the meaning of the view quite radically. Nowadays, it should be possible to reference one view from another. Ie, a view could have, as a member, another view. This can be done to almost infinite depth. I updated the entityengine quite a bit ago to do the correct thing with conditions on view-links(they stay on the link as you nest), and conditions on view members(they become part of the outer view-link, not attached to the outer where). I also added support for changing overly long field names, to an effectively random string(I convert the systemHashCode() to a string, basically). So, if you need to have another view that just enhances one that already exists, just create a new one, with a single member, and add whatever conditions you need. view-entity cannot be extended -- Key: OFBIZ-5210 URL: https://issues.apache.org/jira/browse/OFBIZ-5210 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 12.04 Environment: Windows / Linux Reporter: Skip Dever Assignee: Adam Heath Priority: Minor Fix For: Release Branch 12.04 For example, add the following to the bottom of entitymodel_view.xml in applications\workeffort\entitydef extend-entity entity-name=WorkEffortAndPartyAssign relation type=one-nofk title=Current rel-entity-name=StatusItem key-map field-name=currentStatusId rel-field-name=statusId/ /relation relation type=one-nofk rel-entity-name=WorkEffortType key-map field-name=workEffortTypeId/ /relation relation type=one-nofk rel-entity-name=WorkEffortPurposeType key-map field-name=workEffortPurposeTypeId/ /relation /extend-entity Then, start Ofbiz and you will get an error in the log that WorkEffortAndPartyAssign does not exist. -- This message was sent by Atlassian JIRA (v6.2#6252)
