Infra said we should do it ourselves so will try git-svn to import back our tags, sounds long with the almost 2m of commits on svn, even on a subpath :s
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 4 juin 2019 à 19:27, Romain Manni-Bucau <[email protected]> a écrit : > FYI: https://issues.apache.org/jira/browse/INFRA-18565 > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le lun. 3 juin 2019 à 08:51, Romain Manni-Bucau <[email protected]> a > écrit : > >> Hello everyone, >> >> Do you know where are our 1.x tags/branches? Lost in svn migration? >> Should we ask infra? >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://rmannibucau.metawerx.net/> | Old Blog >> <http://rmannibucau.wordpress.com> | Github >> <https://github.com/rmannibucau> | LinkedIn >> <https://www.linkedin.com/in/rmannibucau> | Book >> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >> >> >> ---------- Forwarded message --------- >> De : Tomasz Wysocki (JIRA) <[email protected]> >> Date: lun. 3 juin 2019 à 08:48 >> Subject: [jira] [Commented] (BVAL-176) setAccessible handling is broken >> for multithreaded apps with SecurityManager >> To: <[email protected]> >> >> >> >> [ >> https://issues.apache.org/jira/browse/BVAL-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854274#comment-16854274 >> ] >> >> Tomasz Wysocki commented on BVAL-176: >> ------------------------------------- >> >> I would be grateful for 1.1.x maintenance branch (fabb6c4) and prompt >> release of 1.1.3 to avoid custom version. >> >> I will do a master fix shortly (second PR). >> >> >> >> > setAccessible handling is broken for multithreaded apps with >> SecurityManager >> > >> ---------------------------------------------------------------------------- >> > >> > Key: BVAL-176 >> > URL: https://issues.apache.org/jira/browse/BVAL-176 >> > Project: BVal >> > Issue Type: Bug >> > Affects Versions: 1.1.2, 2.0.0 >> > Reporter: Tomasz Wysocki >> > Priority: Major >> > Fix For: 1.1.3 >> > >> > Attachments: ReflectionAccessibilityTest.java >> > >> > Time Spent: 10m >> > Remaining Estimate: 0h >> > >> > Currently when using security manager field/method accessible flag will >> be reset back to false. >> > This does not work for multithreaded apps due to lack of >> synchronization between threads. >> > The effect is exception while validating due to invalid access to >> protected or private members of target object. >> > Workaround is to make all validated members public or synchronize on >> Validator instance. >> > This issue contains a test case to show the effect when security >> manager is installed and there is no synchronization as well as a patch to >> 1.1.2. >> > This issue applies to bval2 as well but I haven't made a patch. >> > Below is proposed resolution: >> > Remove reseting of accessible flag when security manager is present >> > >> > And rationale: >> > This feature will not work without some synchronization on the >> > reflection data itself in multithreaded environment. >> > >> > Therefore the feature has been removed due to following concerns: >> > >> > 1. resetting accessible flag for security manager does not mean >> that for >> > short period of time the flag is not actually set and bad code >> could >> > exploit that - therefore resetting accesible back is not really >> making >> > it unaccessible to other code - this is design flaw. If accessible >> flag >> > would be per thread it would work much better. >> > >> > 2. since accessible flag is global it would require >> synchronization to make it work correctly, >> > which is costly. Current implementation just breaks for SM >> present case >> > - it throws 'inaccessible' exceptions since it does not >> synchronize at >> > all. >> > >> > 3. there is no saying what would need to be synchronized (probably >> the >> > field or method reflected instances but it is not specified). >> Therefore >> > synchronizing it would work only within scope of a single framework >> > (bval). >> > >> > 4. other frameworks typically don't reset back accessible and just >> keep >> > the flag set. Therefore any synchronization mechanism specific to >> bval would not cooperate >> > nicely or at all with other frameworks (like spring for instance). >> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v7.6.3#76005) >> >
