|
@Configuration annotation
Hi
I would like to know if there are any restrictions regarding Configuration annotation.
Is it safe to refactor code with such annotations? By that I mean, move methods to other classes/other packages.
@Configuration(key = "DefaultTcpTransport", node = "/SipService/SipProtocol")
public void setDefaultTCPTransport(Boolean aDefaultTCPTransport) {
defaultTCPTransport = aDefaultTCPTransport;
}
/Adrian
|
|
Re: @Configuration annotation
Adrian Szwej wrote:
> Hi
>
> I would like to know if there are any restrictions regarding
> Configuration annotation.
>
> Is it safe to refactor code with such annotations? By that I mean,
> move methods to other classes/other packages.
>
> @Configuration(key = "DefaultTcpTransport", node =
> "/SipService/SipProtocol")
> public void setDefaultTCPTransport(Boolean aDefaultTCPTransport) {
> defaultTCPTransport = aDefaultTCPTransport;
> }
>
Adrian,
It appears to me that only layers would be able to this by default (from
what I could observe in the code). If some other class needs this
capability, com.ericsson.ssa.config.ConfigFactory needs to be used.
I might be completely wrong though.
regards
sankar
> /Adrian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
RE: Re: @Configuration annotation
Hi Adrian and Sankara,
Indeed layers Managers are when initialized also configured. The idea is
that Layer Managers carry the configuration and layer classes are
initialized from the managers or go to the manager for configuration.
However it is possible to activate a class for configuration at the
ConfigFactory (activateConfiguration method), however I would advise
against, so far we saw no reason to break the above pattern.
Any particular reason to move this annotated setDefaultTCPTransport
method?
Cheers,
Eltjo.
> -----Original Message-----
> From: Sankara.Rao@... [mailto: Sankara.Rao@...]
> Sent: Friday, September 19, 2008 8:28 AM
> To: dev@...
> Subject: Re: @Configuration annotation
>
> Adrian Szwej wrote:
> > Hi
> >
> > I would like to know if there are any restrictions regarding
> > Configuration annotation.
> >
> > Is it safe to refactor code with such annotations? By that I mean,
> > move methods to other classes/other packages.
> >
> > @Configuration(key = "DefaultTcpTransport", node =
> > "/SipService/SipProtocol")
> > public void setDefaultTCPTransport(Boolean
> aDefaultTCPTransport) {
> > defaultTCPTransport = aDefaultTCPTransport;
> > }
> >
>
> Adrian,
>
> It appears to me that only layers would be able to this by
> default (from
> what I could observe in the code). If some other class needs this
> capability, com.ericsson.ssa.config.ConfigFactory needs to be used.
>
> I might be completely wrong though.
>
> regards
> sankar
> > /Adrian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
Re: Re: @Configuration annotation
Hi DialogManager have connection/address information for the container. getVipSipUri() getVipSipsUri() This is used for "stamping" contact and record-route. Additionally there is also direct dependency from ApplicationDispatcher layer to DialogManager layer for getting this uri information. (sip-container external address).
Additionally I am working with new Layer for connection reuse where I will include Recorde-Route Route and Path header where I will need this container address information as well. I was thinking that this address information is misplaced in DialogManager and would like to move it to separate ConnectionUtil class. (Or any other suggested class)
Since we need this info in multiple places and also once multihoming is in place, some of the info would go into this class and have immiediete impact on all the places where needed. (this is not the main reason, but I just mention it)
Anyhow, setDefaultTCPTransport is needed for initial construction of these URI's. I think the pattern is great (conf pattern it self), but from refactoring point of its just not safe since we do have unknown constraints; as you mention, annotation processing for layers only.
Do you still feel that ConfigFactory.instance().activateConfiguration(configurable) is wrong way or can you advice other in this matter? Thanx! /Adrian On Fri, Sep 19, 2008 at 9:07 AM, Eltjo Boersma <eltjo.boersma@...> wrote:
Hi Adrian and Sankara,
Indeed layers Managers are when initialized also configured. The idea is
that Layer Managers carry the configuration and layer classes are
initialized from the managers or go to the manager for configuration.
However it is possible to activate a class for configuration at the
ConfigFactory (activateConfiguration method), however I would advise
against, so far we saw no reason to break the above pattern.
Any particular reason to move this annotated setDefaultTCPTransport
method?
Cheers,
Eltjo.
> -----Original Message-----
> From: Sankara.Rao@... [mailto: Sankara.Rao@...]
> Sent: Friday, September 19, 2008 8:28 AM
> To: dev@...
> Subject: Re: @Configuration annotation
>
> Adrian Szwej wrote:
> > Hi
> >
> > I would like to know if there are any restrictions regarding
> > Configuration annotation.
> >
> > Is it safe to refactor code with such annotations? By that I mean,
> > move methods to other classes/other packages.
> >
> > @Configuration(key = "DefaultTcpTransport", node =
> > "/SipService/SipProtocol")
> > public void setDefaultTCPTransport(Boolean
> aDefaultTCPTransport) {
> > defaultTCPTransport = aDefaultTCPTransport;
> > }
> >
>
> Adrian,
>
> It appears to me that only layers would be able to this by
> default (from
> what I could observe in the code). If some other class needs this
> capability, com.ericsson.ssa.config.ConfigFactory needs to be used.
>
> I might be completely wrong though.
>
> regards
> sankar
> > /Adrian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
RE: Re: Re: @Configuration annotation
Hi
Adrian,
If you
look at the DialogManager Vip methods, you see that they make use of m_URI
fields, these are initialized (and dynamic reconfigured) using the
SipBindingResolver.
This
SipBindingResolver is the one who is (should be) incharge of all sip addresses
and has as task to keep track of all the changes on address level. I.e. the
GrizzlyNetworkManager makes use of the SipBindingResolver to get informed on any
changes in the sip-listeners configuration and opens, updates and closes ports
accordingly.
The
SipBindingResolver also keeps track of the sip-container.external-address/ports
changes and you can get informed about them, (this is called the
PUBLIC_BINDING_CTX). That is wat the DialogManager does
currently.
Whether the DialogManager is the best one to provide the
Vip url info to other parts of the Sip stack, I don't
know. However I would like to see that SipBindingResolver is kept being
used whenever a sip stack (or other module that depends on the
sip-stack module) class needs to know about addressing
information (sip-listeners, external-address). So your new layer can make
use of the facilities provided by the SipBindingResolver
directly.
It
make sense I thing to keep track in your 'Connection' which sip-listener was
involved (this is called a SipBindingCtx in the SipBindingResolver) and listens
to any changes on it, so that the connection can be closed / reset, when the
configuration changes.
Note that I only added the configuration on existing fields, so the
choice for location of the field was not mine.
Do you still feel that
ConfigFactory.instance().activateConfiguration(configurable) is wrong way or can
you advice other in this matter?
Sure there are pros and cons for the the pattern with the
layer managers, and how I look towards patterns is that they are not written in
blood. As you can see from my previous comments the @Configuration is not the
only part of the confiuration facility, both the annotation and the
SipBindingResolver are build ontop of a generic Config api. Actually the
annotation is for convinience, but as with the annotations in EJB 3.0 they come
with rules. But you mentiond that you are adding a new layer, so
also a new LayerManager, wouldn't it be possible to have
that one carry your 'layer' configuration.
Cheers,
Eltjo.
Hi DialogManager have connection/address information for
the container. getVipSipUri() getVipSipsUri() This is used for
"stamping" contact and record-route. Additionally there is also direct
dependency from ApplicationDispatcher layer to DialogManager layer for getting
this uri information. (sip-container external address). Additionally I am
working with new Layer for connection reuse where I will include Recorde-Route
Route and Path header where I will need this container address information as
well. I was thinking that this address information is misplaced in
DialogManager and would like to move it to separate ConnectionUtil class. (Or
any other suggested class) Since we need this info in multiple places
and also once multihoming is in place, some of the info would go into this
class and have immiediete impact on all the places where needed. (this is not
the main reason, but I just mention it) Anyhow, setDefaultTCPTransport
is needed for initial construction of these URI's. I think the pattern
is great (conf pattern it self), but from refactoring point of its just not
safe since we do have unknown constraints; as you mention, annotation
processing for layers only. Do you still feel that
ConfigFactory.instance().activateConfiguration(configurable) is wrong way or
can you advice other in this matter? Thanx! /Adrian
On Fri, Sep 19, 2008 at 9:07 AM, Eltjo Boersma <eltjo.boersma@...>
wrote:
Hi
Adrian and Sankara,
Indeed layers Managers are when initialized also
configured. The idea is
that Layer Managers carry the configuration and
layer classes are
initialized from the managers or go to the manager for
configuration.
However it is possible to activate a class for
configuration at the
ConfigFactory (activateConfiguration method),
however I would advise
against, so far we saw no reason to break the
above pattern.
Any particular reason to move this annotated
setDefaultTCPTransport
method?
Cheers,
Eltjo.
> -----Original Message----- > From:
Sankara.Rao@... [mailto: Sankara.Rao@...] > Sent:
Friday, September 19, 2008 8:28 AM > To: dev@...>
Subject: Re: @Configuration annotation > > Adrian Szwej
wrote: > > Hi > > > > I would like to know if
there are any restrictions regarding > > Configuration
annotation. > > > > Is it safe to refactor code with such
annotations? By that I mean, > > move methods to other
classes/other packages. > > > > @Configuration(key =
"DefaultTcpTransport", node = > >
"/SipService/SipProtocol") > > public void
setDefaultTCPTransport(Boolean > aDefaultTCPTransport) { > >
defaultTCPTransport =
aDefaultTCPTransport; > > } >
> > > Adrian, > > It appears to me that only
layers would be able to this by > default (from > what I could
observe in the code). If some other class needs this >
capability, com.ericsson.ssa.config.ConfigFactory needs to be
used. > > I might be completely wrong though. > >
regards > sankar > > /Adrian > > >
--------------------------------------------------------------------- >
To unsubscribe, e-mail: dev-unsubscribe@...>
For additional commands, e-mail: dev-help@...> > --------------------------------------------------------------------- To
unsubscribe, e-mail: dev-unsubscribe@...For
additional commands, e-mail: dev-help@...
|
|
Re: Re: Re: @Configuration annotation
Eltjo Thanx for clarifying this. Then I think these two getVipSip() method can easily be moved into that
SipBindingResolver class including
setDefaultTCPTransport. By changing the names and letting other classes using them and making dependency to that class. "/SipService/SipProtocol" is the config root level for that parameter and that is where SipBidningResolver manages its config.
/Adrian. On Fri, Sep 19, 2008 at 2:08 PM, Eltjo Boersma <eltjo.boersma@...> wrote:
Hi
Adrian,
If you
look at the DialogManager Vip methods, you see that they make use of m_URI
fields, these are initialized (and dynamic reconfigured) using the
SipBindingResolver.
This
SipBindingResolver is the one who is (should be) incharge of all sip addresses
and has as task to keep track of all the changes on address level. I.e. the
GrizzlyNetworkManager makes use of the SipBindingResolver to get informed on any
changes in the sip-listeners configuration and opens, updates and closes ports
accordingly.
The
SipBindingResolver also keeps track of the sip-container.external-address/ports
changes and you can get informed about them, (this is called the
PUBLIC_BINDING_CTX). That is wat the DialogManager does
currently.
Whether the DialogManager is the best one to provide the
Vip url info to other parts of the Sip stack, I don't
know. However I would like to see that SipBindingResolver is kept being
used whenever a sip stack (or other module that depends on the
sip-stack module) class needs to know about addressing
information (sip-listeners, external-address). So your new layer can make
use of the facilities provided by the SipBindingResolver
directly.
It
make sense I thing to keep track in your 'Connection' which sip-listener was
involved (this is called a SipBindingCtx in the SipBindingResolver) and listens
to any changes on it, so that the connection can be closed / reset, when the
configuration changes.
Note that I only added the configuration on existing fields, so the
choice for location of the field was not mine.
Do you still feel that
ConfigFactory.instance().activateConfiguration(configurable) is wrong way or can
you advice other in this matter?
Sure there are pros and cons for the the pattern with the
layer managers, and how I look towards patterns is that they are not written in
blood. As you can see from my previous comments the @Configuration is not the
only part of the confiuration facility, both the annotation and the
SipBindingResolver are build ontop of a generic Config api. Actually the
annotation is for convinience, but as with the annotations in EJB 3.0 they come
with rules. But you mentiond that you are adding a new layer, so
also a new LayerManager, wouldn't it be possible to have
that one carry your 'layer' configuration.
Cheers,
Eltjo.
From: Adrian Szwej
[mailto:adrian.szwej@...]
Sent: Friday, September 19, 2008
10:15 AMSubject: Re: Re:
@Configuration annotation
Hi DialogManager have connection/address information for
the container. getVipSipUri() getVipSipsUri() This is used for
"stamping" contact and record-route. Additionally there is also direct
dependency from ApplicationDispatcher layer to DialogManager layer for getting
this uri information. (sip-container external address). Additionally I am
working with new Layer for connection reuse where I will include Recorde-Route
Route and Path header where I will need this container address information as
well. I was thinking that this address information is misplaced in
DialogManager and would like to move it to separate ConnectionUtil class. (Or
any other suggested class) Since we need this info in multiple places
and also once multihoming is in place, some of the info would go into this
class and have immiediete impact on all the places where needed. (this is not
the main reason, but I just mention it) Anyhow, setDefaultTCPTransport
is needed for initial construction of these URI's. I think the pattern
is great (conf pattern it self), but from refactoring point of its just not
safe since we do have unknown constraints; as you mention, annotation
processing for layers only. Do you still feel that
ConfigFactory.instance().activateConfiguration(configurable) is wrong way or
can you advice other in this matter? Thanx! /Adrian
On Fri, Sep 19, 2008 at 9:07 AM, Eltjo Boersma <eltjo.boersma@...>
wrote:
Hi
Adrian and Sankara,
Indeed layers Managers are when initialized also
configured. The idea is
that Layer Managers carry the configuration and
layer classes are
initialized from the managers or go to the manager for
configuration.
However it is possible to activate a class for
configuration at the
ConfigFactory (activateConfiguration method),
however I would advise
against, so far we saw no reason to break the
above pattern.
Any particular reason to move this annotated
setDefaultTCPTransport
method?
Cheers,
Eltjo.
> -----Original Message----- > From:
Sankara.Rao@... [mailto: Sankara.Rao@...] > Sent:
Friday, September 19, 2008 8:28 AM > To: dev@...>
Subject: Re: @Configuration annotation > > Adrian Szwej
wrote: > > Hi > > > > I would like to know if
there are any restrictions regarding > > Configuration
annotation. > > > > Is it safe to refactor code with such
annotations? By that I mean, > > move methods to other
classes/other packages. > > > > @Configuration(key =
"DefaultTcpTransport", node = > >
"/SipService/SipProtocol") > > public void
setDefaultTCPTransport(Boolean > aDefaultTCPTransport) { > >
defaultTCPTransport =
aDefaultTCPTransport; > > } >
> > > Adrian, > > It appears to me that only
layers would be able to this by > default (from > what I could
observe in the code). If some other class needs this >
capability, com.ericsson.ssa.config.ConfigFactory needs to be
used. > > I might be completely wrong though. > >
regards > sankar > > /Adrian > > >
--------------------------------------------------------------------- >
To unsubscribe, e-mail: dev-unsubscribe@...>
For additional commands, e-mail: dev-help@...> > ---------------------------------------------------------------------
To
unsubscribe, e-mail: dev-unsubscribe@...For
additional commands, e-mail: dev-help@...
|
|
RE: Re: Re: Re: @Configuration annotation
Sorry
for the late response.
But I
am not sure, it depends a bit on the scope of this configuration and the
SipBindingResolvers is not a layer.
For the getVipSip() the
information is already available at the
SipBindingResolver and thus the getVipSip methods could be utility methods
indeed.
But I
thought the setDefaultTCPTransport has a more limited
scope?
Currently the SipBindingResolver reads and monitors the sip-container and
the sip-service.sip-listener(s) only the sip-service.sip-protocol part is
scattered over the layers.
Cheers,
Eltjo.
Eltjo Thanx for clarifying this. Then I think these
two getVipSip() method can easily be moved into that SipBindingResolver class including
setDefaultTCPTransport. By changing the names and letting other classes
using them and making dependency to that
class. "/SipService/SipProtocol" is the config root level for that
parameter and that is where SipBidningResolver manages its
config. /Adrian.
On Fri, Sep 19, 2008 at 2:08 PM, Eltjo Boersma <eltjo.boersma@...>
wrote:
Hi
Adrian,
If you look at the
DialogManager Vip methods, you see that they make use of m_URI fields, these
are initialized (and dynamic reconfigured) using the
SipBindingResolver.
This SipBindingResolver is
the one who is (should be) incharge of all sip addresses and has as task to
keep track of all the changes on address level. I.e. the
GrizzlyNetworkManager makes use of the SipBindingResolver to get informed on
any changes in the sip-listeners configuration and opens, updates and closes
ports accordingly.
The SipBindingResolver also
keeps track of the sip-container.external-address/ports changes and you can
get informed about them, (this is called the PUBLIC_BINDING_CTX). That is
wat the DialogManager does currently.
Whether the DialogManager
is the best one to provide the Vip url info to other
parts of the Sip stack, I don't know. However I would like to
see that SipBindingResolver is kept being used whenever a sip
stack (or other module that depends on the sip-stack module) class
needs to know about addressing information (sip-listeners,
external-address). So your new layer can make use of the facilities
provided by the SipBindingResolver
directly.
It make sense I thing to
keep track in your 'Connection' which sip-listener was involved (this is
called a SipBindingCtx in the SipBindingResolver) and listens to any changes
on it, so that the connection can be closed / reset, when the configuration
changes.
Note that I only added the configuration on existing fields, so
the choice for location of the field was not mine.
Do you still feel that
ConfigFactory.instance().activateConfiguration(configurable) is wrong way or
can you advice other in this matter?
Sure there are
pros and cons for the the pattern with the layer managers, and how I look
towards patterns is that they are not written in blood. As you can see from
my previous comments the @Configuration is not the only part of the
confiuration facility, both the annotation and the SipBindingResolver are
build ontop of a generic Config api. Actually the annotation is for
convinience, but as with the annotations in EJB 3.0 they come with rules.
But you mentiond that you are adding a new layer, so also a
new LayerManager, wouldn't it be possible to have that one
carry your 'layer' configuration.
Cheers,
Eltjo.
From: Adrian Szwej [mailto:adrian.szwej@...]
Sent: Friday,
September 19, 2008 10:15 AM
Subject: Re:
Re: @Configuration annotation
Hi DialogManager have connection/address information
for the container. getVipSipUri() getVipSipsUri() This is
used for "stamping" contact and record-route. Additionally there is
also direct dependency from ApplicationDispatcher layer to DialogManager
layer for getting this uri information. (sip-container external
address). Additionally I am working with new Layer for connection reuse
where I will include Recorde-Route Route and Path header where I will need
this container address information as well. I was thinking that
this address information is misplaced in DialogManager and would like to
move it to separate ConnectionUtil class. (Or any other suggested
class) Since we need this info in multiple places and also once
multihoming is in place, some of the info would go into this class and
have immiediete impact on all the places where needed. (this is not the
main reason, but I just mention it) Anyhow, setDefaultTCPTransport
is needed for initial construction of these URI's. I think the
pattern is great (conf pattern it self), but from refactoring point of its
just not safe since we do have unknown constraints; as you mention,
annotation processing for layers only. Do you still feel that
ConfigFactory.instance().activateConfiguration(configurable) is wrong way
or can you advice other in this matter? Thanx! /Adrian
On Fri, Sep 19, 2008 at 9:07 AM, Eltjo Boersma
<eltjo.boersma@...> wrote:
Hi
Adrian and Sankara,
Indeed layers Managers are when initialized
also configured. The idea is
that Layer Managers carry the
configuration and layer classes are
initialized from the managers or
go to the manager for configuration.
However it is possible to
activate a class for configuration at the
ConfigFactory
(activateConfiguration method), however I would advise
against, so
far we saw no reason to break the above pattern.
Any particular
reason to move this annotated
setDefaultTCPTransport
method?
Cheers,
Eltjo.
> -----Original Message----- > From:
Sankara.Rao@... [mailto: Sankara.Rao@...] > Sent: Friday, September
19, 2008 8:28 AM > To: dev@...> Subject: Re:
@Configuration annotation > > Adrian Szwej wrote: >
> Hi > > > > I would like to know if there are any
restrictions regarding > > Configuration annotation. >
> > > Is it safe to refactor code with such annotations? By
that I mean, > > move methods to other classes/other
packages. > > > > @Configuration(key =
"DefaultTcpTransport", node = > >
"/SipService/SipProtocol") > > public void
setDefaultTCPTransport(Boolean > aDefaultTCPTransport) { >
> defaultTCPTransport =
aDefaultTCPTransport; > > } >
> > > Adrian, > > It appears to me that only
layers would be able to this by > default (from > what I
could observe in the code). If some other class needs this >
capability, com.ericsson.ssa.config.ConfigFactory needs to be
used. > > I might be completely wrong
though. > > regards > sankar > >
/Adrian > > >
--------------------------------------------------------------------- >
To unsubscribe, e-mail: dev-unsubscribe@...> For
additional commands, e-mail: dev-help@...> > --------------------------------------------------------------------- To
unsubscribe, e-mail: dev-unsubscribe@...For additional
commands, e-mail: dev-help@...
|
