Re: [keycloak-dev] Migrate testsuite

Nice! Meanwhile answering my own question, seems like transforAccessToken is required for that test case work. On Tue, Apr 12, 2016 at 3:48 PM, Stan Silvert <ssilvert(a)redhat.com&gt; wrote: > On 4/12/2016 12:16 PM, Stan Silvert wrote: >> On 4/12/2016 10:38 AM, Bruno Oliveira wrote: >>> Good morning, >>> >>> I'm looking at this test case >>> >>> https://gist.github.com/abstractj/8d3f1ca74a0dfb4f58f7810c519c6272#file-a... >>> >>> Although, it fails here >>> >>> https://gist.github.com/abstractj/8d3f1ca74a0dfb4f58f7810c519c6272#file-a... >>> >>> My feeling is the fact that I don't have this method >>> >>> https://github.com/keycloak/keycloak/blob/c7a8742a368bd8d76301145b08bb1e4... >>> >>> My question is: Is this something that could be solved with >>> OAuthClient or is just the matter of migrate transformAccessToken? >> I don't know the answer, but I can tell you where I am with OAuthClient. >> It appears to be all working now. >> >> I've migrated TokenIntrospectionTest and ClientTest, which use several, >> but not all, of the OAuthClient methods. All of the tests in those classes >> will pass. >> >> However, TokenIntrospectionTest will only pass if you run each test >> individually. The reason they won't run as a group is because >> AssertEvents.clear() is not working. It took awhile but I finally figured >> out why. The problem is that AssertEvents.clear() is trying to call >> realmResource.clearEvents(). But there is a servlet filter installed and >> that is where the events are actually read from. So >> realmResource.clearEvents() doesn't have any effect on the event cache being >> read during the test. >> >> There are two ways we could fix this. One is to get rid of the filter and >> make AssertEvents completely rely on the adminClient. The other way is to >> add a clear() method to EventListenerProvider. That way, all event listeners >> will be notified to clear out their event caches. > Actually, there is a third option. I added a second "command" to the > AssertEventsServletFilter. Now it can respond to both /event-queue and > /clear-event-queue. Updated AssertEvents to use clear-event-queue and > everything now works. PR coming soon. > > >> Bruno, for now just be aware that AssertEvents.clear() isn't working. >>> >>> On Thu, Apr 7, 2016 at 2:32 PM, Stian Thorgersen <sthorger(a)redhat.com&gt; >>> wrote: >>>> >>>> On 7 April 2016 at 19:27, Stan Silvert <ssilvert(a)redhat.com&gt; wrote: >>>>> On 4/7/2016 10:52 AM, Stian Thorgersen wrote: >>>>> >>>>> The testsuite before calls the model to change config as required. This >>>>> should just be changed to use admin endpoints. Isn't that all that's >>>>> required? >>>>> >>>>> I'm not sure. The test-app displays a link to account management. >>>>> Presumably, one or more tests are relying on that particular link. >>>>> Plus, >>>>> since tests would then be relying on a different app (admin console), >>>>> there >>>>> would be cascading changes to the realm configuration and probably the >>>>> tests >>>>> themselves. >>>>> >>>>> See below. >>>>> >>>>> >>>>> On 7 April 2016 at 16:40, Bruno Oliveira <abstractj(a)redhat.com&gt; wrote: >>>>>> Sorry about the lack of details. I'm looking more precisely at >>>>>> AccessTokenTest and migrating this method[1] which does not depends on >>>>>> OAuthClient. >>>>>> >>>>>> The "test-app" that I mentioned is this one[2]. >>>>> Rather than refactoring OAuthClient and possibly any code that uses it, >>>>> I'm proposing to move forward and just deploy the little test-app when >>>>> the >>>>> server starts up. >>>>> >>>>> I'm worried about breaking these tests in unknown and possibly >>>>> undetectable ways. Stian, if you've got time to look it all over then >>>>> we >>>>> can do something different, but I don't think Bruno and I know these >>>>> tests >>>>> well enough to change it safely. >>>>> >>>>> I'd rather make sure we can port the tests as-is without changes. It >>>>> won't be hard to let the Keycloak server deploy the little servlet. >>>>> That >>>>> will at least let us move forward. We can always change it later. >>>>> >>>>> Sound ok? >>>> >>>> Oki, but instead of deploying a WAR to Keycloak, something which is not >>>> supported, so may not work in the future, add a custom REST endpoint >>>> like >>>> what I did for the TimeOffset >>>> >>>>>> [1] - >>>>>> >>>>>> https://github.com/keycloak/keycloak/blob/c7a8742a368bd8d76301145b08bb1e4... >>>>>> [2] - >>>>>> >>>>>> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-ar... >>>>>> >>>>>> On Thu, Apr 7, 2016 at 11:32 AM, Stian Thorgersen >>>>>> <sthorger(a)redhat.com&gt; >>>>>> wrote: >>>>>>> >>>>>>> On 7 April 2016 at 16:28, Bruno Oliveira <abstractj(a)redhat.com&gt; >>>>>>> wrote: >>>>>>>> I will also try to take a look later today. I have more questions of >>>>>>>> course, actually I have to enable direct access grant for my >>>>>>>> "test-app". >>>>>>> >>>>>>> What's your "test-app"? >>>>>>> >>>>>>>> My question is: to not mess with other tests, should I just add a >>>>>>>> new >>>>>>>> client to testrealm.json or it's ok to do some changes as long as it >>>>>>>> does not break other tests? >>>>>>> >>>>>>> Depends on what your "test-app" is ;) >>>>>>> >>>>>>>> On Thu, Apr 7, 2016 at 7:56 AM, Stan Silvert <ssilvert(a)redhat.com&gt; >>>>>>>> wrote: >>>>>>>>> On 4/7/2016 12:36 AM, Stian Thorgersen wrote: >>>>>>>>> >>>>>>>>> It can probably fairly easily be converted to not requiring >>>>>>>>> anything >>>>>>>>> to >>>>>>>>> be >>>>>>>>> deployed and instead just send to an invalid url. I can take a look >>>>>>>>> at >>>>>>>>> that >>>>>>>>> if you want? >>>>>>>>> >>>>>>>>> Yes, take a look and let me know what you think about that. It >>>>>>>>> would >>>>>>>>> improve the design of it. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 6 April 2016 at 21:20, Stan Silvert <ssilvert(a)redhat.com&gt; wrote: >>>>>>>>>> On 4/6/2016 9:26 AM, Stian Thorgersen wrote: >>>>>>>>>> >>>>>>>>>> The new one is just a simple method so I don't see the issue in >>>>>>>>>> merging >>>>>>>>>> the two (once the old is working that is) >>>>>>>>>> >>>>>>>>>> I over-simplified my question, which is why I was wanting to chat. >>>>>>>>>> But, >>>>>>>>>> I'm too far in the weeds to talk right now. >>>>>>>>>> >>>>>>>>>> This is getting a bit hairy because the old OAuthClient relies on >>>>>>>>>> the >>>>>>>>>> fact >>>>>>>>>> that there is a little application deployed with context >>>>>>>>>> http://localhost:8081/app. So apparently, I've got to convert the >>>>>>>>>> undertow >>>>>>>>>> DeploymentInfo into a Shirkwrap WebArchive and let arquillian >>>>>>>>>> deploy >>>>>>>>>> the >>>>>>>>>> little app. >>>>>>>>>> >>>>>>>>>> But unless you guys can think of an easier solution I've got quite >>>>>>>>>> a >>>>>>>>>> bit >>>>>>>>>> of work to do before we discuss unification. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 6 April 2016 at 15:09, Stan Silvert <ssilvert(a)redhat.com&gt; >>>>>>>>>> wrote: >>>>>>>>>>> I've found a problem with the migrated OAuth client and I've been >>>>>>>>>>> trying >>>>>>>>>>> to work on that. >>>>>>>>>>> >>>>>>>>>>> The thing I wanted to discuss yesterday was about unification of >>>>>>>>>>> the >>>>>>>>>>> old >>>>>>>>>>> and new OAuth clients. But that's a moot point as long as the >>>>>>>>>>> old >>>>>>>>>>> one >>>>>>>>>>> isn't >>>>>>>>>>> fully working with the new testsuite. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 4/6/2016 8:03 AM, Stian Thorgersen wrote: >>>>>>>>>>> >>>>>>>>>>> Do you and Stan still want a chat? If so I can do it now >>>>>>>>>>> >>>>>>>>>>> On 6 Apr 2016 13:46, "Bruno Oliveira" <abstractj(a)redhat.com&gt; >>>>>>>>>>> wrote: >>>>>>>>>>>> Great news! >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Apr 6, 2016 at 6:24 AM, Stian Thorgersen >>>>>>>>>>>> <sthorger(a)redhat.com&gt; >>>>>>>>>>>> wrote: >>>>>>>>>>>>> Bruno and Stan, thanks to Pedro we now have the ability to add >>>>>>>>>>>>> custom >>>>>>>>>>>>> REST endpoints to Keycloak [1]. Also, thanks to Marko we can >>>>>>>>>>>>> add >>>>>>>>>>>>> already add >>>>>>>>>>>>> custom providers to the Arquillian testsuite. Once [2] is >>>>>>>>>>>>> merged >>>>>>>>>>>>> (in >>>>>>>>>>>>> an hour >>>>>>>>>>>>> or so) tests can easily set the time offset on the server. I >>>>>>>>>>>>> added a >>>>>>>>>>>>> temporary test that does exactly that [3]. >>>>>>>>>>>>> >>>>>>>>>>>>> There's a bit of clean-up to do with assert events and the >>>>>>>>>>>>> custom >>>>>>>>>>>>> testsuite providers, but Marko can do that when he gets back >>>>>>>>>>>>> [4]. >>>>>>>>>>>>> >>>>>>>>>>>>> [1] https://issues.jboss.org/browse/KEYCLOAK-2262 >>>>>>>>>>>>> [2] https://issues.jboss.org/browse/KEYCLOAK-2590 >>>>>>>>>>>>> [3] org.keycloak.testsuite.TempSetTimeOffsetTest >>>>>>>>>>>>> [4] https://issues.jboss.org/browse/KEYCLOAK-2755 >>>>>>>>>>>>> >>>>>>>>>>>>> On 4 April 2016 at 14:30, Bruno Oliveira <abstractj(a)redhat.com&gt; >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Perfect and yes for Drone. That already helps with my n00bish >>>>>>>>>>>>>> about >>>>>>>>>>>>>> the test suite. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Apr 4, 2016 at 9:26 AM, Stian Thorgersen >>>>>>>>>>>>>> <sthorger(a)redhat.com&gt; >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> KeycloakRule should be removed and replaced with extending >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> AbstractKeycloakTest. OAuthClient should be ported, but Drone >>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>> WebDriver >>>>>>>>>>>>>>> under the covers right? So it's just about changing how it's >>>>>>>>>>>>>>> injected. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 4 April 2016 at 14:19, Bruno Oliveira >>>>>>>>>>>>>>> <abstractj(a)redhat.com&gt; >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> I know we have a meeting about it today, but I have a >>>>>>>>>>>>>>>> question — >>>>>>>>>>>>>>>> thinking about AccessTokenTest[1]. Should we keep the >>>>>>>>>>>>>>>> testing >>>>>>>>>>>>>>>> structure as >>>>>>>>>>>>>>>> is and just replace WebDriver by Drone? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For example, from my poor understanding KeycloakRule, >>>>>>>>>>>>>>>> WebRule, >>>>>>>>>>>>>>>> OAuthClient should be migrated to the new test suite and the >>>>>>>>>>>>>>>> bits >>>>>>>>>>>>>>>> refering >>>>>>>>>>>>>>>> to WebDriver ported to Drone[2]. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Am I totally wrong? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] - >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://github.com/keycloak/keycloak/blob/c7a8742a368bd8d76301145b08bb1e4... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [2] - https://docs.jboss.org/author/display/ARQ/Drone >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Apr 4, 2016 at 8:55 AM, Bruno Oliveira >>>>>>>>>>>>>>>> <abstractj(a)redhat.com&gt; wrote: >>>>>>>>>>>>>>>>> Thank you Stan, will give it a try >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Apr 4, 2016 at 8:46 AM, Stan Silvert >>>>>>>>>>>>>>>>> <ssilvert(a)redhat.com&gt; >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> Bruno, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Here is what I've done so far. Still have 9 migrated tests >>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>> this package that don't pass. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> https://github.com/ssilvert/keycloak/tree/migrate-admin/testsuite/integra... >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> AbstractClientTest is where most of the adaptation to the >>>>>>>>>>>>>>>>>> new >>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>> suite happens. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Stan >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 4/1/2016 11:04 AM, Bruno Oliveira wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> That makes sense. I will check your commits and try to >>>>>>>>>>>>>>>>>> adapt to >>>>>>>>>>>>>>>>>> my >>>>>>>>>>>>>>>>>> tests. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks Stan >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Fri, Apr 1, 2016 at 10:24 AM, Stan Silvert >>>>>>>>>>>>>>>>>> <ssilvert(a)redhat.com&gt; wrote: >>>>>>>>>>>>>>>>>>> Having never done this before, we don't have any >>>>>>>>>>>>>>>>>>> guidelines. >>>>>>>>>>>>>>>>>>> But >>>>>>>>>>>>>>>>>>> I can tell you how I am approaching this at the moment. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I don't want to touch the actual test code if possible. >>>>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>>>> reason is that there is no way I could fully understand >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> intent of the >>>>>>>>>>>>>>>>>>> original author. Changes to the test code could yield >>>>>>>>>>>>>>>>>>> false >>>>>>>>>>>>>>>>>>> positives and >>>>>>>>>>>>>>>>>>> we would end up with code that doesn't actually test what >>>>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>> was intended to >>>>>>>>>>>>>>>>>>> test. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So I copy over the original test class and get rid of the >>>>>>>>>>>>>>>>>>> annotations that pertain to the old environment. Then I >>>>>>>>>>>>>>>>>>> write adapter code >>>>>>>>>>>>>>>>>>> that lets the test code remain unchanged while calling >>>>>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>>>>> the new >>>>>>>>>>>>>>>>>>> environment. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Of course, there is risk in that approach as well, but it >>>>>>>>>>>>>>>>>>> seems >>>>>>>>>>>>>>>>>>> less than if I tried to modify the original test methods. >>>>>>>>>>>>>>>>>>> And >>>>>>>>>>>>>>>>>>> it seems to >>>>>>>>>>>>>>>>>>> be working well as about 75% of my tests are passing >>>>>>>>>>>>>>>>>>> unchanged >>>>>>>>>>>>>>>>>>> with only a >>>>>>>>>>>>>>>>>>> minimal bit of adapter code written so far. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> For this reason, I rejected extending AbstractAuthTest in >>>>>>>>>>>>>>>>>>> favor >>>>>>>>>>>>>>>>>>> of my own abstract class that just extends >>>>>>>>>>>>>>>>>>> AbstractKeycloakTest. That new >>>>>>>>>>>>>>>>>>> abstract class is where the adapter code lives. I also >>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>> concerns about >>>>>>>>>>>>>>>>>>> duplication of effort so hopefully at some point I can >>>>>>>>>>>>>>>>>>> provide >>>>>>>>>>>>>>>>>>> generic code >>>>>>>>>>>>>>>>>>> that applies to all the migrated tests instead of just >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> ones I'm working >>>>>>>>>>>>>>>>>>> on. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> But by then, we might be all done anyway... >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 4/1/2016 6:23 AM, Bruno Oliveira wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Good morning, I have a question to prevent duplicated >>>>>>>>>>>>>>>>>>> work. >>>>>>>>>>>>>>>>>>> Taking as an example AccessTokenTest[1]. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> In order to execute the tests we have an user >>>>>>>>>>>>>>>>>>> "no-permissions" >>>>>>>>>>>>>>>>>>> with the role "user". Add an user is easy if I extend >>>>>>>>>>>>>>>>>>> AbstractAuthTest[2], >>>>>>>>>>>>>>>>>>> at the same time we don't have any method to assign the >>>>>>>>>>>>>>>>>>> role >>>>>>>>>>>>>>>>>>> "user". >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> To follow the correct guidelines. Should I extend >>>>>>>>>>>>>>>>>>> AbstractAuthTest and add the proper method to assign >>>>>>>>>>>>>>>>>>> roles >>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>> the same >>>>>>>>>>>>>>>>>>> class? Or this is definitely wrong? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> [1] - >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> https://github.com/keycloak/keycloak/blob/c7a8742a368bd8d76301145b08bb1e4... >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> [2] - >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> https://github.com/keycloak/keycloak/blob/7c64ab228b7c95646c54caa4e156251... >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Mar 29, 2016 at 3:26 PM, Stian Thorgersen >>>>>>>>>>>>>>>>>>> <sthorger(a)redhat.com&gt; wrote: >>>>>>>>>>>>>>>>>>>> We need to co-ordinate who migrate which tests. I'm not >>>>>>>>>>>>>>>>>>>> quite >>>>>>>>>>>>>>>>>>>> so >>>>>>>>>>>>>>>>>>>> available this week, but will be checking email at least >>>>>>>>>>>>>>>>>>>> once >>>>>>>>>>>>>>>>>>>> a day. I will >>>>>>>>>>>>>>>>>>>> be fully operational next week. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Prerequisites to migrating tests are: >>>>>>>>>>>>>>>>>>>> * Port assert events (there's a PR from Marko on this >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>> need >>>>>>>>>>>>>>>>>>>> to review and merge it) >>>>>>>>>>>>>>>>>>>> * Ability to set time offset through admin endpoints >>>>>>>>>>>>>>>>>>>> (only >>>>>>>>>>>>>>>>>>>> required for expirations or other time sensitive tests) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Once those are done we can start migrating tests. To >>>>>>>>>>>>>>>>>>>> prevent >>>>>>>>>>>>>>>>>>>> multiple folks porting the same tests, here's your >>>>>>>>>>>>>>>>>>>> initial >>>>>>>>>>>>>>>>>>>> list to port >>>>>>>>>>>>>>>>>>>> (packages in >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> https://github.com/keycloak/keycloak/tree/master/testsuite/integration/sr...): >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> * Stan - admin (these may be duplicates in the new admin >>>>>>>>>>>>>>>>>>>> endpoints tests), actions >>>>>>>>>>>>>>>>>>>> * Bruno - oauth, forms >>>>>>>>>>>>>>>>>>>> * Bolek - account >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> That's right, we're so behind with tests that even the >>>>>>>>>>>>>>>>>>>> engineering manager has to start coding. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Let's use this thread as a place to discuss progress and >>>>>>>>>>>>>>>>>>>> issues >>>>>>>>>>>>>>>>>>>> around migrating the tests. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>>>> abstractj >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>>> abstractj >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>> abstractj >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>> abstractj >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> - >>>>>>>>>>>>>> abstractj >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - >>>>>>>>>>>> abstractj >>>>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> - >>>>>>>> abstractj >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> - >>>>>> abstractj >>>>> >>>>> >>>