springframework-developer — Spring Framework developers list

[Springframework-developer] MethodInvokingTargetException rethrows InvocationTargetException

[Steven D. <ste...@gm...>]

I've create a JIRA issue
(http://opensource.atlassian.com/projects/spring/browse/SPR-1060) with
patch that improves MethodInvokingTargetException.
InvocationTargetException should not be rethrown as the stack trace
provides no information what-so-ever about the underlying exception.
Instead the target exception should be rethrown.

--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

Re: [Springframework-developer] autowiring hibernate dao objects

[James E. <jam...@gm...>]

I assume by "autowiring" you mean the ability to pass in a bean and the=20
named parameters are automagically pulled from the bean and bound to the=20
named query. If so, you might have a look at the=20
findByNamedQueryAndValueBean method on HibernateTemplate:

http://static.springframework.org/spring/docs/1.2.x/api/org/springframework=
/orm/hibernate/HibernateTemplate.html#findByNamedQueryAndValueBean(java.lan=
g.String,%20java.lang.Object)

Just for clarity...when I hear "autowire" I think "dependencies injected=20
from spring managed beans in the container". Unless you really do mean=20
something like that?

James


On 6/19/05, Steve Stallion <sst...@gm...> wrote:
>=20
> hello all,
>=20
> i am about to start on a project aimed at simplyfing hibernate dao
> integration into spring. The general idea is to provide autowiring for
> named queries to a given dao interface - ive been quite suprised this
> hasnt been done yet.
>=20
> is anyone aware if this has indeed been proposed, or if so, if there are
> any implementations available already?
>=20
>=20
> thanks!
>=20
> Steve
>=20
> --
> Yet magic and hierarchy
> arise from the same source,
> and this source has a null pointer.
>=20
> Reference the NULL within NULL,
> it is the gateway to all wizardry.
>=20
>=20
> -------------------------------------------------------
> SF.Net <http://SF.Net> email is sponsored by: Discover Easy Linux=20
> Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] spring build.287 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050620001616Lbuild.287

Re: [Springframework-developer] Extensible XML processing in Spring: prototype version available in CVS HEAD

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

James, everybody,

After a few private discussions with people that are working on extensible
XML bean definition models as well, I have decided to defer the entire topic
to Spring 1.3 (with RC1 scheduled for August). I hope that's OK with you,
James...

The approaches that are currently in discussion are quite different, so we
shouldn't ship anything in 1.2.2 that might get completely reworked in 1.3.
Consequently, I've removed the prototype from CVS again, as we are about to
ship 1.2.2 this week. We shouldn't ship any such extension that we need to
remain backwards-compatible with - at this point of time.

I hope you understand our reasoning here. For the time being, you can of
course create your own ApplicationContext subclass that uses a custom
XmlBeanDefinitionParser, or use a GenericApplicationContext in conjunction
with a custom XmlBeanDefinitionParser:

  GenericApplicationContext ctx = new GenericApplicationContext();
  XmlBeanDefinitionReader xmlReader = new XmlBeanDefinitionReader(ctx);
  xmlReader.setValidating(false);
  xmlReader.setNamespaceAware(true);
  xmlReader.setParserClass(MyXmlBeanDefinitionParser.class);
  xmlReader.loadBeanDefinitions(new ClassPathResource("myBeans.xml"));
  ctx.refresh();

I've kept the new basic processing hooks in XmlBeanDefinitionReader and
DefaultXmlBeanDefinitionParser, although in a slightly reworked fashion.
This should make it as seamless as possible to plug in a custom extension
for the meantime, no matter which XML extension model you're using.

We need to start a discussion on this as we move forward towards Spring 1.3,
involving everybody who's interested. Among others, Erik Wiersma and Aleks
Seovic have been working on this topic as well. Guys, let's start a concrete
discussion on this right after JavaOne - and create a unified solution for
Spring 1.3 that addresses everyone's needs!

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of jas...@ma...
Sent: Tuesday, June 14, 2005 12:20 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Extensible XML processing in
Spring: prototype version available in CVS HEAD



On 14 Jun 2005, at 09:05, jas...@ma... wrote:

> On 14 Jun 2005, at 08:37, Juergen Hoeller wrote:
>
> Its worth stressing, this is a pretty trivial change - has minimal
> coding impact and adds a pretty trivial plugin interface.

A couple more examples to show the kind of things possible with CVS
HEAD of Spring.

We've done the JBI deployment descriptor as a Spring XML extension,
which is a bit more hardcore XML mapping...

here are the POJOs
http://cvs.servicemix.codehaus.org/servicemix/base/src/main/java/org/
servicemix/jbi/deployment/

with the Spring XML extension implementation classes
http://cvs.servicemix.codehaus.org/servicemix/base/src/main/java/org/
servicemix/jbi/deployment/impl/

these classes rely on these generic Spring helper classes, which we
could move into Spring for others to reuse
http://cvs.servicemix.codehaus.org/servicemix/base/src/main/java/org/
servicemix/jbi/config/spring/

finally, here's an example of a deployment descriptor we can parse
(with embedded Spring XML being possible within  the XML of course :)

http://cvs.servicemix.codehaus.org/*checkout*/servicemix/base/src/
test/resources/org/servicemix/jbi/deployment/example.xml?rev=HEAD

James
-------
http://radio.weblogs.com/0112098/



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
shotput
a projector? How fast can you ride your desk chair down the office luge
track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] spring modules/spring projects/spring extensions

[Alexandru P. <apo...@ez...>]

From my user point of view - with Spring CVS daily updates though (pls le=
t me know if the discussion
is only between Spring developers) the current Spring codebase organizati=
on seems quite nice. I have
read before the discussion about different artifacts, and again imo the c=
urrent distro seems to me
the most appropriate.

I second Juergen when saying that a single sourcebase is much easier to m=
anage with a `smart=B4 build.

sorry if this is supposed to be developer inhouse discussion,
:alex |.::the_mindstorm::.|


#: by Juergen Hoeller's words the mind was *winged* :#
> I believe that the most important separation at this point of time is
> between different distributions. Each distribution needs to have its ow=
n
> part of the repository, for administration reasons. A distribution
> corresponds more to a project than a module, so "spring-projects" is no=
t
> inappropriate, IMO.
>=20
> Whether we go more fine-granular and create separate modules in the
> repository even for parts of a distribution is still undecided for me. =
There
> is arguably no strong need to do this, at least not at this point of ti=
me -
> in contrast to the separate distributions (Web Flow etc), where we
> absolutely _need_ a separation in the repository.
>=20
> As I already indicated earlier, I'm not a great fan of fine-granular so=
urce
> repositories in general. I tend to prefer a single unified codebase _pe=
r
> distribution_, with a simple and straightforward build, rather than a d=
ozen
> module source trees in my IDE project tree. This has proven to work up =
to
> now, so I wouldn't mind continuing down that road.
>=20
> In my opinion, our real problem was the sandbox, which was used for cod=
e
> that was supposed to end up in separate distributions. The sandbox shou=
ld
> really only be used for stuff that's supposed to end up in the Spring c=
ore
> distribution. That problem has been addressed already through factoring=
 out
> Web Flow and co, so I don't see a strong need to do any further splitti=
ng.
>=20
> Of course, if we decide to do further splits _at the distribution level=
_, a
> need for further splitting of the CVS repository would arise. However, =
there
> are currently no concrete plans to do so...
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Colin Sampaleanu
> Sent: Sunday, June 19, 2005 10:01 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] spring modules/spring
> projects/spring extensions
>=20
>=20
> Keith Donald wrote:
>=20
>> We need to reach a consensus on what to call our *core* =93spring
>> modules=94 repository here at sourceforge and the *extension *=93sprin=
g
>> modules=94 repository over at java.net.
>>
>> Right now we=92re calling the core stuff =93spring projects=94 =96 but=
 I=92m not
>> sure about that usage, =93modules=94 seems like such a better name=85
>>
>> However, having two =93spring modules=94 is obviously confusing.
>>
>> What about calling the core modules =93spring modules=94 and the work
>> happening over at java.net =93spring extensions=94? That seems like an
>> ideal situation. What do you think? Rob? Colin? Juergen? Would it be
>> possible to rename the java.net effort or is it too late for that?
>>
> Well, I have to agree with your suggestion; that's why I gave the
> original CVS module the name spring-modules, despite the java.net
> project having the same name. The name just seems best suited for the
> modules that make up Spring itself, whereas what's at java.net is more
> extensions, integrations, or related projects.
>=20
> Obviously our CVS can go either way. Right now there is both
> spring-modules and spring-projects in it (the former was going to be
> pruned, while the latter has the most current code). I just don't know
> how much work it'd be for somebody (Rob I guess since he's admin there)
> to change the java.net project, and how in agreement he is to make a
> change there. Ultimately I don't feel like a big argument over a name..=
.
>=20
> Colin
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl=
ick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl=
ick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20

Re: [Springframework-developer] spring modules/spring projects/spring extensions

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

I believe that the most important separation at this point of time is
between different distributions. Each distribution needs to have its own
part of the repository, for administration reasons. A distribution
corresponds more to a project than a module, so "spring-projects" is not
inappropriate, IMO.

Whether we go more fine-granular and create separate modules in the
repository even for parts of a distribution is still undecided for me. There
is arguably no strong need to do this, at least not at this point of time -
in contrast to the separate distributions (Web Flow etc), where we
absolutely _need_ a separation in the repository.

As I already indicated earlier, I'm not a great fan of fine-granular source
repositories in general. I tend to prefer a single unified codebase _per
distribution_, with a simple and straightforward build, rather than a dozen
module source trees in my IDE project tree. This has proven to work up to
now, so I wouldn't mind continuing down that road.

In my opinion, our real problem was the sandbox, which was used for code
that was supposed to end up in separate distributions. The sandbox should
really only be used for stuff that's supposed to end up in the Spring core
distribution. That problem has been addressed already through factoring out
Web Flow and co, so I don't see a strong need to do any further splitting.

Of course, if we decide to do further splits _at the distribution level_, a
need for further splitting of the CVS repository would arise. However, there
are currently no concrete plans to do so...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Sunday, June 19, 2005 10:01 PM
To: spr...@li...
Subject: Re: [Springframework-developer] spring modules/spring
projects/spring extensions


Keith Donald wrote:

> We need to reach a consensus on what to call our *core* “spring
> modules” repository here at sourceforge and the *extension *“spring
> modules” repository over at java.net.
>
> Right now we’re calling the core stuff “spring projects” – but I’m not
> sure about that usage, “modules” seems like such a better name…
>
> However, having two “spring modules” is obviously confusing.
>
> What about calling the core modules “spring modules” and the work
> happening over at java.net “spring extensions”? That seems like an
> ideal situation. What do you think? Rob? Colin? Juergen? Would it be
> possible to rename the java.net effort or is it too late for that?
>
Well, I have to agree with your suggestion; that's why I gave the
original CVS module the name spring-modules, despite the java.net
project having the same name. The name just seems best suited for the
modules that make up Spring itself, whereas what's at java.net is more
extensions, integrations, or related projects.

Obviously our CVS can go either way. Right now there is both
spring-modules and spring-projects in it (the former was going to be
pruned, while the latter has the most current code). I just don't know
how much work it'd be for somebody (Rob I guess since he's admin there)
to change the java.net project, and how in agreement he is to make a
change there. Ultimately I don't feel like a big argument over a name...

Colin



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] spring modules/spring projects/spring extensions

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

Keith Donald wrote:

> We need to reach a consensus on what to call our *core* “spring 
> modules” repository here at sourceforge and the *extension *“spring 
> modules” repository over at java.net.
>
> Right now we’re calling the core stuff “spring projects” – but I’m not 
> sure about that usage, “modules” seems like such a better name…
>
> However, having two “spring modules” is obviously confusing.
>
> What about calling the core modules “spring modules” and the work 
> happening over at java.net “spring extensions”? That seems like an 
> ideal situation. What do you think? Rob? Colin? Juergen? Would it be 
> possible to rename the java.net effort or is it too late for that?
>
Well, I have to agree with your suggestion; that's why I gave the 
original CVS module the name spring-modules, despite the java.net 
project having the same name. The name just seems best suited for the 
modules that make up Spring itself, whereas what's at java.net is more 
extensions, integrations, or related projects.

Obviously our CVS can go either way. Right now there is both 
spring-modules and spring-projects in it (the former was going to be 
pruned, while the latter has the most current code). I just don't know 
how much work it'd be for somebody (Rob I guess since he's admin there) 
to change the java.net project, and how in agreement he is to make a 
change there. Ultimately I don't feel like a big argument over a name...

Colin

[Springframework-developer] autowiring hibernate dao objects

[Steve S. <sst...@gm...>]

hello all,

i am about to start on a project aimed at simplyfing hibernate dao 
integration into spring. The general idea is to provide autowiring for 
named queries to a given dao interface - ive been quite suprised this 
hasnt been done yet.

is anyone aware if this has indeed been proposed, or if so, if there are 
any implementations available already?


thanks!

Steve

-- 
Yet magic and hierarchy
arise from the same source,
and this source has a null pointer.

Reference the NULL within NULL,
it is the gateway to all wizardry.

Re: [Springframework-developer] spring modules/spring projects/spring extensions

[Alexandru P. <apo...@ez...>]

#: by Keith Donald's words the mind was *winged* :#
> We need to reach a consensus on what to call our core "spring modules"
> repository here at sourceforge and the extension "spring modules" repository
> over at java.net.
> 
>  
> 
> Right now we're calling the core stuff "spring projects" - but I'm not sure
> about that usage, "modules" seems like such a better name.
> 
>  
> 
> However, having two "spring modules" is obviously confusing.
> 
>  
> 
> What about calling the core modules "spring modules" and the work happening
> over at java.net "spring extensions"?  That seems like an ideal situation.
> What do you think?  Rob? Colin? Juergen?  Would it be possible to rename the
> java.net effort or is it too late for that?
> 
>  
> 
> Thanks,
> 
>  
> 
> Keith
> 
>  
> 

Even if i am not part of Spring team I would go for these names.

:alex |.::the_mindstorm::.|

Re: [Springframework-developer] JdoDialect and detach?

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

OK, I'll commit the changes as I guess they are useful in any case. I agree
that we have to expect further operations to be added to JdoDialect, in
particular for post-JDO2 functionality that vendors will introduce. It
doesn't hurt to keep the existing hooks anyway, even in a JDO2 world, as
they introduce a nice level of customizability (through delegation rather
than through subclassing).

Existing JdoDialect implementations shouldn't be affected, as it's just a
bunch of new methods for JDO2-style functionality. If they implement
JdoDialect directly, they will have to implement those new methods once they
upgrade the Spring version that they compile against (which should be fine).
And most of them derive from DefaultJdoDialect anyway, which automatically
makes them inherit the default impls of those new methods.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Marc Logemann
Sent: Sunday, June 19, 2005 5:30 PM
To: spr...@li...
Subject: Re: [Springframework-developer] JdoDialect and detach?


Juergen,

nice to hear that there is an ongoing communication between you and JDO
vendors like Solarmetric. In fact Solarmetric seems quite positive
regarding Spring to the level that they dont complain when i send them
stacktraces with embedded Spring JDO classes in it. <g>

Like i said, i think it would be a great enhancement when Spring can
help JDO developers by enhancing JdoDialect. In the future there will
allways be a need for JdoDialect, because there is allways a gap between
vendor impl's and spec. Thats where the competitions is really showing
up. (i leave out the post JDO2 spec question at this time)

And yes, JdoCallbacks is allways an option, but if you get accustomed to
use JDOTemplate and its convenience methods out of the box, you really
want to leave that only for some rare cases and detach isnt rare at all
inside my app. Call me lazy but thats the way it is ;-)

Great work.


Juergen Hoeller wrote:
> Marc,
>
> I'm actually in regular contact with Patrick myself; we usually keep each
> other up-to-date on Spring/JDO things. Regarding attach/detach in
> JdoDialect, there's probably some miscommunication there ;-) Patrick and I
> have been talking about the need for this before, but no such thing has
made
> it into the Spring codebase yet.
>
> Anyway, I'm leaning towards adding those methods in the meantime. Even
when
> JDO2 is final and mainstream, there might still be some reasons to
override
> the default attach/detach behavior in a vendor-specific fashion, for
example
> customizing the default fetch group or calling some vendor-specific
> overloaded version of attach/detach. Alternatively, there's always the
> option to implement custom JdoCallbacks based on vendor-specific PM API,
of
> course.
>
> I've already refactored JdoTemplate and DefaultJdoDialect accordingly, but
> not committed the changes yet. In the course of this, I've also added a
> "newNamedQuery" hook to JdoDialect, factoring out named query creation too
> (intended for pre-JDO2 named query support as found in Kodo, Lido, Versant
> Open Access). In total, this should pretty much cover most functionality
> that current JDO impls offer beyond JDO 1.0.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Marc Logemann
> Sent: Sunday, June 19, 2005 4:29 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] JdoDialect and detach?
>
> Yeah and here we will certainly have different oppinions. Most people
> will think "hey JDO2 is nearly out the door - no need for dialect stuff
> anymore". I can agree on this only to that point that this argument is
> true and i dont believe this. I asked Patrick Linskey (or Abe White,
> dont know anymore) from Solarmetric and he said that JDO2 is not THAT
near.
>
> Anyway, i am interessted to hear other oppinions on that issue. Perhaps
> i will ask the Solarmetric guys about that to get some more arguments.
> Really funny was a statement from Patrick to me where he believed that
> there is allready an attach/detach abstraction inside JdoDialect, so it
> seems he likes the idea so much that he thought its allready in there ;-)


--
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Annotation to validate required bean attributes

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

Agreed on that advantage of constructor initialization: it can't be
forgotten in plain Java setup code. Of course, that difference doesn't
really matter in a container: the container won't forget to call the init
method...

Annotations for dependency checking don't help here, though. Annotations
won't be checked in plain Java setup code automatically either. And in
contrast to "afterPropertiesSet", you need external helper code to check
them explictly.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Keith Donald
Sent: Sunday, June 19, 2005 5:31 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Annotation to validate required
bean attributes


The problem with relying on afterPropertiesSet() is it's easy to forget to
call it from Java code; constructor initialization is just so much safer and
more elegant _most of the time_.  And in a system with a nicely partitioned
set of roles, the number of constructor args to fulfill for a given bean
typically stays small (say 1 or 2).

I fully agree the body of afterPropertiesSet init method is a great place to
go to see what "pre use" checks are made -- and these checks may contain
more complex logic.

So I think use of constructor based initialization for required
collaborators delegating to an init callback for more complex pre-use checks
really is the ideal situation.  I personally think people should avoid use
of default constructors where possible.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Juergen Hoeller
Sent: Sunday, June 19, 2005 8:41 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Annotation to validate required
bean attributes

Technically speaking, a container-specific annotation is just as much of a
container dependency as a container-specific callback interface. In both
cases, the corresponding container classes need to reside on the classpath
for loading your application class.

I simply see this as two different styles of validating dependencies. They
achieve exactly the same, just in different ways and with different minor
advantages/disadvantages.

One advantage of the "afterPropertiesSet" style is that it can easily be
called in a programmatic fashion, actually. Plain POJO usage of a bean does
not give you an easy way to check annotations, but you can easily call
"myBean.afterPropertiesSet" in any sort of Java code. And as mentioned
before, "afterPropertiesSet" can check arbitrarily complex relations between
the dependencies.

In any case, annotations for dependency checking should remain simple and
straightforward. Once a scripting language such as OGNL or the like creeps
into those annotations, they become very questionable. For complex checks, I
see no viable reason to replace a Java callback method with an annotation
scriptlet.

Finally, don't forget that there's also the option of declaratively
specifying an "init-method" on a Spring bean definition. This does not
impose _any_ container dependency on the object. Simply write an arbitrary
no-arg method that validates your dependencies and specify its name ("init"
or whatever) in the bean definition.

Such declarative init methods are the least intrusive you could get: no
container callback interface to be implemented, no container-specific
annotations to be compiled into the class. The disadvantage being that that
method won't be autodetected and thus needs to be specified explicitly.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Seth Ladd
Sent: Friday, June 17, 2005 1:45 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Annotation to validate required
bean attributes


On 6/16/05, Oliver Hutchison <Ol...@ou...> wrote:
> Are you really saving that much using annotations to validate required
> bean attributes? Since the introduction of the Assert class coding these
> afterPropertiesSet constraint checks has been made really simple. What's
> the difference between typing
>
>         @@RequiredDependency()
> And
>         Assert.notNull(property);
> ?
>
> Not much. Slightly less typing is required, but by using the annotations
> you introduce a set of dependencies that your POJO would never have had
> before. If you're only going to be creating the object using a bean
> factory this is acceptable, however if you want instantiate these
> annotated objects outside of a bean factory (say in a test) your also
> going to have to create all infrastructure needed to do the required
> validation.

Well, that's just the issue, right?  I'm not overly concerned if my
bean is created outside of the bean factory.  If so, I still have to
call afterPropertiesSet() for verification.

It's not so much an issue of saving typing, it's an issue of
minimizing the need to implement container specific interfaces.  For
me, I think it's less intrusive to add a few annotations for this use
case.  But that's certainly a subjective opinion.

I like the ideas of attributes to help the container perform some of
my work for me.  That is, I'm already asking the container to inject
my dependencies.  It's logical (to me) to also ask the container to
let me know if I've misconfigured the dependencies somehow.

And of course, you can always implement afterPropertiesSet() if you
don't like the dependencies.

You bring up good points.  I don't think the annotations method is
perfect for all cases, but I do think it handles much of what
afterPropertiesSet() is used for in a simple way.

Seth


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Annotation to validate required bean attributes

[Keith D. <ke...@in...>]

The problem with relying on afterPropertiesSet() is it's easy to forget =
to
call it from Java code; constructor initialization is just so much safer =
and
more elegant _most of the time_.  And in a system with a nicely =
partitioned
set of roles, the number of constructor args to fulfill for a given bean
typically stays small (say 1 or 2).

I fully agree the body of afterPropertiesSet init method is a great =
place to
go to see what "pre use" checks are made -- and these checks may contain
more complex logic.

So I think use of constructor based initialization for required
collaborators delegating to an init callback for more complex pre-use =
checks
really is the ideal situation.  I personally think people should avoid =
use
of default constructors where possible.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Juergen Hoeller
Sent: Sunday, June 19, 2005 8:41 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Annotation to validate required
bean attributes

Technically speaking, a container-specific annotation is just as much of =
a
container dependency as a container-specific callback interface. In both
cases, the corresponding container classes need to reside on the =
classpath
for loading your application class.

I simply see this as two different styles of validating dependencies. =
They
achieve exactly the same, just in different ways and with different =
minor
advantages/disadvantages.

One advantage of the "afterPropertiesSet" style is that it can easily be
called in a programmatic fashion, actually. Plain POJO usage of a bean =
does
not give you an easy way to check annotations, but you can easily call
"myBean.afterPropertiesSet" in any sort of Java code. And as mentioned
before, "afterPropertiesSet" can check arbitrarily complex relations =
between
the dependencies.

In any case, annotations for dependency checking should remain simple =
and
straightforward. Once a scripting language such as OGNL or the like =
creeps
into those annotations, they become very questionable. For complex =
checks, I
see no viable reason to replace a Java callback method with an =
annotation
scriptlet.

Finally, don't forget that there's also the option of declaratively
specifying an "init-method" on a Spring bean definition. This does not
impose _any_ container dependency on the object. Simply write an =
arbitrary
no-arg method that validates your dependencies and specify its name =
("init"
or whatever) in the bean definition.

Such declarative init methods are the least intrusive you could get: no
container callback interface to be implemented, no container-specific
annotations to be compiled into the class. The disadvantage being that =
that
method won't be autodetected and thus needs to be specified explicitly.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Seth Ladd
Sent: Friday, June 17, 2005 1:45 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Annotation to validate required
bean attributes


On 6/16/05, Oliver Hutchison <Ol...@ou...> wrote:
> Are you really saving that much using annotations to validate required
> bean attributes? Since the introduction of the Assert class coding =
these
> afterPropertiesSet constraint checks has been made really simple. =
What's
> the difference between typing
>
>         @@RequiredDependency()
> And
>         Assert.notNull(property);
> ?
>
> Not much. Slightly less typing is required, but by using the =
annotations
> you introduce a set of dependencies that your POJO would never have =
had
> before. If you're only going to be creating the object using a bean
> factory this is acceptable, however if you want instantiate these
> annotated objects outside of a bean factory (say in a test) your also
> going to have to create all infrastructure needed to do the required
> validation.

Well, that's just the issue, right?  I'm not overly concerned if my
bean is created outside of the bean factory.  If so, I still have to
call afterPropertiesSet() for verification.

It's not so much an issue of saving typing, it's an issue of
minimizing the need to implement container specific interfaces.  For
me, I think it's less intrusive to add a few annotations for this use
case.  But that's certainly a subjective opinion.

I like the ideas of attributes to help the container perform some of
my work for me.  That is, I'm already asking the container to inject
my dependencies.  It's logical (to me) to also ask the container to
let me know if I've misconfigured the dependencies somehow.

And of course, you can always implement afterPropertiesSet() if you
don't like the dependencies.

You bring up good points.  I don't think the annotations method is
perfect for all cases, but I do think it handles much of what
afterPropertiesSet() is used for in a simple way.

Seth


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JdoDialect and detach?

[Marc L. <ma...@lo...>]

Juergen,

nice to hear that there is an ongoing communication between you and JDO 
vendors like Solarmetric. In fact Solarmetric seems quite positive 
regarding Spring to the level that they dont complain when i send them 
stacktraces with embedded Spring JDO classes in it. <g>

Like i said, i think it would be a great enhancement when Spring can 
help JDO developers by enhancing JdoDialect. In the future there will 
allways be a need for JdoDialect, because there is allways a gap between 
vendor impl's and spec. Thats where the competitions is really showing 
up. (i leave out the post JDO2 spec question at this time)

And yes, JdoCallbacks is allways an option, but if you get accustomed to 
use JDOTemplate and its convenience methods out of the box, you really 
want to leave that only for some rare cases and detach isnt rare at all 
inside my app. Call me lazy but thats the way it is ;-)

Great work.


Juergen Hoeller wrote:
> Marc,
> 
> I'm actually in regular contact with Patrick myself; we usually keep each
> other up-to-date on Spring/JDO things. Regarding attach/detach in
> JdoDialect, there's probably some miscommunication there ;-) Patrick and I
> have been talking about the need for this before, but no such thing has made
> it into the Spring codebase yet.
> 
> Anyway, I'm leaning towards adding those methods in the meantime. Even when
> JDO2 is final and mainstream, there might still be some reasons to override
> the default attach/detach behavior in a vendor-specific fashion, for example
> customizing the default fetch group or calling some vendor-specific
> overloaded version of attach/detach. Alternatively, there's always the
> option to implement custom JdoCallbacks based on vendor-specific PM API, of
> course.
> 
> I've already refactored JdoTemplate and DefaultJdoDialect accordingly, but
> not committed the changes yet. In the course of this, I've also added a
> "newNamedQuery" hook to JdoDialect, factoring out named query creation too
> (intended for pre-JDO2 named query support as found in Kodo, Lido, Versant
> Open Access). In total, this should pretty much cover most functionality
> that current JDO impls offer beyond JDO 1.0.
> 
> Juergen
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Marc Logemann
> Sent: Sunday, June 19, 2005 4:29 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] JdoDialect and detach?
> 
> Yeah and here we will certainly have different oppinions. Most people
> will think "hey JDO2 is nearly out the door - no need for dialect stuff
> anymore". I can agree on this only to that point that this argument is
> true and i dont believe this. I asked Patrick Linskey (or Abe White,
> dont know anymore) from Solarmetric and he said that JDO2 is not THAT near.
> 
> Anyway, i am interessted to hear other oppinions on that issue. Perhaps
> i will ask the Solarmetric guys about that to get some more arguments.
> Really funny was a statement from Patrick to me where he believed that
> there is allready an attach/detach abstraction inside JdoDialect, so it
> seems he likes the idea so much that he thought its allready in there ;-)


-- 
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de

Re: [Springframework-developer] JdoDialect and detach?

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

Marc,

I'm actually in regular contact with Patrick myself; we usually keep each
other up-to-date on Spring/JDO things. Regarding attach/detach in
JdoDialect, there's probably some miscommunication there ;-) Patrick and I
have been talking about the need for this before, but no such thing has made
it into the Spring codebase yet.

Anyway, I'm leaning towards adding those methods in the meantime. Even when
JDO2 is final and mainstream, there might still be some reasons to override
the default attach/detach behavior in a vendor-specific fashion, for example
customizing the default fetch group or calling some vendor-specific
overloaded version of attach/detach. Alternatively, there's always the
option to implement custom JdoCallbacks based on vendor-specific PM API, of
course.

I've already refactored JdoTemplate and DefaultJdoDialect accordingly, but
not committed the changes yet. In the course of this, I've also added a
"newNamedQuery" hook to JdoDialect, factoring out named query creation too
(intended for pre-JDO2 named query support as found in Kodo, Lido, Versant
Open Access). In total, this should pretty much cover most functionality
that current JDO impls offer beyond JDO 1.0.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Marc Logemann
Sent: Sunday, June 19, 2005 4:29 PM
To: spr...@li...
Subject: Re: [Springframework-developer] JdoDialect and detach?


Juergen Hoeller wrote:

> To make the actual behavior pluggable, we could factor the actual
> invocations out to corresponding new JdoDialect methods, by default
calling
> the standard JDO 2.0 methods accordingly. This could then be overridden
for
> special vendor-specific attach/detach methods, whether current JDO 2.0
> previews or overloaded vendor-specific versions alongside the standard JDO
> 2.0 methods.

+1, thats the approach i had in mind in the last days.

> Kodo currently has no-arg "attach" and "detach" methods. Versant Open
Access
> currently has "versantAttachCopy" with one or two boolean args, and
> "versantDetachCopy" with a String arg (the fetch group; can be null). Both
> could quite easily be used within a Kodo/Versant-specific JdoDialect,
> passing in default arguments where necessary.

And i know at least one more vendor which could be easily adjusted to
that as well.

> I'm certainly open to go down that route; I'm just a little undecided
> whether it makes sense to do it at this point of time. I'm currently in
the
> process of gathering some further opinions. If it turns out that the
general
> agreement is in favor of such hooks, I'll add them for Spring 1.2.2
> (scheduled for coming Thursday/Friday).

Yeah and here we will certainly have different oppinions. Most people
will think "hey JDO2 is nearly out the door - no need for dialect stuff
anymore". I can agree on this only to that point that this argument is
true and i dont believe this. I asked Patrick Linskey (or Abe White,
dont know anymore) from Solarmetric and he said that JDO2 is not THAT near.

Anyway, i am interessted to hear other oppinions on that issue. Perhaps
i will ask the Solarmetric guys about that to get some more arguments.
Really funny was a statement from Patrick to me where he believed that
there is allready an attach/detach abstraction inside JdoDialect, so it
seems he likes the idea so much that he thought its allready in there ;-)


--
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Stale JTA transaction still attached to a tread

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

I've tracked this down as far as why the old Connection handle (with the old
transaction id) was still hanging around with that thread.  This is
definitely a follow-up error to the unexpected

  java.lang.IllegalStateException: No value for key
  [net.sf.hibernate.impl.SessionFactoryImpl@55f3ea] bound to thread

that came before. Through an unfortunate cascade, such an expected error can
lead to some transaction synchronizations not getting fully executed: in
your case, a ConnectionSynchronization that is supposed to remove the
transactional JDBC Connection handle from the thread.

I've fixed this already: All synchronizations will now get fully executed,
even when some internal transaction synchronization throws an unexpected
assertion failure. This should completely remove the potential for such
follow-up errors, leaving all threads fully intact even in awkward
unexpected cases.

In other words, you won't get dangling transactional resources hanging
around with your threads anymore, not even when some internal assertions
within Spring's own transaction synchronization code fail. In all other
cases, you wouldn't get dangling transactional resources in the first place;
this really only affects our corner case here.

Which leads me to the root question: Why did you get that
IllegalStateException in the first place? Some code must have removed the
SessionHolder from the thread within the transaction: Spring's
synchronization code bound a SessionHolder to the thread at transaction
begin, but couldn't find it anymore at transaction completion.

The obvious cause would be some "TransactionSynchronization.unbindResource"
call in your application, but I doubt that this is the case. It rather seems
that some specific transaction interaction scenario can cause preliminary
unbinding of the SessionHolder, causing the assertion failure in the
surrounding transaction synchronization code.

So in summary, the potential for follow-up errors has been removed: no
dangling thread-bound resource in any case, not even in case of internal
assertion failures. Why that assertion failed in the first place is still
unclear. But at least the effect of such an assertion failure has been
reduced to the transaction that caused it now.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Dave Ballard
Sent: Friday, June 17, 2005 10:45 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Stale JTA transaction still
attached to a tread


Hi Juergen,

There was a failure involving the Spring transactional cleanup code
which may be of interest.

Background: My application architecture is in transition from stateless
session beans (for transaction demarcation) and entity beans, to Spring
managed services (and transaction demarcation) and dao's. So currently,
I've got a mix of both. In some cases, I've got a session bean starting
a transaction, then that session bean calling a Spring service
(resulting in the JTA transaction being joined). In other newer code,
Spring starts the transaction.

The thread in question is ExecuteThread: '5'. The first sign of trouble
with this thread is a failure of an insert statement. I've seen this
'PreparedStatement' exception once before a number of months ago. I
don't *think* this is a Hibernate bug, as the last time the error
involved an entity bean.  It may be a problem with my JDBC driver.

Spring didn't start this transaction, but at this point in processing,
SessionFactoryUtils.getSession(sessionFactory, true) has been called
from the session bean, and a Spring managed service (with a
JtaTransactionManager transaction interceptor) has also been called.

---
ERROR 13:34:55,789 [ExecuteThread: '5' for queue: 'default'] [mariew_]
(MoneyTransactionSessionEJB.java:459) - Error creating advance
net.sf.hibernate.JDBCException: could not insert:
[LedgerEntryClass#LEN000061465159]
    at
net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java:478)
    at
net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java:442)
    at
net.sf.hibernate.impl.ScheduledInsertion.execute(ScheduledInsertion.java:29)
    at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2414)
    at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2367)
    at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2236)
    at
MoneyTransactionSessionEJB.createLedgerEntriesForNewContractItems(MoneyTrans
actionSessionEJB.java:5661)
    at
MoneyTransactionSessionEJB.processTransactionInternal(MoneyTransactionSessio
nEJB.java:704)
    at
MoneyTransactionSessionEJB.processTransaction(MoneyTransactionSessionEJB.jav
a:454)
    at
MoneyTransactionSessionEJB_xvjdlx_ELOImpl.processTransaction(MoneyTransactio
nSessionEJB_xvjdlx_ELOImpl.java:1037)
    at java.lang.reflect.Method.invoke(Native Method)
    at
org.springframework.ejb.access.LocalSlsbInvokerInterceptor.invoke(LocalSlsbI
nvokerInterceptor.java:66)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Reflect
iveMethodInvocation.java:144)
    at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopPro
xy.java:174)
    at $Proxy126.processTransaction(Unknown Source)
    at AdvanceCreate.execute(AdvanceCreate.java:109)
    at AdvanceCommit.createAdvance(AdvanceCommit.java:368)
    at AdvanceCommit.process(AdvanceCommit.java:118)
    at
jsp_servlet._jsp._advance.__advance_confirm._jspService(__advance_confirm.ja
va:125)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
    at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
:275)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
    at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
    at AccessControlFilter.doFilter(AccessControlFilter.java:79)
    at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletCo
ntext.java:2708)
    at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java
:2427)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:159)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:140)
Caused by:
java.sql.SQLException: [JTurbo 3.1d9 JDBC 2.1 Driver]: PreparedStatement
is closed
    at com.newatlanta.jturbo.driver.u.executeUpdate(u.java)
    at weblogic.jdbc.jts.Statement.executeUpdate(Statement.java:508)
    at
net.sf.hibernate.impl.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:
22)
    at
net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java:468)
    ... 29 more
---

One minute later, this same thread was used for a different request (the
username is different):

---
ERROR 13:35:56,805 [ExecuteThread: '5' for queue: 'default'] [dan101_]
(AbstractPlatformTransactionManager.java:585) - Rollback exception
overridden by synchronization exception
java.lang.IllegalStateException: No value for key
[net.sf.hibernate.impl.SessionFactoryImpl@55f3ea] bound to thread
[ExecuteThread: '5' for queue: 'default']
    at
org.springframework.transaction.support.TransactionSynchronizationManager.un
bindResource(TransactionSynchronizationManager.java:175)
    at
org.springframework.orm.hibernate.SessionFactoryUtils$SpringSessionSynchroni
zation.beforeCompletion(SessionFactoryUtils.java:871)
    at
org.springframework.transaction.support.AbstractPlatformTransactionManager.t
riggerBeforeCompletion(AbstractPlatformTransactionManager.java:580)
    at
org.springframework.transaction.support.AbstractPlatformTransactionManager.c
ommit(AbstractPlatformTransactionManager.java:425)
    at
org.springframework.transaction.interceptor.TransactionAspectSupport.doCommi
tTransactionAfterReturning(TransactionAspectSupport.java:258)
    at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(Tr
ansactionInterceptor.java:67)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Reflect
iveMethodInvocation.java:144)
    at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopPro
xy.java:174)
    at $Proxy114.findContract(Unknown Source)
    at AdvanceView.load(AdvanceView.java:228)
    at AdvanceView.process(AdvanceView.java:141)
    at
jsp_servlet._jsp._advance.__advanceview._jspService(__advanceview.java:139)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
    at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
:275)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
    at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
    at AccessControlFilter.doFilter(AccessControlFilter.java:79)
    at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at
weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImp
l.java:289)
    at
webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:222)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
:275)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
    at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
    at AccessControlFilter.doFilter(AccessControlFilter.java:79)
    at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at
weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImp
l.java:289)
    at
weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:119)
    at
jsp_servlet._jsp._advance.__advance_confirm._jspService(__advance_confirm.ja
va:165)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
    at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
:275)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
    at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
    at AccessControlFilter.doFilter(AccessControlFilter.java:79)
    at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletCo
ntext.java:2708)
    at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java
:2427)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:159)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:140)
    ---

There are no nested exceptions. In the previous stack trace, the
presentation layer called a Spring  managed service (which started its
own transaction).

After this point, each time ExecuteThread: '5' is used,  it fails with a
org.springframework.jdbc.UncategorizedSQLException wrapping a WebLogic
TimedOutException. The transaction ID (496219) is always the same. This
happens over and over again. As I was investigating this problem, I
began to ask myself "why are all of these timeouts on the same thread?".
Restarting the app server corrected the problem. The timeout information
looks like:

    ---
    ERROR 13:37:04,650 [ExecuteThread: '5' for queue: 'default']
[torry_] (HibernateSpringContractDAO.java:235) -
      org.springframework.jdbc.UncategorizedSQLException:
      executing PreparedStatementCallback: encountered SQLException
      [The transaction is no longer active (status = Rolled back.
      [Reason=weblogic.transaction.internal.TimedOutException:
      Transaction timed out after 29 seconds
Xid=4954:766e8eae3c8bdd4d(496219),
      Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
since begin=29,
      seconds left=30,activeThread=Thread[ExecuteThread: '5' for queue:
'default',5,
      Thread Group for Queue:
'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=

(state=started,assigned=none),SCInfo[myappserver+appserver]=(state=active),

properties=({weblogic.jdbc=t3://192.168.1.1:80}),OwnerTransactionManager=Ser
verTM[ServerCoordinatorDescriptor=
      (CoordinatorURL=appserver+192.168.1.1:80+myappserver+, Resources={})],
      CoordinatorURL=appserver+192.168.1.1:80+myappserver+)]).
      No further JDBC access is allowed  within this transaction.];
      nested exception is java.sql.SQLException: The transaction is no
longer active
      (status = Rolled back.
[Reason=weblogic.transaction.internal.TimedOutException:
      Transaction timed out after 29 seconds
Xid=4954:766e8eae3c8bdd4d(496219),Status=Active,
      numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since
begin=29,seconds left=30,
      activeThread=Thread[ExecuteThread: '5' for queue:
'default',5,Thread Group for Queue: 'default'],

ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=started,assigned=non
e),

SCInfo[myappserver+appserver]=(state=active),properties=({weblogic.jdbc=t3:/
/192.168.1.1:80}),

OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL
=appserver+192.168.1.1:80+myappserver+,
Resources={})],
      CoordinatorURL=appserver+192.168.1.1:80+myappserver+)]).
      No further JDBC access is allowed  within this transaction.
    ---

    The nested exception is:

    ---

ERROR 13:37:04,650 [ExecuteThread: '5' for queue: 'default'] [torry_]
(ServletUtils.java:221) - Error
[trimmed verbose timeout info referencing Xid=4954:766e8eae3c8bdd4d(496219)]
    at
HibernateSpringContractDAO.findContract(HibernateSpringContractDAO.java:236)
    at java.lang.reflect.Method.invoke(Native Method)
    at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopU
tils.java:288)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint
(ReflectiveMethodInvocation.java:155)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Reflect
iveMethodInvocation.java:122)
    at
org.springframework.orm.hibernate.HibernateInterceptor.invoke(HibernateInter
ceptor.java:164)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Reflect
iveMethodInvocation.java:144)
    at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopPro
xy.java:174)
    at $Proxy93.findContract(Unknown Source)
    at ContractServiceImpl.findContract(ContractServiceImpl.java:59)
    at java.lang.reflect.Method.invoke(Native Method)
    at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopU
tils.java:288)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint
(ReflectiveMethodInvocation.java:155)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Reflect
iveMethodInvocation.java:122)
    at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(Tr
ansactionInterceptor.java:57)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Reflect
iveMethodInvocation.java:144)
    at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopPro
xy.java:174)
    at $Proxy114.findContract(Unknown Source)
    at AdvanceView.load(AdvanceView.java:228)
    at AdvanceView.process(AdvanceView.java:141)
    at
jsp_servlet._jsp._advance.__advanceview._jspService(__advanceview.java:139)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
    at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
:275)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
    at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
    at AccessControlFilter.doFilter(AccessControlFilter.java:79)
    at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at
weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImp
l.java:289)
    at
webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:222)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
:275)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
    at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
    at AccessControlFilter.doFilter(AccessControlFilter.java:79)
    at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletCo
ntext.java:2708)
    at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java
:2427)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:159)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:140)
Caused by:
[trimmed verbose timeout info referencing Xid=4954:766e8eae3c8bdd4d(496219)]
    at weblogic.jdbc.jts.Connection.checkIfRolledBack(Connection.java:526)
    at weblogic.jdbc.jts.Connection.prepareStatement(Connection.java:122)
    at
org.springframework.jdbc.core.JdbcTemplate$SimplePreparedStatementCreator.cr
eatePreparedStatement(JdbcTemplate.java:992)
    at
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:444)
    at
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:491)
    at
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:530)
    at
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:548)
    at
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:553)
    at
HibernateSpringContractDAO.findActiveNSF(HibernateSpringContractDAO.java:716
)
    at
HibernateSpringContractDAO.findContract(HibernateSpringContractDAO.java:231)
    ---

  Please let me know what additional information I can provide.

  Thanks again for your help,
  Dave

Juergen Hoeller wrote:

>Hi Dave,
>
>That's indeed odd, in particular as Spring does not explicitly associate
JTA
>transactions with the current thread (of course the JTA provider itself
will
>use ThreadLocals underneath).
>
>The only thing that could be bound to the thread by Spring within a JTA
>transaction is a transactional resource, such as a JDBC Connection or a
>Hibernate Session. Such resources should _always_ get removed from the
>thread by Spring's corresponding synchronization classes, though: So if
such
>a resource would be the root cause, this would mean some bug in Spring's
>resource cleanup code.
>
>If you can track down any details, I'm gonna address this immediately (even
>during the weekend). It would be great to clarify this before the upcoming
>Spring 1.2.2 release...
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Dave Ballard
>Sent: Friday, June 17, 2005 7:06 PM
>To: spr...@li...
>Subject: [Springframework-developer] Stale JTA transaction still
>attached to a tread
>
>
>Hi Juergen,
>
>Using Spring 1.2.1 with JtaTransactionManager with WebLogic 6.1. A
>review of my logs showed a large number of JTA timeouts. The odd thing
>is that the timeouts seem all to be occurring on the same thread. What
>WebLogic reports as the transaction ID is always the same.
>
>It appears to me that there is stale Spring JTA transaction attached to
>this particular thread. Each time WebLogic releases this thread to a
>request, and attempts to run some SQL (via Spring), it gets a JTA
>timeout with the same transaction ID.
>
>I'm about to restart our server, and I expect this to clear up the
>problem. However, this is a pretty serious problem. I am going to go
>back through the logs and attempt to locate the root error for this thread.
>
>Thanks for your help,
>Dave
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JdoDialect and detach?

[Marc L. <ma...@lo...>]

Juergen Hoeller wrote:

> To make the actual behavior pluggable, we could factor the actual
> invocations out to corresponding new JdoDialect methods, by default calling
> the standard JDO 2.0 methods accordingly. This could then be overridden for
> special vendor-specific attach/detach methods, whether current JDO 2.0
> previews or overloaded vendor-specific versions alongside the standard JDO
> 2.0 methods.

+1, thats the approach i had in mind in the last days.

> Kodo currently has no-arg "attach" and "detach" methods. Versant Open Access
> currently has "versantAttachCopy" with one or two boolean args, and
> "versantDetachCopy" with a String arg (the fetch group; can be null). Both
> could quite easily be used within a Kodo/Versant-specific JdoDialect,
> passing in default arguments where necessary.

And i know at least one more vendor which could be easily adjusted to 
that as well.

> I'm certainly open to go down that route; I'm just a little undecided
> whether it makes sense to do it at this point of time. I'm currently in the
> process of gathering some further opinions. If it turns out that the general
> agreement is in favor of such hooks, I'll add them for Spring 1.2.2
> (scheduled for coming Thursday/Friday).

Yeah and here we will certainly have different oppinions. Most people 
will think "hey JDO2 is nearly out the door - no need for dialect stuff 
anymore". I can agree on this only to that point that this argument is 
true and i dont believe this. I asked Patrick Linskey (or Abe White, 
dont know anymore) from Solarmetric and he said that JDO2 is not THAT near.

Anyway, i am interessted to hear other oppinions on that issue. Perhaps 
i will ask the Solarmetric guys about that to get some more arguments. 
Really funny was a statement from Patrick to me where he believed that 
there is allready an attach/detach abstraction inside JdoDialect, so it 
seems he likes the idea so much that he thought its allready in there ;-)


-- 
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de

Re: [Springframework-developer] Annotation to validate required bean attributes

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

Technically speaking, a container-specific annotation is just as much of a
container dependency as a container-specific callback interface. In both
cases, the corresponding container classes need to reside on the classpath
for loading your application class.

I simply see this as two different styles of validating dependencies. They
achieve exactly the same, just in different ways and with different minor
advantages/disadvantages.

One advantage of the "afterPropertiesSet" style is that it can easily be
called in a programmatic fashion, actually. Plain POJO usage of a bean does
not give you an easy way to check annotations, but you can easily call
"myBean.afterPropertiesSet" in any sort of Java code. And as mentioned
before, "afterPropertiesSet" can check arbitrarily complex relations between
the dependencies.

In any case, annotations for dependency checking should remain simple and
straightforward. Once a scripting language such as OGNL or the like creeps
into those annotations, they become very questionable. For complex checks, I
see no viable reason to replace a Java callback method with an annotation
scriptlet.

Finally, don't forget that there's also the option of declaratively
specifying an "init-method" on a Spring bean definition. This does not
impose _any_ container dependency on the object. Simply write an arbitrary
no-arg method that validates your dependencies and specify its name ("init"
or whatever) in the bean definition.

Such declarative init methods are the least intrusive you could get: no
container callback interface to be implemented, no container-specific
annotations to be compiled into the class. The disadvantage being that that
method won't be autodetected and thus needs to be specified explicitly.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Seth Ladd
Sent: Friday, June 17, 2005 1:45 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Annotation to validate required
bean attributes


On 6/16/05, Oliver Hutchison <Ol...@ou...> wrote:
> Are you really saving that much using annotations to validate required
> bean attributes? Since the introduction of the Assert class coding these
> afterPropertiesSet constraint checks has been made really simple. What's
> the difference between typing
>
>         @@RequiredDependency()
> And
>         Assert.notNull(property);
> ?
>
> Not much. Slightly less typing is required, but by using the annotations
> you introduce a set of dependencies that your POJO would never have had
> before. If you're only going to be creating the object using a bean
> factory this is acceptable, however if you want instantiate these
> annotated objects outside of a bean factory (say in a test) your also
> going to have to create all infrastructure needed to do the required
> validation.

Well, that's just the issue, right?  I'm not overly concerned if my
bean is created outside of the bean factory.  If so, I still have to
call afterPropertiesSet() for verification.

It's not so much an issue of saving typing, it's an issue of
minimizing the need to implement container specific interfaces.  For
me, I think it's less intrusive to add a few annotations for this use
case.  But that's certainly a subjective opinion.

I like the ideas of attributes to help the container perform some of
my work for me.  That is, I'm already asking the container to inject
my dependencies.  It's logical (to me) to also ask the container to
let me know if I've misconfigured the dependencies somehow.

And of course, you can always implement afterPropertiesSet() if you
don't like the dependencies.

You bring up good points.  I don't think the annotations method is
perfect for all cases, but I do think it handles much of what
afterPropertiesSet() is used for in a simple way.

Seth


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JdoDialect and detach?

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

If there is enough interest, we can still add attach/detach hooks to our
JdoDialect abstraction. This would particularly make sense if standard JDO
2.0 implementations are still a while away.

The current JDO 2.0 API methods specify a "makeTransactional" argument for
"attachCopy", where we currently always pass in "true", and no-arg
"detachCopy" methods. The final JDO 2.0 API might specify no-arg
"attachCopy" versions and "detachCopy" versions with a fetch plan argument
(which can be null) instead.

So one option would be to continue covering plain "attachCopy"/"detachCopy"
without special arguments, for both single objects and Collections, in our
JdoTemplate. Such default no-arg methods certainly make sense in general,
even if we might add JDO2-specific overloaded versions (for example with
explicit fetch plan argument) in the future.

To make the actual behavior pluggable, we could factor the actual
invocations out to corresponding new JdoDialect methods, by default calling
the standard JDO 2.0 methods accordingly. This could then be overridden for
special vendor-specific attach/detach methods, whether current JDO 2.0
previews or overloaded vendor-specific versions alongside the standard JDO
2.0 methods.

Kodo currently has no-arg "attach" and "detach" methods. Versant Open Access
currently has "versantAttachCopy" with one or two boolean args, and
"versantDetachCopy" with a String arg (the fetch group; can be null). Both
could quite easily be used within a Kodo/Versant-specific JdoDialect,
passing in default arguments where necessary.

I'm certainly open to go down that route; I'm just a little undecided
whether it makes sense to do it at this point of time. I'm currently in the
process of gathering some further opinions. If it turns out that the general
agreement is in favor of such hooks, I'll add them for Spring 1.2.2
(scheduled for coming Thursday/Friday).

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Marc Logemann
Sent: Friday, June 17, 2005 12:29 PM
To: spr...@li...
Subject: Re: [Springframework-developer] JdoDialect and detach?


Juergen Hoeller wrote:
> We did consider supporting attach/detach hooks as well, but decided not to
> do so, because the exact syntax and behavior of those operations weren't
> clear back then. In contrast to that, almost all JDO 1.0 implementations
had
> JDBC Connection exposure and flushing for ages.

I thought that the syntax differences would be the initial motivation to
write JdoDialect. But i can think of very different approaches of
detach/attach back then.

> At this point of time, our plan is to not extend JdoDialect any further,
> because JDO 2.0 is just around the corner. Our JdoTemplate and
> DefaultJdoDialect already support the standard JDO 2.0 API, so once you
get
> a JDO impl that supports JDO 2.0, that's gonna be immediately available to
> you.

Of course, this is also my thinking, however right now we are in a sad
situation which i will exaplain below. Right now it would be very nice
to have a JdoDialect handling this too, then JdoTemplate could use this
dialect and we would be able to abstract away the differences between
current detach/attach approaches between vendors. But i agree that this
would only be a short-time benefit.

> For JDO 2.0 previews such as current Kodo versions, you can always
implement
> a JdoCallback and cast the passed-in PersistenceManager to the
> vendor-specific PM interface, calling attach/detach and other JDO 2.0
> preview operations there. This can of course be replaced with straight
> JdoTemplate calls once the particular JDO impl officially supports the
> standard JDO 2.0 API.

Yeah i saw that JdoTemplate allready provides JDO2 public draft style
attach/detach API (i heard that the JCP-EG might want to change the
detach API naming for the final spec) but right now i, as a kodo user,
cant use the convenience methods, because kodo detach API is different
to the public draft. They said that they wont change to the public JDO2
draft API spec, because chances are high that it will change ;-)

Of course, implementing an own Callback is possible, you can also create
a child of JdoTemplate and override the attach/detach methods in there.

All in all its an unhealthy situation in the JDO area, we still dont
have JDO2 and it seems this will take a while and we have different
vendors supporting different parts of JDO2, this mixed with unstable
public draft seems not the ideal situation. All in there we have spring
trying to cope with that situation ;-)

>
> As a side note: The pluggable JDBC Connection exposure in JdoDialect can
> still be valuable even with JDO 2.0. For example, you might want to expose
> the native JDBC Connection to JDBC data access code, which could be casted
> to OracleConnection or the like. In this case, you still need
> vendor-specific extraction calls, because standard JDO 2.0 always exposes
a
> wrapped handle...

Hmm, yeah you get a handle which you can ask for a java.sql.Connection
(ok its Object in reality but most implementations will return a JDBC
connection) in the method getNativeConnection(). There is not much of a
difference between a properietary vendor call for a JDBC connection and
the JDO2 one, except for some connection methods which will throw an
exception like getMetaData() or rollback(). But perhaps i am missing
something.


--
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] spring modules/spring projects/spring extensions

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

Well, I guess the proper naming partly depends on what granularity we're
gonna use over here at the core CVS.

If we don't go down the fine-grained module route but rather keep things at
a course-grained subproject level, "spring-projects" will be perfectly fine.
This still hasn't been decided yet, though...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Erwin Vervaet
Sent: Sunday, June 19, 2005 8:10 AM
To: spr...@li...
Subject: Re: [Springframework-developer] spring modules/spring
projects/spring extensions


Check the following:

http://article.gmane.org/gmane.comp.java.springframework.devel/8723
http://article.gmane.org/gmane.comp.java.springframework.devel/8729
http://article.gmane.org/gmane.comp.java.springframework.devel/8730

So as I understand it we'll stick with "spring-projects" for the time being.

Erwin Vervaet
erw...@er...
----- Original Message -----
From: Keith Donald
To: spr...@li...
Sent: Sunday, June 19, 2005 4:52 AM
Subject: [Springframework-developer] spring modules/spring projects/spring
extensions


We need to reach a consensus on what to call our core “spring modules”
repository here at sourceforge and the extension “spring modules” repository
over at java.net.

Right now we’re calling the core stuff “spring projects” – but I’m not sure
about that usage, “modules” seems like such a better name…

However, having two “spring modules” is obviously confusing.

What about calling the core modules “spring modules” and the work happening
over at java.net “spring extensions”?  That seems like an ideal situation.
What do you think?  Rob? Colin? Juergen?  Would it be possible to rename the
java.net effort or is it too late for that?

Thanks,

Keith

--
Keith Donald
Interface21 Principal Consultant
http://www.springframework.com

Re: [Springframework-developer] spring modules/spring projects/spring extensions

[Erwin V. <erw...@er...>]

Check the following:

http://article.gmane.org/gmane.comp.java.springframework.devel/8723
http://article.gmane.org/gmane.comp.java.springframework.devel/8729
http://article.gmane.org/gmane.comp.java.springframework.devel/8730

So as I understand it we'll stick with "spring-projects" for the time =
being.

Erwin Vervaet
erw...@er...
  ----- Original Message -----=20
  From: Keith Donald=20
  To: spr...@li...=20
  Sent: Sunday, June 19, 2005 4:52 AM
  Subject: [Springframework-developer] spring modules/spring =
projects/spring extensions


  We need to reach a consensus on what to call our core "spring modules" =
repository here at sourceforge and the extension "spring modules" =
repository over at java.net.

  =20

  Right now we're calling the core stuff "spring projects" - but I'm not =
sure about that usage, "modules" seems like such a better name.

  =20

  However, having two "spring modules" is obviously confusing.

  =20

  What about calling the core modules "spring modules" and the work =
happening over at java.net "spring extensions"?  That seems like an =
ideal situation.  What do you think?  Rob? Colin? Juergen?  Would it be =
possible to rename the java.net effort or is it too late for that?

  =20

  Thanks,

  =20

  Keith

  =20

  --=20
  Keith Donald
  Interface21 Principal Consultant

  http://www.springframework.com

  =20

[Springframework-developer] spring modules/spring projects/spring extensions

[Keith D. <ke...@in...>]

We need to reach a consensus on what to call our core "spring modules"
repository here at sourceforge and the extension "spring modules" repository
over at java.net.

 

Right now we're calling the core stuff "spring projects" - but I'm not sure
about that usage, "modules" seems like such a better name.

 

However, having two "spring modules" is obviously confusing.

 

What about calling the core modules "spring modules" and the work happening
over at java.net "spring extensions"?  That seems like an ideal situation.
What do you think?  Rob? Colin? Juergen?  Would it be possible to rename the
java.net effort or is it too late for that?

 

Thanks,

 

Keith

 

-- 
Keith Donald
Interface21 Principal Consultant

http://www.springframework.com <http://www.springframework.com/> 

 

[Springframework-developer] FAILED BUILD: sparc-solaris1 (last 30 lines included)

[Darren D. <da...@sh...>]

1119137084
FAILED
    [junit] Testcase: testAutowireWithDefault took 0.039 sec
    [junit] Testcase: testAutowireByConstructor took 0.079 sec
    [junit] Testcase: testAutowireByConstructorWithSimpleValues took 0.06 sec
    [junit] Testcase: testConstructorArgResolution took 0.119 sec
    [junit] Testcase: testConstructorArgWithSingleMatch took 0.081 sec
    [junit] Testcase: testThrowsExceptionOnTooManyArguments took 0.057 sec
    [junit] Testcase: testThrowsExceptionOnAmbiguousResolution took 0.082 sec
    [junit] Testcase: testFactoryBeanDefinedAsPrototype took 0.041 sec
    [junit] Testcase: testDependsOn took 0.238 sec
    [junit] Testcase: testDependsOnInInnerBean took 0.091 sec
    [junit] Testcase: testDependenciesThroughConstructorArguments took 0.036 sec
    [junit] Testcase: testDependenciesThroughConstructorArgumentAutowiring took 0.04 sec
    [junit] Testcase: testDependenciesThroughConstructorArgumentsInInnerBean took 0.043 sec
    [junit] Testcase: testDependenciesThroughProperties took 0.044 sec
    [junit] Testcase: testDependenciesThroughPropertiesWithInTheMiddle took 0.092 sec
    [junit] Testcase: testDependenciesThroughPropertyAutowiringByName took 0.052 sec
    [junit] Testcase: testDependenciesThroughPropertyAutowiringByType took 0.042 sec
    [junit] Testcase: testDependenciesThroughPropertiesInInnerBean took 0.053 sec
    [junit] Testcase: testClassNotFoundWithDefault took 0.038 sec
    [junit] Testcase: testClassNotFoundWithNoBeanClassLoader took 0.035 sec
    [junit] Testcase: testResourceAndInputStream took 0.145 sec
    [junit] Testcase: testClassPathResourceWithImport took 0.071 sec
    [junit] Testcase: testUrlResourceWithImport took 0.068 sec
    [junit] Testcase: testFileSystemResourceWithImport took 0.065 sec
    [junit] Testcase: testLookupOverrideMethodsWithSetterInjection took 1.985 sec
    [junit] 	FAILED
    [junit] null
    [junit] junit.framework.AssertionFailedError
    [junit] 	at org.springframework.beans.factory.xml.XmlBeanFactoryTests.testLookupOverrideMethodsWithSetterInjection(XmlBeanFactoryTests.java:879)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] spring build.286 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050619001703Lbuild.286

Re: [Springframework-developer] Internal use of deprecated methods

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

Good point: those should indeed use the new methods. I've just fixed all
such uses of beanNamesIncludingAncestors and related methods.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Erwin Vervaet
Sent: Saturday, June 18, 2005 6:37 PM
To: spr...@li...
Subject: [Springframework-developer] Internal use of deprecated methods


I was wondering whether or not the framework should use it's own deprecated
methods. For instance, on line 402 of ProxyFactoryBean we find:

String[] globalAdvisorNames =
BeanFactoryUtils.beanNamesIncludingAncestors(beanFactory, Advisor.class);

And the "beanNamesIncludingAncestors" method of BeanFactoryUtils is
deprecated. We could rewrite this using the new prefered method:

String[] globalAdvisorNames =
BeanFactoryUtils.beanNamesForTypeIncludingAncestors(beanFactory,
Advisor.class);

Is there a particular reason to keep using the old deprecated method?

Erwin Vervaet
erw...@er...



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Internal use of deprecated methods

[Erwin V. <erw...@er...>]

I was wondering whether or not the framework should use it's own deprecated 
methods. For instance, on line 402 of ProxyFactoryBean we find:

String[] globalAdvisorNames = 
BeanFactoryUtils.beanNamesIncludingAncestors(beanFactory, Advisor.class);

And the "beanNamesIncludingAncestors" method of BeanFactoryUtils is 
deprecated. We could rewrite this using the new prefered method:

String[] globalAdvisorNames = 
BeanFactoryUtils.beanNamesForTypeIncludingAncestors(beanFactory, 
Advisor.class);

Is there a particular reason to keep using the old deprecated method?

Erwin Vervaet
erw...@er...