gmane.comp.java.jmock.devel

[jira] (JMOCK-261) Behaviour of Expectations.any Matcher has drastically changed

Stefan Penndorf (JIRA — 2012-05-04T13:51:07

    [ https://jira.codehaus.org/browse/JMOCK-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297867#comment-297867 ] 

Stefan Penndorf commented on JMOCK-261:
---------------------------------------

Maybe the workaround does not look that ugly. But it does not read well.

What about: "I'm expecting one of mailer send mail with a success mail as first argument and *(casted to) ErrorHandler anything* as second argument" as opposed to "I'm expecting one of mailer send mail with a success mail as first argument and *any ErrorHandler class* as second argument"

                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe from this list, please visit

[jira] (JMOCK-261) Behaviour of Expectations.any Matcher has drastically changed

Stefan Penndorf (JIRA — 2012-05-04T13:45:03

Stefan Penndorf created JMOCK-261:
-------------------------------------

             Summary: Behaviour of Expectations.any Matcher has drastically changed
                 Key: JMOCK-261
                 URL: https://jira.codehaus.org/browse/JMOCK-261
             Project: jMock
          Issue Type: Bug
          Components: Project chores
    Affects Versions: 2.6.0
            Reporter: Stefan Penndorf
            Priority: Blocker


The behaviour of the method/ Matcher created by org.Expectations.any(type) has drastically changed between JMock 2.5.1 and 2.6.0-RC2:

In 2.5.1 this method creates a (type safe) IsAnything-Matcher which matches even if the argument passed is null
In 2.6.0-RC2 this has changed to hamcrests CoreMatchers.any(type) which is an InstanceOf-Matcher under the hood and does not match null values.

I've been using the any-Matcher to say "I don't care for that argument". This is not possible anymore. The anything()-Matcher is not typesafe, i.e. cannot be used without a cast!

Here is

[jira] (JMOCK-256) Mocks being finalized report "the Mockery is not thread-safe: use a Synchroniser to ensure thread safety"

Duncan McGregor (JIRA — 2012-05-02T15:00:03

    [ https://jira.codehaus.org/browse/JMOCK-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297707#comment-297707 ] 

Duncan McGregor edited comment on JMOCK-256 at 5/2/12 9:58 AM:
---------------------------------------------------------------

A simple workaround, especially for those of us who often run multi-threaded tests anyway, is just to install a Synchroniser and be done with it

{code}
public class JUnitRuleClassImposterisingMockery extends JUnitRuleMockery {

    private final Synchroniser synchroniser = new Synchroniser();

    { 
        setImposteriser(ClassImposteriser.INSTANCE); 
        setThreadingPolicy(synchroniser); // otherwise we get errors on the finalizer thread 
    }
    public Synchroniser getSynchroniser() { 
            return synchroniser; 
    }
}
{code}

I can't help thinking that this should be a reasonably high priority, as it affects every use of ClassImposterizer.
                
      was (Author: dmcg):
    Another simple fi

[jira] (JMOCK-256) Mocks being finalized report "the Mockery is not thread-safe: use a Synchroniser to ensure thread safety"

Duncan McGregor (JIRA — 2012-05-02T14:58:02

    [ https://jira.codehaus.org/browse/JMOCK-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297707#comment-297707 ] 

Duncan McGregor commented on JMOCK-256:
---------------------------------------

Another simple fix, especially for those of us who often run multi-threaded tests anyway, is just to install a Synchroniser and be done with it

{code}
public class JUnitRuleClassImposterisingMockery extends JUnitRuleMockery {

    private final Synchroniser synchroniser = new Synchroniser();

    { 
        setImposteriser(ClassImposteriser.INSTANCE); 
        setThreadingPolicy(synchroniser); // otherwise we get errors on the finalizer thread 
    }
    public Synchroniser getSynchroniser() { 
            return synchroniser; 
    }
}
{code}

                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more in

[jira] (JMOCK-256) Mocks being finalized report "the Mockery is not thread-safe: use a Synchroniser to ensure thread safety"

Toby Weston (JIRA — 2012-05-02T13:48:03

    [ https://jira.codehaus.org/browse/JMOCK-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297687#comment-297687 ] 

Toby Weston commented on JMOCK-256:
-----------------------------------

Same problem here; littered output. Similar solution

{code:java}
public static class SingleThreadedPolicyAvoidingFinaliseProblems extends SingleThreadedPolicy {
        < at >Override
        public Invokable synchroniseAccessTo(final Invokable mockObject) {
            final Invokable synchronizedMockObject = super.synchroniseAccessTo(mockObject);
            return new Invokable() {
                < at >Override
                public Object invoke(Invocation invocation) throws Throwable {
                    if (Thread.currentThread().getName().equalsIgnoreCase("Finalizer"))
                        return mockObject.invoke(invocation);
                    return synchronizedMockObject.invoke(invocation);
                }
            };
        }
    }
{code}
                

--
T

Re: porting to github (ii)

Paul Simmons — 2012-05-02T12:37:37

As a website dev, I wanti to update jmock-website.  I just got round to 
looking at this and have these questions:

Should we replace the old svn repo links with github, and tidy up the 
repository.html page?
Also,  what are the prerequisites to run make on jmock-website?


On 29/04/2012 18:23, Steve Freeman wrote:

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: porting to github (ii)

Steve Freeman — 2012-04-29T17:23:49

yes. Perhaps you could fill in some issues--or just fix it :)

At some point we'll have to move the binaries too.

S

On 29 Apr 2012, at 18:18, Paul Simmons wrote:



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: porting to github (ii)

Paul Simmons — 2012-04-29T17:18:21

Will the 'source repository' link and content not need to change from 
svn codehouse?


On 29/04/2012 15:29, Steve Freeman wrote:

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

porting to github (ii)

Steve Freeman — 2012-04-29T14:29:26

Change of plan

The url is now 

http://jmock-developers.github.com/jmock/

I believe the right thing to do would be to move everything into branches in a repository called jmock

I cloned the jmock-library project rather than renamed it to avoid nasty surprises for anyone who might be working on it. My plan would be to either delete jmock-library, or remove the new jmock and rename jmock-library.

Anyone care to comment?

Anyone care? :)

S.





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

porting to github

Steve Freeman — 2012-04-29T10:52:15

I've been doing a bit of porting to github

This includes a brutal port of the website to http://jmock.github.com

Can people give it a go and make sure it isn't embarrassingly broken? Then I'll do the cname thing and get it off its current host.

Furthermore, if there's someone out there who would be prepared to do a port to use the built-in github site infrastructure, that would be good.

S.

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

+44 797 179 4105
Twitter: < at >sf105
Higher Order Logic Limited
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ. 
Company registered in England & Wales. Number 7522677




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: A question on maven build and branches

Steve Freeman — 2012-04-25T17:13:04

I think we're trying to avoid dependency on maven given that we don't use it. Can we simplify what we've got to collapse the branches?
S. 

Steve Freeman
http://www.higherorderlogic.com

Written on a phone, so please allow for typos and short content.  

On 25 Apr 2012, at 15:46, Paul Simmons <pas-e+AXbWqSrlAAvxtiuMwx3w< at >public.gmane.org> wrote:


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

A question on maven build and branches

Paul Simmons — 2012-04-25T14:46:33

As a confused developer of jmock (rather than a consumer of jmock), I'd like to 
understand how to use the jmock2 branch and packager branch of jmock-library.

Would it be simpler to have maven poms within jmock-library, and replace the ant 
build.xml with the maven equivalent?



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[jira] (JMOCK-246) Expectations "a" and "an" are deprecated, but there is no adequate substitute

Louis Thomas (JIRA — 2012-04-04T22:02:03

    [ https://jira.codehaus.org/browse/JMOCK-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295803#comment-295803 ] 

Louis Thomas commented on JMOCK-246:
------------------------------------

Steve: Actually, in JMock 2.5.1, any() wraps Hamcrest IsAnything(), not IsInstanceOf(), so that really is a behavior change.

I second the motion to change a() from the current, deprecated, silly, "Matcher<Object> a(Class<?> type)" version to the "<T> Matcher<T> a(Class<T> type)".

In Java 6, 
{code}
  public static <T, TT extends T> Matcher<T> a(final Class<TT> type) {
    return (Matcher<T>) new IsInstanceOf(type);
  }
{code}
worked, but in Java 7 it's not compiling. Presumably something like
{code}
  public static <T, TT extends T> Matcher<T> aSubclass(Class<T> base, final Class<TT> type) {
    return (Matcher<T>) new IsInstanceOf(type);
  }
{code}
would work.
                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, pleas

[jira] (JMOCK-246) Expectations "a" and "an" are deprecated, but there is no adequate substitute

Louis Thomas (JIRA — 2012-04-04T22:02:03

    [ https://jira.codehaus.org/browse/JMOCK-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295803#comment-295803 ] 

Louis Thomas edited comment on JMOCK-246 at 4/4/12 5:01 PM:
------------------------------------------------------------

Steve: Actually, in JMock 2.5.1, any() wraps Hamcrest IsAnything(), not IsInstanceOf(), so that really is a behavior change.

I second the motion to change a() from the current, deprecated, silly, "Matcher<Object> a(Class<?> type)" version to the "<T> Matcher<T> a(Class<T> type)" version.

In Java 6, 
{code}
  public static <T, TT extends T> Matcher<T> a(final Class<TT> type) {
    return (Matcher<T>) new IsInstanceOf(type);
  }
{code}
worked, but in Java 7 it's not compiling. Presumably something like
{code}
  public static <T, TT extends T> Matcher<T> aSubclass(Class<T> base, final Class<TT> type) {
    return (Matcher<T>) new IsInstanceOf(type);
  }
{code}
would work.
                
      was (Author: louisth):
    Steve: A

[jira] (JMOCK-260) Add a runNextPendingCommand() to DeterministicExecutor

Daniel Yokomizo (JIRA — 2012-03-27T17:44:03

Daniel Yokomizo created JMOCK-260:
-------------------------------------

             Summary: Add a runNextPendingCommand() to DeterministicExecutor
                 Key: JMOCK-260
                 URL: https://jira.codehaus.org/browse/JMOCK-260
             Project: jMock
          Issue Type: New Feature
          Components: JMock 2.x.x Library
    Affects Versions: 2.5.1
            Reporter: Daniel Yokomizo
            Priority: Trivial


I'm using a DeterministicScheduler in a test only because of this method.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[jira] (JMOCK-246) Expectations "a" and "an" are deprecated, but there is no adequate substitute

Steve Freeman (JIRA — 2012-03-16T08:33:03

    [ https://jira.codehaus.org/browse/JMOCK-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=294299#comment-294299 ] 

Steve Freeman commented on JMOCK-246:
-------------------------------------

any() is a wrapper for Hamcrest IsInstanceOf which has been changing. So I think you've been caught out by the dependency. Perhaps we should change that to wrap IsAnything().
                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[jira] (JMOCK-246) Expectations "a" and "an" are deprecated, but there is no adequate substitute

Erik Forkalsrud (JIRA — 2012-03-14T22:33:03

    [ https://jira.codehaus.org/browse/JMOCK-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=294151#comment-294151 ] 

Erik Forkalsrud commented on JMOCK-246:
---------------------------------------

Regarding any() .. I'm not sure if it's deliberate or a regression, but in 2.5.1 with(any(String.class)) would allow both null and non-null strings to be passed.  In 2.6.0-RC2 null values cause an AssertionError  (parameter 0 did not match: an instance of java.lang.String, because null)
                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[jira] (JMOCK-256) Mocks being finalized report "the Mockery is not thread-safe: use a Synchroniser to ensure thread safety"

Erik Forkalsrud (JIRA — 2012-03-10T01:27:03

    [ https://jira.codehaus.org/browse/JMOCK-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293753#comment-293753 ] 

Erik Forkalsrud commented on JMOCK-256:
---------------------------------------

I have run into the same problem when running a maven build that has a dozen or so tests. The output is littered with the thread safety warnings.

I have a slightly hackish solution that will avoid the warning when it's the Finalizer that finalizes the mocks:

{code:title=SingleThreadedPolicy.java|borderStyle=solid}
public class SingleThreadedPolicy implements ThreadingPolicy {

    static Thread finalizerThread = null;
    static {
        new Object() {
            protected void finalize() {
                finalizerThread = Thread.currentThread();
            }
        };
    }

    ...

    private void checkRunningOnTestThread() {
        if (Thread.currentThread() != testThread && Thread.currentThread() != finalizerThread) {
            reportError("the Mockery

[jira] (JMOCK-259) Synchronization Issue with assertIsSatisfied() using ThreadingPolicy = Synchronizer

Quenio dos Santos (JIRA — 2012-03-05T20:49:02

Quenio dos Santos created JMOCK-259:
---------------------------------------

             Summary: Synchronization Issue with assertIsSatisfied() using ThreadingPolicy = Synchronizer
                 Key: JMOCK-259
                 URL: https://jira.codehaus.org/browse/JMOCK-259
             Project: jMock
          Issue Type: Bug
    Affects Versions: 2.6.0
         Environment: Unix / Mac OS X
            Reporter: Quenio dos Santos


I believe I have encountered a synchronization issue with the new synchronized threading policy mechanism.

In my test, I have the following expectation:

                mockery.checking(new Expectations() {{
                    oneOf(mock).expectedMethod(with(EXPECTE_ARG));
                    will(returnValue(EXPECTED_VALUE));
                    then(processing.is(FINISHED));
                }});

And here is how the test method is executed:

        // thread is started
        try {
            synchroniser.waitUntil(processing.is(FINISHED), 5000);
        } finally {

[jira] (JMOCK-197) Mocking a static nested class causes a net.sf.cglib.core.CodeGenerationException to be thrown.

Duncan Mac-Vicar P. (JIRA — 2012-01-11T22:34:03

    [ https://jira.codehaus.org/browse/JMOCK-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288061#comment-288061 ] 

Duncan Mac-Vicar P. commented on JMOCK-197:
-------------------------------------------

We are seeing this problem when building a rpm package of jmock-1.2.0. The jmock testsuite fails for ppc and s390, which means IBM's JVM. I could reproduce it then on i586 by forcing IBM Java to be installed instead of openJDK.

The testsuite fails on jmock-1.2.0/src/atest/jmock/cglib/MockConcreteClassAcceptanceTest.java

    [junit] Testsuite: atest.jmock.cglib.ErrorDetectionAcceptanceTest
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.014 sec
    [junit] 
    [junit] Testsuite: atest.jmock.cglib.MockConcreteClassAcceptanceTest
    [junit] Tests run: 4, Failures: 0, Errors: 1, Time elapsed: 0.275 sec
    [junit] 
    [junit] Testcase: testCanMockClassesWithComplexConstructors(atest.jmock.cglib.MockConcreteClassAcceptanceTest):Caused an ERRO

[jira] (JMOCK-166) please upload -source / -javadoc attachments to iblio site

Oli Bye (JIRA — 2012-01-10T01:06:02

     [ https://jira.codehaus.org/browse/JMOCK-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oli Bye closed JMOCK-166.
-------------------------

    Resolution: Won't Fix
      Assignee: Oli Bye  (was: Mauro Talevi)

Source included in 2.6.0-RC2 maven artifacts.

Source for old versions is in https://github.com/jmock/jmock-library

Going backwards is too much work given the amount we need to move forwards

                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email