mockobjects-java-dev — For people who are working on the implementation of the java version

Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming

[Steve F. <st...@m3...>]

QXMgYSBmaXJzdCBjdXQsIHRoZXJlIGlzIGEgc2ltcGxlIGV4YW1wbGUgaW5jbHVkZWQgd2l0aCB0
aGUgZG93bmxvYWQuIExvb2sgZm9yIHRoZSBjYWxjdWxhdG9yIHNlcnZsZXQuDQoNClN0ZXZlDQoN
Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiQ2hhcmxlcyBBbmRlcnNvbiIg
PGNhbmRlckBpZGlvbS5jb20+DQpUbzogPG1vY2tvYmplY3RzLWphdmEtZGV2QGxpc3RzLnNvdXJj
ZWZvcmdlLm5ldD4NClNlbnQ6IEZyaWRheSwgQXVndXN0IDI0LCAyMDAxIDg6NDQgQU0NClN1Ympl
Y3Q6IFJlOiBbTW9ja29iamVjdHMtamF2YS1kZXZdIEFPUCA6IEFzcGVjdCBPcmllbnRlZCBQcm9n
cmFtbWluZw0KDQoNCj4gQXQgMTE6NTUgQU0gOC8yMi8wMSArMDEwMCwgeW91IHdyb3RlOg0KPiA+
KiB0aGUgTW9jayBPYmplY3RzIHByb2plY3QgaXMgY29tcG9zZWQgb2YgMiBwYXJ0cyA6IHRoZSBj
b3JlIGZyYW1ld29yayB3aGljaA0KPiA+aXMgbWFkZSBvZiBFeHBlY3RhdGlvbiBjbGFzc2VzIGFu
ZCB0aGUgbGlrZS4gVGhlc2VzIGNvdWxkIGJlIGNvbnNpZGVyZWQgYXMNCj4gPnV0aWxpdHkgY2xh
c3NlcyB2ZXJ5IHVzZWZ1bCB0byB3cml0ZSBtb2NrIGltcGxlbWVudGF0aW9ucy4gTW9jayBNYWtl
ciBpcw0KPiA+dXNpbmcgdGhlbSBmb3IgZXhhbXBsZSAoaXQgaXMgYSBzdGF0aWMgZ2VuZXJhdG9y
IG9mIG1vY2sgaW1wbGVtZW50YXRpb25zDQo+ID5mcm9tIGFuIGludGVyZmFjZSAtIG1heWJlIGV2
ZW4gYSBjbGFzcywgbm90IHN1cmUgaWYgaXQgaXMgaW1wbGVtZW50ZWQgeWV0KS4NCj4gPkEgZnJh
bWV3b3JrIGxpa2UgRWFzeSBNb2NrIGNvdWxkIGFsc28gdXNlIHRoZW0uDQo+IA0KPiBJIG5lZWQg
dG8gbG9vayBtb3JlIGludG8gdGhlIEV4cGVjdGF0aW9uIGNsYXNzZXMuICBBcyBJIGluZGljYXRl
ZCBiZWZvcmUsIEkgDQo+IHdhcyBpbiB0aGUgcHJvY2VzcyBvZiAgY29kaW5nIHNvbWUgY2xhc3Nl
cyBmb3IgdGhlIHNlcnZsZXQgcGFja2FnZSB0aGF0IGFyZSANCj4gbW9yZSBsaWtlIHN0dWJzIHdo
ZW4gSSBlbmNvdW50ZXJlZCBNT3MuDQo+IA0KPiA+KiBzb21lIHN0YXRpYyBtb2NrIGltcGxlbWVu
dGF0aW9ucyBmb3Igc2V2ZXJhbCBBUElzLiBUaGlzIGlzIHNpbXBseSBiZWNhdXNlDQo+ID5ub3Qg
ZXZlcnlvbmUgaXMgdXNpbmcgSkRLIDEuMyBhbmQgZ3JlYXRlciAod2hpY2ggaXMgbmVlZGVkIHRv
IGR5bmFtaWMNCj4gPnByb3hpZXMpLiBUaGUgaWRlYSBpcyB0aGF0IGV2ZW4gd2l0aCBKREsgMS54
IG9yIDEuMiB5b3UgY2FuIGVhc2lseSB1c2UgTW9jaw0KPiA+T2JqZWN0cyBieSB1c2luZyB0aGVz
ZSBhbHJlYWR5IG1hZGUgY2xhc3Nlcw0KPiANCj4gRmFpciBlbm91Z2guIEkgb25seSBqdXN0IHVw
Z3JhZGVkIGZyb20gMS4xLjggdG8gMS4zLjEgbXlzZWxmLg0KPiANCj4gPlRoYW5rcyBmb3IgeW91
ciBpbnRlcmVzdC4gV2UgYXJlIGludGVyZXN0ZWQgaW4geW91ciBmZWVkYmFjayBhcyB0aGVyZSBp
cw0KPiA+b2J2aW91c2x5IHN0aWxsIGEgbG90IG9mIHdvcmsgdG8gYmUgZG9uZSBvbiB0aGUgcHJv
amVjdC4gV2UgYXJlIGFsc28gbG9va2luZw0KPiA+Zm9yIGhlbHAgLi4uIDotKQ0KPiANCj4gTGV0
IG1lIGx1cmsgYSBiaXQgdG8gZmlndXJlIG91dCB3aGVyZSBJIG1pZ2h0IGJlIHVzZWZ1bC4gIChO
b3JtYWxseSwgSSANCj4gd291bGRuJ3Qgc2hvb3QgbXkgbW91dGggb2ZmIHJpZ2h0IGFmdGVyIGpv
aW5pbmcgYSBsaXN0LCBidXQgdGhlIEFPUCB0aHJlYWQgDQo+IHdhcyBzb21ldGhpbmcgdGhhdCBj
YXVnaHQgbXkgZXllLikgIEF0IHRoZSBtb21lbnQsIG15IHBlcnNvbmFsIGludGVyZXN0IGluIA0K
PiBtb2NraW5nIChpZiB0aGF0J3MgdGhlIGNvcnJlY3QgdmVyYikgdGhlIHNlcnZsZXQgc3R1ZmYs
IHNpbmNlIHRoYXQncyB3aGF0IA0KPiBJJ20gaW1wbGVtZW50aW5nIGFuZCB3aGF0IEkgcGVyc29u
YWxseSBuZWVkIHRvIHRlc3QuDQo+IA0KPiANCj4gDQo+IENoYXJsZXMuDQo+IA0KPiANCj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTW9ja29iamVj
dHMtamF2YS1kZXYgbWFpbGluZyBsaXN0DQo+IE1vY2tvYmplY3RzLWphdmEtZGV2QGxpc3RzLnNv
dXJjZWZvcmdlLm5ldA0KPiBodHRwOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3Rp
bmZvL21vY2tvYmplY3RzLWphdmEtZGV2DQo+IA0K

Unit testing servlets (WAS Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming)

[Vincent M. <vm...@oc...>]

----- Original Message -----
From: "Charles Anderson" <ca...@id...>
To: <moc...@li...>
Sent: Friday, August 24, 2001 8:44 AM
Subject: Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming

[snip]
> Let me lurk a bit to figure out where I might be useful.  (Normally, I
> wouldn't shoot my mouth off right after joining a list, but the AOP thread
> was something that caught my eye.)

:-). Don't worry, shoot ... we're looking for any help including the most
important thing : feedback

> At the moment, my personal interest in
> mocking (if that's the correct verb) the servlet stuff, since that's what
> I'm implementing and what I personally need to test.
>

Another alternative or rather complementary approach for unit testing
servlets, JSP, taglibs, filters and EJB is to use Cactus
(http://jakarta.apache.org/commons/cactus). There is a simple and
comparative paper between Mock Objects vs In-Container testing (that's what
Cactus advocates) on
http://jakarta.apache.org/commons/cactus/mockobjects.html ...

-Vincent

Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming

[Charles A. <ca...@id...>]

At 11:55 AM 8/22/01 +0100, you wrote:
>* the Mock Objects project is composed of 2 parts : the core framework which
>is made of Expectation classes and the like. Theses could be considered as
>utility classes very useful to write mock implementations. Mock Maker is
>using them for example (it is a static generator of mock implementations
>from an interface - maybe even a class, not sure if it is implemented yet).
>A framework like Easy Mock could also use them.

I need to look more into the Expectation classes.  As I indicated before, I 
was in the process of  coding some classes for the servlet package that are 
more like stubs when I encountered MOs.

>* some static mock implementations for several APIs. This is simply because
>not everyone is using JDK 1.3 and greater (which is needed to dynamic
>proxies). The idea is that even with JDK 1.x or 1.2 you can easily use Mock
>Objects by using these already made classes

Fair enough. I only just upgraded from 1.1.8 to 1.3.1 myself.

>Thanks for your interest. We are interested in your feedback as there is
>obviously still a lot of work to be done on the project. We are also looking
>for help ... :-)

Let me lurk a bit to figure out where I might be useful.  (Normally, I 
wouldn't shoot my mouth off right after joining a list, but the AOP thread 
was something that caught my eye.)  At the moment, my personal interest in 
mocking (if that's the correct verb) the servlet stuff, since that's what 
I'm implementing and what I personally need to test.



Charles.

Re: [Mockobjects-java-dev] [Proposal] List of tasks for release 0.02

[Vincent M. <vm...@oc...>]

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: <moc...@li...>
Sent: Wednesday, August 22, 2001 11:16 PM
Subject: Re: [Mockobjects-java-dev] [Proposal] List of tasks for release
0.02


> > T7C - add packages.html to each package

description of what a package is. This file will be picked up during javadoc
generation. (one per package)

> > T7D - add overview.html

same but for the first overview page of the javadoc (one in total)

>
> what goes in these?
>
> Steve
>
> 2?¡¸rÛjözùSX,X´Ê'?yˍ«uëS˲<qç®zضY-+²Ê­Ç¢¸ë-+³ù²Ø~¡Én7¶È½§

Have a look at todo.xml, I have committed the task list yesterday.

P.S.: I really like your signature ... :-)

RE: [Mockobjects-java-dev] Coding conventions for the sources

[Tim M. <tim...@po...>]

Guys - those coding conventions are fine with me (if you do decide to dump
my - I push for f as a prefix - its not bad and is easy to type -
underscores are a real pain, I tried them for a while in MockVaj and hated
it).

Tim

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Steve Freeman
> Sent: 22 August 2001 9:20 am
> To: moc...@li...
> Subject: Re: [Mockobjects-java-dev] Coding conventions for the sources
>
>
> > > 1. Sometimes I start class and method braces on the same
> line. Depends on
> > how complicated the signature is. Compact is better.
> >
> > what do you mean sometimes ? We need to choose ... and I don't
> agree that
> > compact is better. For me, the more readable is the best,
> compacity was an
> > issue when we had not enough memory ...
>
> OK. braces always at the end. If we can force braces to the next
> line when the line wraps that would be nice, but not essential.
>
> > > 4. we don't believe so much in javadoc. that's why we ship
> the sources and
> > tests.
> > "
> > Tim (and Steve), how often do you look at the JDK source code
> when you need
> > to
> > understand how the BufferedReader.readLine() methods works and what it
> > returns if there is no more data to be read from the stream ?
>
> The mock library is not in the same category. It's very small
> and, unlike the JDK, it comes with unit tests. We need to include
> the copyright but, after that, all we might need is a short
> description of the class as a whole.
>
> As an exercise, would you like to show some doc that does not
> just reproduce the code?
>
> > > 7. I used to like the 'this.' convention, but went off it. I
> don't feel
> > too strongly. The advantage of a prefix, such as 'my' is that
> completion is
> > more focussed, especially on a large class.
> >
> > Personnally, I liked "m_XXXX" but on the last 5 projects I've worked on,
> > almost everyone else was against me ... and I accepted their
> choice to use
> > the Sun convention (no prefix). Shall we go for that or do you
> want to keep
> > 'my' ?
>
> not 'm_'. Let's stick with 'my' for now because I can't be
> bothered to change the code.
>
>
> > > 8. method parameters should not clash with a class variable, or be
> > prefaced by 'a', not 'the'
> > do you want 'a' ? It's fine with me.
>
> good. smalltalk legacy.
>
> > > 9. 78 characters per line
> > ok, if you wish. I'll change that.
>
> sometimes it wraps better
>
> > err ... it is not in the coding conventions I have put .... (it
> was for cactus though)
> I followed the link you sent.
>
> Anything else?
>
>
> 2¡rjzŠ‚´’yuŠ²q®z¶–²­¢–³²~¡n¶½

Re: [Mockobjects-java-dev] [Proposal] List of tasks for release 0.02

[Steve F. <st...@m3...>]

PiBUN0MgLSBhZGQgcGFja2FnZXMuaHRtbCB0byBlYWNoIHBhY2thZ2UNCj4gVDdEIC0gYWRkIG92
ZXJ2aWV3Lmh0bWwNCg0Kd2hhdCBnb2VzIGluIHRoZXNlPw0KDQpTdGV2ZQ0KDQo=

Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming

[Steve F. <st...@m3...>]

PiBvaCwgeWVzIGl0IGNoYW5nZXMgdGhlIGJ5dGVjb2RlIC4uLiBidXQgbm90IHRoZSBzb3VyY2Vz
IC4uLiBtZWFuaW5nIHRoYXQgaW4NCj4gQW50IGZvciBleGFtcGxlLCB5b3UgcnVuIG9uZSB0YXJn
ZXQgZm9yIHVuaXQgdGVzdGluZyBhbmQgYW5vdGhlciBvbmUgZm9yDQo+IGRlcGxveWluZyB3aXRo
b3V0IHRlc3RpbmcgKG9yIHlvdSBjYW4gZXZlbiBsZWF2ZSB0ZXN0aW5nIG9uLCB3aGljaCBpcyBh
bHNvDQo+IGdyZWF0IGJlY2F1c2UgdGhlIHRlc3RzIGFyZSB0aGVuIGFsc28gZXhlcmNpc2VkIG9u
IHRoZSB1c2VyJ3MgbWFjaGluZSBhbmQNCj4gc29tZXRpbWVzIHlvdSdsbCBmaW5kIHRoYXQgeW91
ciB0ZXN0IHdhcyBub3QgbWFjaGluZSBpbmRlcGVuZGVudCBvciB0aGUNCj4gbGlrZSkuDQoNCnNv
IHRoZSBpc3N1ZSByZW1haW5zLCB0aGF0IHRoZSBjb2RlIHlvdSB0ZXN0IGlzIG5vdCB0aGUgY29k
ZSB5b3UgZGVwbG95LiBTdGlsbCB1c2VmdWwgc29tZXRpbWVzLCBidXQgdG8gYmUgdXNlZCB3aXRo
IGNhcmUuDQoNCg0K

Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming

[Vincent M. <vm...@oc...>]

Hi Charles;

WRT to AOP, I've just discovered the concept 3 days ago ... I have never
used it. I think I'll give a try just to see how usable it is.
WRT to EasyMock :
* the Mock Objects project is composed of 2 parts : the core framework which
is made of Expectation classes and the like. Theses could be considered as
utility classes very useful to write mock implementations. Mock Maker is
using them for example (it is a static generator of mock implementations
from an interface - maybe even a class, not sure if it is implemented yet).
A framework like Easy Mock could also use them.
* some static mock implementations for several APIs. This is simply because
not everyone is using JDK 1.3 and greater (which is needed to dynamic
proxies). The idea is that even with JDK 1.x or 1.2 you can easily use Mock
Objects by using these already made classes

The challenge would be to "standardize" on a set of expectations and utility
classes that could be used by extensions (like JUnit is the core and then
you can build extensions around it). Our goal is to try to make the Mock
Objects project a reference in this area.

Thanks for your interest. We are interested in your feedback as there is
obviously still a lot of work to be done on the project. We are also looking
for help ... :-)

-Vincent

----- Original Message -----
From: "Charles Anderson" <ca...@id...>
To: <moc...@li...>
Sent: Wednesday, August 22, 2001 6:25 AM
Subject: Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming


>
> Hi,
>
> I just discovered Mock Objects (so much better than the servlet stubs I
was
> writing) and joined the list today.  With regards to the example of using
> AOP for logging, dynamic proxies in 1.3 can do that.  I've seen a couple
> articles on it in the last month or two.  I'm not knocking AOP, just
> pointing out another way to deal with logging.
>
> Which brings up another point, has anyone checked out EasyMock
> (http://tammofreese.de/easymock/)?  How does it fit into the mock objects
> development game plan?  (sorry if these are lame questions; I didn't see
> any mention of easy mock in the archives, but then again searching seemed
> to be on the fritz.)
>
>
> Charles.
>
>
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> http://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>

Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming

[Charles A. <ca...@id...>]

Hi,

I just discovered Mock Objects (so much better than the servlet stubs I was 
writing) and joined the list today.  With regards to the example of using 
AOP for logging, dynamic proxies in 1.3 can do that.  I've seen a couple 
articles on it in the last month or two.  I'm not knocking AOP, just 
pointing out another way to deal with logging.

Which brings up another point, has anyone checked out EasyMock 
(http://tammofreese.de/easymock/)?  How does it fit into the mock objects 
development game plan?  (sorry if these are lame questions; I didn't see 
any mention of easy mock in the archives, but then again searching seemed 
to be on the fritz.)


Charles.

[Mockobjects-java-dev] CVS: mockobjects-java/doc/xdocs coding_conventions.xml,1.3,1.4

[Vincent M. <vm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv15530

Modified Files:
	coding_conventions.xml 
Log Message:
updated coding conventions

Index: coding_conventions.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/doc/xdocs/coding_conventions.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- coding_conventions.xml	2001/08/21 10:44:06	1.3
+++ coding_conventions.xml	2001/08/22 10:36:45	1.4
@@ -30,8 +30,8 @@
       <p>
          Below is a list of coding conventions that are specific to Mock
          Objects, everything else not specificially mentioned here should
-         follow the official <link
-         href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html">Sun
+         follow the official <link href=
+         "http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html">Sun
          Java Coding Conventions</link>.
       </p>
 
@@ -42,15 +42,13 @@
       <s2 title="1. Brackets">
 
         <p>
-          For class and method declaration, brackets should begin and end on a
-          <strong>new</strong> line. Example :
+          For class and method declaration, brackets should begin on the
+          <strong>same</strong> line. Example :
         </p>
 
 <source><![CDATA[
-public class SomeClass
-{
-    public void someMethod()
-    {
+public class SomeClass {
+    public void someMethod() {
     }
 }
 ]]></source>
@@ -63,8 +61,7 @@
         </p>
 
 <source><![CDATA[
-public void someMethod()
-{
+public void someMethod() {
     if (expression) {
     } else if (other_expression) {
     }
@@ -178,18 +175,16 @@
       <s2 title="7. Class variables">
 
         <p>
-          Class variables should not have any prefix and <strong>must</strong>
-          be referenced using the <code>this</code> object. Example :
+          Class variables should be prefixed with <strong>my</strong>.
+          Example :
         </p>
 
 <source><![CDATA[
-public class SomeClass
-{
-    private String someString;
+public class SomeClass {
+    private String myString;
 [...]
-    public void someMethod()
-    {
-        logger.debug("Value = " + this.someString);
+    public void someMethod() {
+        logger.debug("Value = " + myString);
     }
 }
 ]]></source>
@@ -199,13 +194,12 @@
       <s2 title="8. Parameter names">
 
         <p>
-          Method parameters should be prefixed by "<code>the</code>" (for
+          Method parameters should be prefixed by "<code>a</code>" (for
           differentiating them from inner variables). For example :
         </p>
 
 <source><![CDATA[
-public void someMethod(String theClassName)
-{
+public void someMethod(String aClassName) {
     String className; // inner variable
 }
 ]]></source>
@@ -215,7 +209,7 @@
       <s2 title="9. Line length">
 
         <p>
-          Avoid lines longer than 80 characters for Code, comments, ...
+          Avoid lines longer than 78 characters for Code, comments, ...
         </p>
 
       </s2>
@@ -230,6 +224,11 @@
 <source><![CDATA[
 @version $Id$
 ]]></source>
+
+        <note>
+          You just need to write <code>@version $Id$</code> and CVS will
+          add the rest during commits
+        </note>
 
       </s2>
 

Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming

[Vincent M. <vm...@oc...>]

----- Original Message -----
From: "Steve Freeman" <st...@ok...>
To: <moc...@li...>
Sent: Wednesday, August 22, 2001 9:54 AM
Subject: Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming


>
> Vincent Massol <vm...@oc...> said:
> > > of course, the real problem is that it changes the code under test, so
it's not totally reliable for that.
> >
> > why do you say that ? That's the beauty of it, it doesn't change the
code at all ... I'll post an example soon ..
>
> It doesn't change the visible code, but it must change something on the
way to the byte code or there'd be no point in having it.

oh, yes it changes the bytecode ... but not the sources ... meaning that in
Ant for example, you run one target for unit testing and another one for
deploying without testing (or you can even leave testing on, which is also
great because the tests are then also exercised on the user's machine and
sometimes you'll find that your test was not machine independent or the
like).

-Vincent

Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming

[Steve F. <st...@ok...>]

Vincent Massol <vm...@oc...> said: 
> > of course, the real problem is that it changes the code under test, so it's not totally reliable for that.
> 
> why do you say that ? That's the beauty of it, it doesn't change the code at all ... I'll post an example soon ..

It doesn't change the visible code, but it must change something on the way to the byte code or there'd be no point in having it.

Steve

Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming

[Vincent M. <vm...@oc...>]

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: <moc...@li...>
Sent: Wednesday, August 22, 2001 9:11 AM
Subject: Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming


> From: "Vincent Massol" <vm...@oc...>
> > I don't know what covariance and contravariance are but after reading
their
> > introduction paper, I really want to try it. I may even try it on Cactus
> > real soon to see how it goes. There is even an Ant task to help for the
> > build (not that it changes much). Also, if you read their paper, you'll
find
> > a screenshot of their IDE extension. They have plugins for JBuilder 4/5
and
> > Netbeans.
> >
> > The concept is great. It seems very easy and great for unit
> > testing/debugging. For other things, it looks a bit more complex but
> > probably simply requires training.
>
> of course, the real problem is that it changes the code under test, so
it's not totally reliable for that.

why do you say that ? That's the beauty of it, it doesn't change the code at
all ... I'll post an example soon ..
-Vincent

Re: [Mockobjects-java-dev] Coding conventions for the sources

[Steve F. <st...@m3...>]

PiA+IDEuIFNvbWV0aW1lcyBJIHN0YXJ0IGNsYXNzIGFuZCBtZXRob2QgYnJhY2VzIG9uIHRoZSBz
YW1lIGxpbmUuIERlcGVuZHMgb24NCj4gaG93IGNvbXBsaWNhdGVkIHRoZSBzaWduYXR1cmUgaXMu
IENvbXBhY3QgaXMgYmV0dGVyLg0KPiANCj4gd2hhdCBkbyB5b3UgbWVhbiBzb21ldGltZXMgPyBX
ZSBuZWVkIHRvIGNob29zZSAuLi4gYW5kIEkgZG9uJ3QgYWdyZWUgdGhhdA0KPiBjb21wYWN0IGlz
IGJldHRlci4gRm9yIG1lLCB0aGUgbW9yZSByZWFkYWJsZSBpcyB0aGUgYmVzdCwgY29tcGFjaXR5
IHdhcyBhbg0KPiBpc3N1ZSB3aGVuIHdlIGhhZCBub3QgZW5vdWdoIG1lbW9yeSAuLi4NCg0KT0su
IGJyYWNlcyBhbHdheXMgYXQgdGhlIGVuZC4gSWYgd2UgY2FuIGZvcmNlIGJyYWNlcyB0byB0aGUg
bmV4dCBsaW5lIHdoZW4gdGhlIGxpbmUgd3JhcHMgdGhhdCB3b3VsZCBiZSBuaWNlLCBidXQgbm90
IGVzc2VudGlhbC4NCg0KPiA+IDQuIHdlIGRvbid0IGJlbGlldmUgc28gbXVjaCBpbiBqYXZhZG9j
LiB0aGF0J3Mgd2h5IHdlIHNoaXAgdGhlIHNvdXJjZXMgYW5kDQo+IHRlc3RzLg0KPiAiDQo+IFRp
bSAoYW5kIFN0ZXZlKSwgaG93IG9mdGVuIGRvIHlvdSBsb29rIGF0IHRoZSBKREsgc291cmNlIGNv
ZGUgd2hlbiB5b3UgbmVlZA0KPiB0bw0KPiB1bmRlcnN0YW5kIGhvdyB0aGUgQnVmZmVyZWRSZWFk
ZXIucmVhZExpbmUoKSBtZXRob2RzIHdvcmtzIGFuZCB3aGF0IGl0DQo+IHJldHVybnMgaWYgdGhl
cmUgaXMgbm8gbW9yZSBkYXRhIHRvIGJlIHJlYWQgZnJvbSB0aGUgc3RyZWFtID8NCg0KVGhlIG1v
Y2sgbGlicmFyeSBpcyBub3QgaW4gdGhlIHNhbWUgY2F0ZWdvcnkuIEl0J3MgdmVyeSBzbWFsbCBh
bmQsIHVubGlrZSB0aGUgSkRLLCBpdCBjb21lcyB3aXRoIHVuaXQgdGVzdHMuIFdlIG5lZWQgdG8g
aW5jbHVkZSB0aGUgY29weXJpZ2h0IGJ1dCwgYWZ0ZXIgdGhhdCwgYWxsIHdlIG1pZ2h0IG5lZWQg
aXMgYSBzaG9ydCBkZXNjcmlwdGlvbiBvZiB0aGUgY2xhc3MgYXMgYSB3aG9sZS4gDQoNCkFzIGFu
IGV4ZXJjaXNlLCB3b3VsZCB5b3UgbGlrZSB0byBzaG93IHNvbWUgZG9jIHRoYXQgZG9lcyBub3Qg
anVzdCByZXByb2R1Y2UgdGhlIGNvZGU/DQoNCj4gPiA3LiBJIHVzZWQgdG8gbGlrZSB0aGUgJ3Ro
aXMuJyBjb252ZW50aW9uLCBidXQgd2VudCBvZmYgaXQuIEkgZG9uJ3QgZmVlbA0KPiB0b28gc3Ry
b25nbHkuIFRoZSBhZHZhbnRhZ2Ugb2YgYSBwcmVmaXgsIHN1Y2ggYXMgJ215JyBpcyB0aGF0IGNv
bXBsZXRpb24gaXMNCj4gbW9yZSBmb2N1c3NlZCwgZXNwZWNpYWxseSBvbiBhIGxhcmdlIGNsYXNz
Lg0KPiANCj4gUGVyc29ubmFsbHksIEkgbGlrZWQgIm1fWFhYWCIgYnV0IG9uIHRoZSBsYXN0IDUg
cHJvamVjdHMgSSd2ZSB3b3JrZWQgb24sDQo+IGFsbW9zdCBldmVyeW9uZSBlbHNlIHdhcyBhZ2Fp
bnN0IG1lIC4uLiBhbmQgSSBhY2NlcHRlZCB0aGVpciBjaG9pY2UgdG8gdXNlDQo+IHRoZSBTdW4g
Y29udmVudGlvbiAobm8gcHJlZml4KS4gU2hhbGwgd2UgZ28gZm9yIHRoYXQgb3IgZG8geW91IHdh
bnQgdG8ga2VlcA0KPiAnbXknID8NCg0Kbm90ICdtXycuIExldCdzIHN0aWNrIHdpdGggJ215JyBm
b3Igbm93IGJlY2F1c2UgSSBjYW4ndCBiZSBib3RoZXJlZCB0byBjaGFuZ2UgdGhlIGNvZGUuDQoN
CiANCj4gPiA4LiBtZXRob2QgcGFyYW1ldGVycyBzaG91bGQgbm90IGNsYXNoIHdpdGggYSBjbGFz
cyB2YXJpYWJsZSwgb3IgYmUNCj4gcHJlZmFjZWQgYnkgJ2EnLCBub3QgJ3RoZScNCj4gZG8geW91
IHdhbnQgJ2EnID8gSXQncyBmaW5lIHdpdGggbWUuDQoNCmdvb2QuIHNtYWxsdGFsayBsZWdhY3ku
DQoNCj4gPiA5LiA3OCBjaGFyYWN0ZXJzIHBlciBsaW5lDQo+IG9rLCBpZiB5b3Ugd2lzaC4gSSds
bCBjaGFuZ2UgdGhhdC4NCg0Kc29tZXRpbWVzIGl0IHdyYXBzIGJldHRlcg0KDQo+IGVyciAuLi4g
aXQgaXMgbm90IGluIHRoZSBjb2RpbmcgY29udmVudGlvbnMgSSBoYXZlIHB1dCAuLi4uIChpdCB3
YXMgZm9yIGNhY3R1cyB0aG91Z2gpDQpJIGZvbGxvd2VkIHRoZSBsaW5rIHlvdSBzZW50Lg0KDQpB
bnl0aGluZyBlbHNlPw0KDQoNCg==

Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming

[Steve F. <st...@m3...>]

RnJvbTogIlZpbmNlbnQgTWFzc29sIiA8dm1hc3NvbEBvY3RvLmNvbT4NCj4gSSBkb24ndCBrbm93
IHdoYXQgY292YXJpYW5jZSBhbmQgY29udHJhdmFyaWFuY2UgYXJlIGJ1dCBhZnRlciByZWFkaW5n
IHRoZWlyDQo+IGludHJvZHVjdGlvbiBwYXBlciwgSSByZWFsbHkgd2FudCB0byB0cnkgaXQuIEkg
bWF5IGV2ZW4gdHJ5IGl0IG9uIENhY3R1cw0KPiByZWFsIHNvb24gdG8gc2VlIGhvdyBpdCBnb2Vz
LiBUaGVyZSBpcyBldmVuIGFuIEFudCB0YXNrIHRvIGhlbHAgZm9yIHRoZQ0KPiBidWlsZCAobm90
IHRoYXQgaXQgY2hhbmdlcyBtdWNoKS4gQWxzbywgaWYgeW91IHJlYWQgdGhlaXIgcGFwZXIsIHlv
dSdsbCBmaW5kDQo+IGEgc2NyZWVuc2hvdCBvZiB0aGVpciBJREUgZXh0ZW5zaW9uLiBUaGV5IGhh
dmUgcGx1Z2lucyBmb3IgSkJ1aWxkZXIgNC81IGFuZA0KPiBOZXRiZWFucy4NCj4gDQo+IFRoZSBj
b25jZXB0IGlzIGdyZWF0LiBJdCBzZWVtcyB2ZXJ5IGVhc3kgYW5kIGdyZWF0IGZvciB1bml0DQo+
IHRlc3RpbmcvZGVidWdnaW5nLiBGb3Igb3RoZXIgdGhpbmdzLCBpdCBsb29rcyBhIGJpdCBtb3Jl
IGNvbXBsZXggYnV0DQo+IHByb2JhYmx5IHNpbXBseSByZXF1aXJlcyB0cmFpbmluZy4NCg0Kb2Yg
Y291cnNlLCB0aGUgcmVhbCBwcm9ibGVtIGlzIHRoYXQgaXQgY2hhbmdlcyB0aGUgY29kZSB1bmRl
ciB0ZXN0LCBzbyBpdCdzIG5vdCB0b3RhbGx5IHJlbGlhYmxlIGZvciB0aGF0Lg0KDQoNCg==

Re: [Mockobjects-java-dev] Coding conventions for the sources

[Vincent M. <vm...@oc...>]

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: <moc...@li...>
Sent: Wednesday, August 22, 2001 2:09 AM
Subject: Re: [Mockobjects-java-dev] Coding conventions for the sources


> 1. Sometimes I start class and method braces on the same line. Depends on
how complicated the signature is. Compact is better.

what do you mean sometimes ? We need to choose ... and I don't agree that
compact is better. For me, the more readable is the best, compacity was an
issue when we had not enough memory ...

I prefer :

out.println("aaa");
out.println("bb");

than

out.println("aaa");out.println("bb");

> 4. we don't believe so much in javadoc. that's why we ship the sources and
tests.

Yes, you already told me this ... :) But you've never answer the question I
asked Tim (and you) ... Which was :

"
Tim (and Steve), how often do you look at the JDK source code when you need
to
understand how the BufferedReader.readLine() methods works and what it
returns if there is no more data to be read from the stream ?

Personnally I don't (although it is available, I even have it on my machine)
and I prefer to look at the javadoc !

Want to make a bet on how people do it ? :-)
"

I agree to some extent that javadoc won't be needed for mock implementation
but I don't agree for core classes. But don't worry I can do it myself if
you don't want to do it. It is always better that someone external write it
because that person will know what's difficult to understand.

> 7. I used to like the 'this.' convention, but went off it. I don't feel
too strongly. The advantage of a prefix, such as 'my' is that completion is
more focussed, especially on a large class.

Personnally, I liked "m_XXXX" but on the last 5 projects I've worked on,
almost everyone else was against me ... and I accepted their choice to use
the Sun convention (no prefix). Shall we go for that or do you want to keep
'my' ?

> 8. method parameters should not clash with a class variable, or be
prefaced by 'a', not 'the'

do you want 'a' ? It's fine with me.

> 9. 78 characters per line

ok, if you wish. I'll change that.

> 11. Logging isn't really appropriate.

err ... it is not in the coding conventions I have put .... (it was for
cactus though)

> 12. 'throws' clauses make explicit statements about the implementation of
your code. throwing exceptions straight through can sometimes be the best
thing to do, e.g. for IO. Each framework should have a base exception class.
etc.

err ... it is not in the coding conventions I have put .... (it was for
cactus though)

As we are only 2 to discuss for the time being, it's easier to agree on
something. I don't really care. Just tell me clearly what you absolutely
want, prefer or don't care. Also, please check the coding_conventions.xml in
CVS as this is our reference document.

Thanks
-Vincent

Re: [Mockobjects-java-dev] JDBC Test First ?

[Vincent M. <vm...@oc...>]

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: <moc...@li...>
Sent: Wednesday, August 22, 2001 1:59 AM
Subject: Re: [Mockobjects-java-dev] JDBC Test First ?


> I'd like to put it up soon, but it needs some more tidy up.
>

ok

> I'd also like to move it to XML, but the current format doesn't support
highlighting within the code.

I don't think it is enough to hold the move to XML ... :)
That's our style for the moment and I think it is good enough for the time
being. We can always improve later on. I think that we badly need some
documentation on the web site to give examples, and it is priority number 1.
Let's go for it ! :)

-Vincent

>
> I'll take a look now we're back online
>
> Steve
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@oc...>
> To: <moc...@li...>
> Sent: Tuesday, August 21, 2001 12:17 PM
> Subject: [Mockobjects-java-dev] JDBC Test First ?
>
>
> > Steve,
> >
> > Any chance that we could put this paper in the Mock Objects web site ?
Could
> > you put it in XML format ?
> >
> > Thanks
> > -Vincent
> >
> >
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > http://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
>
2?$¡¸ÞrÛ#jözùsSX§,X¬´Ê'?ãyËl«ÚuëåSËl²<«qç讧zØm¶Yÿ-+-²Ê.­ÇY¢¸ë-+-³ùb²
ا~æ¡É(n7o¶ÈÚ½§^

Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming

[Vincent M. <vm...@oc...>]

I don't know what covariance and contravariance are but after reading their
introduction paper, I really want to try it. I may even try it on Cactus
real soon to see how it goes. There is even an Ant task to help for the
build (not that it changes much). Also, if you read their paper, you'll find
a screenshot of their IDE extension. They have plugins for JBuilder 4/5 and
Netbeans.

The concept is great. It seems very easy and great for unit
testing/debugging. For other things, it looks a bit more complex but
probably simply requires training.
-Vincent

----- Original Message -----
From: "Tim Mackinnon" <tim...@po...>
To: <moc...@li...>
Sent: Wednesday, August 22, 2001 2:05 AM
Subject: RE: [Mockobjects-java-dev] AOP : Aspect Oriented Programming


> The kicker has always been getting good IDE support to work out what got
> woven in - not sure if they have made any progress on this? There are some
> good examples of weaving in patterns like observer etc. which I thought
were
> good at the time I looked at it - and it did fire my brain a year back
when
> working on the original mock stuff but I never found a good moment to use
> it.
>
> There were also some issues with co-variance and contravariance at the
time
> I looked at it - they had arbitrarily chosen the wrong way and broke the
> rules, but I remember Gregor saying they would consider changing it.
>
> Tim
>
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...]On Behalf Of
> > Steve Freeman
> > Sent: 22 August 2001 12:54 am
> > To: moc...@li...
> > Subject: Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming
> >
> >
> > I've known about this stuff for a while but have quite never
> > found the time to do anything with it.
> >
> > Time to give it a try?
> >
> > Steve
> >
> >
> > ----- Original Message -----
> > From: "Vincent Massol" <vm...@oc...>
> > To: <moc...@li...>
> > Sent: Monday, August 20, 2001 2:10 PM
> > Subject: [Mockobjects-java-dev] AOP : Aspect Oriented Programming
> >
> >
> > > I have discovered AOP this week end (AspectJ) and found it very very
> > > interesting, especially for unit testing purposes. I highly
> > suggest that you
> > > take 30 minutes to an hour to read the "getting started" paper
> > > (http://aspectj.org/doc/gettingStarted/index.html).
> > >
> > > I find the idea great. In a few words, the idea is that there exist
some
> > > crosscutting aspects (hence the name: AspectJ) that encompasses
several
> > > methods. For example, let's say you want to log the entry and exits of
> > > methods. This is a general pattern. In java, it would be very
> > difficult to
> > > materialize this aspect. You would have to add log statements at the
> > > beginning and end of each method, but still you would not have
> > captured the
> > > pattern. Also, if you add a new method, you have to remember to add
log
> > > statements.
> > >
> > > AspectJ let you describe aspects in its own semantic (near
> > java). Then, you
> > > apply the aspect compiler which will transform the code in java
> > and invoke
> > > the javac compiler to compile it.
> > >
> > > It is very very powerful. You can say things like verify that
> > such method is
> > > only called by such other method when it is in such context. There are
> > > better examples (with code) given in the paper highlighted above.
> > >
> > > Just wanted to let you know
> > > -Vincent
> > >
> > >
> > > _______________________________________________
> > > Mockobjects-java-dev mailing list
> > > Moc...@li...
> > > http://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> > >
> > 2?$¡¸ÞrÛ#jözùsSX§,X¬´Ê'?ãyËl«ÚuëåSËl²<«qç讧zØm¶Yÿ-+-²Ê.­ÇY¢¸
> > ë-+-³ùb²Ø§~æ¡É(n7o¶ÈÚ½§^
>
>
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> http://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>

Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming

[Steve F. <st...@m3...>]

T2YgY291cnNlLCB0aGUgb3RoZXIgcHJvYmxlbSB3YXMgYWx3YXlzIHZpc3VhbCBhZ2UuIE1heWJl
IGl0J3MgdGltZSB0byBicmVhayBmcmVlLi4uDQoNCg==

Re: [Mockobjects-java-dev] Coding conventions for the sources

[Steve F. <st...@m3...>]

MS4gU29tZXRpbWVzIEkgc3RhcnQgY2xhc3MgYW5kIG1ldGhvZCBicmFjZXMgb24gdGhlIHNhbWUg
bGluZS4gRGVwZW5kcyBvbiBob3cgY29tcGxpY2F0ZWQgdGhlIHNpZ25hdHVyZSBpcy4gQ29tcGFj
dCBpcyBiZXR0ZXIuDQo0LiB3ZSBkb24ndCBiZWxpZXZlIHNvIG11Y2ggaW4gamF2YWRvYy4gdGhh
dCdzIHdoeSB3ZSBzaGlwIHRoZSBzb3VyY2VzIGFuZCB0ZXN0cy4NCjcuIEkgdXNlZCB0byBsaWtl
IHRoZSAndGhpcy4nIGNvbnZlbnRpb24sIGJ1dCB3ZW50IG9mZiBpdC4gSSBkb24ndCBmZWVsIHRv
byBzdHJvbmdseS4gVGhlIGFkdmFudGFnZSBvZiBhIHByZWZpeCwgc3VjaCBhcyAnbXknIGlzIHRo
YXQgY29tcGxldGlvbiBpcyBtb3JlIGZvY3Vzc2VkLCBlc3BlY2lhbGx5IG9uIGEgbGFyZ2UgY2xh
c3MuDQo4LiBtZXRob2QgcGFyYW1ldGVycyBzaG91bGQgbm90IGNsYXNoIHdpdGggYSBjbGFzcyB2
YXJpYWJsZSwgb3IgYmUgcHJlZmFjZWQgYnkgJ2EnLCBub3QgJ3RoZScNCjkuIDc4IGNoYXJhY3Rl
cnMgcGVyIGxpbmUNCjExLiBMb2dnaW5nIGlzbid0IHJlYWxseSBhcHByb3ByaWF0ZS4NCjEyLiAn
dGhyb3dzJyBjbGF1c2VzIG1ha2UgZXhwbGljaXQgc3RhdGVtZW50cyBhYm91dCB0aGUgaW1wbGVt
ZW50YXRpb24gb2YgeW91ciBjb2RlLiB0aHJvd2luZyBleGNlcHRpb25zIHN0cmFpZ2h0IHRocm91
Z2ggY2FuIHNvbWV0aW1lcyBiZSB0aGUgYmVzdCB0aGluZyB0byBkbywgZS5nLiBmb3IgSU8uIEVh
Y2ggZnJhbWV3b3JrIHNob3VsZCBoYXZlIGEgYmFzZSBleGNlcHRpb24gY2xhc3MuIGV0Yy4NCg0K
DQo=

Re: [Mockobjects-java-dev] JDBC Test First ?

[Steve F. <st...@m3...>]

SSdkIGxpa2UgdG8gcHV0IGl0IHVwIHNvb24sIGJ1dCBpdCBuZWVkcyBzb21lIG1vcmUgdGlkeSB1
cC4NCg0KSSdkIGFsc28gbGlrZSB0byBtb3ZlIGl0IHRvIFhNTCwgYnV0IHRoZSBjdXJyZW50IGZv
cm1hdCBkb2Vzbid0IHN1cHBvcnQgaGlnaGxpZ2h0aW5nIHdpdGhpbiB0aGUgY29kZS4gDQoNCkkn
bGwgdGFrZSBhIGxvb2sgbm93IHdlJ3JlIGJhY2sgb25saW5lDQoNClN0ZXZlDQoNCi0tLS0tIE9y
aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiVmluY2VudCBNYXNzb2wiIDx2bWFzc29sQG9j
dG8uY29tPg0KVG86IDxtb2Nrb2JqZWN0cy1qYXZhLWRldkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ+
DQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjEsIDIwMDEgMTI6MTcgUE0NClN1YmplY3Q6IFtNb2Nr
b2JqZWN0cy1qYXZhLWRldl0gSkRCQyBUZXN0IEZpcnN0ID8NCg0KDQo+IFN0ZXZlLA0KPiANCj4g
QW55IGNoYW5jZSB0aGF0IHdlIGNvdWxkIHB1dCB0aGlzIHBhcGVyIGluIHRoZSBNb2NrIE9iamVj
dHMgd2ViIHNpdGUgPyBDb3VsZA0KPiB5b3UgcHV0IGl0IGluIFhNTCBmb3JtYXQgPw0KPiANCj4g
VGhhbmtzDQo+IC1WaW5jZW50DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4gTW9ja29iamVjdHMtamF2YS1kZXYgbWFpbGluZyBsaXN0
DQo+IE1vY2tvYmplY3RzLWphdmEtZGV2QGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KPiBodHRwOi8v
bGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL21vY2tvYmplY3RzLWphdmEtZGV2
DQo+IA0K

RE: [Mockobjects-java-dev] AOP : Aspect Oriented Programming

[Tim M. <tim...@po...>]

The kicker has always been getting good IDE support to work out what got
woven in - not sure if they have made any progress on this? There are some
good examples of weaving in patterns like observer etc. which I thought were
good at the time I looked at it - and it did fire my brain a year back when
working on the original mock stuff but I never found a good moment to use
it.

There were also some issues with co-variance and contravariance at the time
I looked at it - they had arbitrarily chosen the wrong way and broke the
rules, but I remember Gregor saying they would consider changing it.

Tim

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Steve Freeman
> Sent: 22 August 2001 12:54 am
> To: moc...@li...
> Subject: Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming
>
>
> I've known about this stuff for a while but have quite never
> found the time to do anything with it.
>
> Time to give it a try?
>
> Steve
>
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@oc...>
> To: <moc...@li...>
> Sent: Monday, August 20, 2001 2:10 PM
> Subject: [Mockobjects-java-dev] AOP : Aspect Oriented Programming
>
>
> > I have discovered AOP this week end (AspectJ) and found it very very
> > interesting, especially for unit testing purposes. I highly
> suggest that you
> > take 30 minutes to an hour to read the "getting started" paper
> > (http://aspectj.org/doc/gettingStarted/index.html).
> >
> > I find the idea great. In a few words, the idea is that there exist some
> > crosscutting aspects (hence the name: AspectJ) that encompasses several
> > methods. For example, let's say you want to log the entry and exits of
> > methods. This is a general pattern. In java, it would be very
> difficult to
> > materialize this aspect. You would have to add log statements at the
> > beginning and end of each method, but still you would not have
> captured the
> > pattern. Also, if you add a new method, you have to remember to add log
> > statements.
> >
> > AspectJ let you describe aspects in its own semantic (near
> java). Then, you
> > apply the aspect compiler which will transform the code in java
> and invoke
> > the javac compiler to compile it.
> >
> > It is very very powerful. You can say things like verify that
> such method is
> > only called by such other method when it is in such context. There are
> > better examples (with code) given in the paper highlighted above.
> >
> > Just wanted to let you know
> > -Vincent
> >
> >
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > http://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
> 2‡$¡¸ÞrÛ#jözùšŠX§‚X¬´Ê’†ãyËl«ÚuëåŠËl²‹«qç讧zØm¶Ÿÿ–+-²Ê.­ÇŸ¢¸
> ë–+-³ùb²Ø§~æ¡É(n7œ¶ÈÚ½§^

Re: [Mockobjects-java-dev] AOP : Aspect Oriented Programming

[Steve F. <st...@m3...>]

SSd2ZSBrbm93biBhYm91dCB0aGlzIHN0dWZmIGZvciBhIHdoaWxlIGJ1dCBoYXZlIHF1aXRlIG5l
dmVyIGZvdW5kIHRoZSB0aW1lIHRvIGRvIGFueXRoaW5nIHdpdGggaXQuDQoNClRpbWUgdG8gZ2l2
ZSBpdCBhIHRyeT8NCg0KU3RldmUNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0K
RnJvbTogIlZpbmNlbnQgTWFzc29sIiA8dm1hc3NvbEBvY3RvLmNvbT4NClRvOiA8bW9ja29iamVj
dHMtamF2YS1kZXZAbGlzdHMuc291cmNlZm9yZ2UubmV0Pg0KU2VudDogTW9uZGF5LCBBdWd1c3Qg
MjAsIDIwMDEgMjoxMCBQTQ0KU3ViamVjdDogW01vY2tvYmplY3RzLWphdmEtZGV2XSBBT1AgOiBB
c3BlY3QgT3JpZW50ZWQgUHJvZ3JhbW1pbmcNCg0KDQo+IEkgaGF2ZSBkaXNjb3ZlcmVkIEFPUCB0
aGlzIHdlZWsgZW5kIChBc3BlY3RKKSBhbmQgZm91bmQgaXQgdmVyeSB2ZXJ5DQo+IGludGVyZXN0
aW5nLCBlc3BlY2lhbGx5IGZvciB1bml0IHRlc3RpbmcgcHVycG9zZXMuIEkgaGlnaGx5IHN1Z2dl
c3QgdGhhdCB5b3UNCj4gdGFrZSAzMCBtaW51dGVzIHRvIGFuIGhvdXIgdG8gcmVhZCB0aGUgImdl
dHRpbmcgc3RhcnRlZCIgcGFwZXINCj4gKGh0dHA6Ly9hc3BlY3RqLm9yZy9kb2MvZ2V0dGluZ1N0
YXJ0ZWQvaW5kZXguaHRtbCkuDQo+IA0KPiBJIGZpbmQgdGhlIGlkZWEgZ3JlYXQuIEluIGEgZmV3
IHdvcmRzLCB0aGUgaWRlYSBpcyB0aGF0IHRoZXJlIGV4aXN0IHNvbWUNCj4gY3Jvc3NjdXR0aW5n
IGFzcGVjdHMgKGhlbmNlIHRoZSBuYW1lOiBBc3BlY3RKKSB0aGF0IGVuY29tcGFzc2VzIHNldmVy
YWwNCj4gbWV0aG9kcy4gRm9yIGV4YW1wbGUsIGxldCdzIHNheSB5b3Ugd2FudCB0byBsb2cgdGhl
IGVudHJ5IGFuZCBleGl0cyBvZg0KPiBtZXRob2RzLiBUaGlzIGlzIGEgZ2VuZXJhbCBwYXR0ZXJu
LiBJbiBqYXZhLCBpdCB3b3VsZCBiZSB2ZXJ5IGRpZmZpY3VsdCB0bw0KPiBtYXRlcmlhbGl6ZSB0
aGlzIGFzcGVjdC4gWW91IHdvdWxkIGhhdmUgdG8gYWRkIGxvZyBzdGF0ZW1lbnRzIGF0IHRoZQ0K
PiBiZWdpbm5pbmcgYW5kIGVuZCBvZiBlYWNoIG1ldGhvZCwgYnV0IHN0aWxsIHlvdSB3b3VsZCBu
b3QgaGF2ZSBjYXB0dXJlZCB0aGUNCj4gcGF0dGVybi4gQWxzbywgaWYgeW91IGFkZCBhIG5ldyBt
ZXRob2QsIHlvdSBoYXZlIHRvIHJlbWVtYmVyIHRvIGFkZCBsb2cNCj4gc3RhdGVtZW50cy4NCj4g
DQo+IEFzcGVjdEogbGV0IHlvdSBkZXNjcmliZSBhc3BlY3RzIGluIGl0cyBvd24gc2VtYW50aWMg
KG5lYXIgamF2YSkuIFRoZW4sIHlvdQ0KPiBhcHBseSB0aGUgYXNwZWN0IGNvbXBpbGVyIHdoaWNo
IHdpbGwgdHJhbnNmb3JtIHRoZSBjb2RlIGluIGphdmEgYW5kIGludm9rZQ0KPiB0aGUgamF2YWMg
Y29tcGlsZXIgdG8gY29tcGlsZSBpdC4NCj4gDQo+IEl0IGlzIHZlcnkgdmVyeSBwb3dlcmZ1bC4g
WW91IGNhbiBzYXkgdGhpbmdzIGxpa2UgdmVyaWZ5IHRoYXQgc3VjaCBtZXRob2QgaXMNCj4gb25s
eSBjYWxsZWQgYnkgc3VjaCBvdGhlciBtZXRob2Qgd2hlbiBpdCBpcyBpbiBzdWNoIGNvbnRleHQu
IFRoZXJlIGFyZQ0KPiBiZXR0ZXIgZXhhbXBsZXMgKHdpdGggY29kZSkgZ2l2ZW4gaW4gdGhlIHBh
cGVyIGhpZ2hsaWdodGVkIGFib3ZlLg0KPiANCj4gSnVzdCB3YW50ZWQgdG8gbGV0IHlvdSBrbm93
DQo+IC1WaW5jZW50DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj4gTW9ja29iamVjdHMtamF2YS1kZXYgbWFpbGluZyBsaXN0DQo+IE1v
Y2tvYmplY3RzLWphdmEtZGV2QGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KPiBodHRwOi8vbGlzdHMu
c291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL21vY2tvYmplY3RzLWphdmEtZGV2DQo+IA0K

Re: [Mockobjects-java-dev] www.mockobjects still not pointing to SF

[Steve F. <st...@m3...>]

VHVybnMgb3V0IHdlIGhhdmUgdG8gcGF5IGV4dHJhIGZvciBpdC4gSnVzdCBoYXZlIHRvIGdldCBh
cm91bmQgdG8gaXQuIA0KDQpCZWVuIGhhdmluZyBjb25uZWN0aW9uIHByb2JsZW1zLg0KDQoNCi0t
LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiVmluY2VudCBNYXNzb2wiIDx2bWFz
c29sQG9jdG8uY29tPg0KVG86IDxtb2Nrb2JqZWN0cy1qYXZhLWRldkBsaXN0cy5zb3VyY2Vmb3Jn
ZS5uZXQ+DQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjEsIDIwMDEgMTI6MDEgUE0NClN1YmplY3Q6
IFtNb2Nrb2JqZWN0cy1qYXZhLWRldl0gd3d3Lm1vY2tvYmplY3RzIHN0aWxsIG5vdCBwb2ludGlu
ZyB0byBTRg0KDQoNCj4gVGhlIGh0dHA6Ly93d3cubW9ja29iamVjdHMuY29tIGRvbWFpbiBpcyBz
dGlsbCBub3QgcG9pbnRpbmcgdG8NCj4gaHR0cDovL21vY2tvYmplY3RzLnNvdXJjZWZvcmdlLmNv
bSAuLi4gQ291bGQgd2UgY2hhbmdlIHRoYXQgcXVpY2tseSA/DQo+IA0KPiBUaGFua3MNCj4gLVZp
bmNlbnQNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPiBNb2Nrb2JqZWN0cy1qYXZhLWRldiBtYWlsaW5nIGxpc3QNCj4gTW9ja29iamVj
dHMtamF2YS1kZXZAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+IGh0dHA6Ly9saXN0cy5zb3VyY2Vm
b3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vbW9ja29iamVjdHMtamF2YS1kZXYNCj4gDQo=

Re: [Mockobjects-java-dev] RE: mockmaker conventions updated

[Vincent M. <vm...@oc...>]

----- Original Message -----
From: "ivan moore" <iv...@ta...>
To: <moc...@li...>
Sent: Tuesday, August 21, 2001 7:46 PM
Subject: [Mockobjects-java-dev] RE: mockmaker conventions updated


> >That looks good, although I haven't tried it yet ... :)
>
> :-(

I will try it very soon to try it on HttpServletRequest and the like :-)
My intention is to use it to generate mock implementations for the Mock
Objects project, maybe do some reformating ... :) and see what are the
difference with what Steve and Tim have already coded and then ask questions
... :)

-Vincent