moment
> > of inspiration. If not, supporting two libraries or at least
> configuration
> > modes would seem to be necessary.
> >
> > Another 2 cents.
> >
> > Jonathan
> >
> > > -Original Message-
> > > From: Otho [mailto:taa...@
> > -Original Message-
> > From: Otho [mailto:taa...@googlemail.com]
> > Sent: Saturday, January 03, 2009 10:59
> > To: Tapestry users
> > Subject: Re: spring context troubles
> >
> > Hmm, the question is, how important it is to inject Tapestry IOC
I hope you're starting to see, this is a bigger than "backward
compatibility". This is totally scrapping a huge piece of
functionality. Exposing tapestry services as beans it totally new and
different from exposing my spring beans within tapestry. They serve
totally different purposes, needs
seem to be necessary.
Another 2 cents.
Jonathan
> -Original Message-
> From: Otho [mailto:taa...@googlemail.com]
> Sent: Saturday, January 03, 2009 10:59
> To: Tapestry users
> Subject: Re: spring context troubles
>
> Hmm, the question is, how important it is to inject Tape
Oops, the last line survived the editing. It should have been deleted.
Hmm, the question is, how important it is to inject Tapestry IOC services
into Spring beans compared to just being able to use the Spring beans as
usual.
I would think the latter option is much less effort overall. If I want to
inject something into a spring bean I have to define it as a bean and
Seems like I'm faced with two evils: breaking compatibility on the one
hand, maintaining two different sets of Spring integration on the
other.
On Fri, Jan 2, 2009 at 10:50 AM, Fernando Padilla wrote:
> That's alright to keep them separate, but I'm just worried that the 5.0.18
> will stop working
That's alright to keep them separate, but I'm just worried that the
5.0.18 will stop working at some point..
That is why I proposed that you should really have two different
pacakges.. one for each direction of integration, and people can
explicitly choose which one to use. It just seems kind
Actually, I'm liking the idea that compatibility on this comes from
continuing to use the old version of tapestry-spring. I haven't found
a way to do both: allow injection of Tapestry services into Spring
beans and expose Spring beans as Tapestry services. The lifecycles of
the two containers do no
nice work around. but I want to make sure, this will be a temporary
work around until you get the latest spring module working as you
desire, with two-way integration??
Howard Lewis Ship wrote:
I think the best option for you is to use Tapestry 5.1, but revert
tapestry-spring to 5.0.18. This
I think the best option for you is to use Tapestry 5.1, but revert
tapestry-spring to 5.0.18. This allows you to benefit from the
improvements to tapestry-core without having any compatibility
problems with the changes to tapestry-spring. I'm adding documentation
to the web site to explain this.
I'm sorry that I'm hammering on this code, while it's still probably a
work in progress.. (always available through im)
but I commented out the spring ContextLoaderListener, moved the filter
up to be first, and this seems to initialize properly at least for Jetty
(within eclipse). The next is
but this seems really really flaky, undeterministic and appserver
dependent..
If you really want to create a SpringContext/TapestryIoC love child :)
could you create a new ContextLoaderListener to replace spring's that
does what you want?
So that both the SpringContext and TapestryIoC are lo
On Mon, Dec 29, 2008 at 4:09 PM, Fernando Padilla wrote:
> I was expecting you would be working on this feature, but I really don't
> want to change the way I instantiate my spring context..
>
> Could you hook in something that allows me to turn off this new feature and
> have it be perfectly back
I was expecting you would be working on this feature, but I really don't
want to change the way I instantiate my spring context..
Could you hook in something that allows me to turn off this new feature
and have it be perfectly backward compatible? Or if it finds an already
instantiated Spring
We need to figure out the order that the filters are initialized, so
that the Tapestry filter can be initialized first. I think just
listing it first in the web.xml may do the trick.
On Mon, Dec 29, 2008 at 4:00 PM, Fernando Padilla wrote:
> I just tried it, and it won't work like that :(
>
> Li
I just tried it, and it won't work like that :(
Like I said, I use spring outside of tapestry. So I need a valid
working spring context before the first request ever gets to tapestry
filter..
Here is my exception when I comment out the normal ContextLoaderListener..
[Console output redire
Also, code that expects the ContextLoaderListener will STILL work,
because Tapestry uses the same code, ContextLoader, that CLL does ...
just a little differently.
On Mon, Dec 29, 2008 at 3:40 PM, Fernando Padilla wrote:
> I just tried to run with the latest tapestry-trunk, and I get this
> reall
This is a change in behavior from Tapestry 5.0; it was necessary in
order to coordinate Spring and Tapestry IoC. It is necessary to let
Tapestry initialize Spring and use Tapestry-specific subclasses of
XmlWebApplicationContext and DefaultListableBeanFactory, to hook in
the logic that allows Sprin
I just tried to run with the latest tapestry-trunk, and I get this
really nasty exception :( :(
I initialize my own spring context with a ContextLoaderListener, because
I need spring outside of tapestry. Why is tapestry attempting to create
a context?
2008-12-29 15:18:27,363 [main] ERROR org
I just tried to run with the latest tapestry-trunk, and I get this
really nasty exception :( :(
I initialize my own spring context with a ContextLoaderListener, because
I need spring outside of tapestry. Why is tapestry attempting to create
a context?
2008-12-29 15:18:27,363 [main] ERROR
21 matches
Mail list logo
