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  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.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 
> 

Re: [pax-web][websocket] WebSocket not working with Whiteboard-registration

['Achim Nierbeck' via OPS4J]

Hi,

the idea is to start with the minimal working version.
So if the simple use case works already for you we can track it down to
maybe a bug in the HttpContext handling with websockets.

regards, Achim



2017-05-08 21:21 GMT+02:00 Csákány Róbert :

> Hi Achim,
>
> Thanks for the response.
>
> When I deploy as a WAR it works fine - so I don't think there is a general
> problem. I've tried with debugging, but I don't know the details of
> Pax-Web. The HTTPContext was an idea to be able to emulate the isolation
> like in a WAR deployment - before I've tried without context with no luck.
> The log messages shows everything okay, because the Websocket tracker
> catches the service, find the annotation and find the HTTPContext. So it
> seems OK, but the URL is not mapped. I have the feeling something with the
> URL mapping goes wrong. I haven't tried that the very same HTTPContext
> initializing a Servlet - so I will try it.  So all the two scenario
> mentioned earlier works same way - the websocket is catched and Jetty
> registration is called, but the URL is unavailable, I've got 404. - that
> was that point where I call for help, because my knowledge ended here :)
>
>
> I've checked the integraton test - WebSocketWhiteBoardIntegrationTest
>
> I see there is no any property on service, only the naked instance of
> service is registered. It is not fit for me, because I need managed
> instance of service (because I would like to reference other services).
>
> Regards,
>
> Robert
>
> On Monday, May 8, 2017 at 9:03:21 PM UTC+2, Achim Nierbeck wrote:
>>
>> Hi,
>>
>> this is actually a tricky one. Over the weekend I tried to work on some
>> integration tests for it, but failed.
>> Is it not working in general? Or just in combination with the
>> HttpContext?
>> For the second one we might find an easier solution :)
>>
>> regards, Achim
>>
>>
>> 2017-05-08 20:19 GMT+02:00 Csákány Róbert :
>>
>>> I'm not sure my problems related to this issue, or it is a different one.
>>>
>>> I have a problem with the PAX-Web. I've tried to register a Websocket
>>> service as declrarative, but it is unaccessible from web. I've tried the
>>> given websocket-jsr356-6.0.3.war and it works fine. As I see the WAR file
>>> handles differently the org.osgi.service.http.HttpContext. I've tried
>>> the following scenarios:
>>>
>>>
>>> **Scenario 1 - OSGi R6 Whiteboard HTTP method**
>>>
>>>
>>> Creating a ServletContextHelper:
>>>
>>>
>>> package hu.blackbelt.judo.common.rest.regular;
>>>
>>> import org.apache.felix.scr.annotations.Component;
>>> import org.apache.felix.scr.annotations.Properties;
>>> import org.apache.felix.scr.annotations.Property;
>>> import org.apache.felix.scr.annotations.Service;
>>> import org.osgi.service.http.context.ServletContextHelper;
>>> import org.osgi.service.http.whiteboard.HttpWhiteboardConstants;
>>>
>>> @Component(immediate = true)
>>> @Service(ServletContextHelper.class)
>>> @Properties(value = {
>>> @Property(name = 
>>> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_NAME, value = "chat"),
>>> @Property(name = 
>>> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_PATH, value = "/test")
>>> })
>>> public class ChatServletContext extends ServletContextHelper {
>>> }
>>>
>>>
>>> And adding the Websocket Endpoint:
>>>
>>>
>>> package hu.blackbelt.judo.common.rest.regular;
>>>
>>>
>>> import lombok.extern.slf4j.Slf4j;
>>> import org.apache.felix.scr.annotations.Component;
>>> import org.apache.felix.scr.annotations.Properties;
>>> import org.apache.felix.scr.annotations.Property;
>>> import org.apache.felix.scr.annotations.Service;
>>>
>>> import javax.websocket.EncodeException;
>>> import javax.websocket.OnMessage;
>>> import javax.websocket.OnOpen;
>>> import javax.websocket.Session;
>>> import javax.websocket.server.PathParam;
>>> import javax.websocket.server.ServerEndpoint;
>>> import java.io.IOException;
>>>
>>> @Component(immediate = true)
>>> @Service(Object.class)
>>> @Properties(value = {
>>> @Property(name = 
>>> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_SELECT,
>>> value = "=(" + 
>>> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_NAME + "=chat)")
>>> })
>>> @Slf4j
>>> public class ChatEndpoint {
>>>
>>> public static final String ROOM = "room";
>>>
>>> @OnOpen
>>> public void onOpen(final Session session, @PathParam(ROOM) final 
>>> String room) {
>>> LOGGER.info("session openend and bound to room: " + room);
>>> session.getUserProperties().put(ROOM, room);
>>> }
>>>
>>> @OnMessage
>>> public void onMessage(final Session session, final ChatMessage 
>>> chatMessage) {
>>> String room = (String) session.getUserProperties().get(ROOM);
>>> try {
>>> for (Session s : 

Re: [pax-web][websocket] WebSocket not working with Whiteboard-registration

[Csákány Róbert]

Hi Achim,

Thanks for the response. 

When I deploy as a WAR it works fine - so I don't think there is a general 
problem. I've tried with debugging, but I don't know the details of 
Pax-Web. The HTTPContext was an idea to be able to emulate the isolation 
like in a WAR deployment - before I've tried without context with no luck. 
The log messages shows everything okay, because the Websocket tracker 
catches the service, find the annotation and find the HTTPContext. So it 
seems OK, but the URL is not mapped. I have the feeling something with the 
URL mapping goes wrong. I haven't tried that the very same HTTPContext 
initializing a Servlet - so I will try it.  So all the two scenario 
mentioned earlier works same way - the websocket is catched and Jetty 
registration is called, but the URL is unavailable, I've got 404. - that 
was that point where I call for help, because my knowledge ended here :)


I've checked the integraton test - WebSocketWhiteBoardIntegrationTest

I see there is no any property on service, only the naked instance of 
service is registered. It is not fit for me, because I need managed 
instance of service (because I would like to reference other services). 

Regards,

Robert

On Monday, May 8, 2017 at 9:03:21 PM UTC+2, Achim Nierbeck wrote:
>
> Hi, 
>
> this is actually a tricky one. Over the weekend I tried to work on some 
> integration tests for it, but failed. 
> Is it not working in general? Or just in combination with the HttpContext? 
> For the second one we might find an easier solution :) 
>
> regards, Achim 
>
>
> 2017-05-08 20:19 GMT+02:00 Csákány Róbert :
>
>> I'm not sure my problems related to this issue, or it is a different one.
>>
>> I have a problem with the PAX-Web. I've tried to register a Websocket 
>> service as declrarative, but it is unaccessible from web. I've tried the 
>> given websocket-jsr356-6.0.3.war and it works fine. As I see the WAR file 
>> handles differently the org.osgi.service.http.HttpContext. I've tried the 
>> following scenarios:
>>
>>
>> **Scenario 1 - OSGi R6 Whiteboard HTTP method**
>>
>>
>> Creating a ServletContextHelper:
>>
>> 
>> package hu.blackbelt.judo.common.rest.regular;
>> 
>> import org.apache.felix.scr.annotations.Component;
>> import org.apache.felix.scr.annotations.Properties;
>> import org.apache.felix.scr.annotations.Property;
>> import org.apache.felix.scr.annotations.Service;
>> import org.osgi.service.http.context.ServletContextHelper;
>> import org.osgi.service.http.whiteboard.HttpWhiteboardConstants;
>> 
>> @Component(immediate = true)
>> @Service(ServletContextHelper.class)
>> @Properties(value = {
>> @Property(name = 
>> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_NAME, value = "chat"),
>> @Property(name = 
>> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_PATH, value = "/test")
>> })
>> public class ChatServletContext extends ServletContextHelper {
>> }
>>
>>
>> And adding the Websocket Endpoint:
>>
>>
>> package hu.blackbelt.judo.common.rest.regular;
>> 
>> 
>> import lombok.extern.slf4j.Slf4j;
>> import org.apache.felix.scr.annotations.Component;
>> import org.apache.felix.scr.annotations.Properties;
>> import org.apache.felix.scr.annotations.Property;
>> import org.apache.felix.scr.annotations.Service;
>> 
>> import javax.websocket.EncodeException;
>> import javax.websocket.OnMessage;
>> import javax.websocket.OnOpen;
>> import javax.websocket.Session;
>> import javax.websocket.server.PathParam;
>> import javax.websocket.server.ServerEndpoint;
>> import java.io.IOException;
>> 
>> @Component(immediate = true)
>> @Service(Object.class)
>> @Properties(value = {
>> @Property(name = 
>> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_SELECT,
>> value = "=(" + 
>> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_NAME + "=chat)")
>> })
>> @Slf4j
>> public class ChatEndpoint {
>> 
>> public static final String ROOM = "room";
>> 
>> @OnOpen
>> public void onOpen(final Session session, @PathParam(ROOM) final 
>> String room) {
>> LOGGER.info("session openend and bound to room: " + room);
>> session.getUserProperties().put(ROOM, room);
>> }
>> 
>> @OnMessage
>> public void onMessage(final Session session, final ChatMessage 
>> chatMessage) {
>> String room = (String) session.getUserProperties().get(ROOM);
>> try {
>> for (Session s : session.getOpenSessions()) {
>> if (s.isOpen()
>> && room.equals(s.getUserProperties().get(ROOM))) 
>> {
>> s.getBasicRemote().sendObject(chatMessage);
>> }
>> }
>> } catch (IOException | EncodeException e) {
>>

Re: [pax-web][websocket] WebSocket not working with Whiteboard-registration

['Achim Nierbeck' via OPS4J]

Hi,

this is actually a tricky one. Over the weekend I tried to work on some
integration tests for it, but failed.
Is it not working in general? Or just in combination with the HttpContext?
For the second one we might find an easier solution :)

regards, Achim


2017-05-08 20:19 GMT+02:00 Csákány Róbert :

> I'm not sure my problems related to this issue, or it is a different one.
>
> I have a problem with the PAX-Web. I've tried to register a Websocket
> service as declrarative, but it is unaccessible from web. I've tried the
> given websocket-jsr356-6.0.3.war and it works fine. As I see the WAR file
> handles differently the org.osgi.service.http.HttpContext. I've tried the
> following scenarios:
>
>
> **Scenario 1 - OSGi R6 Whiteboard HTTP method**
>
>
> Creating a ServletContextHelper:
>
>
> package hu.blackbelt.judo.common.rest.regular;
>
> import org.apache.felix.scr.annotations.Component;
> import org.apache.felix.scr.annotations.Properties;
> import org.apache.felix.scr.annotations.Property;
> import org.apache.felix.scr.annotations.Service;
> import org.osgi.service.http.context.ServletContextHelper;
> import org.osgi.service.http.whiteboard.HttpWhiteboardConstants;
>
> @Component(immediate = true)
> @Service(ServletContextHelper.class)
> @Properties(value = {
> @Property(name = 
> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_NAME, value = "chat"),
> @Property(name = 
> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_PATH, value = "/test")
> })
> public class ChatServletContext extends ServletContextHelper {
> }
>
>
> And adding the Websocket Endpoint:
>
>
> package hu.blackbelt.judo.common.rest.regular;
>
>
> import lombok.extern.slf4j.Slf4j;
> import org.apache.felix.scr.annotations.Component;
> import org.apache.felix.scr.annotations.Properties;
> import org.apache.felix.scr.annotations.Property;
> import org.apache.felix.scr.annotations.Service;
>
> import javax.websocket.EncodeException;
> import javax.websocket.OnMessage;
> import javax.websocket.OnOpen;
> import javax.websocket.Session;
> import javax.websocket.server.PathParam;
> import javax.websocket.server.ServerEndpoint;
> import java.io.IOException;
>
> @Component(immediate = true)
> @Service(Object.class)
> @Properties(value = {
> @Property(name = 
> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_SELECT,
> value = "=(" + 
> HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_NAME + "=chat)")
> })
> @Slf4j
> public class ChatEndpoint {
>
> public static final String ROOM = "room";
>
> @OnOpen
> public void onOpen(final Session session, @PathParam(ROOM) final 
> String room) {
> LOGGER.info("session openend and bound to room: " + room);
> session.getUserProperties().put(ROOM, room);
> }
>
> @OnMessage
> public void onMessage(final Session session, final ChatMessage 
> chatMessage) {
> String room = (String) session.getUserProperties().get(ROOM);
> try {
> for (Session s : session.getOpenSessions()) {
> if (s.isOpen()
> && room.equals(s.getUserProperties().get(ROOM))) {
> s.getBasicRemote().sendObject(chatMessage);
> }
> }
> } catch (IOException | EncodeException e) {
> LOGGER.warn("onMessage failed", e);
> }
> }
> }
>
> The logs show me that the Endpoint is catched. I've debugged and Pax-Web
> is registering it.
>
>
> The log shows the following line:
>
> 2017-05-04 02:36:02,698 | INFO | Thread-70 | WebSocketTracker | 330 -
> org.ops4j.pax.web.pax-web-extender-whiteboard - 6.0.3 | found websocket
> endpoint!!
>
>
> But the websocket is unaccessible with the following URL:
> ws://localost:8181/test/chat/testroom
>
>
>
> **Scenario 2 - Pax-Web properties on registered HttpContext (with JAX-RS
> it works)**
>
>
> Creating HttpContext instance: (Utilizing the OSGi given Helper abstract
> class):
>
> package hu.blackbelt.judo.common.rest.regular;
>
> import org.apache.felix.scr.annotations.Component;
> import org.apache.felix.scr.annotations.Properties;
> import org.apache.felix.scr.annotations.Property;
> import org.apache.felix.scr.annotations.Service;
> import org.osgi.service.http.HttpContext;
> import org.osgi.service.http.context.ServletContextHelper;
>
> @Component(immediate = true)
> @Service(HttpContext.class)
> @Properties(value = {
> @Property(name = "httpContext.id", value = "chat"),
> @Property(name = "httpContext.path", value = "test")
> })
> public class ChatHttpContext extends ServletContextHelper implements 
> HttpContext {
> }
>
>
> And the Websocket Endpoint:
>
>
> package 

[pax-web][websocket] WebSocket not working with Whiteboard-registration

[Csákány Róbert]

I'm not sure my problems related to this issue, or it is a different one.

I have a problem with the PAX-Web. I've tried to register a Websocket 
service as declrarative, but it is unaccessible from web. I've tried the 
given websocket-jsr356-6.0.3.war and it works fine. As I see the WAR file 
handles differently the org.osgi.service.http.HttpContext. I've tried the 
following scenarios:


**Scenario 1 - OSGi R6 Whiteboard HTTP method**


Creating a ServletContextHelper:


package hu.blackbelt.judo.common.rest.regular;

import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Properties;
import org.apache.felix.scr.annotations.Property;
import org.apache.felix.scr.annotations.Service;
import org.osgi.service.http.context.ServletContextHelper;
import org.osgi.service.http.whiteboard.HttpWhiteboardConstants;

@Component(immediate = true)
@Service(ServletContextHelper.class)
@Properties(value = {
@Property(name = 
HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_NAME, value = "chat"),
@Property(name = 
HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_PATH, value = "/test")
})
public class ChatServletContext extends ServletContextHelper {
}


And adding the Websocket Endpoint:


package hu.blackbelt.judo.common.rest.regular;


import lombok.extern.slf4j.Slf4j;
import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Properties;
import org.apache.felix.scr.annotations.Property;
import org.apache.felix.scr.annotations.Service;

import javax.websocket.EncodeException;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.PathParam;
import javax.websocket.server.ServerEndpoint;
import java.io.IOException;

@Component(immediate = true)
@Service(Object.class)
@Properties(value = {
@Property(name = 
HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_SELECT,
value = "=(" + 
HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_NAME + "=chat)")
})
@Slf4j
public class ChatEndpoint {

public static final String ROOM = "room";

@OnOpen
public void onOpen(final Session session, @PathParam(ROOM) final String 
room) {
LOGGER.info("session openend and bound to room: " + room);
session.getUserProperties().put(ROOM, room);
}

@OnMessage
public void onMessage(final Session session, final ChatMessage 
chatMessage) {
String room = (String) session.getUserProperties().get(ROOM);
try {
for (Session s : session.getOpenSessions()) {
if (s.isOpen()
&& room.equals(s.getUserProperties().get(ROOM))) {
s.getBasicRemote().sendObject(chatMessage);
}
}
} catch (IOException | EncodeException e) {
LOGGER.warn("onMessage failed", e);
}
}
}

The logs show me that the Endpoint is catched. I've debugged and Pax-Web is 
registering it.


The log shows the following line:

2017-05-04 02:36:02,698 | INFO | Thread-70 | WebSocketTracker | 330 - 
org.ops4j.pax.web.pax-web-extender-whiteboard - 6.0.3 | found websocket 
endpoint!!


But the websocket is unaccessible with the following URL: 
ws://localost:8181/test/chat/testroom



**Scenario 2 - Pax-Web properties on registered HttpContext (with JAX-RS it 
works)**


Creating HttpContext instance: (Utilizing the OSGi given Helper abstract 
class):

package hu.blackbelt.judo.common.rest.regular;

import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Properties;
import org.apache.felix.scr.annotations.Property;
import org.apache.felix.scr.annotations.Service;
import org.osgi.service.http.HttpContext;
import org.osgi.service.http.context.ServletContextHelper;

@Component(immediate = true)
@Service(HttpContext.class)
@Properties(value = {
@Property(name = "httpContext.id", value = "chat"),
@Property(name = "httpContext.path", value = "test")
})
public class ChatHttpContext extends ServletContextHelper implements 
HttpContext {
}


And the Websocket Endpoint:


package hu.blackbelt.judo.common.rest.regular;
   
import lombok.extern.slf4j.Slf4j;
import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Properties;
import org.apache.felix.scr.annotations.Property;
import org.apache.felix.scr.annotations.Service;
import org.osgi.service.http.whiteboard.HttpWhiteboardConstants;

import javax.websocket.EncodeException;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import 

[pax-exam] Release a 4.10.1 or 4.11.0 now or when?

[Michael Vorburger]

Hello,

In order to be able to benefit from 
https://ops4j1.jira.com/browse/PAXEXAM-740 in a downstream project, I would 
be interested in a Pax Exam release some time. It's not super urgent, but 
was hoping for maybe the next week or two.. if this fits with other ongoing 
issues on 
https://ops4j1.jira.com/projects/PAXEXAM?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page=unreleased
 
- what are your plans?

Or can I go ahead and just push a pax exam to central as-is now? Latest 
published is 4.10.0, so shall we have a 4.10.1 next, as there seem to be 
only 4 small fixes since the 4.10.0. That would be in line with the current 
4.10.1-SNAPSHOT in the pom.xml of master .. or do you instead want us to 
bump master to 4.11.0-SNAPSHOT now, to be in line with JIRA 
https://ops4j1.jira.com/browse/PAXEXAM-812 and 
https://ops4j1.jira.com/browse/PAXEXAM-740? 

FYI I just looked around JIRA, have closed the confusing 
https://ops4j1.jira.com/browse/PAXEXAM-805, and don't see anything else in 
progress for (4.10.1 or) 4.11.0.

BTW in JIRA there are currently 4 open versions (4.11.0, 4.x, 5.0.0 and 
unscheduled; but no 4.10.1), so prior to a release perhaps the open 4.x 
issues should perhaps be moved to no version (unscheduled?), and 4.x 
closed, to avoid confusion?

Tx,
M.

-- 
-- 
--
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 Swissbox 1.8.3 released

[Michael Vorburger]

Hello,

Pax Swissbox 1.8.3 has been released; more details on:

https://ops4j1.jira.com/wiki/display/PAXSB/2017/05/08/Pax+
Swissbox+1.8.3+released

Best,
M.
___
Michael Vorburger
http://www.vorburger.ch

-- 
-- 
--
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] 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 

Re: [pax-swissbox] Release 1.8.3 OK if I do it, or would one of you like to handle this? (for [PAXEXAM-740])

[Michael Vorburger]

Christian et al,

On Wed, Apr 12, 2017 at 3:20 PM, Michael Vorburger 
wrote:

> On Wed, Apr 12, 2017 at 7:46 AM, Christian Schneider <
> ch...@die-schneider.net> wrote:
>
> For a release it is always good to first write on the list that you plan
>> to do a release and ask if someone wants to add something to it.
>>
>
> OK, thanks; then I'm hereby announcing on this list that I plan to do a
> 1.8.3 release of pax-swissbox, and asking on this list if someone wants
> to add something to it? ;-) If I don't hear back by say within 1 week, by
> end of next Tuesday 18th, I'll do the release on the 19th.
>
>
>> You should also read https://ops4j1.jira.com/wiki/display/ops4j/Releasing
>>
>
> OK, will do & follow; thanks.
>

I've (finally) taken a moment to do this today, and just pushed Swissbox
1.8.3 to central, BUT I'm not clear how to do the release of the version in
JIRA as explained under section heading "Jira" in the Releasing wiki page
linked to above... I may be missing some permission JIRA to be able to do
that - or just too dumb to find the release button looking at
https://ops4j1.jira.com/projects/PAXSB/versions/17880/tab/release-report-in-progress
?

I can send out the announcement email after we've sorted this out.

Thanks,
M.

PS: https://github.com/ops4j/org.ops4j.pax.exam2/pull/60 will use this
1.8.3 swissbox.

___
Michael Vorburger
http://www.vorburger.ch



>
> Christian
>>
>>
>> 2017-04-11 23:06 GMT+02:00 Michael Vorburger :
>>
>>> Hello OPS4jians,
>>>
>>> Thank you for welcome into your community (https://twitter.com/vorburger
>>> /status/850654708331151360).
>>>
>>> In order to completely wrap up https://ops4j1.jira.com/browse
>>> /PAXEXAM-740 for good, we would need to now release a 1.8.3 of
>>> pax-swissbox including the https://github.com/ops4j/org.o
>>> ps4j.pax.swissbox/pull/4 I just merged, and bump that dependency in
>>> merging https://github.com/ops4j/org.ops4j.pax.exam2/pull/60.
>>>
>>> I have meanwhile obtained the permission to push to Maven Central for
>>> OPS4j, see https://issues.sonatype.org/browse/OSSRH-30344, but wanted
>>> to double check with you guys here how you handle this - can I really
>>> "just" go ahead and do this? That's amazing! ;-) Anything in particular to
>>> do for process?
>>>
>>> Thanks for a quick confirmation that this is really how you guys run
>>> this community - very cool.
>>>
>>> Regards,
>>> M. http://www.vorburger.ch
>>>
>>> --
>>> --
>>> --
>>> 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
>> 
>>
>> Open Source Architect
>> http://www.talend.com
>> 
>>
>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "OPS4J" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/ops4j/4L_QDQjLUOY/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.