springframework-developer — Spring Framework developers list

[Springframework-developer] Spring build.115 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] Heads-up! DTD Location has now changed for Spring 2.0

[Colin S. <col...@ex...>]

Perhaps it's not clear from my email below, but this applies to Spring 
CVS. If you are using Spring 2.0 RC3 or earlier, you should generally 
continue to use the old form, otherwise your version of Spring will not 
be able to resolve the new form locally, and the XML parser will always 
hit the internet for the DTD!

Colin


On 8/18/2006 3:17 PM, Colin Sampaleanu wrote:
> Just a head's up that the location of the Spring 2.0 DTD has changed from:
>
> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 
> "http://www.springframework.org/dtd/spring-beans.dtd">
>
> to
>
> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN" 
> "http://www.springframework.org/dtd/spring-beans_2_0.dtd">
>
> The physical file is now
>     spring-beans_2_0.dtd
>
> It was decided that the number of changes in the DTD for 2.0 warranted 
> this change. Had this not been done, there would generally not have been 
> an issue with any 1.2.x code out there, as the entity resolver in those 
> older versions of Spring would still have found the proper (1.2.x) 
> version of spring-beans.dtd inside the spring jar file, but anybody 
> using an XML editor that went out to the internet to read the DTD would 
> get a number of options (from 2.0) not legal in 1.2.x.
>
> If you are using Spring 2.0, you _should_ change your DTD declarations 
> to the new version, in your XML files. Note that if you use the old 
> version, it should still resolve properly as far as Spring itself is 
> concerned, as the DTD entity resolver will recognize both forms. But the 
> new version is the correct form, and if you want proper popup completion 
> in your XML editor you should use the new form.
>
> If you are using Spring 2's new Schema (xsd) support, this does not 
> affect you in any way!
>
> There is still a question if we should version the schema files to 
> match, or leave them as they are, with no version number. Of course 
> there is no previous version of the schema files.
>
> Colin
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>   

[Springframework-developer] Heads-up! DTD Location has now changed for Spring 2.0

[Colin S. <col...@ex...>]

Just a head's up that the location of the Spring 2.0 DTD has changed from:

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 
"http://www.springframework.org/dtd/spring-beans.dtd">

to

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN" 
"http://www.springframework.org/dtd/spring-beans_2_0.dtd">

The physical file is now
    spring-beans_2_0.dtd

It was decided that the number of changes in the DTD for 2.0 warranted 
this change. Had this not been done, there would generally not have been 
an issue with any 1.2.x code out there, as the entity resolver in those 
older versions of Spring would still have found the proper (1.2.x) 
version of spring-beans.dtd inside the spring jar file, but anybody 
using an XML editor that went out to the internet to read the DTD would 
get a number of options (from 2.0) not legal in 1.2.x.

If you are using Spring 2.0, you _should_ change your DTD declarations 
to the new version, in your XML files. Note that if you use the old 
version, it should still resolve properly as far as Spring itself is 
concerned, as the DTD entity resolver will recognize both forms. But the 
new version is the correct form, and if you want proper popup completion 
in your XML editor you should use the new form.

If you are using Spring 2's new Schema (xsd) support, this does not 
affect you in any way!

There is still a question if we should version the schema files to 
match, or leave them as they are, with no version number. Of course 
there is no previous version of the schema files.

Colin

[Springframework-developer] MultiActionController & Validation

[Tom N. <tom...@gm...>]

Hi spring devs --  I've got a suggestion that I'd like some help with.

I'm using the MultiActionController's binding and validation
capabilities (which by the way, I'd be glad to help there document a
little better...  )

Anyway, I'm trying to use the 'lazy' implementation, where my action
methods have the command object as the third parameter.  The problem
is, if there are validation errors, an exception is thrown (when
binder.closeNoCatch() is called on line 499 (rev 1.33).  The only way
to handle validation errors are:

1.  Don't do it the lazy way, and manually do binding/ validation
or
2.  override getExceptionHandler(Throwable exception) and create a
custom Exception handler for a ServletRequestBindingException.

Both of these could get tedious, so I'm wondering if we could make an
extension point, maybe call it handleValidationError(...) and call it
at the end of MultiActionController.bind(...) if there are validation
errors.  The default implementation could then call
binder.closeNoCatch().

Then the problem becomes, we'd normally want to return to the previous
view and display form errors....  That's where my idea fails.  Does
anyone else see this as an opportunity for enhancement?  I was going
to post an issue on JIRA, but I wanted to get others' input first.

Thanks!
-Tom

[Springframework-developer] Spring build.114 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] MultiActionController and Java SE 5 annotations

[<tbl...@gm...>]

Q2hyaXMsCgpJIHNlZSB5b3UgcG9pbnQgdmVyeSB3ZWxsLiBNeSBpbnRlbnRpb24gaXMgdG8gaW50
cm9kdWNlIGFubm90YXRpb24KYmFzZWQgd2F5IHRvIHNwZWNpZnkgJ2JsZXNzZWQnIG1ldGhvZHMg
dGhhdCBjYW4gYmUgdXNlZCB3aXRoIG9sZCBzdHlsZQptZXRob2QgbWF0Y2hpbmcuCgpJbiBvdGhl
ciB3b3JkcywgeW91IGNhbiB1c2UgYW5ub3RhdGlvbnMsIGJ1dCB5b3UgZG9uJ3QgaGF2ZSB0byB1
c2UKdGhlbSBpZiB5b3UgZG9uJ3QgbGlrZS4gSXQncyB1cCB0byB5b3UsIHlvdSBjYW4gbWl4IGFu
bm90YXRlZCBtZXRob2RzCndpdGggbm9uLWFubm90YXRlZCBwYXR0ZXJuIG1hdGNoaW5nIG1ldGhv
ZHMuCgpJIGtub3cgdGhlcmUgY2FuIGJhIGFtYmlndWl0eSwgYnV0IEkgYmVsaWV2ZSB3ZSBjYW4g
ZmluZCBvdXQgYSBzbWFydApzb2x1dGlvbiBmb3IgdGhpcy4KCkkgaGF2ZSB0byB0aGluayBhYm91
dCBpbmhlcml0YW5jZSBwcm9ibGVtcywgbWF5YmUgZGV2ZWxvcCBhIHByb3RvdHlwZQp0byBzZWUg
aG93IGl0IHdvcmtzLCBvciBkb2Vzbid0IHdvcmsgOikKCkd1eXMsIHdvdWxkIHlvdSBiZSBpbnRl
cmVzdGVkIGluIHN1Y2ggYSBmdW50aW9uYWxpdHkgaW4gU3ByaW5nIE1WQwpmcmFtZXdvcmsuIEkn
bSBub3Qgc3VyZSAgaWYgbXkgaWRlYSBpcyB3b3J0aCBhbiBlZmZvcnQgYXQgYWxsLiBJJ20gbm90
CnZlcnkgY29uZmlkZW50IGluIGl0LCB1bmZvcnR1bmF0ZWxseS4KCkNoZWVycywKVG9tCgpPbiA4
LzE4LzA2LCBDaHJpcyBXb29kIDxjaHJpcy53b29kQG1ldG9jZWFuZW5naW5lZXJzLmNvbT4gd3Jv
dGU6Cj4KPiBUaGUgcHJvYmxlbSB3aXRoIHRoaXMgYXMgSSBzZWUgaXQgd291bGQgYmUgd2hlbiB5
b3Ugc3RhcnQgaW5oZXJpdGluZwo+IGFjdGlvbnMuCj4KPiBUaGVyZSdzIHF1aXRlIGEgZmV3ICdz
dGFuZGFyZCcgYWN0aW9ucyBpbiwgZm9yIGV4YW1wbGUsIHRoZQo+IEZvcm1Db250cm9sbGVyIGNs
YXNzLiBUaGVzZSBjYW4ndCBiZSBhbm5vdGF0ZWQgZm9yIGJhY2sgY29tcGF0aWJpbGl0eQo+IHJl
YXNvbnMuIFlvdSdkIGJlIGxlZnQgd2l0aCBzb21lIHNsaWdodGx5IGZ1bm55IGxvZ2ljIGZvciBk
ZXRlcm1pbmluZyBpZgo+IHlvdSBzaG91bGQgdXNlIHRoZSAnYmxlc3NpbmdzJyBvciBub3QsIGZv
ciBleGFtcGxlIGNoZWNrIGlmIGFueSBtZXRob2RzCj4gaW4gdGhlIGNsYXNzIGhhdmUgYW4gYW5u
b3RhdGlvbiwgYW5kIGlmIHRoZXkgZG8gcmVxdWlyZSBpdCBmb3IgYWxsLCBhbmQKPiBkbyB0aGlz
IG9ubHkgb24gYSBjbGFzcyBieSBjbGFzcyBiYXNpcyB1cCB0aGUgaW5oZXJpdGFuY2UgY2hhaW4u
IFRoaXMKPiBxdWlja2x5IGdldHMgY29uZnVzaW5nIHdoZW4geW91J3JlIGRlYWxpbmcgd2l0aCBz
aW1wbGUgYWN0aW9uIGNsYXNzZXMKPiB3aXRoIG9ubHkgb25lIGFjdGlvbiwgaWYgdGhlcmUncyBu
byBhbm5vdGF0aW9uIHRoZXJlIGl0IG1pZ2h0IHdlbGwgaGF2ZQo+IGJlZW4gZm9yZ290dGVuIGJ1
dCB5b3UgdXNlIGl0IGFueWhvdywgdGhlbiB3aGVuIHNvbWVvbmUgZWxzZSBhZGRzIGFuCj4gYWN0
aW9uIGFuZCByZW1lbWJlcnMgdGhlIGFubm90YXRpb24gdGhlIG9sZCBhY3Rpb24gbWV0aG9kIGlz
IGNvbmZ1c2luZ2x5Cj4gYnJva2VuLgo+Cj4gVG9tYXN6IEKzYWNob3dpY3ogd3JvdGU6Cj4gPiBI
aSB0aGVyZSwKPiA+Cj4gPiBJJ3ZlIGJlZW4gcGxheWluZyBhcm91bmQgd2l0aCBNdWx0aUFjdGlv
bkNvbnRyb2xsZXIgZm9yIGEgZmV3IGRheXMuIEluCj4gPiBnZW5lcmFsIEkgcmVhbGx5IGxpa2Ug
dGhlIGlkZWEgYW5kIHRoZSBjb250cm9sbGVyIHNlZW1zIHRvIHZlcnkgaGFuZHkuCj4gPiBUaGVy
ZSBpcyBvbmUgdGhpbmcgdGhhdCBJJ2QgZW5qb3kuIEkgd2FzIHdvbmRlcmluZyBhYm91dCBhYmls
aXR5IHRvCj4gPiBleHBsaWNpdGx5IHNwZWNpZnkgd2hpY2ggbWV0aG9kcyBhcmUgJ2JsZXNzZWQn
IG9uZXMuIEN1cnJlbnRseSBtZXRob2RzCj4gPiBhcmUgbWF0Y2hlZCB1c2luZyB3ZWxsLWRlZmlu
ZWQgcGF0dGVybiwgYnV0IEknZCBwcmVmZXIgdG8gYW5ub3RhdGUKPiA+IG1ldGhvZHMgdXNpbmcg
SmF2YSBTRSA1IGFubm90YXRpb25zLgo+ID4KPiA+IFdoYXQgYWJvdXQgc3VjaCBhIG5vdGF0aW9u
ICp0aGlzIGlzIGp1c3QgdmVyeSBzaW1wbGUgZXhhbXBsZS9pZGVhKjoKPiA+Cj4gPiBAQWN0aW9u
Cj4gPiBwdWJsaWMgTW9kZWxBbmRWaWV3IGRvU29tZXRoaW5nKEBDb21tYW5kKCJteUNvbW1hbmQi
KSBNeUNvbW1hbmQKPiA+IGNvbW1hbmQsIEBSZXF1ZXN0IEh0dHBTZXJ2bGV0UmVxdWVzdCByZXF1
ZXN0KTsKPiA+Cj4gPiBUaGlzIG1lYW5zIHRoYXQgZG9Tb2VtdGhpbmcgbWV0aG9kIGlzICdibGVz
c2VkJyBvbmUgaS5lIGFjdGlvbiBtZXRob2QsCj4gPiBmaXJzdCBwYXJhbWV0ZXIgaXMgY29tbWFu
ZCBvYmplY3QsIGFuZCBzZWNvbmQgaXMgSFRUUCByZXF1ZXN0Cj4gPiBpbnN0YW5jZS4gTm90ZSB0
aGF0IHdlIGRvbid0IGhhdmUgdG8gZm9sbG93IHN0cmljdCBydWxlcyBpbiBzaWduYXR1cmUKPiA+
IGFuZCB3ZSBoYXZlIGV4dHJlbWUgZmxleGliaWxpdHkgaW4gZGVmaW5pbmcgc2lnbmF0dXJlcy4K
PiA+Cj4gPiBXZSBjYW4gZGVmaW5lIG1vcmUgcGFyYW1ldGVyLWxldmVsIGFubm90YXRpb25zIHRo
YXQgd291bGQgcGFzcwo+ID4gaW5zdGFuY2VzIGFzIHBhcmFtZXRlcnMgaW50byAnYmxlc3NlZCcg
bWV0aG9kcy4gSSdtIHRoaW5raW5nIG9mCj4gPiBAUmVzcG9uc2UsIEBTZXNzaW9uLCBldGMuCj4g
Pgo+ID4gUGxlYXNlIG5vdGUsIHRoaXMgcG9zdCBpcyBqdXN0IHJvdWdoIGlkZWEsIGJ1dCBpdCdz
IHdvcnRoCj4gPiBjb25zaWRlcmF0aW9uLCBJIGJlbGlldmUuIEFueSBjb21tZW50cyBhcmUgd2Vs
Y29tZS4gSSB3b3VsZCBiZSBwbGVhc2VkCj4gPiB0byBkaXNjdXNzIHRoaXMgc3ViamVjdCBpbiBk
ZXRhaWxzIGlmIGFueW9uZSBpcyBpbnRlcmVzdGVkLgo+ID4KPiA+IFJlZ2FyZHMsCj4gPiBUb20K
PiA+Cj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gPiBVc2luZyBUb21jYXQgYnV0IG5lZWQgdG8gZG8g
bW9yZT8gTmVlZCB0byBzdXBwb3J0IHdlYiBzZXJ2aWNlcywgc2VjdXJpdHk/Cj4gPiBHZXQgc3R1
ZmYgZG9uZSBxdWlja2x5IHdpdGggcHJlLWludGVncmF0ZWQgdGVjaG5vbG9neSB0byBtYWtlIHlv
dXIgam9iIGVhc2llcgo+ID4gRG93bmxvYWQgSUJNIFdlYlNwaGVyZSBBcHBsaWNhdGlvbiBTZXJ2
ZXIgdi4xLjAuMSBiYXNlZCBvbiBBcGFjaGUgR2Vyb25pbW8KPiA+IGh0dHA6Ly9zZWwuYXMtdXMu
ZmFsa2FnLm5ldC9zZWw/Y21kPWxuayZraWQ9MTIwNzA5JmJpZD0yNjMwNTcmZGF0PTEyMTY0Mgo+
ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+IFNw
cmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0Cj4gPiBTcHJpbmdmcmFtZXdvcmst
ZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+ID4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vm
b3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcgo+ID4KPgo+
Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQo+IFVzaW5nIFRvbWNhdCBidXQgbmVlZCB0byBkbyBtb3JlPyBO
ZWVkIHRvIHN1cHBvcnQgd2ViIHNlcnZpY2VzLCBzZWN1cml0eT8KPiBHZXQgc3R1ZmYgZG9uZSBx
dWlja2x5IHdpdGggcHJlLWludGVncmF0ZWQgdGVjaG5vbG9neSB0byBtYWtlIHlvdXIgam9iIGVh
c2llcgo+IERvd25sb2FkIElCTSBXZWJTcGhlcmUgQXBwbGljYXRpb24gU2VydmVyIHYuMS4wLjEg
YmFzZWQgb24gQXBhY2hlIEdlcm9uaW1vCj4gaHR0cDovL3NlbC5hcy11cy5mYWxrYWcubmV0L3Nl
bD9jbWQ9bG5rJmtpZD0xMjA3MDkmYmlkPTI2MzA1NyZkYXQ9MTIxNjQyCj4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBTcHJpbmdmcmFtZXdvcmstZGV2
ZWxvcGVyIG1haWxpbmcgbGlzdAo+IFNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291
cmNlZm9yZ2UubmV0Cj4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGlu
Zm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcgo+Cg==

Re: [Springframework-developer] MultiActionController and Java SE 5 annotations

[Chris W. <chr...@me...>]

The problem with this as I see it would be when you start inheriting=20
actions.

There's quite a few 'standard' actions in, for example, the=20
FormController class. These can't be annotated for back compatibility=20
reasons. You'd be left with some slightly funny logic for determining if=20
you should use the 'blessings' or not, for example check if any methods=20
in the class have an annotation, and if they do require it for all, and=20
do this only on a class by class basis up the inheritance chain. This=20
quickly gets confusing when you're dealing with simple action classes=20
with only one action, if there's no annotation there it might well have=20
been forgotten but you use it anyhow, then when someone else adds an=20
action and remembers the annotation the old action method is confusingly=20
broken.

Tomasz B=C5=82achowicz wrote:
> Hi there,
>
> I've been playing around with MultiActionController for a few days. In
> general I really like the idea and the controller seems to very handy.
> There is one thing that I'd enjoy. I was wondering about ability to
> explicitly specify which methods are 'blessed' ones. Currently methods
> are matched using well-defined pattern, but I'd prefer to annotate
> methods using Java SE 5 annotations.
>
> What about such a notation *this is just very simple example/idea*:
>
> @Action
> public ModelAndView doSomething(@Command("myCommand") MyCommand
> command, @Request HttpServletRequest request);
>
> This means that doSoemthing method is 'blessed' one i.e action method,
> first parameter is command object, and second is HTTP request
> instance. Note that we don't have to follow strict rules in signature
> and we have extreme flexibility in defining signatures.
>
> We can define more parameter-level annotations that would pass
> instances as parameters into 'blessed' methods. I'm thinking of
> @Response, @Session, etc.
>
> Please note, this post is just rough idea, but it's worth
> consideration, I believe. Any comments are welcome. I would be pleased
> to discuss this subject in details if anyone is interested.
>
> Regards,
> Tom
>
> -----------------------------------------------------------------------=
--
> Using Tomcat but need to do more? Need to support web services, securit=
y?
> Get stuff done quickly with pre-integrated technology to make your job =
easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron=
imo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  =20

[Springframework-developer] MultiActionController and Java SE 5 annotations

[<tbl...@gm...>]

Hi there,

I've been playing around with MultiActionController for a few days. In
general I really like the idea and the controller seems to very handy.
There is one thing that I'd enjoy. I was wondering about ability to
explicitly specify which methods are 'blessed' ones. Currently methods
are matched using well-defined pattern, but I'd prefer to annotate
methods using Java SE 5 annotations.

What about such a notation *this is just very simple example/idea*:

@Action
public ModelAndView doSomething(@Command("myCommand") MyCommand
command, @Request HttpServletRequest request);

This means that doSoemthing method is 'blessed' one i.e action method,
first parameter is command object, and second is HTTP request
instance. Note that we don't have to follow strict rules in signature
and we have extreme flexibility in defining signatures.

We can define more parameter-level annotations that would pass
instances as parameters into 'blessed' methods. I'm thinking of
@Response, @Session, etc.

Please note, this post is just rough idea, but it's worth
consideration, I believe. Any comments are welcome. I would be pleased
to discuss this subject in details if anyone is interested.

Regards,
Tom

[Springframework-developer] Spring build.113 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] MultiActionController and Java SE 5 annotations

[<tbl...@gm...>]

Hi there,

I've been playing around with MultiActionController for a few days. In
general I really like the idea and the controller seems to very handy.
There is one thing that I'd enjoy. I was wondering about ability to
explicitly specify which methods are 'blessed' ones. Currently methods
are matched using well-defined pattern, but I'd prefer to annotate
methods using Java SE 5 annotations.

What about such a notation *this is just very simple example/idea*:

@Action
public ModelAndView doSomething(@Command("myCommand") MyCommand
command, @Request HttpServletRequest request);

This means that doSoemthing method is 'blessed' one i.e action method,
first parameter is command object, and second is HTTP request
instance. Note that we don't have to follow strict rules in signature
and we have extreme flexibility in defining signatures.

We can define more parameter-level annotations that would pass
instances as parameters into 'blessed' methods. I'm thinking of
@Response, @Session, etc.

Please note, this post is just rough idea, but it's worth
consideration, I believe. Any comments are welcome. I would be pleased
to discuss this subject in details if anyone is interested.

Regards,
Tom

[Springframework-developer] Spring build.112 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Quartz and injecting JobFactory

[Byron S. <byr...@gm...>]

Hi all.

This is in regards to the Quartz integration support in
org.springframework.scheduling.quartz<http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/scheduling/quartz/package-summary.html>

I could not find a way (in 1.2.x or CVS HEAD) to use the
SchedulerFactoryBean to inject my own implementation of a JobFactory into
Schedulers that it creates. Is anyone working on this? If not let me know if
you want me to contribute either of the solutions below.

Solution 1:
I solved the problem at first by extending ScheduleFactoryBean, adding this
field and overriding createScheduler to set the the jobFactory field on
every Scheduler created after the super method completes. This is the only
field like this (one to be set on every Scheduler created) so this seems
like a reasonable solution.

The spring config then looks like:
    <bean id="scheduler" class="com.xyz.JobFactorySchedulerFactoryBean">
        <property name="jobFactory" ref="jobFactory" />
    </bean>
    <bean id="jobFactory" class="com.xyz.DbJobFactory" />


Solution 2:
This solution plans for similar fields being added in the future to
Scheduler (although it doesn't look like Quartz 1.6 will have any based on
the repository). The idea is to create a mostly unimplemented prototype
Scheduler that has all fields set that future Schedulers from the
SchedulerFactory should have. This requires an additional object but seems
nicer than adding fields to the SchedulerFactory that it doesn't actually
use.

createScheduler is again overridden so that super is called first and then
fields from the prototype are copied into each Scheduler that the
SchedulerFactory creates. The benefit of this solution is that the prototype
could hold multiple fields to copy and the SchedulerFactoryBean can remain
blissfully unaware when new fields of this type are added.

The spring config looks like:
    <bean id="scheduler" class="com.xyz.PrototypeSchedulerFactoryBean">
        <property name="prototype" ref="prototypeSchedule" />
    </bean>
    <bean id="jobFactory" class="com.xyz.DbJobFactory" />
    <bean id="prototypeSchedule" class="com.xyz.SchedulerPrototype">
        <property name="jobFactory" ref="jobFactory" />
    </bean>

-- 
Byron
http://byron.saltysiak.com

[Springframework-developer] Spring build.111 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Import statement in spring-beans.xsd

[Matthias F. <mfu...@gm...>]

Hi all,

I just downloaded the spring 2.0 RC3 and I am wondering about one thing...

The xsd file under
http://www.springframework.org/schema/beans/spring-beans.xsd contains
the statement <xsd:import
namespace="http://www.w3.org/XML/1998/namespace"/> at line 4.

Why do you need that statement? I am not a xsd expert, but the
namespace doesn't seem to be used anywhere and if I remove it, the xsd
file is still valid...

I stumbled upon this because Stylus Studio seems to have some problems
with spring-beans.xsd due to that statement.

Regards,
Matthias

[Springframework-developer] Spring build.110 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.109 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.108 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.107 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] Problem with @Configurable and LTWwith latest 2.0rc3

[Guido S. <Gui...@tr...>]

Sorry, forgot something in my mail before ...

>>This is a message coming out of AspectJ itself and almost certainly =20
>>an AspectJ bug (we upgraded Spring to the AspectJ 1.5.2 libraries =20
>>during the Spring rc3 development cycle).

Yeah, I figured that out, because some other tests with Spring AOP and =
@AspectJ, which didn't work with rc2, do now work :-)

Could you please change the spring-framework-2.0-rc3\lib\readme.txt, it =
still shows 1.5.1a

* aspectj/aspectjweaver.jar, aspectj/aspectjrt.jar, =
aspectj/aspectjtools.jar
- AspectJ 1.5.1a (http://www.aspectj.org)

Thanks
Guido


-----Urspr=FCngliche Nachricht-----
Von: spr...@li... im Auftrag =
von Adrian Colyer
Gesendet: Fr 11.08.2006 15:49
An: spr...@li...
Betreff: Re: [Springframework-developer] Problem with @Configurable and =
LTWwith latest 2.0rc3
=20
This is a message coming out of AspectJ itself and almost certainly =20
an AspectJ bug (we upgraded Spring to the AspectJ 1.5.2 libraries =20
during the Spring rc3 development cycle).

Please can you file a report against the AspectJ project: https://=20
bugs.eclipse.org/bugs/enter_bug.cgi?product=3DAspectJ.
If you could also include in the report the full stack trace as =20
produced by the weaver, and attach the project to reproduce the error =20
that would be a big help. Depending on exactly what the error is, I =20
may be able to tell you some compiler options to set to workaround =20
the issue.

Regards, Adrian.


On 11 Aug 2006, at 13:19, Guido Schmutz wrote:

> Hi
>
> I'm currently testing @Configurable and LTW. Everything worked/=20
> works fine with the 2.0rc2 distribution. This morning I then tried =20
> to use rc2 togehter with AspectJ 1.5.2 and had problems.
> Then after seeing that 2.0rc3 has been released, i switched to the =20
> 2.0rc3 distribution with the dependencies from there and I'm =20
> getting the same problems.
>
> With RC3, the domain object doesn't get configured and the error I =20
> get on the console is the following (only parts of it):
>
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 2110 [main] FATAL AspectJ Weaver  - [AspectJ] trouble in:
> public class com.trivadis.aop.configurable.Address extends =20
> java.lang.Object:
>   private transient com.trivadis.aop.configurable.CodeRepository =20
> codeRepository
>   private long id
>   private String street
>   private String city
>   private com.trivadis.aop.configurable.Country country
>   public void setCodeRepository=20
> (com.trivadis.aop.configurable.CodeRepository):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 15)
>                     ALOAD_1     // Lcom/trivadis/aop/configurable/=20
> CodeRepository; codeRepository
>                     PUTFIELD =20
> com.trivadis.aop.configurable.Address.codeRepository Lcom/trivadis/=20
> aop/configurable/CodeRepository;
>                     RETURN   (line 16)
>   end public void setCodeRepository=20
> (com.trivadis.aop.configurable.CodeRepository)
>
>   public String getCity():
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 28)
>                     GETFIELD =20
> com.trivadis.aop.configurable.Address.city Ljava/lang/String;
>                     ARETURN
>   end public String getCity()
>
>   public void setCity(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 32)
>                     ALOAD_1     // Ljava/lang/String; city
>                     PUTFIELD =20
> com.trivadis.aop.configurable.Address.city Ljava/lang/String;
>                     RETURN   (line 33)
>   end public void setCity(String)
>
>   public com.trivadis.aop.configurable.Country getCountry():
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 36)
>                     GETFIELD =20
> com.trivadis.aop.configurable.Address.country Lcom/trivadis/aop/=20
> configurable/Country;
>                     ARETURN
>   end public com.trivadis.aop.configurable.Country getCountry()
>
>   public void setCountry(com.trivadis.aop.configurable.Country):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 40)
>                     ALOAD_1     // Lcom/trivadis/aop/configurable/=20
> Country; country
>                     PUTFIELD =20
> com.trivadis.aop.configurable.Address.country Lcom/trivadis/aop/=20
> configurable/Country;
>                     RETURN   (line 41)
>   end public void setCountry(com.trivadis.aop.configurable.Country)
>
>   public String getStreet():
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 44)
>                     GETFIELD =20
> com.trivadis.aop.configurable.Address.street Ljava/lang/String;
>                     ARETURN
>   end public String getStreet()
>
>   public void setStreet(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 48)
>                     ALOAD_1     // Ljava/lang/String; street
>                     PUTFIELD =20
> com.trivadis.aop.configurable.Address.street Ljava/lang/String;
>                     RETURN   (line 49)
>   end public void setStreet(String)
>
>   private void <init>():
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 53)
>                     INVOKESPECIAL java.lang.Object.<init> ()V
>                     RETURN
>   end private void <init>()
>
>   public static com.trivadis.aop.configurable.Address createAddress=20
> (String, String):
>                     NEW com.trivadis.aop.configurable.Address   =20
> (line 58)
>                     DUP
>                     INVOKESPECIAL =20
> com.trivadis.aop.configurable.Address.<init> ()V
>                     ASTORE_2
>                     ALOAD_2     // Lcom/trivadis/aop/configurable/=20
> Address; adr   (line 59)
>                     ALOAD_0     // Ljava/lang/String; street
>                     INVOKEVIRTUAL =20
> com.trivadis.aop.configurable.Address.setStreet (Ljava/lang/String;)V
>                     ALOAD_2     // Lcom/trivadis/aop/configurable/=20
> Address; adr   (line 60)
>                     ALOAD_1     // Ljava/lang/String; city
>                     INVOKEVIRTUAL =20
> com.trivadis.aop.configurable.Address.setCity (Ljava/lang/String;)V
>                     ALOAD_2     // Lcom/trivadis/aop/configurable/=20
> Address; adr   (line 61)
>                     ARETURN
>   end public static com.trivadis.aop.configurable.Address =20
> createAddress(String, String)
>
>   public com.trivadis.aop.configurable.Address withStreet(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 67)
>                     ALOAD_1     // Ljava/lang/String; street
>                     INVOKEVIRTUAL =20
> com.trivadis.aop.configurable.Address.setStreet (Ljava/lang/String;)V
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 68)
>                     ARETURN
>   end public com.trivadis.aop.configurable.Address withStreet(String)
>
>   public com.trivadis.aop.configurable.Address withCity(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 72)
>                     ALOAD_1     // Ljava/lang/String; city
>                     INVOKEVIRTUAL =20
> com.trivadis.aop.configurable.Address.setCity (Ljava/lang/String;)V
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 73)
>                     ARETURN
>   end public com.trivadis.aop.configurable.Address withCity(String)
>
>   public com.trivadis.aop.configurable.Address forCountry(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 77)
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this
>                     GETFIELD =20
> com.trivadis.aop.configurable.Address.codeRepository Lcom/trivadis/=20
> aop/configurable/CodeRepository;
>                     ALOAD_1     // Ljava/lang/String; code
>                     INVOKEINTERFACE =20
> com.trivadis.aop.configurable.CodeRepository.findCountryByCode =20
> (Ljava/lang/String;)Lcom/trivadis/aop/configurable/Country;
>                     INVOKEVIRTUAL =20
> com.trivadis.aop.configurable.Address.setCountry (Lcom/trivadis/aop/=20
> configurable/Country;)V
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 78)
>                     ARETURN
>   end public com.trivadis.aop.configurable.Address forCountry(String)
>
> end public class com.trivadis.aop.configurable.Address
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> If I switch to compile time weaving, then everything works fine.
>
> Do you have any idea what might be wrong. Am I doing something =20
> wrong. Just let me know, if you need the test case, I have a small =20
> project with only a few classes.
>
> Thanks for your help
>
> Guido
> <winmail.dat>
> ---------------------------------------------------------------------- =

> ---
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?=20
> =
cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642_________________________=
_____=20
> _________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

-- Adrian
adr...@in...

Re: [Springframework-developer] Problem with @Configurable and LTWwith latest 2.0rc3

[Guido S. <Gui...@tr...>]

Hi Adrian

thanks for your quick reply. Just filed the bug against the AspectJ =
project with the stack trace and a test project to reproduce it.

Thanks
Guido

-----Urspr=FCngliche Nachricht-----
Von: spr...@li... im Auftrag =
von Adrian Colyer
Gesendet: Fr 11.08.2006 15:49
An: spr...@li...
Betreff: Re: [Springframework-developer] Problem with @Configurable and =
LTWwith latest 2.0rc3
=20
This is a message coming out of AspectJ itself and almost certainly =20
an AspectJ bug (we upgraded Spring to the AspectJ 1.5.2 libraries =20
during the Spring rc3 development cycle).

Please can you file a report against the AspectJ project: https://=20
bugs.eclipse.org/bugs/enter_bug.cgi?product=3DAspectJ.
If you could also include in the report the full stack trace as =20
produced by the weaver, and attach the project to reproduce the error =20
that would be a big help. Depending on exactly what the error is, I =20
may be able to tell you some compiler options to set to workaround =20
the issue.

Regards, Adrian.


On 11 Aug 2006, at 13:19, Guido Schmutz wrote:

> Hi
>
> I'm currently testing @Configurable and LTW. Everything worked/=20
> works fine with the 2.0rc2 distribution. This morning I then tried =20
> to use rc2 togehter with AspectJ 1.5.2 and had problems.
> Then after seeing that 2.0rc3 has been released, i switched to the =20
> 2.0rc3 distribution with the dependencies from there and I'm =20
> getting the same problems.
>
> With RC3, the domain object doesn't get configured and the error I =20
> get on the console is the following (only parts of it):
>
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 2110 [main] FATAL AspectJ Weaver  - [AspectJ] trouble in:
> public class com.trivadis.aop.configurable.Address extends =20
> java.lang.Object:
>   private transient com.trivadis.aop.configurable.CodeRepository =20
> codeRepository
>   private long id
>   private String street
>   private String city
>   private com.trivadis.aop.configurable.Country country
>   public void setCodeRepository=20
> (com.trivadis.aop.configurable.CodeRepository):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 15)
>                     ALOAD_1     // Lcom/trivadis/aop/configurable/=20
> CodeRepository; codeRepository
>                     PUTFIELD =20
> com.trivadis.aop.configurable.Address.codeRepository Lcom/trivadis/=20
> aop/configurable/CodeRepository;
>                     RETURN   (line 16)
>   end public void setCodeRepository=20
> (com.trivadis.aop.configurable.CodeRepository)
>
>   public String getCity():
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 28)
>                     GETFIELD =20
> com.trivadis.aop.configurable.Address.city Ljava/lang/String;
>                     ARETURN
>   end public String getCity()
>
>   public void setCity(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 32)
>                     ALOAD_1     // Ljava/lang/String; city
>                     PUTFIELD =20
> com.trivadis.aop.configurable.Address.city Ljava/lang/String;
>                     RETURN   (line 33)
>   end public void setCity(String)
>
>   public com.trivadis.aop.configurable.Country getCountry():
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 36)
>                     GETFIELD =20
> com.trivadis.aop.configurable.Address.country Lcom/trivadis/aop/=20
> configurable/Country;
>                     ARETURN
>   end public com.trivadis.aop.configurable.Country getCountry()
>
>   public void setCountry(com.trivadis.aop.configurable.Country):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 40)
>                     ALOAD_1     // Lcom/trivadis/aop/configurable/=20
> Country; country
>                     PUTFIELD =20
> com.trivadis.aop.configurable.Address.country Lcom/trivadis/aop/=20
> configurable/Country;
>                     RETURN   (line 41)
>   end public void setCountry(com.trivadis.aop.configurable.Country)
>
>   public String getStreet():
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 44)
>                     GETFIELD =20
> com.trivadis.aop.configurable.Address.street Ljava/lang/String;
>                     ARETURN
>   end public String getStreet()
>
>   public void setStreet(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 48)
>                     ALOAD_1     // Ljava/lang/String; street
>                     PUTFIELD =20
> com.trivadis.aop.configurable.Address.street Ljava/lang/String;
>                     RETURN   (line 49)
>   end public void setStreet(String)
>
>   private void <init>():
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 53)
>                     INVOKESPECIAL java.lang.Object.<init> ()V
>                     RETURN
>   end private void <init>()
>
>   public static com.trivadis.aop.configurable.Address createAddress=20
> (String, String):
>                     NEW com.trivadis.aop.configurable.Address   =20
> (line 58)
>                     DUP
>                     INVOKESPECIAL =20
> com.trivadis.aop.configurable.Address.<init> ()V
>                     ASTORE_2
>                     ALOAD_2     // Lcom/trivadis/aop/configurable/=20
> Address; adr   (line 59)
>                     ALOAD_0     // Ljava/lang/String; street
>                     INVOKEVIRTUAL =20
> com.trivadis.aop.configurable.Address.setStreet (Ljava/lang/String;)V
>                     ALOAD_2     // Lcom/trivadis/aop/configurable/=20
> Address; adr   (line 60)
>                     ALOAD_1     // Ljava/lang/String; city
>                     INVOKEVIRTUAL =20
> com.trivadis.aop.configurable.Address.setCity (Ljava/lang/String;)V
>                     ALOAD_2     // Lcom/trivadis/aop/configurable/=20
> Address; adr   (line 61)
>                     ARETURN
>   end public static com.trivadis.aop.configurable.Address =20
> createAddress(String, String)
>
>   public com.trivadis.aop.configurable.Address withStreet(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 67)
>                     ALOAD_1     // Ljava/lang/String; street
>                     INVOKEVIRTUAL =20
> com.trivadis.aop.configurable.Address.setStreet (Ljava/lang/String;)V
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 68)
>                     ARETURN
>   end public com.trivadis.aop.configurable.Address withStreet(String)
>
>   public com.trivadis.aop.configurable.Address withCity(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 72)
>                     ALOAD_1     // Ljava/lang/String; city
>                     INVOKEVIRTUAL =20
> com.trivadis.aop.configurable.Address.setCity (Ljava/lang/String;)V
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 73)
>                     ARETURN
>   end public com.trivadis.aop.configurable.Address withCity(String)
>
>   public com.trivadis.aop.configurable.Address forCountry(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 77)
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this
>                     GETFIELD =20
> com.trivadis.aop.configurable.Address.codeRepository Lcom/trivadis/=20
> aop/configurable/CodeRepository;
>                     ALOAD_1     // Ljava/lang/String; code
>                     INVOKEINTERFACE =20
> com.trivadis.aop.configurable.CodeRepository.findCountryByCode =20
> (Ljava/lang/String;)Lcom/trivadis/aop/configurable/Country;
>                     INVOKEVIRTUAL =20
> com.trivadis.aop.configurable.Address.setCountry (Lcom/trivadis/aop/=20
> configurable/Country;)V
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/=20
> Address; this   (line 78)
>                     ARETURN
>   end public com.trivadis.aop.configurable.Address forCountry(String)
>
> end public class com.trivadis.aop.configurable.Address
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> If I switch to compile time weaving, then everything works fine.
>
> Do you have any idea what might be wrong. Am I doing something =20
> wrong. Just let me know, if you need the test case, I have a small =20
> project with only a few classes.
>
> Thanks for your help
>
> Guido
> <winmail.dat>
> ---------------------------------------------------------------------- =

> ---
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?=20
> =
cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642_________________________=
_____=20
> _________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

-- Adrian
adr...@in...

Re: [Springframework-developer] Problem with @Configurable and LTW with latest 2.0rc3

[Adrian C. <adr...@in...>]

This is a message coming out of AspectJ itself and almost certainly  
an AspectJ bug (we upgraded Spring to the AspectJ 1.5.2 libraries  
during the Spring rc3 development cycle).

Please can you file a report against the AspectJ project: https:// 
bugs.eclipse.org/bugs/enter_bug.cgi?product=AspectJ.
If you could also include in the report the full stack trace as  
produced by the weaver, and attach the project to reproduce the error  
that would be a big help. Depending on exactly what the error is, I  
may be able to tell you some compiler options to set to workaround  
the issue.

Regards, Adrian.


On 11 Aug 2006, at 13:19, Guido Schmutz wrote:

> Hi
>
> I'm currently testing @Configurable and LTW. Everything worked/ 
> works fine with the 2.0rc2 distribution. This morning I then tried  
> to use rc2 togehter with AspectJ 1.5.2 and had problems.
> Then after seeing that 2.0rc3 has been released, i switched to the  
> 2.0rc3 distribution with the dependencies from there and I'm  
> getting the same problems.
>
> With RC3, the domain object doesn't get configured and the error I  
> get on the console is the following (only parts of it):
>
> ====================================================================== 
> ===========================================================
> 2110 [main] FATAL AspectJ Weaver  - [AspectJ] trouble in:
> public class com.trivadis.aop.configurable.Address extends  
> java.lang.Object:
>   private transient com.trivadis.aop.configurable.CodeRepository  
> codeRepository
>   private long id
>   private String street
>   private String city
>   private com.trivadis.aop.configurable.Country country
>   public void setCodeRepository 
> (com.trivadis.aop.configurable.CodeRepository):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this   (line 15)
>                     ALOAD_1     // Lcom/trivadis/aop/configurable/ 
> CodeRepository; codeRepository
>                     PUTFIELD  
> com.trivadis.aop.configurable.Address.codeRepository Lcom/trivadis/ 
> aop/configurable/CodeRepository;
>                     RETURN   (line 16)
>   end public void setCodeRepository 
> (com.trivadis.aop.configurable.CodeRepository)
>
>   public String getCity():
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this   (line 28)
>                     GETFIELD  
> com.trivadis.aop.configurable.Address.city Ljava/lang/String;
>                     ARETURN
>   end public String getCity()
>
>   public void setCity(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this   (line 32)
>                     ALOAD_1     // Ljava/lang/String; city
>                     PUTFIELD  
> com.trivadis.aop.configurable.Address.city Ljava/lang/String;
>                     RETURN   (line 33)
>   end public void setCity(String)
>
>   public com.trivadis.aop.configurable.Country getCountry():
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this   (line 36)
>                     GETFIELD  
> com.trivadis.aop.configurable.Address.country Lcom/trivadis/aop/ 
> configurable/Country;
>                     ARETURN
>   end public com.trivadis.aop.configurable.Country getCountry()
>
>   public void setCountry(com.trivadis.aop.configurable.Country):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this   (line 40)
>                     ALOAD_1     // Lcom/trivadis/aop/configurable/ 
> Country; country
>                     PUTFIELD  
> com.trivadis.aop.configurable.Address.country Lcom/trivadis/aop/ 
> configurable/Country;
>                     RETURN   (line 41)
>   end public void setCountry(com.trivadis.aop.configurable.Country)
>
>   public String getStreet():
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this   (line 44)
>                     GETFIELD  
> com.trivadis.aop.configurable.Address.street Ljava/lang/String;
>                     ARETURN
>   end public String getStreet()
>
>   public void setStreet(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this   (line 48)
>                     ALOAD_1     // Ljava/lang/String; street
>                     PUTFIELD  
> com.trivadis.aop.configurable.Address.street Ljava/lang/String;
>                     RETURN   (line 49)
>   end public void setStreet(String)
>
>   private void <init>():
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this   (line 53)
>                     INVOKESPECIAL java.lang.Object.<init> ()V
>                     RETURN
>   end private void <init>()
>
>   public static com.trivadis.aop.configurable.Address createAddress 
> (String, String):
>                     NEW com.trivadis.aop.configurable.Address    
> (line 58)
>                     DUP
>                     INVOKESPECIAL  
> com.trivadis.aop.configurable.Address.<init> ()V
>                     ASTORE_2
>                     ALOAD_2     // Lcom/trivadis/aop/configurable/ 
> Address; adr   (line 59)
>                     ALOAD_0     // Ljava/lang/String; street
>                     INVOKEVIRTUAL  
> com.trivadis.aop.configurable.Address.setStreet (Ljava/lang/String;)V
>                     ALOAD_2     // Lcom/trivadis/aop/configurable/ 
> Address; adr   (line 60)
>                     ALOAD_1     // Ljava/lang/String; city
>                     INVOKEVIRTUAL  
> com.trivadis.aop.configurable.Address.setCity (Ljava/lang/String;)V
>                     ALOAD_2     // Lcom/trivadis/aop/configurable/ 
> Address; adr   (line 61)
>                     ARETURN
>   end public static com.trivadis.aop.configurable.Address  
> createAddress(String, String)
>
>   public com.trivadis.aop.configurable.Address withStreet(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this   (line 67)
>                     ALOAD_1     // Ljava/lang/String; street
>                     INVOKEVIRTUAL  
> com.trivadis.aop.configurable.Address.setStreet (Ljava/lang/String;)V
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this   (line 68)
>                     ARETURN
>   end public com.trivadis.aop.configurable.Address withStreet(String)
>
>   public com.trivadis.aop.configurable.Address withCity(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this   (line 72)
>                     ALOAD_1     // Ljava/lang/String; city
>                     INVOKEVIRTUAL  
> com.trivadis.aop.configurable.Address.setCity (Ljava/lang/String;)V
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this   (line 73)
>                     ARETURN
>   end public com.trivadis.aop.configurable.Address withCity(String)
>
>   public com.trivadis.aop.configurable.Address forCountry(String):
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this   (line 77)
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this
>                     GETFIELD  
> com.trivadis.aop.configurable.Address.codeRepository Lcom/trivadis/ 
> aop/configurable/CodeRepository;
>                     ALOAD_1     // Ljava/lang/String; code
>                     INVOKEINTERFACE  
> com.trivadis.aop.configurable.CodeRepository.findCountryByCode  
> (Ljava/lang/String;)Lcom/trivadis/aop/configurable/Country;
>                     INVOKEVIRTUAL  
> com.trivadis.aop.configurable.Address.setCountry (Lcom/trivadis/aop/ 
> configurable/Country;)V
>                     ALOAD_0     // Lcom/trivadis/aop/configurable/ 
> Address; this   (line 78)
>                     ARETURN
>   end public com.trivadis.aop.configurable.Address forCountry(String)
>
> end public class com.trivadis.aop.configurable.Address
> ====================================================================== 
> ===========================================================
>
> If I switch to compile time weaving, then everything works fine.
>
> Do you have any idea what might be wrong. Am I doing something  
> wrong. Just let me know, if you need the test case, I have a small  
> project with only a few classes.
>
> Thanks for your help
>
> Guido
> <winmail.dat>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642______________________________ 
> _________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

-- Adrian
adr...@in...

[Springframework-developer] Problem with @Configurable and LTW with latest 2.0rc3

[Guido S. <Gui...@tr...>]

Hi

I'm currently testing @Configurable and LTW. Everything worked/works =
fine with the 2.0rc2 distribution. This morning I then tried to use rc2 =
togehter with AspectJ 1.5.2 and had problems.
Then after seeing that 2.0rc3 has been released, i switched to the =
2.0rc3 distribution with the dependencies from there and I'm getting the =
same problems.

With RC3, the domain object doesn't get configured and the error I get =
on the console is the following (only parts of it):

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
2110 [main] FATAL AspectJ Weaver  - [AspectJ] trouble in:=20
public class com.trivadis.aop.configurable.Address extends =
java.lang.Object:
  private transient com.trivadis.aop.configurable.CodeRepository =
codeRepository
  private long id
  private String street
  private String city
  private com.trivadis.aop.configurable.Country country
  public void =
setCodeRepository(com.trivadis.aop.configurable.CodeRepository):
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this   (line 15)
                    ALOAD_1     // =
Lcom/trivadis/aop/configurable/CodeRepository; codeRepository
                    PUTFIELD =
com.trivadis.aop.configurable.Address.codeRepository =
Lcom/trivadis/aop/configurable/CodeRepository;
                    RETURN   (line 16)
  end public void =
setCodeRepository(com.trivadis.aop.configurable.CodeRepository)

  public String getCity():
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this   (line 28)
                    GETFIELD com.trivadis.aop.configurable.Address.city =
Ljava/lang/String;
                    ARETURN
  end public String getCity()

  public void setCity(String):
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this   (line 32)
                    ALOAD_1     // Ljava/lang/String; city
                    PUTFIELD com.trivadis.aop.configurable.Address.city =
Ljava/lang/String;
                    RETURN   (line 33)
  end public void setCity(String)

  public com.trivadis.aop.configurable.Country getCountry():
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this   (line 36)
                    GETFIELD =
com.trivadis.aop.configurable.Address.country =
Lcom/trivadis/aop/configurable/Country;
                    ARETURN
  end public com.trivadis.aop.configurable.Country getCountry()

  public void setCountry(com.trivadis.aop.configurable.Country):
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this   (line 40)
                    ALOAD_1     // =
Lcom/trivadis/aop/configurable/Country; country
                    PUTFIELD =
com.trivadis.aop.configurable.Address.country =
Lcom/trivadis/aop/configurable/Country;
                    RETURN   (line 41)
  end public void setCountry(com.trivadis.aop.configurable.Country)

  public String getStreet():
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this   (line 44)
                    GETFIELD =
com.trivadis.aop.configurable.Address.street Ljava/lang/String;
                    ARETURN
  end public String getStreet()

  public void setStreet(String):
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this   (line 48)
                    ALOAD_1     // Ljava/lang/String; street
                    PUTFIELD =
com.trivadis.aop.configurable.Address.street Ljava/lang/String;
                    RETURN   (line 49)
  end public void setStreet(String)

  private void <init>():
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this   (line 53)
                    INVOKESPECIAL java.lang.Object.<init> ()V
                    RETURN
  end private void <init>()

  public static com.trivadis.aop.configurable.Address =
createAddress(String, String):
                    NEW com.trivadis.aop.configurable.Address   (line =
58)
                    DUP
                    INVOKESPECIAL =
com.trivadis.aop.configurable.Address.<init> ()V
                    ASTORE_2
                    ALOAD_2     // =
Lcom/trivadis/aop/configurable/Address; adr   (line 59)
                    ALOAD_0     // Ljava/lang/String; street
                    INVOKEVIRTUAL =
com.trivadis.aop.configurable.Address.setStreet (Ljava/lang/String;)V
                    ALOAD_2     // =
Lcom/trivadis/aop/configurable/Address; adr   (line 60)
                    ALOAD_1     // Ljava/lang/String; city
                    INVOKEVIRTUAL =
com.trivadis.aop.configurable.Address.setCity (Ljava/lang/String;)V
                    ALOAD_2     // =
Lcom/trivadis/aop/configurable/Address; adr   (line 61)
                    ARETURN
  end public static com.trivadis.aop.configurable.Address =
createAddress(String, String)

  public com.trivadis.aop.configurable.Address withStreet(String):
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this   (line 67)
                    ALOAD_1     // Ljava/lang/String; street
                    INVOKEVIRTUAL =
com.trivadis.aop.configurable.Address.setStreet (Ljava/lang/String;)V
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this   (line 68)
                    ARETURN
  end public com.trivadis.aop.configurable.Address withStreet(String)

  public com.trivadis.aop.configurable.Address withCity(String):
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this   (line 72)
                    ALOAD_1     // Ljava/lang/String; city
                    INVOKEVIRTUAL =
com.trivadis.aop.configurable.Address.setCity (Ljava/lang/String;)V
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this   (line 73)
                    ARETURN
  end public com.trivadis.aop.configurable.Address withCity(String)

  public com.trivadis.aop.configurable.Address forCountry(String):
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this   (line 77)
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this
                    GETFIELD =
com.trivadis.aop.configurable.Address.codeRepository =
Lcom/trivadis/aop/configurable/CodeRepository;
                    ALOAD_1     // Ljava/lang/String; code
                    INVOKEINTERFACE =
com.trivadis.aop.configurable.CodeRepository.findCountryByCode =
(Ljava/lang/String;)Lcom/trivadis/aop/configurable/Country;
                    INVOKEVIRTUAL =
com.trivadis.aop.configurable.Address.setCountry =
(Lcom/trivadis/aop/configurable/Country;)V
                    ALOAD_0     // =
Lcom/trivadis/aop/configurable/Address; this   (line 78)
                    ARETURN
  end public com.trivadis.aop.configurable.Address forCountry(String)

end public class com.trivadis.aop.configurable.Address
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

If I switch to compile time weaving, then everything works fine.

Do you have any idea what might be wrong. Am I doing something wrong. =
Just let me know, if you need the test case, I have a small project with =
only a few classes.

Thanks for your help

Guido

[Springframework-developer] Spring build.106 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring Framework 2.0 RC3 released

[Juergen H. <ju...@in...>]

Dear Spring community,

I'm pleased to announce that Spring 2.0 RC3 has been released. This third
release candidate includes many refinements based on feedback that we
received for the previous release candidates. (Thanks everybody!)

The most significant changes are:

* Spring 1.2 compatibility has been restored for default-lazy-init="true",
with respect to detection of special beans (such as
PropertyPlaceholderConfigurers) by type. Alongside, lazy class loading has
been reworked to still allow for placeholders in class names etc. Strict
lazy class loading can still be enforced for special ApplicationContexts.

* Persistence exception translation based on the @Repository annotation is
now available for Hibernate3, JDO and TopLink as well, not just for JPA.
Exception translation is now based on the underlying ORM tool's native
exceptions as far as possible, with Spring-specific SQLException translation
only applying when explicitly specified.

* DefaultMessageListenerContainer features refined resource handling (which
works on JBoss 4.0 as well), and is able to recover from a broken Connection
or Destination. The caching of JMS resources is now fully configurable, with
sensible defaults for both the XA and the non-XA scenario. Furthermore,
JmsTemplate reuses cached JMS resources within a JTA transaction.

* Servlet and Portlet Web MVC support a common WebRequestInterceptor
abstraction now, which allows Open Session/EntityManager/etc in View
interceptors to be reused across Servlet and Portlet environments. As a
consequence, all such Portlet-specific interceptors have been dropped in
favor of the new generic ones (OpenSessionInViewInterceptor etc).

Of course, there are many further refiements in the details. Please see the
changelog file (as well as the changelog in JIRA) for details.

Let us know about any remaining issues you might encounter with RC3... 
The Spring 2.0 final release is now just around the corner!

Cheers,

Juergen

[Springframework-developer] Spring build.105 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).