Grzegorz Kossakowski schrieb:
I hope to commit some basic (without caching implemented) code within days. It
took me quite a long time to clarify
whole idea...
Great!
You mentioned that you play with Dojo. I have some troubles with fixing upload
progress sample from Forms. I guess it's
clea
Alexander Klimetschek wrote:
Reinhard Poetz schrieb:
After thinking more about this, I believe that one main distinction is
that cocoon-rcl creates an environment which is used at development
time. Alex' solution is used in production too, IIUC.
It's actually not that important to have reload
Alexander Klimetschek napisał(a):
> Great, I'd love to have a postable source. How far are you? I could help
> you in testing it next week, when I have our webapp running with Cocoon
> trunk (going from dojo 0.3.1 to 0.4.1 is quite some work...).
> Specifically I want to reuse lots of styling pipel
Reinhard Poetz schrieb:
After thinking more about this, I believe that one main distinction is
that cocoon-rcl creates an environment which is used at development
time. Alex' solution is used in production too, IIUC.
It's actually not that important to have reloading for the shielded
servlets
Alexander Klimetschek napisał(a):
>
> I find the wiki much more easier to find/use than the daisy
> documentation, eg. I have a full text search - although most of its
> content is quite old. No one outside of the developer mailinglist knows
> about the cocoon.zones.apache.org website and the dais
Daniel Fagerstrom schrieb:
You are supposed to be able to use the ShieldingServletService,
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-components/src/main/java/org/apache/cocoon/servletservice/shielding/ShieldingServletService.java,
with a or
Reinhard Poetz schrieb:
Daniel Fagerstrom wrote:
Becoming even vaguer: could such a shielding classloader interceptor
somehow use the reloading classloader from cocoon-rcl?
TBH, I have no idea ATM, but I will look into Alex' work when I make
cocoon-rcl ready for a release.
FYI: The Shieldin
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Daniel Fagerstrom wrote:
I also had some idea that the shielding stuff seem to be rather
orthogonal to the servlet service stuff. So maybe it would be better
to reimplement it as an interceptor that is applied before the
s
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Daniel Fagerstrom wrote:
I also had some idea that the shielding stuff seem to be rather
orthogonal to the servlet service stuff. So maybe it would be better
to reimplement it as an interceptor that is applied before the
servlet service proxy.
Reinhard Poetz skrev:
Daniel Fagerstrom wrote:
I also had some idea that the shielding stuff seem to be rather
orthogonal to the servlet service stuff. So maybe it would be better
to reimplement it as an interceptor that is applied before the
servlet service proxy.
+1
Becoming even vaguer:
Daniel Fagerstrom wrote:
I also had some idea that the shielding stuff seem to be rather
orthogonal to the servlet service stuff. So maybe it would be better to
reimplement it as an interceptor that is applied before the servlet
service proxy.
+1
--
Reinhard Pötz Independent Consu
Alexander Klimetschek skrev:
Hi Servlet Hackers,
I am switching from our old block servlet config to the current servlet
services in trunk and have problems with the configuration. I have two
problems:
1)
Seem to be handled later in the thread.
2)
How to configure the ShieldingServletSer
Grzegorz Kossakowski schrieb:
For now, just digging into the code is the only option IMO.
Ok, I will have a look at it next week.
> I'm busy with other stuff (postable source especially) so will not
be able to do this.
Great, I'd love to have a postable source. How far are you? I could help
Alexander Klimetschek napisał(a):
Grzegorz Kossakowski schrieb:
I could easily create the patch for the warning message.
Regarding the other solution (automatically resolving the circular dep
and thus allowing it): I would now agree to skip this. A bit of
research showed that generic circular
Grzegorz Kossakowski schrieb:
Alexander Klimetschek napisał(a):
Yes, this would indeed be better. The super block must not know of its
concrete children, but be able to call polymorphic matchers - true OO.
Then I can remove the cyclic dep.
Alex
BTW: When I started to use blocks and especially
Alexander Klimetschek napisał(a):
>
> Yes, this would indeed be better. The super block must not know of its
> concrete children, but be able to call polymorphic matchers - true OO.
> Then I can remove the cyclic dep.
>
> Alex
>
> BTW: When I started to use blocks and especially using the inheri
Rice Yeh napisał(a):
> The idea directly applies to OO's inheritance definition. However,
> it might not be easy to implement because it is hard to define "the
> looked-up resource does not exist in the extending servlet." Take
> flowscript as example, it is usually a javascript error when calling
Grzegorz Kossakowski schrieb:
In short: I mean that super should work as fallback mechanism. I guess
it does not work that way now. However, this would eliminate need for
circular dependencies and give cleaner design.
What do you think?
Yes, this would indeed be better. The super block must
On 4/4/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote:
Alexander Klimetschek napisał(a):
> Grzegorz Kossakowski schrieb:
>
> We do need the circular dependency: the basic principle is a super
> block that runs cforms that are mainly defined in a child block - the
> model lies in the child bl
Alexander Klimetschek napisał(a):
Grzegorz Kossakowski schrieb:
We do need the circular dependency: the basic principle is a super
block that runs cforms that are mainly defined in a child block - the
model lies in the child block and it contains a selection-list whose
source is block:child:/
Grzegorz Kossakowski schrieb:
My opinion is that circular dependencies should not be allowed and I
agree that more meaningful exception is needed here.
We do need the circular dependency: the basic principle is a super block
that runs cforms that are mainly defined in a child block - the model
Alexander Klimetschek napisał(a):
Oh, I got it: there was a circular dependency in the servlet connections
(A using B, B using A as super). It did work with the old block
servlets, but now you get the very unhelpful exception. I don't think we
actually need this circular connection in particula
Oh, I got it: there was a circular dependency in the servlet connections (A
using B, B using A as super). It did work with the old block servlets, but
now you get the very unhelpful exception. I don't think we actually need
this circular connection in particular. But generally, two solutions are
Further debugging shows that the method ServletFactoryBean.getObject() is
called by Spring (DefaultListableBeanFactory.getObjectFromFactoryBean(...))
*before* the embeddedServlet or any other property was set. So
embeddedServlet is null, which makes the code inside getObject() fail:
public
Hi Servlet Hackers,
I am switching from our old block servlet config to the current servlet
services in trunk and have problems with the configuration. I have two problems:
1)
I changed the spring configuration to look like the following snippet, but I
get an exception (see below). Debugging
25 matches
Mail list logo
