I am now thinking of how to isolate this code to write a proper test.
This is not going to be successful tonight, while the original seven
samurai is on tv. Maybe reverting is the best option and we live with
findbugs regression for a day. I will think of a way to fix this
tomorrow wit a more clear head.
On Thu, Jul 30, 2015 at 9:33 PM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
> But reintroduced the vulnerability that findbugs was complaining about...
> I think the problem is in this bit:
>
> int i=0;
> for (Map.Entry<String, String> detail : details.entrySet()) {
> pstmt.setString(++i,detail.getKey());
> pstmt.setString(++i,detail.getValue());
> }
>
> ++i should have been i++ in both cases. I messed those in my review, sorry
>
>
> On Thu, Jul 30, 2015 at 9:24 PM, Mike Tutkowski
> <mike.tutkow...@solidfire.com> wrote:
>> No problem, Daan. :)
>>
>> Just from an empirical standpoint, though, reverting the commit in my local
>> repo fixed the problem.
>>
>> On Thu, Jul 30, 2015 at 1:20 PM, Daan Hoogland <daan.hoogl...@gmail.com>
>> wrote:
>>>
>>> never mind that again, answerring to fast as I probably do one out of
>>> two or three times :( Looking further...
>>>
>>> On Thu, Jul 30, 2015 at 9:19 PM, Daan Hoogland <daan.hoogl...@gmail.com>
>>> wrote:
>>> > Mike, I am looking at the commit and it makes perfect sense as the the
>>> > prior situation was creating a prepared statement based on dynamicly
>>> > added strings. The only queer thing is that the int i = 1 is replaced
>>> > with i = 1, reusing the loop counter instead of hiding it. Maybe this
>>> > is the problem
>>> >
>>> > On Thu, Jul 30, 2015 at 8:55 PM, Mike Tutkowski
>>> > <mike.tutkow...@solidfire.com> wrote:
>>> >> I see the problem.
>>> >>
>>> >> The way a SQL statement was constructed was changed by commit
>>> >> b84093f691ae0b09d2c525d50f2e2d200c709b2c:
>>> >>
>>> >>
>>> >> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java;h=d3c29f70d6ab56379c2436b5cafc933049200f31;hp=faf5291554a68506b14438a7e1cda61cd4c3cc0c;hb=b84093f691ae0b09d2c525d50f2e2d200c709b2c;hpb=1407033cc2e0742653d82bb0181c041b31253693
>>> >>
>>> >> and no longer makes any sense
>>> >>
>>> >> SELECT storage_pool.* from storage_pool LEFT JOIN storage_pool_details
>>> >> ON
>>> >> storage_pool.id = storage_pool_details.pool_id WHERE
>>> >> storage_pool.removed is
>>> >> null and storage_pool.status = 'Up' and storage_pool.data_center_id = 1
>>> >> and
>>> >> storage_pool.scope = 'ZONE' and (((storage_pool_details.name=1) AND
>>> >> (storage_pool_details.value=** NOT SPECIFIED **))) GROUP BY
>>> >> storage_pool_details.pool_id HAVING COUNT(storage_pool_details.name) >=
>>> >> **
>>> >> NOT SPECIFIED **
>>> >>
>>> >> I think I'm just going to revert this commit. It was related to a
>>> >> change put
>>> >> in at the request of FindBugs.
>>> >>
>>> >> I've CCed the relevant participants in the commit in case they wish to
>>> >> re-evaluate the FindBugs request and resubmit a fix.
>>> >>
>>> >>
>>> >> On Thu, Jul 30, 2015 at 12:13 PM, Mike Tutkowski
>>> >> <mike.tutkow...@solidfire.com> wrote:
>>> >>>
>>> >>> FYI that I get the same error message when trying to attach a data
>>> >>> disk
>>> >>> that is based on zone-wide primary storage.
>>> >>>
>>> >>> On Thu, Jul 30, 2015 at 12:10 PM, Mike Tutkowski
>>> >>> <mike.tutkow...@solidfire.com> wrote:
>>> >>>>
>>> >>>> I'm actually having trouble creating a VM whose root disk runs on
>>> >>>> zone-wide primary storage.
>>> >>>>
>>> >>>> This is definitely a blocker for 4.6. I'm just beginning to look into
>>> >>>> this, but this is the error message I receive:
>>> >>>>
>>> >>>> findZoneWideStoragePoolsByTags:Exception:No value specified for
>>> >>>> parameter
>>> >>>> 4
>>> >>>>
>>> >>>> On Mon, Jul 27, 2015 at 8:51 PM, Pierre-Luc Dion
>>> >>>> <pdion...@apache.org>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> Hi,
>>> >>>>>
>>> >>>>> I've create this jira filter[1] for the Release Manager, based on
>>> >>>>> it,
>>> >>>>> there
>>> >>>>> would be only 4 maybe just 3 blockers on 4.6. Based on this, should
>>> >>>>> we
>>> >>>>> consider placing a target date for RC1 somewhere like end of August
>>> >>>>> ?
>>> >>>>>
>>> >>>>> What's missing and to do in 4.6 as far as I know:
>>> >>>>>
>>> >>>>> 1. Basic documentation of new features,
>>> >>>>> 2. Decide if we let it in master and freeze merge during RC ?
>>> >>>>> 3. Build all job as 4.6 in jenkins ?
>>> >>>>> 4. Organize a QA-party, like old time lan-party
>>> >>>>>
>>> >>>>> [1] https://issues.apache.org/jira/issues/?filter=12332940
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Mike Tutkowski
>>> >>>> Senior CloudStack Developer, SolidFire Inc.
>>> >>>> e: mike.tutkow...@solidfire.com
>>> >>>> o: 303.746.7302
>>> >>>> Advancing the way the world uses the cloud™
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Mike Tutkowski
>>> >>> Senior CloudStack Developer, SolidFire Inc.
>>> >>> e: mike.tutkow...@solidfire.com
>>> >>> o: 303.746.7302
>>> >>> Advancing the way the world uses the cloud™
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Mike Tutkowski
>>> >> Senior CloudStack Developer, SolidFire Inc.
>>> >> e: mike.tutkow...@solidfire.com
>>> >> o: 303.746.7302
>>> >> Advancing the way the world uses the cloud™
>>> >
>>> >
>>> >
>>> > --
>>> > Daan
>>>
>>>
>>>
>>> --
>>> Daan
>>
>>
>>
>>
>> --
>> Mike Tutkowski
>> Senior CloudStack Developer, SolidFire Inc.
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the cloud™
>
>
>
> --
> Daan
--
Daan
