mockry-developer — Mockry Developer List

[Mockry-developer] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[Mockry-developer] Aspects configuration

[<Vin...@ge...>]

I talked with Jonas (aspectwerkz guy) again, and he is working on
implementing dynamic configuration of pointcuts (places where you hook in
the class). It's not stable yet and will require some time I guess.

In the meantime, we can get around that pretty easily by being very generous
when we define pointcuts for classes. The nice thing is that specification
of aspects is based on regexp, so we can do something like:

<aspect pattern="myclasses..">
	<pointcut type="method" pattern"* *(..)"/>
</aspect>

That will weave all methods all methods in all classes under the myclasses
package.

In a first phase, we can deal with that and generate a minimal config file
for aspectwerkz when the test is run, then load the aspectwerkz framework.

Scenario
--------
So suppose we want to mock class MyClass.

When test code creates a new Mock like this:

	Mock mock = new Mock(MyClass.class)

we generate an aspectwerkz configuration file for MyClass that will weave
all methods and fields. We can add advices as necessary from there to do
whatever we want.

We need to be careful with classloading though. We need to reload the
aspectwerkz framework after generating the configuration file, and then
reload the MyClass class. I guess we will need to use our own classloader
for that inside our Mock framework. Any thoughts on this?

-- Vincent

[Mockry-developer] Going forward

[<Vin...@ge...>]

I am getting a clearer picture of what we need to do.

Where to go
-----------

We can achieve our goals with a combination of the following:

1. We build our framework around the dynamic mock framework (in
mockobjects-java cvs under src/core/com/mockobjects/dynamic and
src/core/com/mockobjects/constraints). It already implements all the
concepts of mocks we need. The implementation we want to change is the Mock
class itself, which relies on dynamic proxies to do the interception.

Here's an example of usage taken from the mockobjects mailing list:

	public void testDoGetOldStyle() throws ServletException, IOException {
        	Mock mockTimer = new Mock(Timer.class);
		Mock mockHttpServletResponse = new OrderedMock(HttpServletResponse.class,
"response");
		Mock mockHttpServletRequest = new Mock(HttpServletRequest.class);

		mockHttpServletRequest.matchAndReturn( "getParameter",
			C.args(C.eq("browser-identifier")), "MSIE-5.0" );
		mockHttpServletRequest.expectAndReturn( "getParameter", "subject", "Mail
Subject" );
		mockHttpServletRequest.expectAndReturn( "getParameter",
C.args(C.eq("body")), "Mail Body" );
        	mockTimer.expectAndReturn("getTime", 10000);
        	mockTimer.expectAndReturn("getTime", 20000);

		final PrintWriter contentWriter = new PrintWriter(new StringWriter());

		mockHttpServletResponse.expect( "setContentType", "text/html");
		mockHttpServletResponse.expectAndReturn( "getWriter", C.args(),
contentWriter );

// proposed arbitrary odering implementation
//		CallMatch m1 = mockHttpServletResponse.expect( "setContentType",
"text/html");
//		CallMatch m2 = mockHttpServletResponse.expectAndReturn( "getWriter",
contentWriter );
//		m1.expectBefore(m2);

		SimpleServlet aServlet = new SimpleServlet((Timer)mockTimer.proxy());
		aServlet.doGet((HttpServletRequest) mockHttpServletRequest.proxy(),
			(HttpServletResponse) mockHttpServletResponse.proxy());

		mockHttpServletRequest.verify();
		mockHttpServletResponse.verify();
		mockTimer.verify();
	}

The nice thing about it is that we never have to actually write any mock
class anymore. They are all dynamically generated.

2. We use aspects to intercept calls in the Mock class instead of dynamic
proxies. In pseudo code, would look like:

// We intercept call for setContentType on HttpServletResponse

public class ExampleAdvice extends MethodAdvice {

    private final ExpectationValue m_value = ...

    public ExampleAdvice () {
        super();
    }

    public void setExpectedValue(String value) {
	  ....
    }

    public Object execute(final JoinPoint joinPoint) throws Throwable {
        MethodJoinPoint jp = (MethodJoinPoint)joinPoint;

	// Intercept call to setContentType
	  String actual = jp.getParameters[0];
	  m_value.setActual( actual );

	 // forget about original invocation
    }
}

Then we add the method advice to the method setContentType of
HttpServletResponse.

Jonas just mailed me that he has already implemented some dynamic aspects
configuration. The way it worked before was through configuration files.
This implies you have to know in advance, what aspects you want to add,
which usually is just fine. However, in our case, it depends on what the
test decides. So we need an API to add aspects to classes.

3. AspectWerkz relies on JMangler, so it can't modify classes from rt.jar.
We discussed that before, and I believe there is no easy way to modify
arbitrary classes from that jar, since if a class has already been loaded,
we're doomed. I don't want to modify the VM and be VM dependent (sick!). I
guess we can get around this by modifying the class under test using BCEL or
maybe serp.

Suppose we have a class that reads a file and parses it to generate an
Object. It performs manipulation of file content and if the file contains
error, it should generate exceptions. It's legacy code and we can't (or
don't want to) change it.

public class MyClass {

	private final File m_file;

	public MyClass(String path) {
		m_file = new File(path);
	}

	public void Object parse() {
		...
	}
}

One way to test it would be to replace the reference to File with a
reference to MockFile. MockFile is a copy of File we generate dynamically.
It must be binary compatible with File. We then add aspects to MockFile as
described in 2. When we use MyClass in the test, it will use our mock class
instead of File.

How to get there
----------------

I can think of the following things to do:

1. Evolve AspectWerkz to be 100% runtime configurable without config files.
2. Play with BCEL/serp to implement 3.

Then we wrap up everything and implement Mock class from dynamic mocks using
1+2.

I will start looking into 1. Who volunteers for 2?

-- Vincent

RE: [Mockry-developer] AspectWerkz issues

[<Vin...@ge...>]

I don't know serp at all. Is it a BCEL like tool or does it covers aspects
as well? We will need both of them anyway.

BTW, I've been exchanging e-mails with Jonas - creator of aspectwerkz - and
he is willing to make his framework evolve to support our needs. Good news.

-- Vincent

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of JP
> Belanger
> Sent: Tuesday, May 06, 2003 22:20
> To: moc...@li...
> Subject: Re: [Mockry-developer] AspectWerkz issues
>
>
> Vincent Tenci wrote:
>
> >I took a quick look at AspectWerkz and has to stop before
> getting too sick
> >;-)
> >
> Any reason we are not looking at
> http://sourceforge.net/projects/serp ??
>
>
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux
> enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> mockry-developer mailing list
> moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockry-developer
>

Re: [Mockry-developer] AspectWerkz issues

[JP B. <jpb...@el...>]

Vincent Tenci wrote:

>I took a quick look at AspectWerkz and has to stop before getting too sick
>;-)
>
Any reason we are not looking at  http://sourceforge.net/projects/serp ??

[Mockry-developer] AspectWerkz issues

[<Vin...@ge...>]

I took a quick look at AspectWerkz and has to stop before getting too sick
;-)

Seriously, it's pretty nice and powerfull, but the guy broke IoC everywhere
with regards configuration. As a consequence it makes it hard to change for
a model where aspects are externally managed via an API - rather than a
configuration file. Since I don't want to have to write configuration files
for all my tests :-0, I will look at refactoring the thing. I want to avoid
forking the code base for maintenance reasons, but there are many statics
that make me fear we might have too. We can start anyway and maybe try to
have our changes backported to the AspectWerkz code base later on.

-- Vincent

RE: [Mockry-developer] Classloading mechanism

[<Vin...@ge...>]

You can't load a class if it's already been loaded by the parent
classloader. Thta's the rule cince classloader do upward delegation before
loading the class themselves. So you might be able to load File suing a
custom classloader if it's not been loaded by the bootstrap classloader,
i.e. when your bootstrap code was loaded. However, it certainly won't work
with String or Object ;-) So it's not a universal method. It we want to mock
the String class, I think we need to dynamically copy the String class,
modify the copy using aspects and replace in the class under test references
to String by references to MockString using BCEL. For custom or third-party
classes, it's easier since we can directly modify original classes thanks to
JMangler.

-- Vincent

> -----Original Message-----
> From: Jerome Fillon [mailto:fi...@vi...]
> Sent: Monday, May 05, 2003 14:32
> To: Vincent Tencé
> Cc: Moc...@li...
> Subject: Re: [Mockry-developer] Classloading mechanism
>
>
>
> Well actually you can load java.io.File in your own
> classloader. Maybe
> there is a limitation in JMangler.
> But it's possible.
> You can load a class in the original system loader and call a
> specific
> method that will create our own classloader and then load the classes
> needed.
> We must pay attention to how junit works as well....
>
> Let's spike! :)
>
>
> Vincent Tencé wrote:
>
> >Been thinking about Mockry 2 this week-end.
> >
> >I looked at AspectWerkz, JMangler and the Dynamic Mocks from
> mock objects.
> >We have very powerfull tools in hands and most of the funtionality is
> >already there:
> >
> >1. The dynamic mock framework looks like 95% reusable. They have the
> >concepts of mocks, expectations, parameters, return values,
> ... We can reuse
> >95% of their code base. All we have to change is the Mock
> class that uses
> >JDK1.3 proxies to do the job.
> >
> >2. AspectWerkz (using JMangler) brings the tools to modify classes &
> >interfaces at the methods & fields level.
> >
> >There still are some things to work out though. First, I
> don't know yet if
> >we can use AspectWerkz using an API. All I've seen atm is
> configuration
> >files.
> >
> >Secondly, JMangler cannot modify classes from rt.jar. JP was
> right and
> >classloading mechanism works this way:
> >
> >1. Classes always ask the ClassLoader that loaded them to
> load any of their
> >dependent classes, and
> >2. ClassLoaders always delegate up the delegation tree to
> see if their
> >"parent" ClassLoaders wish to load the class first.
> >
> >All classes in rt.jar will be loaded by the bootstrap classloader. Of
> >course, the bootstrap classloader is located in the VM and
> written in native
> >code.
> >
> >However, I think we can get around this. What if we don't
> try to modify, say
> >String.class, but modify the class that uses String.class
> and make it use
> >MockString.class instead. I think that's how Agile Test from
> Polygenix does
> >it. Not sure thouhgt. I think all we need to do is ensure binary
> >compatibility of the MockString over String. Then we modify
> MockString using
> >AspectWerkz and make our class under test use MockString
> instead. Thoughts?
> >
> >-- Vincent
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:ThinkGeek
> >Welcome to geek heaven.
> >http://thinkgeek.com/sf
> >_______________________________________________
> >Mockry-developer mailing list
> >Moc...@li...
> >https://lists.sourceforge.net/lists/listinfo/mockry-developer
> >
> >
> >
>
>

Re: [Mockry-developer] Classloading mechanism

[Jerome F. <fi...@vi...>]

Well actually you can load java.io.File in your own classloader. Maybe 
there is a limitation in JMangler.
But it's possible.
You can load a class in the original system loader and call a specific 
method that will create our own classloader and then load the classes 
needed.
We must pay attention to how junit works as well....

Let's spike! :)


Vincent Tencé wrote:

>Been thinking about Mockry 2 this week-end.
>
>I looked at AspectWerkz, JMangler and the Dynamic Mocks from mock objects.
>We have very powerfull tools in hands and most of the funtionality is
>already there:
>
>1. The dynamic mock framework looks like 95% reusable. They have the
>concepts of mocks, expectations, parameters, return values, ... We can reuse
>95% of their code base. All we have to change is the Mock class that uses
>JDK1.3 proxies to do the job.
>
>2. AspectWerkz (using JMangler) brings the tools to modify classes &
>interfaces at the methods & fields level.
>
>There still are some things to work out though. First, I don't know yet if
>we can use AspectWerkz using an API. All I've seen atm is configuration
>files.
>
>Secondly, JMangler cannot modify classes from rt.jar. JP was right and
>classloading mechanism works this way:
>
>1. Classes always ask the ClassLoader that loaded them to load any of their
>dependent classes, and
>2. ClassLoaders always delegate up the delegation tree to see if their
>"parent" ClassLoaders wish to load the class first.
>
>All classes in rt.jar will be loaded by the bootstrap classloader. Of
>course, the bootstrap classloader is located in the VM and written in native
>code.
>
>However, I think we can get around this. What if we don't try to modify, say
>String.class, but modify the class that uses String.class and make it use
>MockString.class instead. I think that's how Agile Test from Polygenix does
>it. Not sure thouhgt. I think all we need to do is ensure binary
>compatibility of the MockString over String. Then we modify MockString using
>AspectWerkz and make our class under test use MockString instead. Thoughts?
>
>-- Vincent
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Mockry-developer mailing list
>Moc...@li...
>https://lists.sourceforge.net/lists/listinfo/mockry-developer
>
>  
>

[Mockry-developer] Classloading mechanism

[<Vin...@ge...>]

Been thinking about Mockry 2 this week-end.

I looked at AspectWerkz, JMangler and the Dynamic Mocks from mock objects.
We have very powerfull tools in hands and most of the funtionality is
already there:

1. The dynamic mock framework looks like 95% reusable. They have the
concepts of mocks, expectations, parameters, return values, ... We can reuse
95% of their code base. All we have to change is the Mock class that uses
JDK1.3 proxies to do the job.

2. AspectWerkz (using JMangler) brings the tools to modify classes &
interfaces at the methods & fields level.

There still are some things to work out though. First, I don't know yet if
we can use AspectWerkz using an API. All I've seen atm is configuration
files.

Secondly, JMangler cannot modify classes from rt.jar. JP was right and
classloading mechanism works this way:

1. Classes always ask the ClassLoader that loaded them to load any of their
dependent classes, and
2. ClassLoaders always delegate up the delegation tree to see if their
"parent" ClassLoaders wish to load the class first.

All classes in rt.jar will be loaded by the bootstrap classloader. Of
course, the bootstrap classloader is located in the VM and written in native
code.

However, I think we can get around this. What if we don't try to modify, say
String.class, but modify the class that uses String.class and make it use
MockString.class instead. I think that's how Agile Test from Polygenix does
it. Not sure thouhgt. I think all we need to do is ensure binary
compatibility of the MockString over String. Then we modify MockString using
AspectWerkz and make our class under test use MockString instead. Thoughts?

-- Vincent