Re: [osgi-dev] Angular New Enroute

[David Leangen via osgi-dev]

Hi,

Angular 2+ works very differently from AngularJS. In enRoute (or at least in 
v2, I am not yet familiar with the current enRoute), it used AngularJS. You 
used to be able to just include the JS file, and that was it. Angular 2+ 
requires you to build/compile your application first, so you cannot just ship 
the source code (unless you include some kind of interpreter, but I’ve never 
attempted that).

What we do is build the files at some point during the build process, and ship 
the entire dist directory.

It works for us as a deployment mechanism. Never tried it as a DS component, 
though. Because of the way an Angular 2+ app works, I don’t immediately see how 
you could do that. If you figure it out, I’d be interested in hearing your 
solution. 


Cheers,
=David


> On Aug 4, 2018, at 4:55, Matthews, Kevin via osgi-dev 
>  wrote:
> 
> Hello,
>  
> Has anyone integrated the new angular 2+/6 into the enroute project as a 
> separate UI module/DS component? I have added the contents of my angular src 
> folder into the static folder  of the enroute sample but doesn’t seem to 
> render the static pages. Should I add the entire angular folder to static 
> folder or just the src folder of my angular generate project?
>  
> Kevin Matthews 
> Senior Application Analyst
> First Data, 3975 NW 120 Ave, Coral Springs, FL 33065
> Office: 954-845-4222 | Mobile: 561-465-6694
> 
> kevin.matth...@firstdata.com  | 
> firstdata.com  
>  
> The information in this message may be proprietary and/or confidential, and 
> protected from disclosure. If the reader of this message is not the intended 
> recipient, or an employee or agent responsible for delivering this message to 
> the intended recipient, you are hereby notified that any dissemination, 
> distribution or copying of this communication is strictly prohibited. If you 
> have received this communication in error, please notify First Data 
> immediately by replying to this message and deleting it from your computer.
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org 
> https://mail.osgi.org/mailman/listinfo/osgi-dev 
> 
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] Angular New Enroute

[Matthews, Kevin via osgi-dev]

Hello,

Has anyone integrated the new angular 2+/6 into the enroute project as a 
separate UI module/DS component? I have added the contents of my angular src 
folder into the static folder  of the enroute sample but doesn't seem to render 
the static pages. Should I add the entire angular folder to static folder or 
just the src folder of my angular generate project?

Kevin Matthews
Senior Application Analyst
First Data, 3975 NW 120 Ave, Coral Springs, FL 33065
Office: 954-845-4222 | Mobile: 561-465-6694

kevin.matth...@firstdata.com | 
firstdata.com

The information in this message may be proprietary and/or confidential, and 
protected from disclosure. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any dissemination, 
distribution or copying of this communication is strictly prohibited. If you 
have received this communication in error, please notify First Data immediately 
by replying to this message and deleting it from your computer.
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Extending Services

[Alain Picard via osgi-dev]

Thanks Neil and Tim.

I was able to use the target to avoid the circularity, but my tests so far
are not conclusive. I will keep at it and might have further questions.

Alain


On Fri, Aug 3, 2018 at 8:52 AM Tim Ward  wrote:

> I agree with Neil that, in general, you don’t want to reference a service
> of the same type that you advertise without something to prevent you wiring
> to yourself.
>
> Service properties are a good way to do this, but so is type safety. For
> example does it really make sense for the AppSessionServiceImpl to
> advertise as a CoreSessionService? Would someone looking in the service
> registry for a CoreSessionService really be ok with having the
> ApplicationSessionService come back? In fact, what I’m trying to say is “is
> it really the right thing for these advertised interfaces to extend one
> another?”.
>
> The often stated rule is to prefer composition over inheritance, which the
> implementation is doing here, but the API isn’t. It seems odd to me that an
> “Application specific session service” would also be a “core platform
> session service” as well as a generic session service. You might well have
> some interfaces defining common the methods, but the advertised service
> interfaces really feel like they should be different type hierarchies. At
> this point you would no longer run the risk of wiring to a service that
> isn’t appropriate (for example one application delegating to another
> application seems like a bad idea).
>
> Best Regards,
>
> Tim
>
> On 3 Aug 2018, at 13:41, Neil Bartlett via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> Are these DS components?
>
> I'm not entirely sure what would happen if a component both provides a
> service and binds to the same service type. In theory it might be able to
> bind to itself, especially if it is a lazy (delayed) service component,
> because then the service registration exists before the component is
> activated. But possibly SCR prevents this scenario, I'm not sure.
>
> A safe way to protect against this regardless is to use properties and
> filters. For example the AppSessionServiceImpl can provide the
> SessionService with a property such as app=true. Then it would bind to
> SessionService with a target filter of (!(app=*)).
>
> Neil
>
> On Fri, Aug 3, 2018 at 1:17 PM, Alain Picard via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Facing an issue and looking for the right pattern to apply where I have a
>> service interface that is extended and at run time I want to always run the
>> most appropriate one. Each extension provides additional method to the API.
>>
>> As an example (posted here:
>> https://github.com/castortech/osgi-test-session), there's a
>> CoreSessionService ifc (no direct implementation) that will be used by core
>> part of the code. There is an extension to it (SessionService ifc) that
>> adds some new methods and can be used by common level modules and then we
>> have the AppSessionService that is app specific and can exist for some apps
>> and not for other, which would then rely on the SessionServiceImpl.
>>
>> My issue is that for example the AppSessionServiceImpl needs a reference
>> to the SessionService and this either creates a circular dependency (tried
>> to use the Top/Bottom approach in the seminal Concurrency paper from
>> enRoute) but that is not working so far.
>>
>> Any hints on how to proceed here.
>>
>> Thanks
>> Alain
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Extending Services

[Tim Ward via osgi-dev]

I agree with Neil that, in general, you don’t want to reference a service of 
the same type that you advertise without something to prevent you wiring to 
yourself.

Service properties are a good way to do this, but so is type safety. For 
example does it really make sense for the AppSessionServiceImpl to advertise as 
a CoreSessionService? Would someone looking in the service registry for a 
CoreSessionService really be ok with having the ApplicationSessionService come 
back? In fact, what I’m trying to say is “is it really the right thing for 
these advertised interfaces to extend one another?”. 

The often stated rule is to prefer composition over inheritance, which the 
implementation is doing here, but the API isn’t. It seems odd to me that an 
“Application specific session service” would also be a “core platform session 
service” as well as a generic session service. You might well have some 
interfaces defining common the methods, but the advertised service interfaces 
really feel like they should be different type hierarchies. At this point you 
would no longer run the risk of wiring to a service that isn’t appropriate (for 
example one application delegating to another application seems like a bad 
idea).

Best Regards,

Tim

> On 3 Aug 2018, at 13:41, Neil Bartlett via osgi-dev  
> wrote:
> 
> Are these DS components?
> 
> I'm not entirely sure what would happen if a component both provides a 
> service and binds to the same service type. In theory it might be able to 
> bind to itself, especially if it is a lazy (delayed) service component, 
> because then the service registration exists before the component is 
> activated. But possibly SCR prevents this scenario, I'm not sure.
> 
> A safe way to protect against this regardless is to use properties and 
> filters. For example the AppSessionServiceImpl can provide the SessionService 
> with a property such as app=true. Then it would bind to SessionService with a 
> target filter of (!(app=*)).
> 
> Neil
> 
> On Fri, Aug 3, 2018 at 1:17 PM, Alain Picard via osgi-dev 
> mailto:osgi-dev@mail.osgi.org>> wrote:
> Facing an issue and looking for the right pattern to apply where I have a 
> service interface that is extended and at run time I want to always run the 
> most appropriate one. Each extension provides additional method to the API.
> 
> As an example (posted here: https://github.com/castortech/osgi-test-session 
> ), there's a 
> CoreSessionService ifc (no direct implementation) that will be used by core 
> part of the code. There is an extension to it (SessionService ifc) that adds 
> some new methods and can be used by common level modules and then we have the 
> AppSessionService that is app specific and can exist for some apps and not 
> for other, which would then rely on the SessionServiceImpl.
> 
> My issue is that for example the AppSessionServiceImpl needs a reference to 
> the SessionService and this either creates a circular dependency (tried to 
> use the Top/Bottom approach in the seminal Concurrency paper from enRoute) 
> but that is not working so far.
> 
> Any hints on how to proceed here.
> 
> Thanks
> Alain
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org 
> https://mail.osgi.org/mailman/listinfo/osgi-dev 
> 
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Extending Services

[Neil Bartlett via osgi-dev]

Are these DS components?

I'm not entirely sure what would happen if a component both provides a
service and binds to the same service type. In theory it might be able to
bind to itself, especially if it is a lazy (delayed) service component,
because then the service registration exists before the component is
activated. But possibly SCR prevents this scenario, I'm not sure.

A safe way to protect against this regardless is to use properties and
filters. For example the AppSessionServiceImpl can provide the
SessionService with a property such as app=true. Then it would bind to
SessionService with a target filter of (!(app=*)).

Neil

On Fri, Aug 3, 2018 at 1:17 PM, Alain Picard via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Facing an issue and looking for the right pattern to apply where I have a
> service interface that is extended and at run time I want to always run the
> most appropriate one. Each extension provides additional method to the API.
>
> As an example (posted here: https://github.com/castortech/
> osgi-test-session), there's a CoreSessionService ifc (no direct
> implementation) that will be used by core part of the code. There is an
> extension to it (SessionService ifc) that adds some new methods and can be
> used by common level modules and then we have the AppSessionService that is
> app specific and can exist for some apps and not for other, which would
> then rely on the SessionServiceImpl.
>
> My issue is that for example the AppSessionServiceImpl needs a reference
> to the SessionService and this either creates a circular dependency (tried
> to use the Top/Bottom approach in the seminal Concurrency paper from
> enRoute) but that is not working so far.
>
> Any hints on how to proceed here.
>
> Thanks
> Alain
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] Extending Services

[Alain Picard via osgi-dev]

Facing an issue and looking for the right pattern to apply where I have a
service interface that is extended and at run time I want to always run the
most appropriate one. Each extension provides additional method to the API.

As an example (posted here: https://github.com/castortech/osgi-test-session),
there's a CoreSessionService ifc (no direct implementation) that will be
used by core part of the code. There is an extension to it (SessionService
ifc) that adds some new methods and can be used by common level modules and
then we have the AppSessionService that is app specific and can exist for
some apps and not for other, which would then rely on the
SessionServiceImpl.

My issue is that for example the AppSessionServiceImpl needs a reference to
the SessionService and this either creates a circular dependency (tried to
use the Top/Bottom approach in the seminal Concurrency paper from enRoute)
but that is not working so far.

Any hints on how to proceed here.

Thanks
Alain
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev