[THUCYDIDES-270] Reset implicitly timeout issue. Incorrect operation with TimeoutStack object. Serenity 1.0.42 and above. Created: 26/May/15  Updated: 26/May/15

Status: Open
Project: thucydides
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: alexamber Assignee: johnsmart
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: core

 Description   

Seems to be a recall to present issue on github
Implicitly timeout in WebDriver is not reset to the previous value correctly. For example after isCurrentlyVisible method was called it creates two similar entries in TimeoutStack instance with value "0" that is used in net.thucydides.core.webdriver.WebDriverFactory.resetTimeouts() method so the implicitly timeout is not reset to the previous value and stays equal to "0" causing unexpected failures. It seems that operation with TimeoutStack while finding elements has some bugs that cause creating of duplicates of timeout values. Please investigate what can be done to fix the issue. I suggest in to be critical for those who move to serenity and actively use implicitly waits.






Upgrade Spring to 4.0.x (PINEAPPLE-723)

[PINEAPPLE-734] Failure to run unit tests due to exception: IncompatibleClassChangeError: Found class org.springframework.test.context.TestContext, but interface was expected Created: 09/Jun/14  Updated: 14/Aug/14  Resolved: 09/Jun/14

Status: Resolved
Project: pineapple
Component/s: pineapple-core
Affects Version/s: 1.6
Fix Version/s: 1.6

Type: Sub-task Priority: Major
Reporter: Allan Thrane Andersen Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: core, spring

 Description   

Exception:

java.lang.IncompatibleClassChangeError: Found class org.springframework.test.context.TestContext, but interface was expected
at com.alpha.springutils.DirectoryTestExecutionListener.beforeTestMethod(DirectoryTestExecutionListener.java:69)
at org.springframework.test.context.TestContextManager.beforeTestMethod(TestContextManager.java:349)
at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:73)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:83)
at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:88)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Links:
https://jira.spring.io/browse/SPR-7692



 Comments   
Comment by Allan Thrane Andersen [ 09/Jun/14 ]

Resolved by recompilation of the project.





[PINEAPPLE-681] Create model in module repository Created: 27/May/14  Updated: 27/May/14  Resolved: 27/May/14

Status: Resolved
Project: pineapple
Component/s: pineapple-api, pineapple-core
Affects Version/s: None
Fix Version/s: 1.6

Type: New Feature Priority: Major
Reporter: Allan Thrane Andersen Assignee: Allan Thrane Andersen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on PINEAPPLE-253 Support for creating a new model in m... Resolved
Tags: core

 Description   

Add support for creation of empty model in module repository.



 Comments   
Comment by Allan Thrane Andersen [ 27/May/14 ]

Resolved with r2471.

Comment by Allan Thrane Andersen [ 27/May/14 ]

Duplicate of PINEAPPLE-253.





[JAVAMONEY-42] Add Percent Operation Created: 09/May/13  Updated: 05/Feb/15  Resolved: 30/Aug/13

Status: Closed
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.5

Type: Improvement Priority: Minor
Reporter: keilw Assignee: keilw
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: arithmetic, core

 Description   

Based on Chris' suggestion
1) Do we need to model the concept of a percentage? I think this would make a lot of money operations more readable (especially GST / VAT), and it's a candidate for being an immutable type itself.

and existing approaches to that in Eclipse UOMo Business let's try to create a reusable Percent operation ideally based on the MonetaryOperation/MonetaryFunction paradigm the JSR already has.






[JAVAMONEY-12] Align Integration Requirements With OpenJDK Created: 30/Jan/13  Updated: 02/Sep/14  Due: 14/Mar/15  Resolved: 02/Sep/14

Status: Closed
Project: javamoney
Component/s: Impl: RI
Affects Version/s: None
Fix Version/s: 0.9

Type: Task Priority: Minor
Reporter: atsticks Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days
Environment:

Targeting SE 9.


Tags: JSR, SE, core, design

 Description   

It is viable to discuss with Oracle JDK architects the required constraints on value type and accessor design. As a result of this task a small document should be written or provided that states the common requirements for SE JSRs like this. As an advantage this document can also be shared with other JSRs that are not lead by Oracle.



 Comments   
Comment by keilw [ 26/Apr/13 ]

Given Java 9 has been deferred to early 2016 this issue probably won't matter at all for 1.0





[GLASSFISH-19810] usage of internal proprietary API in nucleus/core/bootstrap Created: 08/Mar/13  Updated: 08/Mar/13  Resolved: 08/Mar/13

Status: Resolved
Project: glassfish
Component/s: other
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b80_EE7MS6

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: Tom Mueller
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: boostrap, build, core, maven, proprietary-api, warning

 Description   
[WARNING]  nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/ASMainHelper.java:[43,44] Constant is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/ASMainHelper.java:[43,44] Constant is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/ASMainHelper.java:[43,44] Constant is internal proprietary API and may be removed in a future release

note that this class was refactored recently to MainHelper, this issue is still relevant though.



 Comments   
Comment by Romain Grécourt [ 08/Mar/13 ]

Tom, I was not able to find the right component for this.
Please re-assign this as needed.

Thanks.

Comment by Tom Mueller [ 08/Mar/13 ]

Fixed on the trunk in revision 60235.





Generated at Thu Jul 28 21:30:17 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.