flashUtilityService and parentBean

[Tom Chiverton]

It looks like if I have many RemoteFactoryBean's that all extend the
same parent (abstract=true) bean, they all get the same
flashUtilityService applied to them, even when this property is only
set on a few of the concrete RemoteFactoryBean defs.

Has anyone else run into this ?

The reason I think that is what is going on is that
<bean id="abstractRemoteProxy" class="" abstract="true">
<property name="beanFactoryScope">
<value>application</value>
</property>
<property name="beanFactoryName">
<value>beanFactory</value>
</property>
<!-- location to the physical proxy component -->
<property name="relativePath">
<value>/com/halliwells/CFCs/fraud/service/</value>
</property>
</bean>
<bean id="remoteEnvironmentService"
class="coldspring.aop.framework.RemoteFactoryBean"
parent="abstractRemoteProxy">
<property name="target">
<ref bean="environmentManager" />
</property>
<property name="interceptorNames">
<list>
<value>securityAdvisor</value>
<value>flexRemoteAdvice</value>
</list>
</property>
<property name="serviceName">
<value>EnvironmentService</value>
</property>
<property name="remoteMethodNames">
<value>*</value>
</property>
</bean>

Gets the utility service invoked from about child of the parent. If I
create an identical abstract bean (called abstractRemoteProxy2) and
give that to the remoteEnvironmentService bean then the
flashUtilityService is never called - i.e. just changing the parent
bean instance makes the error go away.

Should this behaviour be happening ? Do I need to make the parent bean
singleton=false or something ?

--
Tom

[Tom Chiverton]

Sorry, forgot to say this is the 1.2 RC1 version.
--
Tom

[Brian Kotek]

Is that the latest from CVS Tom? There were some bugs in the way the parent bean attributes got built up for the children that I fixed a little while back.

[Tom Chiverton]

2008/8/1 Brian Kotek <bria...@gmail.com>:

> Is that the latest from CVS Tom?

>> Sorry, forgot to say this is the 1.2 RC1 version.

Is there more than one 1.2 RC1 ?

--
Tom, puzzled

[Brian Kotek]

To be honest right now I have no idea what "1.2 RC1" incorporates, I'm just using the latest code from CVS. The bleeding edge download should be the same as what is in CVS also.

[Tom Chiverton]

2008/8/1 Brian Kotek <bria...@gmail.com>:

> To be honest right now I have no idea what "1.2 RC1" incorporates, I'm just
> using the latest code from CVS. The bleeding edge download should be the
> same as what is in CVS also.

Fair enough :-)
I've got the nightly and 1.2 RC1 downloads here, so will try and make
up a test case.

--
Tom

[Tom Chiverton]

2008/8/1 Tom Chiverton <tom.ch...@gmail.com>:

> I've got the nightly and 1.2 RC1 downloads here, so will try and make
> up a test case.

Hmm, I can't seem to replicate what I saw at work in a simpler test
case at home.
Bah, curse of the bug :-)

--
Tom

[Qasim Rasheed]

OT but is there a plan to make an official release in near future. I've to struggle hard to get 1.2RC on our servers as our Sysadmin will not allow any RC version of frameworks on servers?

Thanks

Qasim

[Brian Kotek]

It keeps coming up but we keep not actually doing it. I will ping Chris and Dave and see if we just go ahead and do it, since as far as I know what is in CVS is ready for release (enough people are using it in production!).

[James Holmes]

Please do try - I'd also like to update our standard version and
people will be happier to go with a new stable release.

On Sat, Aug 2, 2008 at 12:23 PM, Brian Kotek <bria...@gmail.com> wrote:
> It keeps coming up but we keep not actually doing it. I will ping Chris and
> Dave and see if we just go ahead and do it, since as far as I know what is
> in CVS is ready for release (enough people are using it in production!).
>
> On Fri, Aug 1, 2008 at 10:29 PM, Qasim Rasheed <qasim...@gmail.com>
> wrote:
>>
>> OT but is there a plan to make an official release in near future. I've to
>> struggle hard to get 1.2RC on our servers as our Sysadmin will not allow any
>> RC version of frameworks on servers?

--
mxAjax / CFAjax docs and other useful articles:
http://www.bifrost.com.au/blog/

[Qasim Rasheed]

Brian,

Thanks for the effort.

[Tom Chiverton]

2008/8/2 Brian Kotek <bria...@gmail.com>:

> in CVS is ready for release (enough people are using it in production!).

We just upgraded the main corporate site and all our extranet's to 1.2
RC1, and it caused no issues at all.

--
Tom

[Tom Chiverton]

2008/8/1 Tom Chiverton <tom.ch...@gmail.com>:

Hmm.
Another way to make the apperent conflict go away at work is to remove

<property name="beanFactoryScope">
<value>application</value>
</property>
<property name="beanFactoryName">
<value>beanFactory</value>
</property>

from the abstractRemoteProxy (as these are the defaults anyway).

I can only suggest it must be something very subtle somewhere in CS or our code.
I've attached a patch for a minor issue VarScoper found in bug
#CSP-104, but it doesn't appear to make a difference - I still have to
remove the two properties above.
Odd.

--
Tom

[Tom Chiverton]

2008/8/4 Tom Chiverton <tom.ch...@gmail.com>:

> Another way to make the apperent conflict go away at work is to remove
> <property name="beanFactoryScope">
> <value>application</value>
> </property>
> <property name="beanFactoryName">
> <value>beanFactory</value>
> </property>
> from the abstractRemoteProxy (as these are the defaults anyway).

Nope, not, this was just hiding the problem, my bad.

--
Tom