Re: CDI?

[ranx]

Weird, I didn't see this last year after you posted it. I don't know why. I 
was up here reading on the latest as I'm going to be doing some prototyping 
with Fuse 7 and wanted to see what latest best practices are and where CDI 
is after the February release date. 

I probably should write a blog/tutorial on this stuff. Using Mockito to 
mock OSGi injection, pojos (not Processors/Exchanges) and using standard 
Camel Java DSLs and CamelTestSupport make testing simple. Part of the 
problem I've found with the Blueprint implementation of Camel is if one 
uses the XML the routes are stuck in the Camel context and can't be broken 
down into sub-routes for easy testing. The CamelRouteBuilder mitigates that 
a lot. So you get an onion peel testing of JUnit for basic handlers, 
Mockito for injecting OSGi mock services, CamelTestSupport for testing the 
wire up of handlers and eips with mock services (you have to use the JNDI 
registry in CamelTestSupport and not the OSGi service registry), and only 
use the CamelBlueprintTestSupport for a general sanity check that 
everything is wired and spelled correctly.

One downside is that I end up using the Camel annotations for injection 
then and not CDI or other standard. A small price I guess...I just keep 
hoping we get the best of all worlds at some point with CDI for easy wire 
up and DS mechanics under the covers.

For CXF services I usually use both SOAP and REST annotations on an 
interface and then use a Camel route with either a recipientList using the 
operation name to specify an immediate endpoint or I use the 
toD(direct"${operationName}") to hit a route (I'm writing that off the top 
of my head so may be misrecalling the variable). However, I've also inject 
OSGi services into the CXF bundle and have every method on the web service 
invoke the same direct: endpoint which has a single bean on it - the 
injected OSGi service. Camel uses reflection to select the correct method 
to invoke. That works as long as the requests are uniquely named. Otherwise 
it's back to using the recipientList or toD variant. That means that Camel 
and CXF live in one bundle and the OSGi service just gets messages. I 
should mention that I usually use canonical domain objects so before the 
OSGi service actually gets invoked I'm transforming using Dozer into a 
canonical domain model. That way I don't get protocol/transport artifacts 
like XMLGregorianCalendar leaking into the rest of the world. 

But I use a variety of messaging and not just web services. That's where 
routing between bundles with Camel can be quite beneficial. I might use 
SEDA (VM) during development or even deployment and use a string 
interpolation injected via @PropertyInject for that endpoint and set it in 
the Blueprint by default but can override it in the pid.cfg file. That way 
if I move a bundle the servicing bundle to another container I can change 
the endpoint to a amq: or whatever else it might be. That's rare. More 
usual reasons for changing it would be if the incoming event or any even is 
transactional and I want to drop it on a persistent queue before returning 
an ACK to the client that things are OK.  

But that use case is what I meant by it being loosely coupled. If I'm using 
SEDA on a route and CXF receives an incoming event, converts the object to 
a domain model sans JAXB/XML elements, and then sends it on an endpoint, I 
don't need to decide what the endpoint is until runtime. Default of SEDA/VM 
for development and then it may or may not be the same when deployed 
depending on where the consuming bundle lives.



On Wednesday, August 16, 2017 at 3:42:13 PM UTC-5, Christian Schneider 
wrote:
>
> On 15.08.2017 16:06, ra...@enjekt.org  wrote:
>
> Christian, 
>
> I've also seen a lot of people using Processors/Exchanges which 
> unnecessarily couples their cod to the Camel framework. Unfortunately the 
> Camel in Action book doesn't get around to advising against that practice 
> until your well over 100 pages into the books. And when it does it is in a 
> bulleted list at the end of a chapter. When I'm at client sites it's one of 
> the first things I teach them when mentoring developers. Use POJOs and unit 
> tests just like any other code. Unfortunately neither the Camel website nor 
> the Camel in Action book stress this and too many code examples use 
> Processor/Exchanges unnecessarily. Honestly, in the past six years, I don't 
> recall the last time I used Camel Processor/Exchange directly. 
>
> I think you are on a very good track with this approach and it would be 
> good to spread the word about it. As you wrote it is not emphasized enough 
> in the camel book. So if you have a blog that would be a great theme.
>
> But services aren't more loosely coupled than messaging. If I have bundle 
> A with all its classes unexported in ".internal" package and bundle B in 
> the same situation 

Re: Failed to load PAX CDI 1.0.0-SNAPSHOT feature

[Tyler Dinh]

Hi Grzegorz,

Thank you for making it happen so quickly. I appreciate it.!

Tyler

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Failed to load PAX CDI 1.0.0-SNAPSHOT feature

[Grzegorz Grzybek]

Hello

I've just:
 – allowed pax-cdi-web to use pax-web 6.0+[1] (instead of 6.1+)
 – lowered features XSD version from 1.5.0 to 1.4.0[2]
 – backported PAXCDI-210 fix to pax-web 6.0.10-SNAPSHOT (and I'm just
finishing integration tests run)

So when pax-cdi 1.0.0 and pax-web 6.0.10 is released, it could be
successfully used in Karaf 4.1+

best regards
Grzegorz Grzybek

===
[1]:
https://github.com/ops4j/org.ops4j.pax.cdi/commit/c24e14da5932d310bbf47b03bbabe357366e7348
[2]:
https://github.com/ops4j/org.ops4j.pax.cdi/commit/13e93f03f4c8d3c1779ed92a465f11ca9cb53ff9

2018-02-15 19:29 GMT+01:00 Tyler Dinh <tyler.d...@gmail.com>:

>  Hi Grzegorz,
>
> Thanks for the quick response. Yes indeed it works with Karaf 4.2.x but
> bear in mind that this is still a milestone 2 release.
> The newer version of the karaf feature bundle does embed v1.5.0 schema.
>
> It would be nice if we could use the PAX-CDI snapshot for trying out with
> existing Karaf 4.1.x. Otherwise I would have to be forking it making
> unnecessary change.
>
>
> Thanks again for your help.
>
> Tyler
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Failed to load PAX CDI 1.0.0-SNAPSHOT feature

[Grzegorz Grzybek]

Hello Tyler, I just took version from Karaf 4.2.0-SNAPSHOT...
The reason is that fixes in pax-cdi required changes in pax-web
6.1.2-SNAPSHOT (extracting "pax-web-core" feature).

And probably I should:
 - downgrade to 1.4.0 version of XSD
 - add pax-web-core feature to pax-web 6.0.10-SNAPSHOT
 - upgrade (at some point) Karaf 4.1.x to pax-web 6.0.10

In the meantime - could you please check with Karaf 4.2.x?

best regards
Grzegorz Grzybek

2018-02-15 0:44 GMT+01:00 Tyler Dinh <tyler.d...@gmail.com>:

> Hello,
>
> I am looking to try out PAX-CDI 1.0.0-SNAPSHOT since it got a few fixes
> from 1.0.0.RC2 but having problem loading it.
> The feature indicates that it is using karaf.feature v1.5.0 schema but
> Karaf 4.1.4 (which PAX CDI depends on) still supports up to v1.4.0.
> I also tried it out on ServiceMix 7.0.1 with same schema issue.
>
> Any reason to update to 1.5.0 schema for the feature.xml? Any
> recommendation how to work around this?
>
> Thanks,
>
> Tyler
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Failed to load PAX CDI 1.0.0-SNAPSHOT feature

[Tyler Dinh]

Hello,

I am looking to try out PAX-CDI 1.0.0-SNAPSHOT since it got a few fixes 
from 1.0.0.RC2 but having problem loading it.
The feature indicates that it is using karaf.feature v1.5.0 schema but 
Karaf 4.1.4 (which PAX CDI depends on) still supports up to v1.4.0.
I also tried it out on ServiceMix 7.0.1 with same schema issue. 

Any reason to update to 1.5.0 schema for the feature.xml? Any 
recommendation how to work around this?

Thanks,

Tyler

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] status (CDI, JSF, pax-web)

[Grzegorz Grzybek]

Hello

2018-02-01 21:23 GMT+01:00 Marc Schlegel <maschle...@gmail.com>:

> Awesome work Grzegorz
>
> Looking forward to a solution to this, even though the use-case in my
> company died.
>

:) Personally, mixing CDI and OSGi is not very good idea... But if it can
be done, I'll try. Currently I'm reviewing all pax-cdi itests and see if
they work with my changes - so far, so good (at least with
pax-exam-container-native) - even some previously @Ignored tests started
working.

The problem (now) is that pax-cdi 1.0.x is generally CDI 1.2, but it's
being aligned with pax-web 6.x, which at the same time has some JDK9
improvements (ASM6 for example). Weld works well with ASM6 (doesn't need it
at all), but It's Openwebbean version 2.x, that's designed for JDK9/ASM6,
but it's CDI 2.0...

Anyway - I'm pretty sure no one would wait for implementing given use case
and no wonder it died ;) My personal favorite was (few years back)
spring-MVC + Thymeleaf, but it's a different story.

best regards
Grzegorz Grzybek


>
> Am Dienstag, 30. Januar 2018 13:13:34 UTC+1 schrieb Grzegorz Grzybek:
>>
>> Actually... I got it working! (MyFaces, Weld, pax-cdi and pax-web-jetty)
>> - it was my fault with proxies for annotations.
>>
>> But "What I had to change" is still valid - I can try proposing a PR with
>> these changes and ask for review.
>>
>> best regards
>> Grzegorz Grzybek
>>
>> 2018-01-30 11:45 GMT+01:00 Grzegorz Grzybek <gr.gr...@gmail.com>:
>>
>>> Hello
>>>
>>> I wanted to share my recent experience related to
>>> https://ops4j1.jira.com/browse/PAXCDI-210 (JSF Beans cannot be
>>> resolved).
>>>
>>> What I wanted to do is to run simple(st) example with @Named,
>>> @RequestScoped managed bean accessible from JSF/facelets/EL.
>>>
>>> After several major changes (which I hate) I got the example working
>>> (which required lots of insight into how it works in plain Tomcat + Weld +
>>> Myfaces), BUT I wasn't able to @Inject a @org.ops4j.pax.cdi.api.Service to
>>> my bean. I gave up after seeing that weld is trying to compare real
>>> annotation class (@org.ops4j.pax.cdi.api.Component) with
>>> com.sun.Proxy...
>>>
>>> What I had to change?
>>>  - in pax-web I had to carefully sort org.ops4j.pax.web.service.jett
>>> y.internal.HttpServiceContext#servletContainerInitializers field, to
>>> ensure that CDI is "run" before JSF
>>>  - in pax-web, I had to disable tldScanning for additional (declared in
>>> *.tld) s and move that part to org.ops4j.pax.web.jsp.JasperIn
>>> itializer
>>>  - org.ops4j.pax.web.service.spi.model.ContextModel#containerInitializers
>>> has to be *linked* hashMap
>>>  - in pax-web event listeners have to be removed in the context of web
>>> app's classloader
>>>  - in pax-web, org.ops4j.pax.web.extender.war
>>> .internal.model.WebApp#addListener() has to skip duplicates (I saw
>>> several other duplicates for listeners, EL resolvers, etc and I didn't have
>>> time to fix it)
>>>  - in pax-cdi, org.ops4j.pax.cdi.spi.Abstract
>>> CdiContainer#contextClassLoader has to be carefully chosen - I checked
>>> that if we're in the context of pax-web, we have to take existing TCCL from
>>> pax-web 
>>> (org.ops4j.pax.web.service.spi.util.ResourceDelegatingBundleClassLoader)
>>> and just add CDI provider bundle to it - otherwise CDI.current() won't work
>>> (JSF won't find it)
>>>  - in pax-cdi only pax-cdi-undertow-weld had correct JSF integration - I
>>> had to move it to pax-cdi-weld (Weld → JSF → EL integration, as described
>>> in http://docs.jboss.org/weld/reference/latest/en-US/html/ri-spi.html,
>>> A.2.4)
>>>  - pax-cdi-jetty-weld didn't pass correct "org.ops4j.pax.cdi.BeanManager"
>>> context attribute
>>>  - weld 2.4.6.Final started to require javax.ejb package - weld
>>> 2.4.5.Final works fine
>>>  - pax-cdi-extensions actually had to export the packages of both
>>> extensions and my sample WAR bundle had to import them explicitly (I used
>>> DynamicImport-Package for pax-cdi, weld and myfaces packages)
>>>
>>> Summarizing - are there any plans to release pax-cdi 1.0.0.GA at some
>>> point? For me we're not there yet - it's still not working well. JSF itself
>>> is IMO a mess full of statics (it's personal opinion, as I've never liked
>>> JSF, so please excuse me) which are not very OSGI friendly.
>>>
>>> I'm also not sure how aries-cdi project goes and at what stage it

Re: [pax-cdi] status (CDI, JSF, pax-web)

[Marc Schlegel]

Awesome work Grzegorz


Am Dienstag, 30. Januar 2018 13:13:34 UTC+1 schrieb Grzegorz Grzybek:
>
> Actually... I got it working! (MyFaces, Weld, pax-cdi and pax-web-jetty) - 
> it was my fault with proxies for annotations.
>
> But "What I had to change" is still valid - I can try proposing a PR with 
> these changes and ask for review.
>
> best regards
> Grzegorz Grzybek
>
> 2018-01-30 11:45 GMT+01:00 Grzegorz Grzybek <gr.gr...@gmail.com 
> >:
>
>> Hello
>>
>> I wanted to share my recent experience related to 
>> https://ops4j1.jira.com/browse/PAXCDI-210 (JSF Beans cannot be resolved).
>>
>> What I wanted to do is to run simple(st) example with @Named, 
>> @RequestScoped managed bean accessible from JSF/facelets/EL.
>>
>> After several major changes (which I hate) I got the example working 
>> (which required lots of insight into how it works in plain Tomcat + Weld + 
>> Myfaces), BUT I wasn't able to @Inject a @org.ops4j.pax.cdi.api.Service to 
>> my bean. I gave up after seeing that weld is trying to compare real 
>> annotation class (@org.ops4j.pax.cdi.api.Component) with com.sun.Proxy...
>>
>> What I had to change?
>>  - in pax-web I had to carefully sort 
>> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext#servletContainerInitializers
>>  
>> field, to ensure that CDI is "run" before JSF
>>  - in pax-web, I had to disable tldScanning for additional (declared in 
>> *.tld) s and move that part to 
>> org.ops4j.pax.web.jsp.JasperInitializer
>>  - org.ops4j.pax.web.service.spi.model.ContextModel#containerInitializers 
>> has to be *linked* hashMap
>>  - in pax-web event listeners have to be removed in the context of web 
>> app's classloader
>>  - in pax-web, 
>> org.ops4j.pax.web.extender.war.internal.model.WebApp#addListener() has to 
>> skip duplicates (I saw several other duplicates for listeners, EL 
>> resolvers, etc and I didn't have time to fix it)
>>  - in pax-cdi, 
>> org.ops4j.pax.cdi.spi.AbstractCdiContainer#contextClassLoader has to be 
>> carefully chosen - I checked that if we're in the context of pax-web, we 
>> have to take existing TCCL from pax-web 
>> (org.ops4j.pax.web.service.spi.util.ResourceDelegatingBundleClassLoader) 
>> and just add CDI provider bundle to it - otherwise CDI.current() won't work 
>> (JSF won't find it)
>>  - in pax-cdi only pax-cdi-undertow-weld had correct JSF integration - I 
>> had to move it to pax-cdi-weld (Weld → JSF → EL integration, as described 
>> in http://docs.jboss.org/weld/reference/latest/en-US/html/ri-spi.html, 
>> A.2.4)
>>  - pax-cdi-jetty-weld didn't pass correct "org.ops4j.pax.cdi.BeanManager" 
>> context attribute
>>  - weld 2.4.6.Final started to require javax.ejb package - weld 
>> 2.4.5.Final works fine
>>  - pax-cdi-extensions actually had to export the packages of both 
>> extensions and my sample WAR bundle had to import them explicitly (I used 
>> DynamicImport-Package for pax-cdi, weld and myfaces packages)
>>
>> Summarizing - are there any plans to release pax-cdi 1.0.0.GA at some 
>> point? For me we're not there yet - it's still not working well. JSF itself 
>> is IMO a mess full of statics (it's personal opinion, as I've never liked 
>> JSF, so please excuse me) which are not very OSGI friendly.
>>
>> I'm also not sure how aries-cdi project goes and at what stage it is and 
>> how it can be compared to pax-cdi.
>>
>> What do you think?
>>
>> best regards
>> Grzegorz Grzybek
>>
>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] status (CDI, JSF, pax-web)

[Grzegorz Grzybek]

Actually... I got it working! (MyFaces, Weld, pax-cdi and pax-web-jetty) -
it was my fault with proxies for annotations.

But "What I had to change" is still valid - I can try proposing a PR with
these changes and ask for review.

best regards
Grzegorz Grzybek

2018-01-30 11:45 GMT+01:00 Grzegorz Grzybek <gr.grzy...@gmail.com>:

> Hello
>
> I wanted to share my recent experience related to
> https://ops4j1.jira.com/browse/PAXCDI-210 (JSF Beans cannot be resolved).
>
> What I wanted to do is to run simple(st) example with @Named,
> @RequestScoped managed bean accessible from JSF/facelets/EL.
>
> After several major changes (which I hate) I got the example working
> (which required lots of insight into how it works in plain Tomcat + Weld +
> Myfaces), BUT I wasn't able to @Inject a @org.ops4j.pax.cdi.api.Service to
> my bean. I gave up after seeing that weld is trying to compare real
> annotation class (@org.ops4j.pax.cdi.api.Component) with com.sun.Proxy...
>
> What I had to change?
>  - in pax-web I had to carefully sort org.ops4j.pax.web.service.jett
> y.internal.HttpServiceContext#servletContainerInitializers field, to
> ensure that CDI is "run" before JSF
>  - in pax-web, I had to disable tldScanning for additional (declared in
> *.tld) s and move that part to org.ops4j.pax.web.jsp.JasperIn
> itializer
>  - org.ops4j.pax.web.service.spi.model.ContextModel#containerInitializers
> has to be *linked* hashMap
>  - in pax-web event listeners have to be removed in the context of web
> app's classloader
>  - in pax-web, 
> org.ops4j.pax.web.extender.war.internal.model.WebApp#addListener()
> has to skip duplicates (I saw several other duplicates for listeners, EL
> resolvers, etc and I didn't have time to fix it)
>  - in pax-cdi, org.ops4j.pax.cdi.spi.AbstractCdiContainer#contextClassLoader
> has to be carefully chosen - I checked that if we're in the context of
> pax-web, we have to take existing TCCL from pax-web
> (org.ops4j.pax.web.service.spi.util.ResourceDelegatingBundleClassLoader)
> and just add CDI provider bundle to it - otherwise CDI.current() won't work
> (JSF won't find it)
>  - in pax-cdi only pax-cdi-undertow-weld had correct JSF integration - I
> had to move it to pax-cdi-weld (Weld → JSF → EL integration, as described
> in http://docs.jboss.org/weld/reference/latest/en-US/html/ri-spi.html,
> A.2.4)
>  - pax-cdi-jetty-weld didn't pass correct "org.ops4j.pax.cdi.BeanManager"
> context attribute
>  - weld 2.4.6.Final started to require javax.ejb package - weld
> 2.4.5.Final works fine
>  - pax-cdi-extensions actually had to export the packages of both
> extensions and my sample WAR bundle had to import them explicitly (I used
> DynamicImport-Package for pax-cdi, weld and myfaces packages)
>
> Summarizing - are there any plans to release pax-cdi 1.0.0.GA at some
> point? For me we're not there yet - it's still not working well. JSF itself
> is IMO a mess full of statics (it's personal opinion, as I've never liked
> JSF, so please excuse me) which are not very OSGI friendly.
>
> I'm also not sure how aries-cdi project goes and at what stage it is and
> how it can be compared to pax-cdi.
>
> What do you think?
>
> best regards
> Grzegorz Grzybek
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pax-cdi] status (CDI, JSF, pax-web)

[Grzegorz Grzybek]

Hello

I wanted to share my recent experience related to https://ops4j1.jira.com/
browse/PAXCDI-210 (JSF Beans cannot be resolved).

What I wanted to do is to run simple(st) example with @Named,
@RequestScoped managed bean accessible from JSF/facelets/EL.

After several major changes (which I hate) I got the example working (which
required lots of insight into how it works in plain Tomcat + Weld +
Myfaces), BUT I wasn't able to @Inject a @org.ops4j.pax.cdi.api.Service to
my bean. I gave up after seeing that weld is trying to compare real
annotation class (@org.ops4j.pax.cdi.api.Component) with com.sun.Proxy...

What I had to change?
 - in pax-web I had to carefully sort org.ops4j.pax.web.service.
jetty.internal.HttpServiceContext#servletContainerInitializers field, to
ensure that CDI is "run" before JSF
 - in pax-web, I had to disable tldScanning for additional (declared in
*.tld) s and move that part to org.ops4j.pax.web.jsp.
JasperInitializer
 - org.ops4j.pax.web.service.spi.model.ContextModel#containerInitializers
has to be *linked* hashMap
 - in pax-web event listeners have to be removed in the context of web
app's classloader
 - in pax-web,
org.ops4j.pax.web.extender.war.internal.model.WebApp#addListener() has to
skip duplicates (I saw several other duplicates for listeners, EL
resolvers, etc and I didn't have time to fix it)
 - in pax-cdi,
org.ops4j.pax.cdi.spi.AbstractCdiContainer#contextClassLoader has to be
carefully chosen - I checked that if we're in the context of pax-web, we
have to take existing TCCL from pax-web
(org.ops4j.pax.web.service.spi.util.ResourceDelegatingBundleClassLoader)
and just add CDI provider bundle to it - otherwise CDI.current() won't work
(JSF won't find it)
 - in pax-cdi only pax-cdi-undertow-weld had correct JSF integration - I
had to move it to pax-cdi-weld (Weld → JSF → EL integration, as described
in http://docs.jboss.org/weld/reference/latest/en-US/html/ri-spi.html,
A.2.4)
 - pax-cdi-jetty-weld didn't pass correct "org.ops4j.pax.cdi.BeanManager"
context attribute
 - weld 2.4.6.Final started to require javax.ejb package - weld 2.4.5.Final
works fine
 - pax-cdi-extensions actually had to export the packages of both
extensions and my sample WAR bundle had to import them explicitly (I used
DynamicImport-Package for pax-cdi, weld and myfaces packages)

Summarizing - are there any plans to release pax-cdi 1.0.0.GA at some
point? For me we're not there yet - it's still not working well. JSF itself
is IMO a mess full of statics (it's personal opinion, as I've never liked
JSF, so please excuse me) which are not very OSGI friendly.

I'm also not sure how aries-cdi project goes and at what stage it is and
how it can be compared to pax-cdi.

What do you think?

best regards
Grzegorz Grzybek

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CDI?

[Christian Schneider]

 On 15.08.2017 16:06, r...@enjekt.org wrote:

Christian,

I've also seen a lot of people using Processors/Exchanges which
unnecessarily couples their cod to the Camel framework. Unfortunately the
Camel in Action book doesn't get around to advising against that practice
until your well over 100 pages into the books. And when it does it is in a
bulleted list at the end of a chapter. When I'm at client sites it's one of
the first things I teach them when mentoring developers. Use POJOs and unit
tests just like any other code. Unfortunately neither the Camel website nor
the Camel in Action book stress this and too many code examples use
Processor/Exchanges unnecessarily. Honestly, in the past six years, I don't
recall the last time I used Camel Processor/Exchange directly.

I think you are on a very good track with this approach and it would be
good to spread the word about it. As you wrote it is not emphasized enough
in the camel book. So if you have a blog that would be a great theme.

But services aren't more loosely coupled than messaging. If I have bundle A
with all its classes unexported in ".internal" package and bundle B in the
same situation but they communicate via Camel routes, that's decoupled at
compile time and at runtime. Injecting a service interface whether it is
through a proxy or not couples the two bundles at compile time and
temporally couples them at runtime. If one puts the service interface into
a separate bundle one now has a different dependency.

Communicating externally is of course very loosely coupled. On the other
hand remote communication is typically a lot more expensive than local
communication using an OSGi service. Another problem with remote
communication is also that it tends to make your domain model anemic. For
the remote communication you need simple DTO like classes. So the logic is
typically separated from the data. If this really is a problem typically
depends on how complex your domain is.
Your approach sounds a lot like a typical microservice approach.

What I currently look into is combining domain driven design and
microservices. I found that making each service in a bounded context a
microservice is creating a lot of overhead. Instead I think it makes sense
to use OSGi services to talk between bundles of the same bounded context.
The border services that form the outside view of the bounded context are a
good match for the camel endpoints you are using.
Btw. What type of communication do you use? REST or more message based?

One other thing I am looking into is how to separate the user code from the
transport protocol.  For this case jax-rs-whiteboard or Aries RSA with CXF
might be interesting for you if you use REST or SOAP. It allows to offer
and consume services without a direct dependency to camel or CXF.
Unfortunately we do not yet have a good solution for one way messaging
based communication / eventing.

best regards
Christian

-- 
Christian Schneiderhttp://www.liquid-reality.de

Open Source Architecthttp://www.talend.com

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CDI?

[ranx]

I'm not quite sure I grok this. I've used both Blueprint and DS. I've also 
used CDI but it isn't quite ready for primetime.

But CDI permits exporting services, referencing services, and wiring bundle 
internals with injection annotations. It greatly simplifies testing.

So I'm not quite sure what you mean by "there is no framework that solves 
all  your problems."



On Friday, August 11, 2017 at 2:51:42 AM UTC-5, laeubi wrote:
>
> Well in fact here is no framework that solves all your problems... I'm 
> using OSGi and DS for year now and it works without a problem, even 
> though there where sometimes bugs in the code or flaws in my concepts or 
> architectural decsions I had to solve. But I never exspected that DS, 
> OSGi or anything else "solves" this for me in a magical way. 
>
> If you want to use OSGi DS is IMO the best choice (as mentioned before) 
> because it provides what we have with bundles and import/exports to the 
> service level, but must be used with OSGi in mind. The problem is that 
> ppl exspect the can just throw things togeter and it would then work in 
> some magical way. 
>
>
> You can add Blueprint, CDI, Camel and whatever to the mix try to keep 
> away OSGi but will be hurt by "flaky" things then. Thats not the fault 
> of the framework/lib but a restriction of the programming model. I can't 
> find "use of services ends up being complex" but the other way round: 
> Using services with DS is incredible easy and powerfull. So if you have 
> a problem, provide an example and I'm sure you will get help to solve 
> the problem. 
>
> Also DS can of course be used to wire up "things" inside your bundle, 
> what should keep you away of doing so? 
>
> Am 10.08.2017 22:37, schrieb ra...@enjekt.org : 
> > I did use it not too long ago but had to get back to a paying gig. But 
> > the technology is certainly what we need, I think. 
> > 
> > SCR is fine until you then realize that you have wire things up in 
> > your bundle and don't have too many good choices about the matter. 
> > Blueprint is a little long tooth and clunky to work with. From what 
> > I've heard from Christian and others it sounds as though the proxies 
> > have naughty habits. I can say that with time I've drifted away from 
> > using OSGi services when I have a reasonable choice between using a 
> > service and something like a Camel route. A lot of that has to do with 
> > the path of least resistance. I'm putting in a system right now that 
> > has a data source bootstrapped via PAX JDBC which is then consumed by 
> > a "connector" bundle (essentially a DTO). Initially I'd exported that 
> > connector as a service for other bundles to pick up and make service 
> > calls. But the services seemed to have flaky problems when I 
> > uninstalled/installed. Since I had other issues to solve I just fell 
> > back to using Camel routes for data access from other bundles. 
> > 
> > That doesn't seem to be a unique situation for me with Blueprint. 
> > Maybe it isn't Blueprint. But the use of services ends up being 
> > complex and that's a shame. If there's a technology like CDI that lets 
> > me easily export and reference service that will be spectacular. I was 
> > stunned about how easy is to test with the CDI anotations. 
> > 
> > Of course, for bread and butter I'm still consulting on Fuse and 
> > that's not exactly cutting edge 
> > 
>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CDI?

[Christian Schneider]

I agree. Not using services in OSGi is a bad idea. Services allow you to
keep your bundles loosely coupled.
You should also try to only use standard java types in your service
interfaces.

I have seen some cases where people share camel routes between bundles or
use camel classes in service interfaces. In the start this seems fun but as
your system grows you realize that the coupling badly hurts your ability to
evolve parts of your system.

Also when using services try to avoid retrieving a service and blocking
until it is there. Instead let DS or another DI framework inject the
service. Especially using DS this will make your system highly reactive to
changes and even work when things are replaced at runtime like in
development. It also copes well with refreshes like they happen a lot in
apache karaf when you install features.

Christian

2017-08-11 9:51 GMT+02:00 'Christoph Läubrich' via OPS4J <
ops4j@googlegroups.com>:

> Well in fact here is no framework that solves all your problems... I'm
> using OSGi and DS for year now and it works without a problem, even though
> there where sometimes bugs in the code or flaws in my concepts or
> architectural decsions I had to solve. But I never exspected that DS, OSGi
> or anything else "solves" this for me in a magical way.
>
> If you want to use OSGi DS is IMO the best choice (as mentioned before)
> because it provides what we have with bundles and import/exports to the
> service level, but must be used with OSGi in mind. The problem is that ppl
> exspect the can just throw things togeter and it would then work in some
> magical way.
>
>
> You can add Blueprint, CDI, Camel and whatever to the mix try to keep away
> OSGi but will be hurt by "flaky" things then. Thats not the fault of the
> framework/lib but a restriction of the programming model. I can't find "use
> of services ends up being complex" but the other way round: Using services
> with DS is incredible easy and powerfull. So if you have a problem, provide
> an example and I'm sure you will get help to solve the problem.
>
> Also DS can of course be used to wire up "things" inside your bundle, what
> should keep you away of doing so?
>
> Am 10.08.2017 22:37, schrieb r...@enjekt.org:
>
>> I did use it not too long ago but had to get back to a paying gig. But
>> the technology is certainly what we need, I think.
>>
>> SCR is fine until you then realize that you have wire things up in your
>> bundle and don't have too many good choices about the matter. Blueprint is
>> a little long tooth and clunky to work with. From what I've heard from
>> Christian and others it sounds as though the proxies have naughty habits. I
>> can say that with time I've drifted away from using OSGi services when I
>> have a reasonable choice between using a service and something like a Camel
>> route. A lot of that has to do with the path of least resistance. I'm
>> putting in a system right now that has a data source bootstrapped via PAX
>> JDBC which is then consumed by a "connector" bundle (essentially a DTO).
>> Initially I'd exported that connector as a service for other bundles to
>> pick up and make service calls. But the services seemed to have flaky
>> problems when I uninstalled/installed. Since I had other issues to solve I
>> just fell back to using Camel routes for data access from other bundles.
>>
>> That doesn't seem to be a unique situation for me with Blueprint. Maybe
>> it isn't Blueprint. But the use of services ends up being complex and
>> that's a shame. If there's a technology like CDI that lets me easily export
>> and reference service that will be spectacular. I was stunned about how
>> easy is to test with the CDI anotations.
>>
>> Of course, for bread and butter I'm still consulting on Fuse and that's
>> not exactly cutting edge
>>
>>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> --- You received this message because you are subscribed to the Google
> Groups "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CDI?

[Christian Schneider]

It is certainly worth to try. I would be very interested in your experience
with the current state of CDI support.

Christian

2017-08-09 17:20 GMT+02:00 <r...@enjekt.org>:

> Matt,
>
> This is an exchange between Christian and Guillaume from  couple of months
> back when I was asking about this. I've put Guillaume's comments in bold.
>
> DI would be great but it is is less well supported on OSGi than blueprint
> and the current implementations also have the same bad proxy behaviour. So
> while I would like to see a really good CDI implementation on OSGi with
> dynamic behaviour like DS we are not there yet.
>
> *No, the work I've done on CDI is free from those drawbacks. It has the
> same semantics as DS, so anything you can do in DS, you can do in CDI. You
> can even do more than DS because you can wire services "internally", i.e.
> you don't have to expose your services to the OSGi registry to wire them
> together.*
>
>
>
> On Monday, August 7, 2017 at 8:34:57 PM UTC-5, Matt Sicker wrote:
>>
>> I'm not so sure about deprecated, but DS is the only dependency injection
>> standard in OSGi that respects the dynamic nature of services. CDI,
>> blueprint, etc., all have to rely on hacky proxies to emulate support while
>> adding nonstandard extensions at times.
>>
>> On 7 August 2017 at 17:02, <ra...@enjekt.org> wrote:
>>
>>> I posted this to the Karaf forum but it may more appropriately belong
>>> here. It's going to be one or the other.
>>>
>>> Has CDI been deprecated from the OSGi specification. I was hoping to use
>>> it in the future instead of Blueprint or DS or in addition to them. I re
>>> all last year a new OSGi service export and reference annotations were
>>> added. So this surprised me a bit.
>>>
>>> https://issues.apache.org/jira/browse/CAMEL-11029
>>>
>>> According to that issue, Camel's CDI support for OSGi doesn't work
>>> because CDI on OSGi is deprecated.
>>>
>>> --
>>> --
>>> --
>>> OPS4J - http://www.ops4j.org - op...@googlegroups.com
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "OPS4J" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to ops4j+un...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Matt Sicker <boa...@gmail.com>
>>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CDI?

[ranx]

What I found odd about the Camel comment that Claus made is that Guillaume 
just put in the CDI annotations for service export and reference last year. 
Initially he did it with Blueprint but swapped it out with DS. I prefer 
working with CDI as there is a lot of testing I can do in Camel that uses 
the CDI wiring mechanisms but I don't have to use CBTS or PAX Exam. The 
internal wiring provided by CDI is a big relief. But the last time I used 
it I couldn't get it working just right. I think that was RC1. The CDI 
annotation mechanism means the paradigm is the same for both internal wire 
up and for external services. Right now working with DS and Blueprint and 
Camel feels like a kludge of items bolted on as an afterthought.

It would be great to have some trustworthy annotations that were usable 
with Camel inside of Karaf/Felix. There are some Camel annotations that I 
trust, some I'm not sure about, and others I know are simply broken. 

One other benefit is that it might make J2EE developers a little more 
inclined to give OSGi/Karaf a shot if that familiar paradigm is available.


On Monday, August 7, 2017 at 8:34:57 PM UTC-5, Matt Sicker wrote:
>
> I'm not so sure about deprecated, but DS is the only dependency injection 
> standard in OSGi that respects the dynamic nature of services. CDI, 
> blueprint, etc., all have to rely on hacky proxies to emulate support while 
> adding nonstandard extensions at times. 
>
> On 7 August 2017 at 17:02, <ra...@enjekt.org > wrote:
>
>> I posted this to the Karaf forum but it may more appropriately belong 
>> here. It's going to be one or the other.
>>
>> Has CDI been deprecated from the OSGi specification. I was hoping to use 
>> it in the future instead of Blueprint or DS or in addition to them. I re 
>> all last year a new OSGi service export and reference annotations were 
>> added. So this surprised me a bit.
>>
>> https://issues.apache.org/jira/browse/CAMEL-11029
>>
>> According to that issue, Camel's CDI support for OSGi doesn't work 
>> because CDI on OSGi is deprecated.
>>
>> -- 
>> -- 
>> --
>> OPS4J - http://www.ops4j.org - op...@googlegroups.com 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ops4j+un...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Matt Sicker <boa...@gmail.com >
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CDI?

['Achim Nierbeck' via OPS4J]

Hi,

The OSGi CDI spec was never approved as the champion pushing the spec
withdrew.
At the time People here at OPS4j worked on a CDI implementation which
should follow that spec.
That's Pax CDI, but as the spec was never approved that's basically it.
Though it's functional working.
Besides, the latest CDI 2 specification was supposed to be also used for a
new try to have a OSGi CDI specification.
AFAIK Apache Aries tries to be the home of it.
That's for the CDI stuff, if you are looking for just injection of other
Services, I'd go with DS.

regards, Achim


2017-08-08 3:34 GMT+02:00 Matt Sicker <boa...@gmail.com>:

> I'm not so sure about deprecated, but DS is the only dependency injection
> standard in OSGi that respects the dynamic nature of services. CDI,
> blueprint, etc., all have to rely on hacky proxies to emulate support while
> adding nonstandard extensions at times.
>
> On 7 August 2017 at 17:02, <r...@enjekt.org> wrote:
>
>> I posted this to the Karaf forum but it may more appropriately belong
>> here. It's going to be one or the other.
>>
>> Has CDI been deprecated from the OSGi specification. I was hoping to use
>> it in the future instead of Blueprint or DS or in addition to them. I re
>> all last year a new OSGi service export and reference annotations were
>> added. So this surprised me a bit.
>>
>> https://issues.apache.org/jira/browse/CAMEL-11029
>>
>> According to that issue, Camel's CDI support for OSGi doesn't work
>> because CDI on OSGi is deprecated.
>>
>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to ops4j+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Matt Sicker <boa...@gmail.com>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CDI?

[Matt Sicker]

I'm not so sure about deprecated, but DS is the only dependency injection
standard in OSGi that respects the dynamic nature of services. CDI,
blueprint, etc., all have to rely on hacky proxies to emulate support while
adding nonstandard extensions at times.

On 7 August 2017 at 17:02, <r...@enjekt.org> wrote:

> I posted this to the Karaf forum but it may more appropriately belong
> here. It's going to be one or the other.
>
> Has CDI been deprecated from the OSGi specification. I was hoping to use
> it in the future instead of Blueprint or DS or in addition to them. I re
> all last year a new OSGi service export and reference annotations were
> added. So this surprised me a bit.
>
> https://issues.apache.org/jira/browse/CAMEL-11029
>
> According to that issue, Camel's CDI support for OSGi doesn't work because
> CDI on OSGi is deprecated.
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Matt Sicker <boa...@gmail.com>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-web] What are OSGI MVC frameworks that can be used with Pax-Web and Pax-CDI?

[nino martinez wael]

Theres also PAX Wicket :) Which is plain wicket along with a couple of nice 
extra features.

https://ops4j1.jira.com/wiki/display/paxwicket/Pax+Wicket
https://wicket.apache.org/

On Tuesday, June 6, 2017 at 3:33:30 PM UTC+2, Pavel wrote:
>
> Hi all 
>
> Could anyone suggest MVC framework that work on OSGi and which work
> with pax-web and pax-cdi? What I need:
> 1) It must work with pax-web 6 and pax-cdi 1
> 2) Of course it must be as OSGI bundles
> 3) The project must be alive.
>
> Best regards, Pavel
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-web] What are OSGI MVC frameworks that can be used with Pax-Web and Pax-CDI?

[Oliver Lietz]

On Tuesday 06 June 2017 06:33:29 Pavel wrote:
> Hi all

Hi Pavel,

> Could anyone suggest MVC framework that work on OSGi and which work
> with pax-web and pax-cdi?

Apache Sling: http://sling.apache.org/

> What I need:
> 1) It must work with pax-web 6 and pax-cdi 1

runs with Felix HTTP Service and Pax Web, doesn't use CDI but DS/SCR (but 
should work with CDI).

> 2) Of course it must be as OSGI bundles

lots of bundles...

> 3) The project must be alive.

and alive since 2007.

Regards,
O.

> Best regards, Pavel

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-web] What are OSGI MVC frameworks that can be used with Pax-Web and Pax-CDI?

['Achim Nierbeck' via OPS4J]

Hi Pavel ...

depends on your personal taste I guess.
Most projects I work with nowadays skip the mvc frameworks and do have a
REST based backend with some JS frontends.

For Rest endpoints you can use CXF.
Javascript .. pick yourself a personal favorite, as it's static content
it's "osgi-safe" ;)

regards, Achim



2017-06-06 15:33 GMT+02:00 Pavel <pavelkastor...@gmail.com>:

> Hi all
>
> Could anyone suggest MVC framework that work on OSGi and which work
> with pax-web and pax-cdi? What I need:
> 1) It must work with pax-web 6 and pax-cdi 1
> 2) Of course it must be as OSGI bundles
> 3) The project must be alive.
>
> Best regards, Pavel
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pax-web] What are OSGI MVC frameworks that can be used with Pax-Web and Pax-CDI?

[Pavel]

Hi all 

Could anyone suggest MVC framework that work on OSGi and which work
with pax-web and pax-cdi? What I need:
1) It must work with pax-web 6 and pax-cdi 1
2) Of course it must be as OSGI bundles
3) The project must be alive.

Best regards, Pavel

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] How to inject beans from another bundle?

[Pavel Kastornyy]

I think many people had this problem and many people will have.

On 22.05.2017 18:54, Marc Schlegel wrote:

Aaaah that one: I've fallen for that one several times in JEE projects too
:-)
The file is used as a marker for CDI so it doesnt have to scan all JARs

Am Montag, 22. Mai 2017 16:28:42 UTC+2 schrieb Pavel:

It was necessary to put in bundlA META-INF folder beans.xml file.
I thought that beans.xml is required only in bundle for which container
is created. However, it turned out that this file is also required
for bundles for which container is not created but which contain
CDI beans.

On 22.05.2017 16:55, Marc Schlegel wrote:

What was the problem?

Maybe somebody else has the same issue and could learn from this thread.

Am Montag, 22. Mai 2017 13:26:34 UTC+2 schrieb Pavel:

Hi Marc

Thank you for your suggestion. I have solved that problem.

Best regards, Pavel

понедельник, 22 мая 2017 г., 13:39:24 UTC+3 пользователь Marc Schlegel
написал:

I remember that I had a example which pretty much covered your

use-case

and it was working with RC1.

Maybe you can share your two Beans as well as your manifest.

regards
Marc

Am Samstag, 20. Mai 2017 20:16:16 UTC+2 schrieb Pavel:

Hi all

I have two bundles - A and B.

In bundleA I have an cdi Bean (@Dependent) in package com.temp. For
bundleA cdi container is not created.

For bundleB cdi container is created. BundleB imports package

com.temp.

However, bundleB cdi container
doesn't find bean from bundleA.

Could anyone say if it is possible to do and if possible then how?

Best regards, Pavel





--
--
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups "OPS4J" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] How to inject beans from another bundle?

[Marc Schlegel]

Aaaah that one: I've fallen for that one several times in JEE projects too 
:-)
The file is used as a marker for CDI so it doesnt have to scan all JARs

Am Montag, 22. Mai 2017 16:28:42 UTC+2 schrieb Pavel:
>
> It was necessary to put in bundlA META-INF folder beans.xml file. 
> I thought that beans.xml is required only in bundle for which container 
> is created. However, it turned out that this file is also required 
> for bundles for which container is not created but which contain 
> CDI beans. 
>
> On 22.05.2017 16:55, Marc Schlegel wrote: 
> > What was the problem? 
> > 
> > Maybe somebody else has the same issue and could learn from this thread. 
> > 
> > Am Montag, 22. Mai 2017 13:26:34 UTC+2 schrieb Pavel: 
> >> Hi Marc 
> >> 
> >> Thank you for your suggestion. I have solved that problem. 
> >> 
> >> Best regards, Pavel 
> >> 
> >> понедельник, 22 мая 2017 г., 13:39:24 UTC+3 пользователь Marc Schlegel 
> >> написал: 
> >>> I remember that I had a example which pretty much covered your 
> use-case 
> >>> and it was working with RC1. 
> >>> 
> >>> Maybe you can share your two Beans as well as your manifest. 
> >>> 
> >>> regards 
> >>> Marc 
> >>> 
> >>> Am Samstag, 20. Mai 2017 20:16:16 UTC+2 schrieb Pavel: 
> >>>> Hi all 
> >>>> 
> >>>> I have two bundles - A and B. 
> >>>> 
> >>>> In bundleA I have an cdi Bean (@Dependent) in package com.temp. For 
> >>>> bundleA cdi container is not created. 
> >>>> 
> >>>> For bundleB cdi container is created. BundleB imports package 
> com.temp. 
> >>>> However, bundleB cdi container 
> >>>> doesn't find bean from bundleA. 
> >>>> 
> >>>> Could anyone say if it is possible to do and if possible then how? 
> >>>> 
> >>>> Best regards, Pavel 
> >>>> 
>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] How to inject beans from another bundle?

[Pavel Kastornyy]

It was necessary to put in bundlA META-INF folder beans.xml file.
I thought that beans.xml is required only in bundle for which container
is created. However, it turned out that this file is also required
for bundles for which container is not created but which contain
CDI beans.

On 22.05.2017 16:55, Marc Schlegel wrote:

What was the problem?

Maybe somebody else has the same issue and could learn from this thread.

Am Montag, 22. Mai 2017 13:26:34 UTC+2 schrieb Pavel:

Hi Marc

Thank you for your suggestion. I have solved that problem.

Best regards, Pavel

понедельник, 22 мая 2017 г., 13:39:24 UTC+3 пользователь Marc Schlegel
написал:

I remember that I had a example which pretty much covered your use-case
and it was working with RC1.

Maybe you can share your two Beans as well as your manifest.

regards
Marc

Am Samstag, 20. Mai 2017 20:16:16 UTC+2 schrieb Pavel:

Hi all

I have two bundles - A and B.

In bundleA I have an cdi Bean (@Dependent) in package com.temp. For
bundleA cdi container is not created.

For bundleB cdi container is created. BundleB imports package com.temp.
However, bundleB cdi container
doesn't find bean from bundleA.

Could anyone say if it is possible to do and if possible then how?

Best regards, Pavel



--
--
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups "OPS4J" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] How to inject beans from another bundle?

[Marc Schlegel]

What was the problem?

Maybe somebody else has the same issue and could learn from this thread.

Am Montag, 22. Mai 2017 13:26:34 UTC+2 schrieb Pavel:
>
> Hi Marc
>
> Thank you for your suggestion. I have solved that problem.
>
> Best regards, Pavel
>
> понедельник, 22 мая 2017 г., 13:39:24 UTC+3 пользователь Marc Schlegel 
> написал:
>>
>> I remember that I had a example which pretty much covered your use-case 
>> and it was working with RC1.
>>
>> Maybe you can share your two Beans as well as your manifest.
>>
>> regards
>> Marc
>>
>> Am Samstag, 20. Mai 2017 20:16:16 UTC+2 schrieb Pavel:
>>>
>>> Hi all
>>>
>>> I have two bundles - A and B. 
>>>
>>> In bundleA I have an cdi Bean (@Dependent) in package com.temp. For 
>>> bundleA cdi container is not created. 
>>>
>>> For bundleB cdi container is created. BundleB imports package com.temp. 
>>> However, bundleB cdi container
>>> doesn't find bean from bundleA.
>>>
>>> Could anyone say if it is possible to do and if possible then how?
>>>
>>> Best regards, Pavel
>>>
>>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] How to inject beans from another bundle?

[Pavel]

Hi Marc

Thank you for your suggestion. I have solved that problem.

Best regards, Pavel

понедельник, 22 мая 2017 г., 13:39:24 UTC+3 пользователь Marc Schlegel 
написал:
>
> I remember that I had a example which pretty much covered your use-case 
> and it was working with RC1.
>
> Maybe you can share your two Beans as well as your manifest.
>
> regards
> Marc
>
> Am Samstag, 20. Mai 2017 20:16:16 UTC+2 schrieb Pavel:
>>
>> Hi all
>>
>> I have two bundles - A and B. 
>>
>> In bundleA I have an cdi Bean (@Dependent) in package com.temp. For 
>> bundleA cdi container is not created. 
>>
>> For bundleB cdi container is created. BundleB imports package com.temp. 
>> However, bundleB cdi container
>> doesn't find bean from bundleA.
>>
>> Could anyone say if it is possible to do and if possible then how?
>>
>> Best regards, Pavel
>>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] Application scoped bean and its lifecycle

[Pavel]

Weld developers suggested another way with using weld 2.3.5:

@ApplicationScoped
class Test {

public Test() {
System.out.println("Test was created.");
}

void appContextInit(@Observes @Initialized(ApplicationScoped.class) 
Object init) {
  // Empty body - force eager instantiation
}

@PostConstruct
void onInit() {
  // logic... will only be called once
  System.out.println("Test was initialized");
}

@PreDestroy
void onDestroy() {
  // logic will be called once before
System.out.println("Test was destroyed.");
}

}

They say that Weld 2.4.4.Final (that should fix this bug) will 
approximately released Jun/17.

понедельник, 22 мая 2017 г., 13:37:33 UTC+3 пользователь Marc Schlegel 
написал:
>
> Hi Pavel. Thanks for your findings regarding the Weld issues and providing 
> a workaround.
>
> BTW: I doubt that you will get more answers by posting jokes about the 
> community. Please keep in mind that PAX-CDI 1.0.0 is not released yet, so 
> there are probably not many people using it yet. 
>
> regards
> Marc
>
> Am Montag, 22. Mai 2017 12:15:34 UTC+2 schrieb Pavel:
>>
>> Hi all
>>
>> With developers of WELD the problem was found out. 
>>
>> Up to version 2.2 Weld did not fire @Initialized/@Destroyed events for
>>   @ApplicationScoped for non-web modules. The behavior changed in 2.3 -
>>  see also WELD-1821 [2]. Issue WELD-2389 [3] was created.
>>
>> So, @ApplicationScoped events are broken in PAX-CDI 1.0.0.RC2 
>> that uses weld 2.3.5.Final and such beans are not singletons.
>>
>> As a workaround I replaced 2.3.5.Final with 2.2.16.Final. Besides in 
>> 2.2.16 in
>> manifest I had to export package org.jboss.weld.config which is used by 
>> pax-cdi.  
>>
>> Now  on bundle start:
>> Test was created.
>> Test was initialized
>>
>> Now  on bundle stop:
>> Test was destroyed.
>>
>> JOKE: What is common in working with PAX-CDI and searching for 
>> extraterrestrial civilizations?
>> You send messages and hope to get answer. But... no, not any message 
>> ever...
>>
>> [2] https://issues.jboss.org/browse/WELD-1821
>>
>> [3] https://issues.jboss.org/browse/WELD-2389
>>
>>
>> воскресенье, 21 мая 2017 г., 21:51:26 UTC+3 пользователь Pavel написал:
>>>
>>> Hi all
>>>
>>> Sorry for one more message but I have rather strange situation.  I use 
>>> pax-cdi -1.0.0.RC2 and weld 2.3.5.Final.
>>>
>>> This is the test class: 
>>>
>>> import javax.enterprise.context.ApplicationScoped;
>>> import javax.enterprise.context.Destroyed;
>>> import javax.enterprise.context.Initialized;
>>> import javax.enterprise.event.Observes;
>>>
>>> @ApplicationScoped
>>> public class Test {
>>>
>>> public Test() {
>>> System.out.println("Test was created.");
>>> }
>>>
>>> public void init(@Observes @Initialized(ApplicationScoped.class) 
>>> Object init) {
>>> System.out.println("Test was initialized");
>>> }
>>>
>>> public void destroy(@Observes @Destroyed(ApplicationScoped.class) 
>>> Object init) {
>>> System.out.println("Test was destroyed.");
>>> }
>>> }
>>>
>>> When I start test-bundle I see the following output:
>>> Test was created.
>>> Test was initialized
>>> Test was initialized
>>> When I stop test-bundle I see the following output:
>>> Test was destroyed.
>>> Test was created.
>>> Test was destroyed.
>>>
>>> So as result this bean was two times created, two times initialized and 
>>> two times destroyed.
>>>
>>> I expected that this bean must be once created, one initialized and once 
>>> destroyed.
>>>
>>> Is this a bug that must be reported or my mistake?
>>>
>>> Best regards, Pavel
>>>
>>>
>>>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] How to inject beans from another bundle?

[Marc Schlegel]

I remember that I had a example which pretty much covered your use-case and 
it was working with RC1.

Maybe you can share your two Beans as well as your manifest.

regards
Marc

Am Samstag, 20. Mai 2017 20:16:16 UTC+2 schrieb Pavel:
>
> Hi all
>
> I have two bundles - A and B. 
>
> In bundleA I have an cdi Bean (@Dependent) in package com.temp. For 
> bundleA cdi container is not created. 
>
> For bundleB cdi container is created. BundleB imports package com.temp. 
> However, bundleB cdi container
> doesn't find bean from bundleA.
>
> Could anyone say if it is possible to do and if possible then how?
>
> Best regards, Pavel
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] Application scoped bean and its lifecycle

[Marc Schlegel]

Hi Pavel. Thanks for your findings regarding the Weld issues and providing 
a workaround.

BTW: I doubt that you will get more answers by posting jokes about the 
community. Please keep in mind that PAX-CDI 1.0.0 is not released yet, so 
there are probably not many people using it yet. 

regards
Marc

Am Montag, 22. Mai 2017 12:15:34 UTC+2 schrieb Pavel:
>
> Hi all
>
> With developers of WELD the problem was found out. 
>
> Up to version 2.2 Weld did not fire @Initialized/@Destroyed events for
>   @ApplicationScoped for non-web modules. The behavior changed in 2.3 -
>  see also WELD-1821 [2]. Issue WELD-2389 [3] was created.
>
> So, @ApplicationScoped events are broken in PAX-CDI 1.0.0.RC2 
> that uses weld 2.3.5.Final and such beans are not singletons.
>
> As a workaround I replaced 2.3.5.Final with 2.2.16.Final. Besides in 
> 2.2.16 in
> manifest I had to export package org.jboss.weld.config which is used by 
> pax-cdi.  
>
> Now  on bundle start:
> Test was created.
> Test was initialized
>
> Now  on bundle stop:
> Test was destroyed.
>
> JOKE: What is common in working with PAX-CDI and searching for 
> extraterrestrial civilizations?
> You send messages and hope to get answer. But... no, not any message 
> ever...
>
> [2] https://issues.jboss.org/browse/WELD-1821
>
> [3] https://issues.jboss.org/browse/WELD-2389
>
>
> воскресенье, 21 мая 2017 г., 21:51:26 UTC+3 пользователь Pavel написал:
>>
>> Hi all
>>
>> Sorry for one more message but I have rather strange situation.  I use 
>> pax-cdi -1.0.0.RC2 and weld 2.3.5.Final.
>>
>> This is the test class: 
>>
>> import javax.enterprise.context.ApplicationScoped;
>> import javax.enterprise.context.Destroyed;
>> import javax.enterprise.context.Initialized;
>> import javax.enterprise.event.Observes;
>>
>> @ApplicationScoped
>> public class Test {
>>
>> public Test() {
>> System.out.println("Test was created.");
>> }
>>
>> public void init(@Observes @Initialized(ApplicationScoped.class) 
>> Object init) {
>> System.out.println("Test was initialized");
>> }
>>
>> public void destroy(@Observes @Destroyed(ApplicationScoped.class) 
>> Object init) {
>> System.out.println("Test was destroyed.");
>> }
>> }
>>
>> When I start test-bundle I see the following output:
>> Test was created.
>> Test was initialized
>> Test was initialized
>> When I stop test-bundle I see the following output:
>> Test was destroyed.
>> Test was created.
>> Test was destroyed.
>>
>> So as result this bean was two times created, two times initialized and 
>> two times destroyed.
>>
>> I expected that this bean must be once created, one initialized and once 
>> destroyed.
>>
>> Is this a bug that must be reported or my mistake?
>>
>> Best regards, Pavel
>>
>>
>>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pax-cdi] Application scoped bean and its lifecycle

[Pavel]

Hi all

Sorry for one more message but I have rather strange situation.  I use 
pax-cdi -1.0.0.RC2 and weld 2.3.5.Final.

This is the test class: 

import javax.enterprise.context.ApplicationScoped;
import javax.enterprise.context.Destroyed;
import javax.enterprise.context.Initialized;
import javax.enterprise.event.Observes;

@ApplicationScoped
public class Test {

public Test() {
System.out.println("Test was created.");
}

public void init(@Observes @Initialized(ApplicationScoped.class) Object 
init) {
System.out.println("Test was initialized");
}

public void destroy(@Observes @Destroyed(ApplicationScoped.class) 
Object init) {
System.out.println("Test was destroyed.");
}
}

When I start test-bundle I see the following output:
Test was created.
Test was initialized
Test was initialized
When I stop test-bundle I see the following output:
Test was destroyed.
Test was created.
Test was destroyed.

So as result this bean was two times created, two times initialized and two 
times destroyed.

I expected that this bean must be once created, one initialized and once 
destroyed.

Is this a bug that must be reported or my mistake?

Best regards, Pavel


-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pax-cdi] How to inject beans from another bundle?

[Pavel]

Hi all

I have two bundles - A and B. 

In bundleA I have an cdi Bean (@Dependent) in package com.temp. For bundleA 
cdi container is not created. 

For bundleB cdi container is created. BundleB imports package com.temp. 
However, bundleB cdi container
doesn't find bean from bundleA.

Could anyone say if it is possible to do and if possible then how?

Best regards, Pavel

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] Thread dead lock with osgi refresh

[Guillaume Nodet]

I pushed a fix anyway.

2017-05-10 13:50 GMT+02:00 Pavel <pavelkastor...@gmail.com>:

> Simon said which configuration must be used. Weld developers said this
> configuration
> can be set via system settings -Dorg.jboss.weld.bootstrap.
> concurrentDeployment=false
> so there is no need to modify PAX-CDI code.
>
> If someone has the same problem he can find more information here:
> https://issues.jboss.org/browse/WELD-2383
>
> вторник, 9 мая 2017 г., 23:58:57 UTC+3 пользователь Pavel написал:
>
>> Hi Simon
>>
>> Thank you very much! This is really helped. But what are the consequences
>> of such workaround?
>>
>> Best regards, Pavel
>>
>> вторник, 9 мая 2017 г., 18:43:43 UTC+3 пользователь Simon Spero написал:
>>>
>>> This is probably suboptimal, but it may be good enough:
>>>
>>> When configuring the weld bootstrap at
>>>
>>> https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-c
>>> di-weld/src/main/java/org/ops4j/pax/cdi/weld/impl/WeldCdiCon
>>> tainer.java#L120
>>>
>>> it is possible to disable concurrent deployment by  chaining
>>> .add(ConfigurationKey.CONCURRENT_DEPLOYMENT,"false")
>>>
>>> That should either solve the deadlock, or move it :)
>>>
>>> Simon
>>>
>>> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Guillaume Nodet

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] Thread dead lock with osgi refresh

[Pavel]

Simon said which configuration must be used. Weld developers said this 
configuration 
can be set via system settings 
-Dorg.jboss.weld.bootstrap.concurrentDeployment=false
so there is no need to modify PAX-CDI code.

If someone has the same problem he can find more information here:
https://issues.jboss.org/browse/WELD-2383 

вторник, 9 мая 2017 г., 23:58:57 UTC+3 пользователь Pavel написал:
>
> Hi Simon
>
> Thank you very much! This is really helped. But what are the consequences 
> of such workaround?
>
> Best regards, Pavel
>
> вторник, 9 мая 2017 г., 18:43:43 UTC+3 пользователь Simon Spero написал:
>>
>> This is probably suboptimal, but it may be good enough:
>>
>> When configuring the weld bootstrap at 
>>
>>
>> https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-cdi-weld/src/main/java/org/ops4j/pax/cdi/weld/impl/WeldCdiContainer.java#L120
>>
>> it is possible to disable concurrent deployment by  chaining
>> .add(ConfigurationKey.CONCURRENT_DEPLOYMENT,"false")
>>
>> That should either solve the deadlock, or move it :) 
>>
>> Simon
>>
>>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] Thread dead lock with osgi refresh

[Pavel]

Hi Simon

Thank you very much! This is really helped. But what are the consequences 
of such workaround?

Best regards, Pavel

вторник, 9 мая 2017 г., 18:43:43 UTC+3 пользователь Simon Spero написал:
>
> This is probably suboptimal, but it may be good enough:
>
> When configuring the weld bootstrap at 
>
>
> https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-cdi-weld/src/main/java/org/ops4j/pax/cdi/weld/impl/WeldCdiContainer.java#L120
>
> it is possible to disable concurrent deployment by  chaining
> .add(ConfigurationKey.CONCURRENT_DEPLOYMENT,"false")
>
> That should either solve the deadlock, or move it :) 
>
> Simon
>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] Thread dead lock with osgi refresh

[Simon Spero]

This is probably suboptimal, but it may be good enough:

When configuring the weld bootstrap at 

https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-cdi-weld/src/main/java/org/ops4j/pax/cdi/weld/impl/WeldCdiContainer.java#L120

it is possible to disable concurrent deployment by  chaining
.add(ConfigurationKey.CONCURRENT_DEPLOYMENT,"false")

That should either solve the deadlock, or move it :) 

Simon

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] Thread dead lock with osgi refresh

[Pavel]

Guillaume, thank you for your suggestions, but it didn't help.

I've checked all bundles manifest and only in two I found dynamic import in 
felix.scr and org.osgi.enterprise.
I removed those dynamic imports but it didn't help. Result is the same.

вторник, 9 мая 2017 г., 16:20:49 UTC+3 пользователь Guillaume Nodet написал:
>
> Or could you put a breakpoint where I told you, that would give you the 
> name of the package and the bundle by looking at the variables on the stack.
>
> 2017-05-08 12:02 GMT+02:00 Pavel <pavelka...@gmail.com >:
>
>> Hi all
>>
>> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two 
>> bundles: bundleA and bundleB. 
>>
>> BundleB has CDI beans and CDI container is created for bundleB. Besides 
>> bundleB depends on bundleA.
>>
>> Now I update bundleA and do osgi refresh using this code
>>
>> Bundle systemBundle = bundleContext.getBundle(0);
>> FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class); 
>> frameworkWiring.refreshBundles(null);
>>
>> What I see in log of bundle B.
>>
>> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> STOPPING - com.bundleB
>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>> UNREGISTERING - [java.lang.Object] - com.bundleB
>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED 
>> - com.bundleB
>> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> UNRESOLVED - com.bundleB
>> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> RESOLVED - com.bundleB
>> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> STARTING - com.bundleB
>> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>> REGISTERED - [java.lang.Object] - com.bundleB
>>
>> Please,note that bundleB didn't change state to STARTED. When I don't use in 
>> bundleB CDI
>> beans and CDI container is not created for bundleB then everything is ok - 
>> after bundleA
>> update and osgi refresh bundleB reaches STARTED state.
>>
>> Is this a bug or maybe I do something wrong or something else? This is some 
>> thread dump:
>>
>> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
>> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>>java.lang.Thread.State: BLOCKED (on object monitor)
>>  at 
>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>>  - waiting to lock <0xfd03aa50> (a java.lang.Class for 
>> org.jboss.weld.util.bytecode.ClassFileUtils)
>>  at 
>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
>>  at 
>> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
>>  at 
>> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
>>  at 
>> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
>>  at 
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>>  at 
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>>  at 
>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>>  at 
>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>>  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>  at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>  at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>  at java.lang.Thread.run(Thread.java:745)
>>
>> "weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800 
>> nid=0x1dc6 in Object.wait() [0x7f3dd967e000]
>>java.lang.Thread.State: WAITING (on object monitor)
>>  at java.lang.Object.wait(Native Method)
>>  at java.lang.Object.wait(Object.java:502)
>>  at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
>>  - locked <0xed6de970> (a [Ljava.lang.Object;)
>>  at 
>> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:481)
>>  at 
>> org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1652)
>>

Re: [pax-cdi] Thread dead lock with osgi refresh

[Guillaume Nodet]

Or could you put a breakpoint where I told you, that would give you the
name of the package and the bundle by looking at the variables on the stack.

2017-05-08 12:02 GMT+02:00 Pavel <pavelkastor...@gmail.com>:

> Hi all
>
> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two
> bundles: bundleA and bundleB.
>
> BundleB has CDI beans and CDI container is created for bundleB. Besides
> bundleB depends on bundleA.
>
> Now I update bundleA and do osgi refresh using this code
>
> Bundle systemBundle = bundleContext.getBundle(0);
> FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class);
> frameworkWiring.refreshBundles(null);
>
> What I see in log of bundle B.
>
> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPING 
> - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> UNREGISTERING - [java.lang.Object] - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED 
> - com.bundleB
> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
> UNRESOLVED - com.bundleB
> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent RESOLVED 
> - com.bundleB
> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent STARTING 
> - com.bundleB
> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> REGISTERED - [java.lang.Object] - com.bundleB
>
> Please,note that bundleB didn't change state to STARTED. When I don't use in 
> bundleB CDI
> beans and CDI container is not created for bundleB then everything is ok - 
> after bundleA
> update and osgi refresh bundleB reaches STARTED state.
>
> Is this a bug or maybe I do something wrong or something else? This is some 
> thread dump:
>
> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>   - waiting to lock <0xfd03aa50> (a java.lang.Class for 
> org.jboss.weld.util.bytecode.ClassFileUtils)
>   at 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
>   at 
> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
>   at 
> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
>   at 
> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
>   at 
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>   at 
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
>
> "weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800 
> nid=0x1dc6 in Object.wait() [0x7f3dd967e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
>   - locked <0xed6de970> (a [Ljava.lang.Object;)
>   at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:481)
>   at 
> org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1652)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1552)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925)
>   at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
>   at 
> org.apache.xbean.osgi.bundle.util.DelegatingBundle.loadClass(DelegatingBundle.java:170)
>   at 
> org.apache.xbean.osgi.bundl

Re: [pax-cdi] Thread dead lock with osgi refresh

[Pavel]

As I understand you DynamicImport-Package must be defined in bundle 
MANIFEST. 

So do I need to check MANIFESTs of all bundles for containing 
DynamicImport-Package
property?

вторник, 9 мая 2017 г., 16:04:53 UTC+3 пользователь Guillaume Nodet написал:
>
> Well, according to the stack trace, someone does.  I've checked weld and 
> pax-cdi bundles and they don't have any dynamic import.  Can you double 
> check all the deployed bundles ?  Maybe it's not one of you bundles, but 
> there's definitely at least one bundle which uses dynamic import.
> One way to avoid the dynamic import resolution is to back all dynamically 
> imported packages by statically imported optional packages, so that they 
> are rather statically bound than dynamically bound.
> Also, if you can easily reproduce the issue, one good way would be to put 
> a breakpoint in 
>   org.apache.felix.framework.StatefulResolver.resolve(
> StatefulResolver.java:481)
> and check which package cause the resolution.
>
>
> 2017-05-09 14:54 GMT+02:00 Pavel <pavelka...@gmail.com >:
>
>> Hi Guillaume
>>
>> Thank you for your answer. But I don't use any dynamic-imports.
>>
>> вторник, 9 мая 2017 г., 15:52:03 UTC+3 пользователь Guillaume Nodet 
>> написал:
>>>
>>> Yeah, and I'm telling you that you should remove the DynamicImport from 
>>> your bundles in order maybe to get around those issues.
>>>
>>> 2017-05-09 14:40 GMT+02:00 Pavel <pavelka...@gmail.com>:
>>>
>>>> I wrote to Weld developers and this is the answer I got from them
>>>>
>>>> I'm not sure whether this is a PAX-CDI, Felix or Weld problem.
>>>> The only argument is what I wrote earlier:
>>>> "it is true that Weld's ClassFileUtils holds 0xfd03aa50 and 
>>>> also 
>>>> waiting in another thread to release this lock. But the weld-worker-1 
>>>> thread (which holds the lock) is in state WAITING (on object monitor) 
>>>> due to 
>>>> org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332) 
>>>> which calls m_bundleLock.wait()."
>>>>
>>>> So there is a problem - if PAX-CDI + Weld + Felix are used then bundle 
>>>> update
>>>> operation is not supported in many cases which require osgi refresh.
>>>>
>>>> The question to community - should I create pax-cdi issue as pax-cdi is 
>>>> the responsible
>>>> for creating weld containers for osgi bundles or this is the end of 
>>>> story?
>>>>
>>>> вторник, 9 мая 2017 г., 2:14:31 UTC+3 пользователь Niclas Hedhman 
>>>> написал:
>>>>>
>>>>> I see two locks in JBoss Weld. 
>>>>>
>>>>> - locked <0xfd03aa50> (a java.lang.Class for 
>>>>> org.jboss.weld.util.bytecode.ClassFileUtils)
>>>>>
>>>>>
>>>>> and I doubt that it is anything we can do about it in OPS4J to avoid 
>>>>> this.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, May 8, 2017 at 6:02 PM, Pavel <pavelka...@gmail.com> wrote:
>>>>>
>>>>>> Hi all
>>>>>>
>>>>>> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two 
>>>>>> bundles: bundleA and bundleB. 
>>>>>>
>>>>>> BundleB has CDI beans and CDI container is created for bundleB. 
>>>>>> Besides bundleB depends on bundleA.
>>>>>>
>>>>>> Now I update bundleA and do osgi refresh using this code
>>>>>>
>>>>>> Bundle systemBundle = bundleContext.getBundle(0);
>>>>>> FrameworkWiring frameworkWiring = 
>>>>>> systemBundle.adapt(FrameworkWiring.class); 
>>>>>> frameworkWiring.refreshBundles(null);
>>>>>>
>>>>>> What I see in log of bundle B.
>>>>>>
>>>>>> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>>>>> STOPPING - com.bundleB
>>>>>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>>>>>> UNREGISTERING - [java.lang.Object] - com.bundleB
>>>>>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>>>>> STOPPED - com.bundleB
>>>>>> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>>>>> UNRESOLVED - com.bu

Re: [pax-cdi] Thread dead lock with osgi refresh

[Guillaume Nodet]

Well, according to the stack trace, someone does.  I've checked weld and
pax-cdi bundles and they don't have any dynamic import.  Can you double
check all the deployed bundles ?  Maybe it's not one of you bundles, but
there's definitely at least one bundle which uses dynamic import.
One way to avoid the dynamic import resolution is to back all dynamically
imported packages by statically imported optional packages, so that they
are rather statically bound than dynamically bound.
Also, if you can easily reproduce the issue, one good way would be to put a
breakpoint in
  org.apache.felix.framework.StatefulResolver.resolve(
StatefulResolver.java:481)
and check which package cause the resolution.


2017-05-09 14:54 GMT+02:00 Pavel <pavelkastor...@gmail.com>:

> Hi Guillaume
>
> Thank you for your answer. But I don't use any dynamic-imports.
>
> вторник, 9 мая 2017 г., 15:52:03 UTC+3 пользователь Guillaume Nodet
> написал:
>>
>> Yeah, and I'm telling you that you should remove the DynamicImport from
>> your bundles in order maybe to get around those issues.
>>
>> 2017-05-09 14:40 GMT+02:00 Pavel <pavelka...@gmail.com>:
>>
>>> I wrote to Weld developers and this is the answer I got from them
>>>
>>> I'm not sure whether this is a PAX-CDI, Felix or Weld problem.
>>> The only argument is what I wrote earlier:
>>> "it is true that Weld's ClassFileUtils holds 0xfd03aa50 and also
>>> waiting in another thread to release this lock. But the weld-worker-1
>>> thread (which holds the lock) is in state WAITING (on object monitor)
>>> due to
>>> org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
>>> which calls m_bundleLock.wait()."
>>>
>>> So there is a problem - if PAX-CDI + Weld + Felix are used then bundle
>>> update
>>> operation is not supported in many cases which require osgi refresh.
>>>
>>> The question to community - should I create pax-cdi issue as pax-cdi is
>>> the responsible
>>> for creating weld containers for osgi bundles or this is the end of
>>> story?
>>>
>>> вторник, 9 мая 2017 г., 2:14:31 UTC+3 пользователь Niclas Hedhman
>>> написал:
>>>>
>>>> I see two locks in JBoss Weld.
>>>>
>>>> - locked <0xfd03aa50> (a java.lang.Class for 
>>>> org.jboss.weld.util.bytecode.ClassFileUtils)
>>>>
>>>>
>>>> and I doubt that it is anything we can do about it in OPS4J to avoid
>>>> this.
>>>>
>>>>
>>>>
>>>> On Mon, May 8, 2017 at 6:02 PM, Pavel <pavelka...@gmail.com> wrote:
>>>>
>>>>> Hi all
>>>>>
>>>>> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two
>>>>> bundles: bundleA and bundleB.
>>>>>
>>>>> BundleB has CDI beans and CDI container is created for bundleB.
>>>>> Besides bundleB depends on bundleA.
>>>>>
>>>>> Now I update bundleA and do osgi refresh using this code
>>>>>
>>>>> Bundle systemBundle = bundleContext.getBundle(0);
>>>>> FrameworkWiring frameworkWiring = 
>>>>> systemBundle.adapt(FrameworkWiring.class);
>>>>> frameworkWiring.refreshBundles(null);
>>>>>
>>>>> What I see in log of bundle B.
>>>>>
>>>>> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>>>> STOPPING - com.bundleB
>>>>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>>>>> UNREGISTERING - [java.lang.Object] - com.bundleB
>>>>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>>>> STOPPED - com.bundleB
>>>>> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>>>> UNRESOLVED - com.bundleB
>>>>> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>>>> RESOLVED - com.bundleB
>>>>> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>>>> STARTING - com.bundleB
>>>>> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>>>>> REGISTERED - [java.lang.Object] - com.bundleB
>>>>>
>>>>> Please,note that bundleB didn't change state to STARTED. When I don't use 
>>>>> in bundleB CDI
>>>>> beans and CDI container is not created for bundleB then everything is ok 
>>>>> - after bundleA
&

Re: [pax-cdi] Thread dead lock with osgi refresh

[Pavel]

Hi Guillaume

Thank you for your answer. But I don't use any dynamic-imports.

вторник, 9 мая 2017 г., 15:52:03 UTC+3 пользователь Guillaume Nodet написал:
>
> Yeah, and I'm telling you that you should remove the DynamicImport from 
> your bundles in order maybe to get around those issues.
>
> 2017-05-09 14:40 GMT+02:00 Pavel <pavelka...@gmail.com >:
>
>> I wrote to Weld developers and this is the answer I got from them
>>
>> I'm not sure whether this is a PAX-CDI, Felix or Weld problem.
>> The only argument is what I wrote earlier:
>> "it is true that Weld's ClassFileUtils holds 0xfd03aa50 and also 
>> waiting in another thread to release this lock. But the weld-worker-1 
>> thread (which holds the lock) is in state WAITING (on object monitor) 
>> due to 
>> org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332) 
>> which calls m_bundleLock.wait()."
>>
>> So there is a problem - if PAX-CDI + Weld + Felix are used then bundle 
>> update
>> operation is not supported in many cases which require osgi refresh.
>>
>> The question to community - should I create pax-cdi issue as pax-cdi is 
>> the responsible
>> for creating weld containers for osgi bundles or this is the end of story?
>>
>> вторник, 9 мая 2017 г., 2:14:31 UTC+3 пользователь Niclas Hedhman написал:
>>>
>>> I see two locks in JBoss Weld. 
>>>
>>> - locked <0xfd03aa50> (a java.lang.Class for 
>>> org.jboss.weld.util.bytecode.ClassFileUtils)
>>>
>>>
>>> and I doubt that it is anything we can do about it in OPS4J to avoid 
>>> this.
>>>
>>>
>>>
>>> On Mon, May 8, 2017 at 6:02 PM, Pavel <pavelka...@gmail.com> wrote:
>>>
>>>> Hi all
>>>>
>>>> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two 
>>>> bundles: bundleA and bundleB. 
>>>>
>>>> BundleB has CDI beans and CDI container is created for bundleB. Besides 
>>>> bundleB depends on bundleA.
>>>>
>>>> Now I update bundleA and do osgi refresh using this code
>>>>
>>>> Bundle systemBundle = bundleContext.getBundle(0);
>>>> FrameworkWiring frameworkWiring = 
>>>> systemBundle.adapt(FrameworkWiring.class); 
>>>> frameworkWiring.refreshBundles(null);
>>>>
>>>> What I see in log of bundle B.
>>>>
>>>> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>>> STOPPING - com.bundleB
>>>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>>>> UNREGISTERING - [java.lang.Object] - com.bundleB
>>>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>>> STOPPED - com.bundleB
>>>> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>>> UNRESOLVED - com.bundleB
>>>> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>>> RESOLVED - com.bundleB
>>>> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>>> STARTING - com.bundleB
>>>> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>>>> REGISTERED - [java.lang.Object] - com.bundleB
>>>>
>>>> Please,note that bundleB didn't change state to STARTED. When I don't use 
>>>> in bundleB CDI
>>>> beans and CDI container is not created for bundleB then everything is ok - 
>>>> after bundleA
>>>> update and osgi refresh bundleB reaches STARTED state.
>>>>
>>>> Is this a bug or maybe I do something wrong or something else? This is 
>>>> some thread dump:
>>>>
>>>> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
>>>> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>>>>java.lang.Thread.State: BLOCKED (on object monitor)
>>>>at 
>>>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>>>>- waiting to lock <0xfd03aa50> (a java.lang.Class for 
>>>> org.jboss.weld.util.bytecode.ClassFileUtils)
>>>>at 
>>>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
>>>>at 
>>>> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
>>>>at 
>>>> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
>>>>   

Re: [pax-cdi] Thread dead lock with osgi refresh

[Guillaume Nodet]

Yeah, and I'm telling you that you should remove the DynamicImport from
your bundles in order maybe to get around those issues.

2017-05-09 14:40 GMT+02:00 Pavel <pavelkastor...@gmail.com>:

> I wrote to Weld developers and this is the answer I got from them
>
> I'm not sure whether this is a PAX-CDI, Felix or Weld problem.
> The only argument is what I wrote earlier:
> "it is true that Weld's ClassFileUtils holds 0xfd03aa50 and also
> waiting in another thread to release this lock. But the weld-worker-1
> thread (which holds the lock) is in state WAITING (on object monitor)
> due to
> org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
> which calls m_bundleLock.wait()."
>
> So there is a problem - if PAX-CDI + Weld + Felix are used then bundle
> update
> operation is not supported in many cases which require osgi refresh.
>
> The question to community - should I create pax-cdi issue as pax-cdi is
> the responsible
> for creating weld containers for osgi bundles or this is the end of story?
>
> вторник, 9 мая 2017 г., 2:14:31 UTC+3 пользователь Niclas Hedhman написал:
>>
>> I see two locks in JBoss Weld.
>>
>> - locked <0xfd03aa50> (a java.lang.Class for 
>> org.jboss.weld.util.bytecode.ClassFileUtils)
>>
>>
>> and I doubt that it is anything we can do about it in OPS4J to avoid this.
>>
>>
>>
>> On Mon, May 8, 2017 at 6:02 PM, Pavel <pavelka...@gmail.com> wrote:
>>
>>> Hi all
>>>
>>> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two
>>> bundles: bundleA and bundleB.
>>>
>>> BundleB has CDI beans and CDI container is created for bundleB. Besides
>>> bundleB depends on bundleA.
>>>
>>> Now I update bundleA and do osgi refresh using this code
>>>
>>> Bundle systemBundle = bundleContext.getBundle(0);
>>> FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class);
>>> frameworkWiring.refreshBundles(null);
>>>
>>> What I see in log of bundle B.
>>>
>>> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>> STOPPING - com.bundleB
>>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>>> UNREGISTERING - [java.lang.Object] - com.bundleB
>>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>> STOPPED - com.bundleB
>>> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>> UNRESOLVED - com.bundleB
>>> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>> RESOLVED - com.bundleB
>>> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>> STARTING - com.bundleB
>>> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>>> REGISTERED - [java.lang.Object] - com.bundleB
>>>
>>> Please,note that bundleB didn't change state to STARTED. When I don't use 
>>> in bundleB CDI
>>> beans and CDI container is not created for bundleB then everything is ok - 
>>> after bundleA
>>> update and osgi refresh bundleB reaches STARTED state.
>>>
>>> Is this a bug or maybe I do something wrong or something else? This is some 
>>> thread dump:
>>>
>>> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
>>> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>>>java.lang.Thread.State: BLOCKED (on object monitor)
>>> at 
>>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>>> - waiting to lock <0xfd03aa50> (a java.lang.Class for 
>>> org.jboss.weld.util.bytecode.ClassFileUtils)
>>> at 
>>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
>>> at 
>>> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
>>> at 
>>> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
>>> at 
>>> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
>>> at 
>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>>> at 
>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>>> at 
>>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(Iterative

Re: [pax-cdi] Thread dead lock with osgi refresh

[Pavel]

I wrote to Weld developers and this is the answer I got from them

I'm not sure whether this is a PAX-CDI, Felix or Weld problem.
The only argument is what I wrote earlier:
"it is true that Weld's ClassFileUtils holds 0xfd03aa50 and also 
waiting in another thread to release this lock. But the weld-worker-1 
thread (which holds the lock) is in state WAITING (on object monitor) 
due to 
org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332) 
which calls m_bundleLock.wait()."

So there is a problem - if PAX-CDI + Weld + Felix are used then bundle 
update
operation is not supported in many cases which require osgi refresh.

The question to community - should I create pax-cdi issue as pax-cdi is the 
responsible
for creating weld containers for osgi bundles or this is the end of story?

вторник, 9 мая 2017 г., 2:14:31 UTC+3 пользователь Niclas Hedhman написал:
>
> I see two locks in JBoss Weld. 
>
> - locked <0xfd03aa50> (a java.lang.Class for 
> org.jboss.weld.util.bytecode.ClassFileUtils)
>
>
> and I doubt that it is anything we can do about it in OPS4J to avoid this.
>
>
>
> On Mon, May 8, 2017 at 6:02 PM, Pavel <pavelka...@gmail.com > 
> wrote:
>
>> Hi all
>>
>> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two 
>> bundles: bundleA and bundleB. 
>>
>> BundleB has CDI beans and CDI container is created for bundleB. Besides 
>> bundleB depends on bundleA.
>>
>> Now I update bundleA and do osgi refresh using this code
>>
>> Bundle systemBundle = bundleContext.getBundle(0);
>> FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class); 
>> frameworkWiring.refreshBundles(null);
>>
>> What I see in log of bundle B.
>>
>> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> STOPPING - com.bundleB
>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>> UNREGISTERING - [java.lang.Object] - com.bundleB
>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED 
>> - com.bundleB
>> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> UNRESOLVED - com.bundleB
>> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> RESOLVED - com.bundleB
>> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> STARTING - com.bundleB
>> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>> REGISTERED - [java.lang.Object] - com.bundleB
>>
>> Please,note that bundleB didn't change state to STARTED. When I don't use in 
>> bundleB CDI
>> beans and CDI container is not created for bundleB then everything is ok - 
>> after bundleA
>> update and osgi refresh bundleB reaches STARTED state.
>>
>> Is this a bug or maybe I do something wrong or something else? This is some 
>> thread dump:
>>
>> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
>> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>>java.lang.Thread.State: BLOCKED (on object monitor)
>>  at 
>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>>  - waiting to lock <0xfd03aa50> (a java.lang.Class for 
>> org.jboss.weld.util.bytecode.ClassFileUtils)
>>  at 
>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
>>  at 
>> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
>>  at 
>> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
>>  at 
>> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
>>  at 
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>>  at 
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>>  at 
>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>>  at 
>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>>  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>  at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>  at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>  at java.lang.Thread.run(Thread.java:745)
>>
>> &quo

Re: [pax-cdi] Thread dead lock with osgi refresh

[Guillaume Nodet]

You should avoid the use of dynamic imports whenever possible.  Try
removing those from your bundles.


2017-05-08 12:02 GMT+02:00 Pavel <pavelkastor...@gmail.com>:

> Hi all
>
> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two
> bundles: bundleA and bundleB.
>
> BundleB has CDI beans and CDI container is created for bundleB. Besides
> bundleB depends on bundleA.
>
> Now I update bundleA and do osgi refresh using this code
>
> Bundle systemBundle = bundleContext.getBundle(0);
> FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class);
> frameworkWiring.refreshBundles(null);
>
> What I see in log of bundle B.
>
> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPING 
> - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> UNREGISTERING - [java.lang.Object] - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED 
> - com.bundleB
> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
> UNRESOLVED - com.bundleB
> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent RESOLVED 
> - com.bundleB
> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent STARTING 
> - com.bundleB
> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> REGISTERED - [java.lang.Object] - com.bundleB
>
> Please,note that bundleB didn't change state to STARTED. When I don't use in 
> bundleB CDI
> beans and CDI container is not created for bundleB then everything is ok - 
> after bundleA
> update and osgi refresh bundleB reaches STARTED state.
>
> Is this a bug or maybe I do something wrong or something else? This is some 
> thread dump:
>
> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>   - waiting to lock <0xfd03aa50> (a java.lang.Class for 
> org.jboss.weld.util.bytecode.ClassFileUtils)
>   at 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
>   at 
> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
>   at 
> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
>   at 
> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
>   at 
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>   at 
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
>
> "weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800 
> nid=0x1dc6 in Object.wait() [0x7f3dd967e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
>   - locked <0xed6de970> (a [Ljava.lang.Object;)
>   at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:481)
>   at 
> org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1652)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1552)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925)
>   at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
>   at 
> org.apache.xbean.osgi.bundle.util.DelegatingBundle.loadClass(DelegatingBundle.java:170)
>   at 
> org.apache.xbean.osgi.bundle.ut

Re: [pax-cdi] Thread dead lock with osgi refresh

[Niclas Hedhman]

I see two locks in JBoss Weld.

- locked <0xfd03aa50> (a java.lang.Class for
org.jboss.weld.util.bytecode.ClassFileUtils)


and I doubt that it is anything we can do about it in OPS4J to avoid this.



On Mon, May 8, 2017 at 6:02 PM, Pavel <pavelkastor...@gmail.com> wrote:

> Hi all
>
> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two
> bundles: bundleA and bundleB.
>
> BundleB has CDI beans and CDI container is created for bundleB. Besides
> bundleB depends on bundleA.
>
> Now I update bundleA and do osgi refresh using this code
>
> Bundle systemBundle = bundleContext.getBundle(0);
> FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class);
> frameworkWiring.refreshBundles(null);
>
> What I see in log of bundle B.
>
> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPING 
> - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> UNREGISTERING - [java.lang.Object] - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED 
> - com.bundleB
> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
> UNRESOLVED - com.bundleB
> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent RESOLVED 
> - com.bundleB
> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent STARTING 
> - com.bundleB
> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> REGISTERED - [java.lang.Object] - com.bundleB
>
> Please,note that bundleB didn't change state to STARTED. When I don't use in 
> bundleB CDI
> beans and CDI container is not created for bundleB then everything is ok - 
> after bundleA
> update and osgi refresh bundleB reaches STARTED state.
>
> Is this a bug or maybe I do something wrong or something else? This is some 
> thread dump:
>
> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>   - waiting to lock <0xfd03aa50> (a java.lang.Class for 
> org.jboss.weld.util.bytecode.ClassFileUtils)
>   at 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
>   at 
> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
>   at 
> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
>   at 
> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
>   at 
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>   at 
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
>
> "weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800 
> nid=0x1dc6 in Object.wait() [0x7f3dd967e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
>   - locked <0xed6de970> (a [Ljava.lang.Object;)
>   at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:481)
>   at 
> org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1652)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1552)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925)
>   at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
>   at 
> org.apache.xbean.osgi.bundle.u

[pax-cdi] Thread dead lock with osgi refresh

[Pavel]

Hi all

I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two 
bundles: bundleA and bundleB. 

BundleB has CDI beans and CDI container is created for bundleB. Besides 
bundleB depends on bundleA.

Now I update bundleA and do osgi refresh using this code

Bundle systemBundle = bundleContext.getBundle(0);
FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class); 
frameworkWiring.refreshBundles(null);

What I see in log of bundle B.

2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPING - 
com.bundleB
2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
UNREGISTERING - [java.lang.Object] - com.bundleB
2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED - 
com.bundleB
2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent UNRESOLVED 
- com.bundleB
2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent RESOLVED - 
com.bundleB
2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent STARTING - 
com.bundleB
2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
REGISTERED - [java.lang.Object] - com.bundleB

Please,note that bundleB didn't change state to STARTED. When I don't use in 
bundleB CDI
beans and CDI container is not created for bundleB then everything is ok - 
after bundleA
update and osgi refresh bundleB reaches STARTED state.

Is this a bug or maybe I do something wrong or something else? This is some 
thread dump:

"weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 nid=0x1dc8 
waiting for monitor entry [0x7f3dd867a000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at 
org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
- waiting to lock <0xfd03aa50> (a java.lang.Class for 
org.jboss.weld.util.bytecode.ClassFileUtils)
at 
org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
at 
org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
at 
org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
at 
org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
at 
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
at 
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
at 
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
at 
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

"weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800 nid=0x1dc6 
in Object.wait() [0x7f3dd967e000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
- locked <0xed6de970> (a [Ljava.lang.Object;)
at 
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:481)
at 
org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1652)
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1552)
at 
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at 
org.apache.xbean.osgi.bundle.util.DelegatingBundle.loadClass(DelegatingBundle.java:170)
at 
org.apache.xbean.osgi.bundle.util.BundleClassLoader.loadClass(BundleClassLoader.java:75)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0xfb14e428> (a 
org.ops4j.pax.cdi.weld.impl.util.BundleClassLoader)
at 
org.ops4j.pax.cdi.weld.impl.util.BundleClassLoader.loadClass(BundleClassLoader.java:193)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.r

Re: [pax-cdi] Approximate plan of bug fixing

[Guillaume Nodet]

I plan to have a look at it, but it won't be before next week.
In the mean time, a nice thing would be to try writing a unit test to
demonstrate the problem.

2017-04-17 13:43 GMT+02:00 Pavel :

> Hi all
>
> Four days ago I created bug issue https://ops4j1.jira.com/browse
> /PAXCDI-231 , And from that time there is no
> any action on it. Could anyone say when approximately this bug can be
> fixed? In a week, month etc?
>
> Best regards, Pavel
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Guillaume Nodet

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pax-cdi] Approximate plan of bug fixing

[Pavel]

Hi all

Four days ago I created bug issue https://ops4j1.jira.com/browse/PAXCDI-231 
, And from that time there is no
any action on it. Could anyone say when approximately this bug can be 
fixed? In a week, month etc?

Best regards, Pavel

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] Pax-cdi 1.0.0.RC2 - > @Singleton are ignored when bean-discovery-mode="annotated"

[Pavel]

Done. https://ops4j1.jira.com/browse/PAXCDI-231

среда, 12 апреля 2017 г., 22:22:51 UTC+3 пользователь Guillaume Nodet 
написал:
>
> Could you raise a JIRA issue on pax-cdi and provide the necessary bundles 
> to replicate the problem ? A unit test would be even better ...
>
> 2017-04-12 21:17 GMT+02:00 Pavel <pavelka...@gmail.com >:
>
>> Hi all
>>
>> Before I used pax-cdi 0.13.0-SNAPSHOT with pax-web 6.0.0-SNAPSHOT with 
>> weld-osgi-bundle-2.2.12.Final.jar and I didn't have any problems.
>>
>> Today I started to use pax-cdi 1.0.0.RC2 with pax-web 6.1.0-SNAPSHOT with 
>> weld-osgi-bundle-2.3.5.Final.jar. And I have a problem -
>> when I set bean-discovery-mode="annotated" @Singleton beans are totally 
>> ignored. At the same time @Dependent and @ApplicationScoped are
>> found.
>>
>> The only information I found is 
>> https://issues.jboss.org/browse/WELD-1733?_sscc=t but it says about 
>> 2.2.4 but I used 2.2.12 on it was ok.
>>
>> This is my beans.xml
>>
>> 
>> http://xmlns.jcp.org/xml/ns/javaee;
>>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>>xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
>> http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd;
>>bean-discovery-mode="annotated">
>> 
>>
>> Could anyone advise something?
>>
>> Best regards, Pavel
>>
>>
>>
>> -- 
>> -- 
>> --
>> OPS4J - http://www.ops4j.org - op...@googlegroups.com 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ops4j+un...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> 
> Guillaume Nodet
>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] Camel RouteBuilder and CDI using pax-cdi and camel-cdi

[sorok...@gmail.com]

I'm not sure that we're quite communicating-- that beans.xml file is _not_ 
Spring. It has nothing to do with Spring. It's a CDI-specific artifact that 
just happens to have the same name as a Spring artifact. If I understand your 
situation correctly (and people with more experience at CDI than me are invited 
to correct me) you aren't using Spring at all and it's just not an issue.

You can use a Spring XML context named foo.xml or whigglesnort.xml or whatever. 
What matters is the contents. But the beans.xml for CDI _must_ be named that 
(and must be in the right place) and the contents only come into play if you 
are using alternative impl beans or other CDI features. I.e. a requisite for an 
artifact to be recognized as CDI is that name "beans.xml". That's not optional. 
The existence of a file with that name in the right place is what cues the CDI 
framework to work on the contents of that artifact.

So, no Spring to worry about.

---
A. Soroka
The University of Virginia Library



> On Mar 16, 2017, at 12:23 PM, Bob Blackard <black...@omniprise.com> wrote:
> 
> Thanks for the link.  I knew that CDI was defined by Java EE, but hadn't 
> realized that it was bound up with Spring.
> 
> So, yea, from the link you provided, it seems Spring is it.  But that doesn't 
> answer my other concerns about Spring.
> 
> Can anyone provide more insight on Spring in OSGi?  A couple of years ago I 
> had a lot of struggles with Spring in OSGi and started pushing hard to get 
> clients to adopt Blueprint.  I'm therefore somewhat uncomfortable with 
> pushing clients to adopt CDI.
> 
> Thanks
> Bob
> 
> On Thursday, March 16, 2017 at 11:13:00 AM UTC-5, A. Soroka wrote:
> I'm not in any way an expert on CDI, but are you sure that the beans.xml file 
> to which you had recourse isn't just the (normally needed) CDI beans.xml 
> file? 
> 
> https://docs.oracle.com/javaee/6/tutorial/doc/gjbnz.html 
> 
> --- 
> A. Soroka 
> The University of Virginia Library 
> 
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] Camel RouteBuilder and CDI using pax-cdi and camel-cdi

[sorok...@gmail.com]

I'm not in any way an expert on CDI, but are you sure that the beans.xml file 
to which you had recourse isn't just the (normally needed) CDI beans.xml file?

https://docs.oracle.com/javaee/6/tutorial/doc/gjbnz.html

---
A. Soroka
The University of Virginia Library



> On Mar 16, 2017, at 12:11 PM, Bob Blackard <black...@omniprise.com> wrote:
> 
> Howdy all.
> 
> I've been struggling with pax-cdi/camel-cdi trying to get a RouteBuilder to 
> trigger when the bundle is loaded.  I had tried creating my own project based 
> on the camel-example-cdi-osgi which uses pax-cdi, pax-cdi-weld and 
> camel-osgi.  Problem was, I missed the META-INF/beans.xml document, which 
> contains nothing more than .
> 
> Without that document, I could see CDI wiring itself up, but my RouteBuilder 
> wasn't getting triggered.  When I added that document, my RouteBuilder got 
> triggered.
> 
> This implies that the CDI initiator is bound, somehow, to the Spring 
> initiator.
> 
> I tried switching the META-INF/beans.xml to an 
> OSGI-INF/blueprint/blueprint.xml, containing nothing more than  xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"/>, but that didn't cause 
> my RouteBuilder to get triggered.
> 
> I generally avoid Spring when working with OSGi since, in my experience at 
> least, it doesn't play well due to classloader issues.  So, I'm left with 
> lots of questions.
> 
> Blueprint
> -
> Is there a way to use pax-cdi with a Blueprint initiator rather than a Spring 
> initiator?
> 
> Spring
> -
> Are my concerns about Spring on OSGi unfounded?  Have the classloader/wiring 
> issues that I experienced with Spring in OSGi in the past been resolved?  Is 
> that why so many people seem to be pushing Spring over Blueprint these days, 
> even though Blueprint is build to support the OSGi classloader/wiring model?  
> Is there now an OSGi-enabled classloader for Spring?
> 
> Thanks
> Bob
> 
> 
> 
> -- 
> -- 
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pax-cdi 1.0.0-RC2 missing requirements on CdiOsgi

[Jean-Baptiste Onofré]

Hi Charlie

Let me take a look.

Regards
JB

On Feb 25, 2017, 20:32, at 20:32, Charlie Mordant <cmorda...@gmail.com> wrote:
>Hi Opened guys!
>
>I'm trying the newest and greatest 1.0.0-RC2 version of pax-cdi.
>While trying to load some CDI fragments (aries tx weld transactional
>support and deltaspike configadmin property support), these fragment
>are
>unresolved (staying on an installed state).
>
>Here's the Karaf 'diag':
>
>Aries tx CDI bridge (19)
>
>
>
>Status: Installed
>
>Unsatisfied Requirements:
>
>CdiOsgi
>
>
>
>But my manifest hasn't got any requirement on it.
>
>Have you got any advice on how to fix it?
>
>I noticed another NPE in an isWebBundle(bundle) test somewhere, but one
>issue at a time ;-)
>
>
>Best regards,
>
>Charlie
>
>-- 
>-- 
>--
>OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
>--- 
>You received this message because you are subscribed to the Google
>Groups "OPS4J" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to ops4j+unsubscr...@googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

PAX-CDI: pax-cdi version and cdi specification version

[iJava]

Hi all

Could anyone say what cdi spec pax-cdi 0.13 and pax-cdi 1.0.0.RC2 support?
I took a look here https://github.com/ops4j/org.ops4j.pax.cdi  and here 
https://ops4j1.jira.com/wiki/display/paxcdi/Documentation
and still have no answer.

Best regards, Pavel

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PAX-CDI 1.0.0.RC2 - where is pax-cdi-web-weld

[iJava]

Thank you very much for you answer!

четверг, 22 декабря 2016 г., 12:46:13 UTC+3 пользователь Guillaume Nodet 
написал:
>
> It has been removed to pax-cdi-jetty-weld as this bundle is specific to 
> jetty. 
> In a similar way, you now have a pax-cdi-undertow-weld bundle.
>
> Cheers,
> Guillaume Nodet
>
> 2016-12-22 10:29 GMT+01:00 iJava <pavelka...@gmail.com >:
>
>> Hi all
>>
>> I try to migrate from pax-cdi 0.13 to 1.0.0.RC2 and now I found out that 
>> there is no
>> pax-cdi-web-weld in central repo  
>> http://central.maven.org/maven2/org/ops4j/pax/cdi/pax-cdi-web-weld/ 
>>
>> Could anyone explain why? I use weld so it is important for me.
>>
>> Best regards, Pavel
>>
>>
>> -- 
>> -- 
>> --
>> OPS4J - http://www.ops4j.org - op...@googlegroups.com 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ops4j+un...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com 
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

PAX-CDI 1.0.0.RC2 - where is pax-cdi-web-weld

[iJava]

Hi all

I try to migrate from pax-cdi 0.13 to 1.0.0.RC2 and now I found out that 
there is no
pax-cdi-web-weld in central repo  
http://central.maven.org/maven2/org/ops4j/pax/cdi/pax-cdi-web-weld/ 

Could anyone explain why? I use weld so it is important for me.

Best regards, Pavel


-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Pax-Web 4.4.0 and Pax-Cdi 1.0.0.RC2 released

['Achim Nierbeck' via OPS4J]

Hi Marc,

maybe it did take a bit longer but RC2 is available from central
http://search.maven.org/#artifactdetails%7Corg.ops4j.pax%7Ccdi%7C1.0.0.RC2%7Cpom

regards, Achim


2016-10-19 17:21 GMT+02:00 Marc Schlegel <maschle...@gmail.com>:

> I was going to give it a test-drive, unfortunately the build broke [1].
> Currently only RC1 is available on Central [2].
>
> [1] http://ci.ops4j.org/jenkins/job/org.ops4j.pax.cdi/
> [2] https://mvnrepository.com/artifact/org.ops4j.pax.cdi/pax-cdi-api
>
> regards
> Marc
>
>
> Am Mittwoch, 19. Oktober 2016 11:48:04 UTC+2 schrieb Guillaume Nodet:
>>
>> They are available on maven central !
>>
>> --
>> 
>> Guillaume Nodet
>> 
>> Red Hat, Open Source Integration
>>
>> Email: gno...@redhat.com
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>
>> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Pax-Web 4.4.0 and Pax-Cdi 1.0.0.RC2 released

[Marc Schlegel]

I was going to give it a test-drive, unfortunately the build broke [1]. 
Currently only RC1 is available on Central [2].

[1] http://ci.ops4j.org/jenkins/job/org.ops4j.pax.cdi/
[2] https://mvnrepository.com/artifact/org.ops4j.pax.cdi/pax-cdi-api

regards
Marc


Am Mittwoch, 19. Oktober 2016 11:48:04 UTC+2 schrieb Guillaume Nodet:
>
> They are available on maven central !
>
> -- 
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com 
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Pax-Web 4.4.0 and Pax-Cdi 1.0.0.RC2 released

[Guillaume Nodet]

They are available on maven central !

-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Pax-Cdi/Web] JSF cannot access CdiBean

[Marc Schlegel]

Just saw your comment on the Jira issue. I will go ahead and create an 
integration-test for Pax-Web 4.4.0-SNAPSHOT with the latest Pax-Cdi 
snapshot.

Am Mittwoch, 12. Oktober 2016 15:46:37 UTC+2 schrieb Marc Schlegel:
>
> Awesome, thank you very much.
>
> I think it would be enough to use the sample provided by pax-cdi [1].
>
> What I am wondering is, that the web-implementations in pax-cdi (currently 
> Jetty and Undertow) use different approaches: for example, 
> pax-cdi-web-undertow-weld provides a faces-config [2] while the others 
> dont. That's why I am currently trying to get my examples to run on 
> Undertow rather than Jetty, hoping that this might solve the issue.
>
> If you need another example/integration-test for pax-web I can create one.
>
> regards
> Marc
>
> [1] 
> https://github.com/ops4j/org.ops4j.pax.cdi/tree/master/pax-cdi-samples/pax-cdi-sample4-jsf
> [2] 
> https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-cdi-undertow-weld/src/main/resources/META-INF/faces-config.xml
>
> Am Mittwoch, 12. Oktober 2016 14:48:32 UTC+2 schrieb Guillaume Nodet:
>>
>> I'm willing to investigate this issue.
>> Can someone come up with a complete list of features / bundles to install 
>> to reproduce the problem ?
>>
>> Guillaume
>>
>> Le mardi 17 mai 2016 13:21:42 UTC+2, Marc Schlegel a écrit :
>>>
>>> Is there anything we can do about PAXCDI-210 
>>> <https://ops4j1.jira.com/projects/PAXCDI/issues/PAXCDI-210>?
>>>
>>> I came accross this issue today as well while updating a JSF-example 
>>> (using Pax-Web) to use CDI-Beans instead of the old ManagedBeans. The 
>>> JSF-expression cannot resolve the Cdi-bean.
>>>
>>> It seems that Pax-Web doesnt know that Pax-Cdi is managing the beans.
>>>
>>> regards
>>> Marc
>>>
>>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Pax-Cdi/Web] JSF cannot access CdiBean

[Guillaume Nodet]

I'm willing to investigate this issue.
Can someone come up with a complete list of features / bundles to install 
to reproduce the problem ?

Guillaume

Le mardi 17 mai 2016 13:21:42 UTC+2, Marc Schlegel a écrit :
>
> Is there anything we can do about PAXCDI-210 
> <https://ops4j1.jira.com/projects/PAXCDI/issues/PAXCDI-210>?
>
> I came accross this issue today as well while updating a JSF-example 
> (using Pax-Web) to use CDI-Beans instead of the old ManagedBeans. The 
> JSF-expression cannot resolve the Cdi-bean.
>
> It seems that Pax-Web doesnt know that Pax-Cdi is managing the beans.
>
> regards
> Marc
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pax-CDI (1.0.0-SNAPSHOT): How to inject OSGi-Service in Bean

[Marc Schlegel]

Thanks for the clarification Guillaume.

I expected @OsgiService to be deprecated in the new release, but it is 
working. I guess @OsgiService is prone to service-damping since the 
cdi-bean is managed by Weld/OWB. Is that still the case (there were some 
discussions on the osgi-dev list)?

Personally I am mostly using DS, but in order to migrate some bigger 
JEE-Applications towards OSGi it would be great if the developers could 
keep their favored component-model (in our case CDI) and inject services.
Now I am only stuck with PAXCDI-210.

regards
Marc

Am Donnerstag, 6. Oktober 2016 09:05:56 UTC+2 schrieb Guillaume Nodet:
>
>
>
> Le mercredi 5 octobre 2016 18:33:51 UTC+2, Marc Schlegel a écrit :
>>
>> I am still trying to figure out how to use Pax-CDI with JSF in Pax-Web.
>>
>> *When I inject a OSGi-Service in a CDI-Bean I get a IllegalStateException*
>>
>> java.lang.IllegalArgumentException: Beans with @Service, @Component or 
>> @Config injection points should be annotated with @Component
>>
>> @RequestScoped
>> @Named("loginController")
>> public class LoginController {
>>
>>   private String username;
>>   private String password;
>>   
>>   @Inject 
>>   @Service
>>   private LoginService loginService;
>>
>> How would I inject an OSGi-Service in a scoped bean? 
>>
>
> So you have two possibilities:
>   * either you annotate the bean with @Component, and eventually with a 
> scope in @SingletonScoped, @BundleScoped or @PrototypeScoped.  In such a 
> case, the lifecycle is managed by pax-cdi and your bean will be created / 
> destroyed according to the availability of the LoginService osgi service
>   * or you annotated your injection point with the additional @Global 
> annotation.  
> In such a case, your entire application lifecycle will be conditionned by 
> the availability of the LoginService, i.e. it won't start until the service 
> is available.
>
> Note that in both cases, you can annotate your injection point with 
> @Optional or @Greedy to further modify the behaviour.
>  
>
>> I think that was possible with version 0.13.0 by using 
>>
>> @Inject @OsgiService
>> private LoginService loginService;
>>
>>
>>
> You should still be able to use this annotation.
>
> Guillaume
>  
>
>> Should I file a bug or am I missing something?
>>
>> regards
>> Marc
>>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pax-CDI (1.0.0-SNAPSHOT): How to inject OSGi-Service in Bean

[Marc Schlegel]

You're right. Until (including) 1.0.0-RC1 a Service was registered using 
@OsgiServiceProvider and the Qualifier for the injection-point was 
@OsgiService.
This was changed in the Snapshot to the following

@Service
@Component
public class CdiServiceBean implements CdiService {

  @Inject
  @Service
  private SomeOtherOsgiService service;

So, a OsgiService is registered with @Component + @Service while @Service 
is also used as a Qualifier for the injection-point. In this case it works 
because CdiServiceBean is a CDI-OsgiService. Using a Enterprise-Bean (e.g. 
@ReguestScoped) the @Service annotation cannot be used.

Either I am missing something, or OSGi-Service-injection in plain cdi-beans 
is not supported.

regards
Marc


Am Mittwoch, 5. Oktober 2016 21:57:06 UTC+2 schrieb Achim Nierbeck:
>
> Hi, 
>
> I'm not sure but didn't the osgi service injection change with the 
> 1.0.0-SNAPSHOT ?
> Could be another annotation now. 
>
> regards, Achim 
>
>
> 2016-10-05 18:33 GMT+02:00 Marc Schlegel <masch...@gmail.com 
> >:
>
>> I am still trying to figure out how to use Pax-CDI with JSF in Pax-Web.
>>
>> *When I inject a OSGi-Service in a CDI-Bean I get a IllegalStateException*
>>
>> java.lang.IllegalArgumentException: Beans with @Service, @Component or 
>> @Config injection points should be annotated with @Component
>>
>> @RequestScoped
>> @Named("loginController")
>> public class LoginController {
>>
>>   private String username;
>>   private String password;
>>   
>>   @Inject 
>>   @Service
>>   private LoginService loginService;
>>
>> How would I inject an OSGi-Service in a scoped bean? I think that was 
>> possible with version 0.13.0 by using 
>>
>> @Inject @OsgiService
>> private LoginService loginService;
>>
>>
>> Should I file a bug or am I missing something?
>>
>> regards
>> Marc
>>
>> -- 
>> -- 
>> --
>> OPS4J - http://www.ops4j.org - op...@googlegroups.com 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ops4j+un...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & 
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master 
>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pax-CDI (1.0.0-SNAPSHOT): How to inject OSGi-Service in Bean

['Achim Nierbeck' via OPS4J]

Hi,

I'm not sure but didn't the osgi service injection change with the
1.0.0-SNAPSHOT ?
Could be another annotation now.

regards, Achim


2016-10-05 18:33 GMT+02:00 Marc Schlegel <maschle...@gmail.com>:

> I am still trying to figure out how to use Pax-CDI with JSF in Pax-Web.
>
> *When I inject a OSGi-Service in a CDI-Bean I get a IllegalStateException*
>
> java.lang.IllegalArgumentException: Beans with @Service, @Component or
> @Config injection points should be annotated with @Component
>
> @RequestScoped
> @Named("loginController")
> public class LoginController {
>
>   private String username;
>   private String password;
>
>   @Inject
>   @Service
>   private LoginService loginService;
>
> How would I inject an OSGi-Service in a scoped bean? I think that was
> possible with version 0.13.0 by using
>
> @Inject @OsgiService
> private LoginService loginService;
>
>
> Should I file a bug or am I missing something?
>
> regards
> Marc
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pax-CDI (1.0.0-SNAPSHOT): How to inject OSGi-Service in Bean

[Marc Schlegel]

I am still trying to figure out how to use Pax-CDI with JSF in Pax-Web.

*When I inject a OSGi-Service in a CDI-Bean I get a IllegalStateException*

java.lang.IllegalArgumentException: Beans with @Service, @Component or 
@Config injection points should be annotated with @Component

@RequestScoped
@Named("loginController")
public class LoginController {

  private String username;
  private String password;
  
  @Inject 
  @Service
  private LoginService loginService;

How would I inject an OSGi-Service in a scoped bean? I think that was 
possible with version 0.13.0 by using 

@Inject @OsgiService
private LoginService loginService;


Should I file a bug or am I missing something?

regards
Marc

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pax CDI and Camel...testing...

[Brad Johnson]

It makes me wonder if since this is still in RC if the @OSGiServiceProvider
and @OSGiService shouldn't just be removed.  Or, at the very least, market
as deprecated.

On Tue, Sep 6, 2016 at 10:53 AM, Brad Johnson <brad.john...@mediadriver.com>
wrote:

> A very cool.  Thank you.  I'll give that a shot.  And I agree with 100%
> that having to specify a start order is a recipe for spaghetti and circular
> dependencies that could make you pull your hair out.
>
> On Mon, Sep 5, 2016 at 2:47 PM, Guillaume Nodet <gno...@gmail.com> wrote:
>
>> Yeah, that looks one of the big limitation of pax-cdi 1.0.0.RC1.
>> The problem is that the bean validation will fail if the service is not
>> available in the OSGi registry.
>> This implies that the bundle have to be started in the correct order,
>> which imho is a REALLY bad idea.
>>
>> In order to fix this problem along with some other problems, I've defined
>> a new set of annotations which is available in 1.0.0-SNAPSHOT (not released
>> yet).  Those are modeled closely to the OSGi DS semantics.
>>
>> So try with
>> @Inject @Service  private DataStore datastore;
>> on on the service implementation:
>> @Service @Component
>>   public class DevelopmentDataStoreImpl implements DataStore {
>>
>> If you have any problem, let me know and I'll fix it.
>>
>>
>> On Sat, Sep 3, 2016 at 5:50 PM, Brad Johnson <
>> brad.john...@mediadriver.com> wrote:
>>
>>> I've been using the 2.17 update of Camel that more closely integrates
>>> CDI 1.2 and specifically Pax CDI.  I'm quite impressed with and look
>>> forward to using it in the years ahead.  I've used blueprint for quite
>>> awhile and while it works well enough the CDI simply makes development much
>>> easier and testing is a snap.
>>>
>>> One problem I've run into is with the CDI testing framework.  Within
>>> bundle tests or even bundles listed as dependencies work just fine.  But
>>> when I try to use the @OsgiServiceProvider and @OsgiService I run into some
>>> problems.  It may simply be that the regular CDI runner with Weld isn't
>>> appropriate for testing service export and import.
>>>
>>> From what I can tell I'm either missing a library dependency or the CDI
>>> test even within bundle will not respect the pick up or use the annotations.
>>>
>>> The @Inject in this unit test shows a squiggly yellow underline
>>> indicating it can't find anything to inject.
>>>
>>> @RunWith(CamelCdiRunner.class)
>>> public class DevelopmentDataStoreTest {
>>>
>>> @Inject
>>> @OsgiService
>>> private DataStore datastore;
>>>
>>> In the same bundle I have am Impl of the DataStore interface that looks
>>> like this:
>>>
>>> @Singleton
>>> @OsgiServiceProvider
>>> public class DevelopmentDataStoreImpl implements DataStore {
>>>
>>> I've tried a number of different permutations such as adding a
>>> dynamic=true to the OsgiService annotation.
>>>
>>> The stack trace on the test seems to indicate that it understand what it
>>> is I want to do but I don't have something right about it (italics are
>>> mine).
>>>
>>> ELD-001408: Unsatisfied dependencies for type DataStore with qualifiers
>>> @OsgiService
>>>   at injection point [BackedAnnotatedField] @Inject @OsgiService private
>>> org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTest.datastore
>>>   at org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTes
>>> t.datastore(DevelopmentDataStoreTest.java:0)
>>> WELD-001475: *The following beans match by type, but none have matching
>>> qualifiers:*
>>> *  - Managed Bean [class
>>> org.enjekt.panda.developmentdatastore.DevelopmentDataStoreImpl] with
>>> qualifiers [@OsgiServiceProvider @Any]*
>>>
>>> Italics are mine. So something is off about my annotations. Should the
>>> OsgiServiceProvider be scoped differently?  For in bundle testing like this
>>> I could use @Named("dataStore") and inject it that way.
>>>
>>>
>>> My imports look like the following:
>>> 
>>> javax.enterprise
>>> cdi-api
>>> ${cdi.version}
>>> 
>>> 
>>> org.ops4j.pax.cdi
>>> pax-cdi-api
>>> 1.0.0.RC1
>>> 
>>> 
>>> org.apache.camel
>>> camel-cdi
>>> ${camel.version}
>>> 2.17.3
>>> 
>>>
>>> 
>>> 
>>> o

Re: Pax CDI and Camel...testing...

[Brad Johnson]

A very cool.  Thank you.  I'll give that a shot.  And I agree with 100%
that having to specify a start order is a recipe for spaghetti and circular
dependencies that could make you pull your hair out.

On Mon, Sep 5, 2016 at 2:47 PM, Guillaume Nodet <gno...@gmail.com> wrote:

> Yeah, that looks one of the big limitation of pax-cdi 1.0.0.RC1.
> The problem is that the bean validation will fail if the service is not
> available in the OSGi registry.
> This implies that the bundle have to be started in the correct order,
> which imho is a REALLY bad idea.
>
> In order to fix this problem along with some other problems, I've defined
> a new set of annotations which is available in 1.0.0-SNAPSHOT (not released
> yet).  Those are modeled closely to the OSGi DS semantics.
>
> So try with
> @Inject @Service  private DataStore datastore;
> on on the service implementation:
> @Service @Component
>   public class DevelopmentDataStoreImpl implements DataStore {
>
> If you have any problem, let me know and I'll fix it.
>
>
> On Sat, Sep 3, 2016 at 5:50 PM, Brad Johnson <brad.john...@mediadriver.com
> > wrote:
>
>> I've been using the 2.17 update of Camel that more closely integrates CDI
>> 1.2 and specifically Pax CDI.  I'm quite impressed with and look forward to
>> using it in the years ahead.  I've used blueprint for quite awhile and
>> while it works well enough the CDI simply makes development much easier and
>> testing is a snap.
>>
>> One problem I've run into is with the CDI testing framework.  Within
>> bundle tests or even bundles listed as dependencies work just fine.  But
>> when I try to use the @OsgiServiceProvider and @OsgiService I run into some
>> problems.  It may simply be that the regular CDI runner with Weld isn't
>> appropriate for testing service export and import.
>>
>> From what I can tell I'm either missing a library dependency or the CDI
>> test even within bundle will not respect the pick up or use the annotations.
>>
>> The @Inject in this unit test shows a squiggly yellow underline
>> indicating it can't find anything to inject.
>>
>> @RunWith(CamelCdiRunner.class)
>> public class DevelopmentDataStoreTest {
>>
>> @Inject
>> @OsgiService
>> private DataStore datastore;
>>
>> In the same bundle I have am Impl of the DataStore interface that looks
>> like this:
>>
>> @Singleton
>> @OsgiServiceProvider
>> public class DevelopmentDataStoreImpl implements DataStore {
>>
>> I've tried a number of different permutations such as adding a
>> dynamic=true to the OsgiService annotation.
>>
>> The stack trace on the test seems to indicate that it understand what it
>> is I want to do but I don't have something right about it (italics are
>> mine).
>>
>> ELD-001408: Unsatisfied dependencies for type DataStore with qualifiers
>> @OsgiService
>>   at injection point [BackedAnnotatedField] @Inject @OsgiService private
>> org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTest.datastore
>>   at org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTes
>> t.datastore(DevelopmentDataStoreTest.java:0)
>> WELD-001475: *The following beans match by type, but none have matching
>> qualifiers:*
>> *  - Managed Bean [class
>> org.enjekt.panda.developmentdatastore.DevelopmentDataStoreImpl] with
>> qualifiers [@OsgiServiceProvider @Any]*
>>
>> Italics are mine. So something is off about my annotations. Should the
>> OsgiServiceProvider be scoped differently?  For in bundle testing like this
>> I could use @Named("dataStore") and inject it that way.
>>
>>
>> My imports look like the following:
>> 
>> javax.enterprise
>> cdi-api
>> ${cdi.version}
>> 
>> 
>> org.ops4j.pax.cdi
>> pax-cdi-api
>> 1.0.0.RC1
>> 
>> 
>> org.apache.camel
>> camel-cdi
>> ${camel.version}
>> 2.17.3
>> 
>>
>> 
>> 
>> org.apache.camel
>> camel-test-cdi
>> ${camel.version}
>> test
>> 
>>
>> Any help is appreciated.
>>
>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to ops4j+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> --
> --
> OPS4J - http:/

Re: Pax CDI and Camel...testing...

[Ranx0r0x]

While I find this less than ideal, until I get to know how CDI in general 
and Pax CDI specifically work, I've modified my DatastoreImpl class to have 
a @Produces annotation with a "factory" method for lack of a better name.

While this facilitates testing locally and lets me inject the interface via 
a standard @Inject annotation, I'm not sure if this will have ramifications 
when I install it in Karaf.  If this works for both testing and deployment 
I'm cool with it.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pax CDI and Camel...testing...

[Brad Johnson]

While not ideal, if I just remove the @OsgiService from the unit test it 
injects because it is within the same bundle.  I'll likely have to use a 
different testing mechanism to get the provider/service injection to work. 
I've also added this to make sure the service is exported the way I want 
from the bundle.  This more like what I'd do in blueprint and if I have it 
right the Pax CDI is using the same proxy mechanism as blueprint.

@OsgiServiceProvider(classes = {DataStore.class})

On Saturday, September 3, 2016 at 10:50:03 AM UTC-5, Brad Johnson wrote:
>
> I've been using the 2.17 update of Camel that more closely integrates CDI 
> 1.2 and specifically Pax CDI.  I'm quite impressed with and look forward to 
> using it in the years ahead.  I've used blueprint for quite awhile and 
> while it works well enough the CDI simply makes development much easier and 
> testing is a snap.
>
> One problem I've run into is with the CDI testing framework.  Within 
> bundle tests or even bundles listed as dependencies work just fine.  But 
> when I try to use the @OsgiServiceProvider and @OsgiService I run into some 
> problems.  It may simply be that the regular CDI runner with Weld isn't 
> appropriate for testing service export and import.
>
> From what I can tell I'm either missing a library dependency or the CDI 
> test even within bundle will not respect the pick up or use the annotations.
>
> The @Inject in this unit test shows a squiggly yellow underline indicating 
> it can't find anything to inject.
>
> @RunWith(CamelCdiRunner.class)
> public class DevelopmentDataStoreTest {
>
> @Inject
> @OsgiService
> private DataStore datastore;
>
> In the same bundle I have am Impl of the DataStore interface that looks 
> like this:
>
> @Singleton
> @OsgiServiceProvider
> public class DevelopmentDataStoreImpl implements DataStore {
>
> I've tried a number of different permutations such as adding a 
> dynamic=true to the OsgiService annotation.
>
> The stack trace on the test seems to indicate that it understand what it 
> is I want to do but I don't have something right about it (italics are 
> mine).
>
> ELD-001408: Unsatisfied dependencies for type DataStore with qualifiers 
> @OsgiService
>   at injection point [BackedAnnotatedField] @Inject @OsgiService private 
> org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTest.datastore
>   at 
> org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTest.datastore(DevelopmentDataStoreTest.java:0)
> WELD-001475: *The following beans match by type, but none have matching 
> qualifiers:*
> *  - Managed Bean [class 
> org.enjekt.panda.developmentdatastore.DevelopmentDataStoreImpl] with 
> qualifiers [@OsgiServiceProvider @Any]*
>
> Italics are mine. So something is off about my annotations. Should the 
> OsgiServiceProvider be scoped differently?  For in bundle testing like this 
> I could use @Named("dataStore") and inject it that way.
>
>
> My imports look like the following:
> 
> javax.enterprise
> cdi-api
> ${cdi.version}
> 
> 
> org.ops4j.pax.cdi
> pax-cdi-api
> 1.0.0.RC1
> 
> 
> org.apache.camel
> camel-cdi
> ${camel.version}
> 2.17.3
> 
>
> 
> 
> org.apache.camel
> camel-test-cdi
> ${camel.version}
> test
> 
>
> Any help is appreciated.
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pax CDI and Camel...testing...

[Brad Johnson]

I've been using the 2.17 update of Camel that more closely integrates CDI 
1.2 and specifically Pax CDI.  I'm quite impressed with and look forward to 
using it in the years ahead.  I've used blueprint for quite awhile and 
while it works well enough the CDI simply makes development much easier and 
testing is a snap.

One problem I've run into is with the CDI testing framework.  Within bundle 
tests or even bundles listed as dependencies work just fine.  But when I 
try to use the @OsgiServiceProvider and @OsgiService I run into some 
problems.  It may simply be that the regular CDI runner with Weld isn't 
appropriate for testing service export and import.

>From what I can tell I'm either missing a library dependency or the CDI 
test even within bundle will not respect the pick up or use the annotations.

The @Inject in this unit test shows a squiggly yellow underline indicating 
it can't find anything to inject.

@RunWith(CamelCdiRunner.class)
public class DevelopmentDataStoreTest {

@Inject
@OsgiService
private DataStore datastore;

In the same bundle I have am Impl of the DataStore interface that looks 
like this:

@Singleton
@OsgiServiceProvider
public class DevelopmentDataStoreImpl implements DataStore {

I've tried a number of different permutations such as adding a dynamic=true 
to the OsgiService annotation.

The stack trace on the test seems to indicate that it understand what it is 
I want to do but I don't have something right about it (italics are mine).

ELD-001408: Unsatisfied dependencies for type DataStore with qualifiers 
@OsgiService
  at injection point [BackedAnnotatedField] @Inject @OsgiService private 
org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTest.datastore
  at 
org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTest.datastore(DevelopmentDataStoreTest.java:0)
WELD-001475: *The following beans match by type, but none have matching 
qualifiers:*
*  - Managed Bean [class 
org.enjekt.panda.developmentdatastore.DevelopmentDataStoreImpl] with 
qualifiers [@OsgiServiceProvider @Any]*

Italics are mine. So something is off about my annotations. Should the 
OsgiServiceProvider be scoped differently?  For in bundle testing like this 
I could use @Named("dataStore") and inject it that way.


My imports look like the following:

javax.enterprise
cdi-api
${cdi.version}


org.ops4j.pax.cdi
pax-cdi-api
1.0.0.RC1


org.apache.camel
camel-cdi
${camel.version}
2.17.3




org.apache.camel
camel-test-cdi
${camel.version}
test


Any help is appreciated.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PAX-CDI+PAX-WEB: org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308: Unable to resolve any beans for Type

[iJava]

Please, any hint. The problem still not solved...

On Friday, 2 September 2016 15:27:05 UTC+3, iJava wrote:
>
> Hi all,
>
> I have a very very bad problem with pax-cdi and pax-web. My configuration: 
> jetty 9.3.11.v20160721, weld 2.2.12.Final, pax-cdi 0.13.0-SNAPSHOT, 
> pax-swissbox 1.8.0 , pax-web 6.0.0-SNAPSHOT.
>
> The problem is that the SAME war bundle sometimes works fine, sometimes I 
> get the exception:
>
> org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308: 
> Unable to resolve any beans for Type: class com.example.SomeClass; 
> Qualifiers: [@javax.enterprise.inject.Any()]
> at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:101)
>
> When I set logging level to debug - I see in weld log file that class 
> com.example.SomeClass is found with qualifiers Any and Default.
>
> However, when logging level is set to debug and everything works much 
> slower I don't get this exception. However, when I set
> logging level to warn and everything works fast I SOMETIMES get this 
> exception. So it may be about timing???
>
> Please, any help and hints
>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

PAX-CDI+PAX-WEB: org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308: Unable to resolve any beans for Type

[iJava]

Hi all,

I have a very very bad problem with pax-cdi and pax-web. My configuration: 
jetty 9.3.11.v20160721, weld 2.2.12.Final, pax-cdi 0.13.0-SNAPSHOT, 
pax-swissbox 1.8.0 , pax-web 6.0.0-SNAPSHOT.

The problem is that the SAME war bundle sometimes works fine, sometimes I 
get the exception:

org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308: 
Unable to resolve any beans for Type: class com.example.SomeClass; 
Qualifiers: [@javax.enterprise.inject.Any()]
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:101)

When I set logging level to debug - I see in weld log file that class 
com.example.SomeClass is found with qualifiers Any and Default.

However, when logging level is set to debug and everything works much 
slower I don't get this exception. However, when I set
logging level to warn and everything works fast I SOMETIMES get this 
exception. So it may be about timing???

Please, any help and hints

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PAX-CDI] Which Version to use

[Guillaume Nodet]

I've pushed quite a lot of changes to the master branch in the past
months.  The version is 1.0.0-SNAPSHOT.

There's no 1.0.0 release afaik, but a 1.0.0.RC1.
I'd like to release a RC2 with all my changes.

I've no idea where the 0.13-SNAPSHOT comes from.  Where did you see it ? It
must be an old snapshot.

Le jeudi 25 août 2016, Marc Schlegel <maschle...@gmail.com> a écrit :

> Hello everyone
>
> Since there are currently some questions about which version
> from Pax-CDI is currently under development and which one should be used in
> certain environments [1] I thought it would be usefull to pull this to its
> own thread.
>
> For example, in one of my examples I upgraded the dependency to 1.0.0 as
> well, but it seems this is not the latest release.
> Can someone from the Pax-CDI team clarify which version should be used
> regarding the split between 0.10.0 -> 1.0.0 -> 0.13.0-Snapshot? It seems
> that 0.13.0-Snapshot is the current development version.
>
> regards
> Marc
>
>
> [1] https://groups.google.com/d/msg/ops4j/q8A4qniAtCg/J8-c2LDXBgAJ
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
> <javascript:_e(%7B%7D,'cvml','ops4j@googlegroups.com');>
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com
> <javascript:_e(%7B%7D,'cvml','ops4j%2bunsubscr...@googlegroups.com');>.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PAX-WEB 6.0 - what version if pax cdi can it work with?

[iJava]

Thank you for your answer. I tried pax-cdi 1.0.0 with pax-web 6. But the 
pax-cdi said it can't find pax-web 4. Won't pax-cdi 0.13 say the same?
Have you already tried to work with both of them?

On Monday, 22 August 2016 21:31:27 UTC+3, Achim Nierbeck wrote:
>
> Hi, 
>
> right now I don't think we have a version at hand that could be called 
> out-of-the-box tested and verified. 
> My best bet right now is to go with the next 0.13-SNAPSHOT version and 
> test the both together. 
>
> regards, Achim 
>
>
> 2016-08-22 16:05 GMT+02:00 iJava <pavelka...@gmail.com >:
>
>> Hi all,
>>
>> I know that pax-web 6 is not released yet. However, can anyone say what 
>> version of pax-cdi it works with? 
>>
>> -- 
>> -- 
>> --
>> OPS4J - http://www.ops4j.org - op...@googlegroups.com 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ops4j+un...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & 
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master 
>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How can I register on pax-cdi jira?

[iJava]

Hi, Niclas.

Yes, I read that message and that's why wrote here. Please, add me. What 
should I do?

On Friday, 19 August 2016 11:01:02 UTC+3, Niclas Hedhman wrote:
>
> At top of https://ops4j1.jira.com/ the following message has been posted;
> 
> Due to users using Jira to post their SPAM, self registration of users has 
> been disabled. Please contact us on 
> https://groups.google.com/forum/#!forum/ops4j
> 
>
> I am not sure who is supposed to handle this, but if no one yells within 
> an hour, I think I can add you...
>
> Cheers
>
> On Fri, Aug 19, 2016 at 3:22 PM, iJava <pavelka...@gmail.com 
> > wrote:
>
>> Hi, how can I create account on pax-cdi jira?
>>
>> -- 
>> -- 
>> --
>> OPS4J - http://www.ops4j.org - op...@googlegroups.com 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ops4j+un...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How can I register on pax-cdi jira?

[Niclas Hedhman]

At top of https://ops4j1.jira.com/ the following message has been posted;

Due to users using Jira to post their SPAM, self registration of users has
been disabled. Please contact us on
https://groups.google.com/forum/#!forum/ops4j


I am not sure who is supposed to handle this, but if no one yells within an
hour, I think I can add you...

Cheers

On Fri, Aug 19, 2016 at 3:22 PM, iJava <pavelkastor...@gmail.com> wrote:

> Hi, how can I create account on pax-cdi jira?
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PAX -WEB/CDI: how to stop war bundle with CDI?

[Marc Schlegel]

Just to give some advice here.

If you could create a Gihub-repository and upload your example we might be 
able to help.

CDI is currently work-in-progess. On the Aries Mailinglists are some 
discussions about CDI+DS integration and how to handle those proxies CDI is 
based on. 
Now, this might be a stupid advice: if you currently dont really need CDI, 
use Declarative Services because this also takes the OSGi dynamics into 
account. CDI is JEE and therefore makes different assumptions (in JEE 
everything is basically static after its started).

regards
Marc

Am Donnerstag, 18. August 2016 10:58:29 UTC+2 schrieb Achim Nierbeck:
>
>
>
> 2016-08-18 10:50 GMT+02:00 iJava <pavelka...@gmail.com >:
>
>>
>>
>> On Thursday, 18 August 2016 11:35:27 UTC+3, Achim Nierbeck wrote:
>>>
>>> Well writing UPPER Case is kind of barking/shouting ... 
>>> besides I tried my best to help as far as I can while doing my day$ Job 
>>> or being on vacation. 
>>>
>>> UPPER CASE IS USED TO ACCENT SOME THINGS. 
>>
>
> writing all upper case is called rude, please see this: 
> https://in.answers.yahoo.com/question/index?qid=20070718202452AAHIRQL
>
> One word might be highlighting ... a full sentence is screaming ... 
>  
>
>>  
>>
>>> TBH ... if you think it's no complicated task and just a bug, please 
>>> provide a PullRequest so we can fix it. It's OpenSource 
>>> and free in terms of free knowledge and not free beer. 
>>>
>>> I find it rather harsh criticizing this community / me  of being not 
>>> helpful or "in time" of fixing bugs. Please re-think your usage of open 
>>> source software. Get yourself engaged, people here are working on it in 
>>> their free time and if you want to have a full blown support go somewhere 
>>> and buy yourself a product for a couple of thousands of dollars. 
>>>
>>
>> No one criticized community. Where did you take it from? PLEASE, READ 
>> CAREFULLY WHAT I WRITE.
>>
>
> yes you did and I'm citing just the email I answered to ... 
>
>
> I am not speaking about some complicated taks. I am speaking about the 
>> simplest - stop/start bundle on osgi.
>> I have some doubts already about pax-web. If no one from OPS4J community 
>> has time/wish to help with their products
>> then just honestly say - the product is not mature, it has a lot of bugs, 
>> if you need to fix them - then fix, no one currently can help you.
>
>
>  
> this for me is criticizing the community and saying this is a bad product 
> ...
>
> I know how it is difficult to develop a software product and how many 
>> thousand of hours it requires. I see that the community did enormous work.
>> And I am thankful to community for allowing me to use this product. 
>> But I said quite different thing. I started use this product (because 
>> you, Achim, offered me it on SO). I have serious problems with the CORE 
>> functionality. 
>> I applied to community. The problem is not solved. Only facts, not any 
>> emotions, claims etc. I am alone with my problem.
>>
>
> sorry that you feel alone with your issue, but it's very hard without a 
> concrete example to verify this in a 2h window in the evening, after a full 
> day of work  
> I might be repeating myself ... community is about give and take ... till 
> know you've taken. If you want more you need to give us something in turn. 
> A Integration test for example so the community is able to understand your 
> issue. 
>  
>
>>  
>>
>>> About matureness of the product ... well afaik PaxWeb is in productional 
>>> use by Talend ESB, RetHat - FUSE ESB and in projects like OpenDaylight
>>>
>>> If you see an issue please report it on Jira, please provide an easy way 
>>> of reproduction (I'm not talking of a list of jars to use) - I won't use my 
>>> spare time to re-create an issue reported if it requires me a full working 
>>> day to just try to do a setup of that. 
>>>
>>> Next way of partricipitation is to provide an pull-request. If you're 
>>> not willing to help the community with that (actually being part of the 
>>> community instead of just consuming) don't expect people jumping in to help 
>>> more. 
>>>
>>> If you don't have a Jira user by now, just give me the details about how 
>>> you want to be registered, as we needed to close the self-registration due 
>>> to Spammers using our Jira system for spamming (go figure why one want's to 
>>> do that) 
>>>
>>> Thanks, Achim 
>>>
>>>
>>

Re: PAX -WEB/CDI: how to stop war bundle with CDI?

['Achim Nierbeck' via OPS4J]

2016-08-18 10:50 GMT+02:00 iJava <pavelkastor...@gmail.com>:

>
>
> On Thursday, 18 August 2016 11:35:27 UTC+3, Achim Nierbeck wrote:
>>
>> Well writing UPPER Case is kind of barking/shouting ...
>> besides I tried my best to help as far as I can while doing my day$ Job
>> or being on vacation.
>>
>> UPPER CASE IS USED TO ACCENT SOME THINGS.
>

writing all upper case is called rude, please see this:
https://in.answers.yahoo.com/question/index?qid=20070718202452AAHIRQL

One word might be highlighting ... a full sentence is screaming ...


>
>
>> TBH ... if you think it's no complicated task and just a bug, please
>> provide a PullRequest so we can fix it. It's OpenSource
>> and free in terms of free knowledge and not free beer.
>>
>> I find it rather harsh criticizing this community / me  of being not
>> helpful or "in time" of fixing bugs. Please re-think your usage of open
>> source software. Get yourself engaged, people here are working on it in
>> their free time and if you want to have a full blown support go somewhere
>> and buy yourself a product for a couple of thousands of dollars.
>>
>
> No one criticized community. Where did you take it from? PLEASE, READ
> CAREFULLY WHAT I WRITE.
>

yes you did and I'm citing just the email I answered to ...


I am not speaking about some complicated taks. I am speaking about the
> simplest - stop/start bundle on osgi.
> I have some doubts already about pax-web. If no one from OPS4J community
> has time/wish to help with their products
> then just honestly say - the product is not mature, it has a lot of bugs,
> if you need to fix them - then fix, no one currently can help you.



this for me is criticizing the community and saying this is a bad product
...

I know how it is difficult to develop a software product and how many
> thousand of hours it requires. I see that the community did enormous work.
> And I am thankful to community for allowing me to use this product.
> But I said quite different thing. I started use this product (because you,
> Achim, offered me it on SO). I have serious problems with the CORE
> functionality.
> I applied to community. The problem is not solved. Only facts, not any
> emotions, claims etc. I am alone with my problem.
>

sorry that you feel alone with your issue, but it's very hard without a
concrete example to verify this in a 2h window in the evening, after a full
day of work 
I might be repeating myself ... community is about give and take ... till
know you've taken. If you want more you need to give us something in turn.
A Integration test for example so the community is able to understand your
issue.


>
>
>> About matureness of the product ... well afaik PaxWeb is in productional
>> use by Talend ESB, RetHat - FUSE ESB and in projects like OpenDaylight
>>
>> If you see an issue please report it on Jira, please provide an easy way
>> of reproduction (I'm not talking of a list of jars to use) - I won't use my
>> spare time to re-create an issue reported if it requires me a full working
>> day to just try to do a setup of that.
>>
>> Next way of partricipitation is to provide an pull-request. If you're not
>> willing to help the community with that (actually being part of the
>> community instead of just consuming) don't expect people jumping in to help
>> more.
>>
>> If you don't have a Jira user by now, just give me the details about how
>> you want to be registered, as we needed to close the self-registration due
>> to Spammers using our Jira system for spamming (go figure why one want's to
>> do that)
>>
>> Thanks, Achim
>>
>>
>> 2016-08-18 9:40 GMT+02:00 iJava <pavelka...@gmail.com>:
>>
>> Hi Achim,
>>
>> Thank you for your help. I don't bark at you - where did you take it
>> from? By the way I don't bark at all.
>> I appreciate your help, however, let's be honest. It is 8'th message and
>> still no solution how to stop bundle without exception.
>>
>> I am not speaking about some complicated taks. I am speaking about the
>> simplest - stop/start bundle on osgi.
>>
>> I have some doubts already about pax-web. If no one from OPS4J community
>> has time/wish to help with their products
>> then just honestly say - the product is not mature, it has a lot of bugs,
>> if you need to fix them - then fix, no one currently can help you.
>>
>> On Thursday, 18 August 2016 09:58:57 UTC+3, Achim Nierbeck wrote:
>>
>> erf ... it's been a mere explanation why 1.0 doesn't really fit. No
>> reason to bark at me ...
>> I'm trying my best here to help you around with the issue you go

Re: PAX -WEB/CDI: how to stop war bundle with CDI?

['Achim Nierbeck' via OPS4J]

Pax Web 4.2.x is pretty stable.
But it looks like as you're using a not supported Jetty version you seem to
run into special edge cases.
Those might be already be solved with Pax-web 6.0.0-SNAPSHOT

The problem right now, is. Pax-CDI is using Pax-Web so we need to check the
Pax-CDI tests which version of Pax-Web those are using. AFAIK 0.12.x works
with vanilla Pax-Web 4.2.x (without Jetty 9.3), it might be that 1.0 was
based on Jetty higher then what's delivered in conjunction with Pax-Web
4.2.x. This I need to verify.
As I only have a limited amount of private time to spent on those projects
I might not be able to get the complete picture on it
as you might expect. Till now my usage/development in the Pax-CDI part has
been limited.

regards, Achim


2016-08-17 19:57 GMT+02:00 iJava <pavelkastor...@gmail.com>:

> The problem was solved that way: I took sources of pax-cdi 0.12 and added
> two methods
> @Override
> public  T decorate(T target) {
> getInjector().inject(target);
> return target;
> }
>
> @Override
> public void destroy(Object target) {
> getInjector().destroy(target);
> }
>
> to pax-cdi-web-weld in JettyDecorator. Their implementation I took from
> pax-cdi 1.0. The bug is described here :
> https://ops4j1.jira.com/browse/PAXCDI-209
>
> However, in spite of all my attempts (I have all the same versions as
> karaf) I still can't normally stop war bundle.
>
> Please, help me. Is pax-web 4.2.6 ready for production? Maybe it is still
> in development and I ask stupid questions...
>
> Now I get (this is it is clear the problem is in pax-web) :
>
> org.ops4j.pax.web.pax-web-extender-war[org.ops4j.pax.
> web.extender.war.internal.WebObserver$1] : Error stopping extension for
> bundle com.example.site.fend [63]
> java.lang.NullPointerException
> at org.ops4j.pax.web.extender.war.internal.
> DefaultWebAppDependencyManager.removeWebApp(DefaultWebAppDependencyManager
> .java:99)
> at org.ops4j.pax.web.extender.war.internal.WebObserver$1.
> doDestroy(WebObserver.java:189)
> at org.ops4j.pax.web.extender.war.internal.extender.
> SimpleExtension.destroy(SimpleExtension.java:71)
> at org.ops4j.pax.web.extender.war.internal.extender.
> AbstractExtender$2.run(AbstractExtender.java:306)
> at java.util.concurrent.Executors$RunnableAdapter.
> call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender.
> destroyExtension(AbstractExtender.java:332)
> at org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender.
> bundleChanged(AbstractExtender.java:190)
> at org.apache.felix.framework.util.EventDispatcher.
> invokeBundleListenerCallback(EventDispatcher.java:916)
> at org.apache.felix.framework.util.EventDispatcher.
> fireEventImmediately(EventDispatcher.java:835)
> at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(
> EventDispatcher.java:517)
> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)
> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2600)
> at org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:1038)
> at org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:1024)
> at com.example.solution.mgr.core.services.OsgiServiceImpl.
> stopBundle(OsgiServiceImpl.java:106)
> at com.example.solution.mgr.svr.services.RmiOsgiServiceImpl.
> stopBundle(RmiOsgiServiceImpl.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(
> TCPTransport.java:568)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(
> TCPTransport.java:826)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$
> 250(TCPTransport.java:683)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$1/620361102.run(Unknown
> Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(
> TCPTransport.java:682)
> at java.util.concurrent.Th

PAX-CDI: how to get reference to BeanManager in bundle without using CDI

[iJava]

There is a bundle A and threre is class MyClass in bundle A.

We suppose that pax-cdi+weld is on.

Can can I get reference to BeanManager of the bundle A inside MyClass 
without using @Inject and other CDI annotations? 
Via osgi service? Or how?

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PAX-CDI Producer method

['Achim Nierbeck' via OPS4J]

Hi Maarten,

thanks for providing a pull request.
Please also link a JIRA issue with it. We need this so it's clear in the
release notes what is contained and maybe for later regressions.

I'll try to look at this pr after I'm back from vacation.

Regards Achim

sent from mobile device

Am 01.08.2016 11:27 vorm. schrieb "Maarten Winkels" <
maartenwink...@gmail.com>:

> Hi,
>
> I'm trying to use PAX-CDI on karaf. I'm looking at version 0.12.0.
>
> I have a problem with a CDI producer method that has the
> @OsgiServiceProvider Qualifier annotation.
> According to the doc:
>
> Qualifier for automatic registration of CDI beans as OSGi service.
>> In application code, this qualifier shall only be used on classes and
>> producer methods.
>
>
> When I use the annotation, I get the following error:
>
> 15:19:10.895 [Start Level Event Dispatcher] INFO  
> o.o.p.c.e.i.c.ComponentLifecycleManager - component Greeter, Name:null, 
> WebBeans Type:PRODUCERMETHOD, API 
> Types:[java.lang.Object,sample.osgiProviderProducerMethod.Greeter], 
> Qualifiers:[javax.enterprise.inject.Any,org.ops4j.pax.cdi.api.OsgiServiceProvider]
>  is available
> 15:19:10.912 [Start Level Event Dispatcher] ERROR 
> o.o.pax.cdi.spi.AbstractCdiContainer -
> java.lang.NullPointerException: null
> at 
> org.ops4j.pax.cdi.extension.impl.component.ComponentLifecycleManager.registerService(ComponentLifecycleManager.java:183)
>  ~[pax-cdi-extension-0.13.0-SNAPSHOT.jar:na]
> at 
> org.ops4j.pax.cdi.extension.impl.component.ComponentLifecycleManager.start(ComponentLifecycleManager.java:107)
>  ~[pax-cdi-extension-0.13.0-SNAPSHOT.jar:na]
> at 
> org.ops4j.pax.cdi.extension.impl.component.ComponentLifecycleManager$$OwbNormalScopeProxy0.start(org/ops4j/pax/cdi/extension/impl/component/ComponentLifecycleManager.java)
>  ~[na:na]
> at 
> org.ops4j.pax.cdi.extension.impl.BeanBundleImpl.onInitialized(BeanBundleImpl.java:60)
>  ~[pax-cdi-extension-0.13.0-SNAPSHOT.jar:na]
> ...
>
> I have created a pull request on Github
> <https://github.com/ops4j/org.ops4j.pax.cdi/pull/34> with a fix for this.
>
> Can someone please look into this?
>
> Thanks,
> Regards,
>
> -Maarten Winkels
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

PAX-CDI Producer method

[Maarten Winkels]

Hi,

I'm trying to use PAX-CDI on karaf. I'm looking at version 0.12.0.

I have a problem with a CDI producer method that has the 
@OsgiServiceProvider Qualifier annotation.
According to the doc: 

Qualifier for automatic registration of CDI beans as OSGi service.
> In application code, this qualifier shall only be used on classes and 
> producer methods.


When I use the annotation, I get the following error:

15:19:10.895 [Start Level Event Dispatcher] INFO  
o.o.p.c.e.i.c.ComponentLifecycleManager - component Greeter, Name:null, 
WebBeans Type:PRODUCERMETHOD, API 
Types:[java.lang.Object,sample.osgiProviderProducerMethod.Greeter], 
Qualifiers:[javax.enterprise.inject.Any,org.ops4j.pax.cdi.api.OsgiServiceProvider]
 is available
15:19:10.912 [Start Level Event Dispatcher] ERROR 
o.o.pax.cdi.spi.AbstractCdiContainer - 
java.lang.NullPointerException: null
at 
org.ops4j.pax.cdi.extension.impl.component.ComponentLifecycleManager.registerService(ComponentLifecycleManager.java:183)
 ~[pax-cdi-extension-0.13.0-SNAPSHOT.jar:na]
at 
org.ops4j.pax.cdi.extension.impl.component.ComponentLifecycleManager.start(ComponentLifecycleManager.java:107)
 ~[pax-cdi-extension-0.13.0-SNAPSHOT.jar:na]
at 
org.ops4j.pax.cdi.extension.impl.component.ComponentLifecycleManager$$OwbNormalScopeProxy0.start(org/ops4j/pax/cdi/extension/impl/component/ComponentLifecycleManager.java)
 ~[na:na]
at 
org.ops4j.pax.cdi.extension.impl.BeanBundleImpl.onInitialized(BeanBundleImpl.java:60)
 ~[pax-cdi-extension-0.13.0-SNAPSHOT.jar:na]
...

I have created a pull request on Github 
<https://github.com/ops4j/org.ops4j.pax.cdi/pull/34> with a fix for this.

Can someone please look into this?

Thanks,
Regards,

-Maarten Winkels

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.