It would be useful if Apostolis Giannakidis can explain the use case behind
this request, now it is a bit abstract to me.
On Wed, Jan 27, 2016 at 4:13 PM, Matt Sicker <boa...@gmail.com> wrote:
> I mean keeping the Node tree to get attributes. It would only work from
> config files (and the config builder classes). We get questions every so
> often about modifying the config programmatically which would either need
> to maintain more Nodes or just be unsupported.
>
> On 27 January 2016 at 09:09, Mikael Ståldal <mikael.stal...@magine.com>
> wrote:
>
> > I don't quite understand what you mean.
> >
> > On Wed, Jan 27, 2016 at 4:02 PM, Matt Sicker <boa...@gmail.com> wrote:
> >
> > > That sounds a little fragile as some people either create or modify
> their
> > > creation directly from the plugin factories.
> > >
> > > On 27 January 2016 at 07:05, Mikael Ståldal <mikael.stal...@magine.com
> >
> > > wrote:
> > >
> > > > Then perhaps we should keep the node tree and expose it for this kind
> > of
> > > > queries, something like this:
> > > >
> > > > String hostname = loggerContext.getConfiguration().
> > > > getAttributesForAppender("syslogAppender").get("host");
> > > >
> > > > This would require a new method in
> > > > org.apache.logging.log4j.core.config.Configuration:
> > > >
> > > > public Map<String, String> getAttributesForAppender(String
> > appenderName);
> > > >
> > > >
> > > >
> > > > On Wed, Jan 27, 2016 at 1:27 PM, Ralph Goers <
> > ralph.go...@dslextreme.com
> > > >
> > > > wrote:
> > > >
> > > > > While I understand your point, the node tree is discarded after the
> > > > > plugins are created. We would have to keep it around for this to
> > work.
> > > > > Furthermore, each component would need to have a reference to its
> > > > > corresponding node, which we obviously don't currently do.
> > > > >
> > > > > Ralph
> > > > >
> > > > > > On Jan 27, 2016, at 2:33 AM, Mikael Ståldal <
> > > mikael.stal...@magine.com
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > To me it does not seems good to force all Appender
> implementations
> > to
> > > > > > implement this. Especially not since the next logical step would
> > then
> > > > be
> > > > > to
> > > > > > do the same with other components such as Layouts. That would be
> a
> > > lot
> > > > of
> > > > > > work in total, and also add more work for all future components,
> > > > > including
> > > > > > 3rd party plugins.
> > > > > >
> > > > > > I think it makes more sense, and would be less work in total, if
> > the
> > > > > > configuration system would store and expose those attributes
> > without
> > > > > > involving the components themselves.
> > > > > >
> > > > > > On Wed, Jan 27, 2016 at 7:14 AM, Gary Gregory <
> > > garydgreg...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >> Apostolis,
> > > > > >>
> > > > > >> You are warmly welcome to contribute to Log4j. You can create a
> > JIRA
> > > > and
> > > > > >> attach a patch in unified diff file format. Unit tests as part
> of
> > > the
> > > > > patch
> > > > > >> are a must IMO. Feel free to flush out any design or
> > implementation
> > > > > here on
> > > > > >> the dev ML.
> > > > > >>
> > > > > >> Thank you!
> > > > > >> Gary
> > > > > >>
> > > > > >> On Tue, Jan 26, 2016 at 5:02 PM, Ralph Goers <
> > > > > ralph.go...@dslextreme.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >>> All the attributes have to have String representations to be
> > usable
> > > > in
> > > > > >> the
> > > > > >>> XML, JSON & Properties configurations. Yes, the Map could
> contain
> > > > > Objects
> > > > > >>> but then every one of them has to be cast to its real object to
> > be
> > > > > >> usable.
> > > > > >>>
> > > > > >>> The map should be read-only because modifying its contents
> would
> > > have
> > > > > no
> > > > > >>> effect on the appender.
> > > > > >>>
> > > > > >>> The map should not be stored in an ivar but constructed
> whenever
> > > the
> > > > > >>> attributes are retrieved. Otherwise it will be temping to just
> > keep
> > > > > them
> > > > > >> in
> > > > > >>> a map and not as individual attributes, which would cause
> > problems.
> > > > > >>>
> > > > > >>> If you have nesting such as MyAppender extends MyBaseAppender
> > > > extends
> > > > > >>> AbstractOutputStreamAppender extends AbstractAppender, I
> > envision a
> > > > > >>> fillAttributes method at each “level” that fills in the
> > attributes
> > > it
> > > > > >> knows
> > > > > >>> about, so fillAttributeMap(map) should always call
> > > > > >>> super.fillAttributeMap(map) - except in AbstractAppender of
> > course
> > > -
> > > > > and
> > > > > >>> should call it before filling in its own attributes so that it
> > can
> > > > > >> override
> > > > > >>> any values provided by the base Appenders. If the primary
> > Appender
> > > > > does
> > > > > >>> not implement fillAttributeMap then only the attributes of its
> > > super
> > > > > >>> classes will be included, which is actually correct for the
> > > > > >> SyslogAppender.
> > > > > >>>
> > > > > >>> Ralph
> > > > > >>>
> > > > > >>>> On Jan 26, 2016, at 5:24 PM, Apostolis Giannakidis <
> > > > > >>> ap.giannaki...@gmail.com> wrote:
> > > > > >>>>
> > > > > >>>> One thing to note here. Correct me if I am wrong, but the map
> > > should
> > > > > >>>> be Map<String,
> > > > > >>>> Object> because not all attributes are Strings. From the top
> of
> > my
> > > > > >> head,
> > > > > >>> I
> > > > > >>>> know that an attribute could also be a boolean.
> > > > > >>>>
> > > > > >>>> On Wed, Jan 27, 2016 at 12:06 AM, Gary Gregory <
> > > > > garydgreg...@gmail.com
> > > > > >>>
> > > > > >>>> wrote:
> > > > > >>>>
> > > > > >>>>> I could see AbstractAppender implementing a getAttributes()
> > > method
> > > > > >> like
> > > > > >>>>> this:
> > > > > >>>>>
> > > > > >>>>> public Map<String, String> getAttributes() {
> > > > > >>>>> Map<String, String> map = new HashMap<>();
> > > > > >>>>> fillAttributeMap(map);
> > > > > >>>>> // (1) should the map be read-only? why?
> > > > > >>>>> // (2) if the map is cached in an ivar, the it must be
> > > > updated
> > > > > >> by
> > > > > >>>>> each appender when an attribute changes, so
> > > > > >>>>> // I'd say no and follow the KISS principle for now.
> > > > > >>>>> return map;
> > > > > >>>>> }
> > > > > >>>>>
> > > > > >>>>> protected void fillAttributeMap(Map<String, String> map) {
> > > > > >>>>> // ...
> > > > > >>>>> }
> > > > > >>>>>
> > > > > >>>>> The boilerplate of creating and/or managing the map can be in
> > > > > >>>>> getAttributes().
> > > > > >>>>> Actually filling in the map in is done in fillAttributeMap()
> > > which
> > > > > >> each
> > > > > >>>>> appender can override.
> > > > > >>>>>
> > > > > >>>>> fillAttributeMap() could be abstract to force each appender
> to
> > > make
> > > > > >> sure
> > > > > >>>>> developers pay attention to providing an implementation.
> > > > > >>>>>
> > > > > >>>>> Gary
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> On Tue, Jan 26, 2016 at 3:46 PM, Apostolis Giannakidis <
> > > > > >>>>> ap.giannaki...@gmail.com> wrote:
> > > > > >>>>>
> > > > > >>>>>> Well, since the idea is to add it to the Appender interface,
> > it
> > > > > means
> > > > > >>>>> that
> > > > > >>>>>> all concrete Appenders need to be modified as well. So,
> yes, I
> > > can
> > > > > >> give
> > > > > >>>>> it
> > > > > >>>>>> a try to implement it for all the Appenders. One other
> simple
> > > way
> > > > > >> would
> > > > > >>>>> be
> > > > > >>>>>> to implement it once in the AbstractAppender so that all its
> > > > > >> subclasses
> > > > > >>>>>> will inherit it.
> > > > > >>>>>>
> > > > > >>>>>> On Tue, Jan 26, 2016 at 9:15 PM, Gary Gregory <
> > > > > >> garydgreg...@gmail.com>
> > > > > >>>>>> wrote:
> > > > > >>>>>>
> > > > > >>>>>>> On Tue, Jan 26, 2016 at 1:06 PM, Apostolis Giannakidis <
> > > > > >>>>>>> ap.giannaki...@gmail.com> wrote:
> > > > > >>>>>>>
> > > > > >>>>>>>> Actually, since this seems to be a useful feature, I would
> > > love
> > > > to
> > > > > >> do
> > > > > >>>>>> the
> > > > > >>>>>>>> patch myself and contribute it to the project, if you
> don't
> > > > mind.
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>> Do you plan on implementing this for all Appenders?
> > > > > >>>>>>>
> > > > > >>>>>>> Gary
> > > > > >>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> On Tue, Jan 26, 2016 at 8:56 PM, Ralph Goers <
> > > > > >>>>>> ralph.go...@dslextreme.com
> > > > > >>>>>>>>
> > > > > >>>>>>>> wrote:
> > > > > >>>>>>>>
> > > > > >>>>>>>>> Actually, I kind of like the idea of adding a
> > getAttributes()
> > > > > >>>>> method
> > > > > >>>>>> to
> > > > > >>>>>>>>> the Appender interface. Then each concrete Appender would
> > do:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> public void getAttributes() {
> > > > > >>>>>>>>> Map<String, String> attributes = new HashMap<>();
> > > > > >>>>>>>>> super.getAttributes(attributes):
> > > > > >>>>>>>>> attributes.put(“myAttribute1”, “value1”);
> > > > > >>>>>>>>> return Collections.unmodifiableMap(attributes);
> > > > > >>>>>>>>> }
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> On Jan 26, 2016, at 1:28 PM, Gary Gregory <
> > > > > >>>>> garydgreg...@gmail.com>
> > > > > >>>>>>>>> wrote:
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> How about adding getters for the fields
> > > > > >>>>>>>>>> in
> > org.apache.logging.log4j.core.net.AbstractSocketManager?
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> Gary
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> On Tue, Jan 26, 2016 at 12:20 PM, Matt Sicker <
> > > > boa...@gmail.com
> > > > > >
> > > > > >>>>>>>> wrote:
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> You could always use reflection to access it for now.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> On 26 January 2016 at 14:17, Apostolis Giannakidis <
> > > > > >>>>>>>>>>> ap.giannaki...@gmail.com
> > > > > >>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> Thank you very much for the prompt reply Ralph.
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> As far as I can see, the SyslogAppender class does not
> > > > expose
> > > > > a
> > > > > >>>>>> way
> > > > > >>>>>>>> to
> > > > > >>>>>>>>>>>> access these attributes. So, if there is no other way
> of
> > > > > >>>>>> accessing
> > > > > >>>>>>>>> these
> > > > > >>>>>>>>>>>> attributes, then I am not able to retrieve the
> > attributes
> > > > that
> > > > > >>>>> I
> > > > > >>>>>>> want
> > > > > >>>>>>>>>>> from
> > > > > >>>>>>>>>>>> the existing SyslogAppender implementation. If I
> > > understand
> > > > > >>>>>>>> correctly,
> > > > > >>>>>>>>>>>> correct me if I am wrong, I might have to create my
> own
> > > that
> > > > > >>>>>>> exposes
> > > > > >>>>>>>>>>> these
> > > > > >>>>>>>>>>>> attributes.
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> Apos
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> On Tue, Jan 26, 2016 at 8:03 PM, Ralph Goers <
> > > > > >>>>>>>>> ralph.go...@dslextreme.com
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> Not exactly. You can do:
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> Appender appender =
> > > > > >>>>>>>>>>> ctx.getConfiguration().getAppender(“syslogAppender”);
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> then you would have to do
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> SyslogAppender syslogAppender = (SyslogAppender)
> > > appender;
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> normally you would probably use instanceof to verify
> it
> > > is
> > > > > >>>>>>> actually
> > > > > >>>>>>>> a
> > > > > >>>>>>>>>>>>> SyslogAppender.
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> Once you have that you can call whatever methods the
> > > > > >>>>>>> SyslogAppender
> > > > > >>>>>>>>>>>>> exposes for getting its attributes. They are not
> stored
> > > in
> > > > a
> > > > > >>>>> Map
> > > > > >>>>>>>>>>> however,
> > > > > >>>>>>>>>>>>> so you can’t just call a generic getAttribute method.
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> Ralph
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> On Jan 26, 2016, at 11:58 AM, Apostolis Giannakidis
> <
> > > > > >>>>>>>>>>>>> ap.giannaki...@gmail.com> wrote:
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> Hello team,
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> I have created a logger with an appender using the
> > > > > >>>>>>>>>>> ConfigurationBuilder
> > > > > >>>>>>>>>>>>> and
> > > > > >>>>>>>>>>>>>> the AppenderComponentBuilder.
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> Let's say that this is how I create my appender:
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> AppenderComponentBuilder appenderBuilder =
> > > > > >>>>>>>>>>>>>> builder.newAppender( "syslogAppender",
> > > > > >>>>> "Syslog" )
> > > > > >>>>>>>>>>>>>> .addAttribute( "protocol", "TCP" )
> > > > > >>>>>>>>>>>>>> .addAttribute( "host", "localhost" )
> > > > > >>>>>>>>>>>>>> .addAttribute( "port", 514 )
> > > > > >>>>>>>>>>>>>> .addAttribute( "facility", "LOCAL2" )
> > > > > >>>>>>>>>>>>>> .addAttribute( "immediateFlush", true )
> > > > > >>>>>>>>>>>>>> .addAttribute( "newLine", true );
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> Then, after I finish creating the builder I use the
> > > > > >>>>>>>>>>>>>> Configurator.initialize( builder.build() ) to get
> the
> > > > > >>>>>>>> LoggerContext.
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> Is there any way I can access the attributes of the
> > > > appender
> > > > > >>>>>>>> through
> > > > > >>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>> LoggerContext?
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> For example something like this:
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> LoggerContext ctx = Configurator.initialize(
> > > > builder.build()
> > > > > >>>>> );
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> String hostname =
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> ctx.getConfiguration()..getAppenders().get("syslogAppender").getAttribute("host");
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> Thank you all very much for your help.
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> Apostolis
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>
> > > ---------------------------------------------------------------------
> > > > > >>>>>>>>>>>>> To unsubscribe, e-mail:
> > > > > >>>>>> log4j-user-unsubscr...@logging.apache.org
> > > > > >>>>>>>>>>>>> For additional commands, e-mail:
> > > > > >>>>>>> log4j-user-h...@logging.apache.org
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> --
> > > > > >>>>>>>>>>> Matt Sicker <boa...@gmail.com>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> --
> > > > > >>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > > > >>>>>>>>>> Java Persistence with Hibernate, Second Edition
> > > > > >>>>>>>>>> <http://www.manning.com/bauer3/>
> > > > > >>>>>>>>>> JUnit in Action, Second Edition <
> > > > > >>>>> http://www.manning.com/tahchiev/>
> > > > > >>>>>>>>>> Spring Batch in Action <
> http://www.manning.com/templier/>
> > > > > >>>>>>>>>> Blog: http://garygregory.wordpress.com
> > > > > >>>>>>>>>> Home: http://garygregory.com/
> > > > > >>>>>>>>>> Tweet! http://twitter.com/GaryGregory
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>
> > > > ---------------------------------------------------------------------
> > > > > >>>>>>>>> To unsubscribe, e-mail:
> > > > > log4j-user-unsubscr...@logging.apache.org
> > > > > >>>>>>>>> For additional commands, e-mail:
> > > > > >>>>> log4j-user-h...@logging.apache.org
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>> --
> > > > > >>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > > > >>>>>>> Java Persistence with Hibernate, Second Edition
> > > > > >>>>>>> <http://www.manning.com/bauer3/>
> > > > > >>>>>>> JUnit in Action, Second Edition <
> > > > http://www.manning.com/tahchiev/>
> > > > > >>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
> > > > > >>>>>>> Blog: http://garygregory.wordpress.com
> > > > > >>>>>>> Home: http://garygregory.com/
> > > > > >>>>>>> Tweet! http://twitter.com/GaryGregory
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> --
> > > > > >>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > > > >>>>> Java Persistence with Hibernate, Second Edition
> > > > > >>>>> <http://www.manning.com/bauer3/>
> > > > > >>>>> JUnit in Action, Second Edition <
> > > http://www.manning.com/tahchiev/>
> > > > > >>>>> Spring Batch in Action <http://www.manning.com/templier/>
> > > > > >>>>> Blog: http://garygregory.wordpress.com
> > > > > >>>>> Home: http://garygregory.com/
> > > > > >>>>> Tweet! http://twitter.com/GaryGregory
> > > > > >>>>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > ---------------------------------------------------------------------
> > > > > >>> To unsubscribe, e-mail:
> > log4j-user-unsubscr...@logging.apache.org
> > > > > >>> For additional commands, e-mail:
> > > log4j-user-h...@logging.apache.org
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > > > >> Java Persistence with Hibernate, Second Edition
> > > > > >> <http://www.manning.com/bauer3/>
> > > > > >> JUnit in Action, Second Edition <
> http://www.manning.com/tahchiev/
> > >
> > > > > >> Spring Batch in Action <http://www.manning.com/templier/>
> > > > > >> Blog: http://garygregory.wordpress.com
> > > > > >> Home: http://garygregory.com/
> > > > > >> Tweet! http://twitter.com/GaryGregory
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > [image: MagineTV]
> > > > > >
> > > > > > *Mikael Ståldal*
> > > > > > Senior software developer
> > > > > >
> > > > > > *Magine TV*
> > > > > > mikael.stal...@magine.com
> > > > > > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
> > > > > >
> > > > > > Privileged and/or Confidential Information may be contained in
> this
> > > > > > message. If you are not the addressee indicated in this message
> > > > > > (or responsible for delivery of the message to such a person),
> you
> > > may
> > > > > not
> > > > > > copy or deliver this message to anyone. In such case,
> > > > > > you should destroy this message and kindly notify the sender by
> > reply
> > > > > > email.
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > > > > For additional commands, e-mail:
> log4j-user-h...@logging.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > [image: MagineTV]
> > > >
> > > > *Mikael Ståldal*
> > > > Senior software developer
> > > >
> > > > *Magine TV*
> > > > mikael.stal...@magine.com
> > > > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
> > > >
> > > > Privileged and/or Confidential Information may be contained in this
> > > > message. If you are not the addressee indicated in this message
> > > > (or responsible for delivery of the message to such a person), you
> may
> > > not
> > > > copy or deliver this message to anyone. In such case,
> > > > you should destroy this message and kindly notify the sender by reply
> > > > email.
> > > >
> > >
> > >
> > >
> > > --
> > > Matt Sicker <boa...@gmail.com>
> > >
> >
> >
> >
> > --
> > [image: MagineTV]
> >
> > *Mikael Ståldal*
> > Senior software developer
> >
> > *Magine TV*
> > mikael.stal...@magine.com
> > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
> >
> > Privileged and/or Confidential Information may be contained in this
> > message. If you are not the addressee indicated in this message
> > (or responsible for delivery of the message to such a person), you may
> not
> > copy or deliver this message to anyone. In such case,
> > you should destroy this message and kindly notify the sender by reply
> > email.
> >
>
>
>
> --
> Matt Sicker <boa...@gmail.com>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.stal...@magine.com
Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
