You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Sanjiva Weerawarana <sa...@opensource.lk> on 2006/03/09 18:39:10 UTC
Re: svn commit: r384499 - in
/webservices/axis2/trunk/java/modules:
core/src/org/apache/axis2/deployment/repository/util/
core/src/org/apache/axis2/description/ core/src/org/apache/axis2/engine/
core/test/org/apache/axis2/deployment/ integration/test
On Thu, 2006-03-09 at 22:15 +0600, Ruchith Fernando wrote:
>
> IMHO, for example we should be able to create two instances of the
> _same_ stub within a method and invoke them independently. Before
> modifying those security test cases this is the behaviour that we had.
> Can we make sure we have this behaviour?
Absolutely; I'm confused what's stopping that from happening? Stub
instances are not threads safe but if you take two instances it should
work just fine. Obviously I'm missing something ..
Sanjiva.
Re: svn commit: r384499 - in
/webservices/axis2/trunk/java/modules:
core/src/org/apache/axis2/deployment/repository/util/
core/src/org/apache/axis2/description/ core/src/org/apache/axis2/engine/
core/test/org/apache/axis2/deployment/ integration/test
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+1 to removing it; all that needs to be done is to move the static code
to inside the constructor.
Sanjiva.
On Sat, 2006-03-11 at 16:22 +0600, Ajith Ranabahu wrote:
> Hi all,
> Let me start by explaing why a static AxisService found it's way into
> the stub. A stub is always for a single service and it made perfect
> sense to have a single AxisService object embedded in the stub. This
> has been always the case and all the Axis1 crowd would remember that
> they had a similar static block in the stubs as well.
> However now the problem is this. All the modules engaged for client
> stays in the AxisService embedded in the stub. Since the undelying
> AxisService is static, it prevents the user from assuming that each
> stub instance is independent of each other (they infact share a static
> AxisService and if some modules are engaged to one instance they endup
> engaged into the other as well). As all of you can see this whole
> issue came into being since we use the axis service to handle the
> engaged modules
> As far as I can see we need to use instance variables instead of
> statics. We lose the reusability but in this case resusing is
> theoretically impossible. I have to agree with Deepal in this and my
> guess is that we'll have to remove the static block altogether.
>
> thoughts ?
>
> --
> Ajith Ranabahu
Re: svn commit: r384499 - in /webservices/axis2/trunk/java/modules: core/src/org/apache/axis2/deployment/repository/util/ core/src/org/apache/axis2/description/ core/src/org/apache/axis2/engine/ core/test/org/apache/axis2/deployment/ integration/test
Posted by Davanum Srinivas <da...@gmail.com>.
+1 get rid of it.
-- dims
On 3/11/06, Deepal Jayasinghe <de...@opensource.lk> wrote:
> Hi Ajith ;
>
> Great :)
>
> Not only module engagement , but also parameter modification will have
> the same problem so its better to get rid from the static axisService in
> o.a.... Stub
>
> Ajith Ranabahu wrote:
>
> >Hi all,
> >Let me start by explaing why a static AxisService found it's way into
> >the stub. A stub is always for a single service and it made perfect
> >sense to have a single AxisService object embedded in the stub. This
> >has been always the case and all the Axis1 crowd would remember that
> >they had a similar static block in the stubs as well.
> >However now the problem is this. All the modules engaged for client
> >stays in the AxisService embedded in the stub. Since the undelying
> >AxisService is static, it prevents the user from assuming that each
> >stub instance is independent of each other (they infact share a static
> >AxisService and if some modules are engaged to one instance they endup
> >engaged into the other as well). As all of you can see this whole
> >issue came into being since we use the axis service to handle the
> >engaged modules
> >As far as I can see we need to use instance variables instead of
> >statics. We lose the reusability but in this case resusing is
> >theoretically impossible. I have to agree with Deepal in this and my
> >guess is that we'll have to remove the static block altogether.
> >
> >thoughts ?
> >
> >--
> >Ajith Ranabahu
> >
> >
> >
> >
>
> --
> Thanks,
> Deepal
> ................................................................
> ~Future is Open~
>
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: svn commit: r384499 - in /webservices/axis2/trunk/java/modules:
core/src/org/apache/axis2/deployment/repository/util/ core/src/org/apache/axis2/description/
core/src/org/apache/axis2/engine/ core/test/org/apache/axis2/deployment/
integration/test
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Ajith ;
Great :)
Not only module engagement , but also parameter modification will have
the same problem so its better to get rid from the static axisService in
o.a.... Stub
Ajith Ranabahu wrote:
>Hi all,
>Let me start by explaing why a static AxisService found it's way into
>the stub. A stub is always for a single service and it made perfect
>sense to have a single AxisService object embedded in the stub. This
>has been always the case and all the Axis1 crowd would remember that
>they had a similar static block in the stubs as well.
>However now the problem is this. All the modules engaged for client
>stays in the AxisService embedded in the stub. Since the undelying
>AxisService is static, it prevents the user from assuming that each
>stub instance is independent of each other (they infact share a static
>AxisService and if some modules are engaged to one instance they endup
>engaged into the other as well). As all of you can see this whole
>issue came into being since we use the axis service to handle the
>engaged modules
>As far as I can see we need to use instance variables instead of
>statics. We lose the reusability but in this case resusing is
>theoretically impossible. I have to agree with Deepal in this and my
>guess is that we'll have to remove the static block altogether.
>
>thoughts ?
>
>--
>Ajith Ranabahu
>
>
>
>
--
Thanks,
Deepal
................................................................
~Future is Open~
Re: svn commit: r384499 - in /webservices/axis2/trunk/java/modules: core/src/org/apache/axis2/deployment/repository/util/ core/src/org/apache/axis2/description/ core/src/org/apache/axis2/engine/ core/test/org/apache/axis2/deployment/ integration/test
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi all,
Let me start by explaing why a static AxisService found it's way into
the stub. A stub is always for a single service and it made perfect
sense to have a single AxisService object embedded in the stub. This
has been always the case and all the Axis1 crowd would remember that
they had a similar static block in the stubs as well.
However now the problem is this. All the modules engaged for client
stays in the AxisService embedded in the stub. Since the undelying
AxisService is static, it prevents the user from assuming that each
stub instance is independent of each other (they infact share a static
AxisService and if some modules are engaged to one instance they endup
engaged into the other as well). As all of you can see this whole
issue came into being since we use the axis service to handle the
engaged modules
As far as I can see we need to use instance variables instead of
statics. We lose the reusability but in this case resusing is
theoretically impossible. I have to agree with Deepal in this and my
guess is that we'll have to remove the static block altogether.
thoughts ?
--
Ajith Ranabahu
Re: svn commit: r384499 - in /webservices/axis2/trunk/java/modules:
core/src/org/apache/axis2/deployment/repository/util/ core/src/org/apache/axis2/description/
core/src/org/apache/axis2/engine/ core/test/org/apache/axis2/deployment/
integration/test
Posted by Deepal Jayasinghe <de...@opensource.lk>.
The problem is due to stub keep static axisService instance in it
any way this is wt i encountered
Previously when engage a module if it is already engaged then it
just ignore that , but there was a JIRA in the list and when I fixed
that all the security test case were failing with the exception saying
"trying to engage already engaged module" (that is correct).
As I understood the problem is due to modifying static axisService by
two stub instance in the way that its lead to incorrect behavior.
I think we have to solve this problem , for me I can not understand why
do we need to keep static instance of AxisService inside the stub , my
personal view is we have to get rid of that , and I think Ajith is the
correct person to answer this question.
Sanjiva Weerawarana wrote:
>On Thu, 2006-03-09 at 22:15 +0600, Ruchith Fernando wrote:
>
>
>>IMHO, for example we should be able to create two instances of the
>>_same_ stub within a method and invoke them independently. Before
>>modifying those security test cases this is the behaviour that we had.
>>Can we make sure we have this behaviour?
>>
>>
>
>Absolutely; I'm confused what's stopping that from happening? Stub
>instances are not threads safe but if you take two instances it should
>work just fine. Obviously I'm missing something ..
>
>Sanjiva.
>
>
>
>
>
--
Thanks,
Deepal
................................................................
~Future is Open~