from:"Pavel"

Re: PAX:WEB How many war bundles do pax-web support?

2019-05-22 Thread Pavel

Hi Akhil,

I developed that patch and it worked for multiple virtual hosts. However, I 
wouldn't suggest you 
using OSGi + Jetty. I would suggest using JPMS + Jetty. Jetty now supports 
JPMS. There is
an issue on Jetty (google) how to configure it and set classloading and 
JSP. If you need modularity 
I thinkthis is a better way. If you need dynamism you can consider using 
one JPMS layer for every
web application. We did it in our framework and everything works fine.

Best regards, Pavel

среда, 22 мая 2019 г., 14:28:46 UTC+3 пользователь Akhil Grover написал:
>
> Hi All,
>
> The patch was merged into master but as far as I can see never released. 
> Is there any issue related to the patch? 
> Is there a time line on when this patch will be merged into 7.3.x branch?
>
> Regards,
> Akhil
>
> On Wednesday, October 19, 2016 at 7:53:03 PM UTC+1, Pavel wrote:
>>
>> Hi all
>>
>> I created a patch that allows to use N virtual hosts on one port and M 
>> context path inside
>> each virtual host. The solution is backward compatible with pax-web 6.0. 
>> I created an 
>> issue https://ops4j1.jira.com/browse/PAXWEB-1026 and attached the patch 
>> there.
>>
>> I hope it will be useful for anyone and the developers will include it in 
>> master branch
>> although it must be tested, but unfortunately I really have no time.
>>
>> Best regards, 
>>
>> среда, 12 октября 2016 г., 14:41:47 UTC+3 пользователь iJava написал:
>>>
>>> Ok. Thank you making the situation clear. 
>>>
>>> Best regards,
>>>
>>> среда, 12 октября 2016 г., 14:40:12 UTC+3 пользователь Achim Nierbeck 
>>> написал:
>>>>
>>>> sorry didn't want to bother you with my bla-bla-bla ... 
>>>> therefore I have nothing else to say. 
>>>>
>>>> regards, Achim 
>>>>
>>>> 2016-10-12 13:35 GMT+02:00 iJava :
>>>>
>>>>> Hi Achim
>>>>>
>>>>> Are you there? Will you answer to my suggestion?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> понедельник, 10 октября 2016 г., 9:07:15 UTC+3 пользователь iJava 
>>>>> написал:
>>>>>>
>>>>>> Hi Achim
>>>>>>
>>>>>> Thank you for detailed explanation. However, I think soon google 
>>>>>> mailing list will complain
>>>>>> about our bla-bla-bla because there is still no result.
>>>>>>
>>>>>> Lets get closer to business.
>>>>>> So, I think that web-contextpath musn't be across all connectors 
>>>>>> because it's logically wrong.
>>>>>>
>>>>>> What I suggest after short analysis is:
>>>>>> 1) The solution must be absolute backward compatible with pax-web 
>>>>>> 6.0. (I need this feature
>>>>>> and I can't wait ? time for version 7.0.0)
>>>>>> 2) In deployed bundles there will be an optional(!) Virtual-Hosts 
>>>>>> setting in manifest of war bundle.
>>>>>> I think that even it there is any virtual-host settings separate from 
>>>>>> bundles in the future,
>>>>>>  it is bundle that must say to which virtual host it wants to belong 
>>>>>> to.
>>>>>> 3) We add virtualHosts collection to org.ops4j.pax.web.service.spi.
>>>>>> model.ServerModel + 
>>>>>> fix all match* methods. Besides we fix match* in 
>>>>>> JettyServerHandlerCollection 
>>>>>> 4) it is necessary to allow war bundles with the same context if the 
>>>>>> have virtual-hosts setting.
>>>>>> I haven't looked yet where it can be done.
>>>>>> 5) The suggested solution is a "first attempt" to see how it will be 
>>>>>> like and will not
>>>>>> require much time (which is the problem #1). If someone has time in 
>>>>>> future he\she can
>>>>>> always make the solution better.
>>>>>>
>>>>>> What will you say? 
>>>>>>
>>>>>> P.S. I considered only for jetty as I wrote above.
>>>>>>
>>>>>>
>>>>>>
>>>>>> понедельник, 10 октября 2016 г., 0:03:28 UTC+3 пользователь Achim 
>>>>>> Nierbeck написал:
>>>>>>
>>>>>>> I fully understand your problem, but it can't be solved easily. 
>>>>>&g

Re: Pax products and JPMS of Java 9

2017-09-09 Thread Pavel Kastornyy


Hi Achim

The problem is that there is no solution how to work with JPMS together
with OSGi (one module = one bundle) at the current time and there is
no information when such solution will appear. For details see
https://mail.osgi.org/pipermail/osgi-dev/2017-September/thread.html

I've read many articles in internet about possible solution and all
they say that "suggested solution is not for production".

So, I started to think that static JPMS will not allow us to use OSGi
dynamism. I very much hope that I am wrong because all our projects
are on OSGi.

Best regards, Pavel

On 09.09.2017 09:08, 'Achim Nierbeck' via OPS4J wrote:

Hi Pavel,

as all those projects are targeted to run in an  OSGi environment.
I don't see anything special to handle JPMS.
The goal is to have these bundles as OSGi bundles, so the OSGi framework
will take care of that.
JPMS does have a complete different goal (at least to my understanding)
Therefore I don't see any special handling is needed.

Besides maybe the pax-url project. It's the only one also capable of
running outside of a container.
Though as it's just another jar it should work right away on top of any
jdk.

regards, Achim

2017-09-08 19:56 GMT+02:00 Pavel <pavelkastor...@gmail.com>:


Hello, everyone

Pax products are well known (pax-logging, pax-cdi, pax-web, pax-exam etc)
in OSGi world.
I think that pax products are among the most important products for
building infrastructure
for OSGi. Thanks to community.

Now Java 9 with its own module system (JPMS) is about to be released.
Could anyone
give any information about pax products future and possible plans for
creating products for JPMS
infrastructure.

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.






--
--
--
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 products and JPMS of Java 9

2017-09-08 Thread Pavel

Hello, everyone

Pax products are well known (pax-logging, pax-cdi, pax-web, pax-exam etc) 
in OSGi world.
I think that pax products are among the most important products for 
building infrastructure
for OSGi. Thanks to community.

Now Java 9 with its own module system (JPMS) is about to be released. Could 
anyone
give any information about pax products future and possible plans for 
creating products for JPMS
infrastructure.

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-web] What are OSGI MVC frameworks that can be used with Pax-Web and Pax-CDI?

2017-06-06 Thread 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-web] Osgi + Pax-web + Spring - is there any sense

2017-06-06 Thread Pavel Kastornyy


Achim, then if Spring is not good for osgi why apache
builds Spring for osgi in project servicemix? The question
is related to another my question.

On 06.06.2017 15:11, 'Achim Nierbeck' via OPS4J wrote:

Hi Pavel,

kind of. If you want to have something similar to Spring, Blueprint is to
the rescue.
The downside of it, it's purely XML, that's where Declarative Services (DS)
come in handy,
as they support annotations, also for configurations.
Downside on DS, no inner-bundle wiring, only wiring of Services.

regards, Achim



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


Hi all

I had an idea to make a soltuion Osgi+Pax-web+Spring. But after reading
some information,
for example https://stackoverflow.com/a/25001220/5057736 and some work
it seems that such configuration
has no future. Am I right?

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.






--
--
--
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] JSP are not rendered with pax-web and Spring

2017-06-06 Thread Pavel Kastornyy


Hi Achim

1. Where did you take this bundle from? In cental maven repo
(http://central.maven.org/maven2/org/springframework/  )
I see only

org.springframework
spring-core
3.2.3.RELEASE

that is not osgi bundle. But I don't see there

org.springframework
org.springframework.core
3.2.3.RELEASE

which manifest you sent.

2. Besides there is a servicemix from Apache.
https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-core 


so, as I understand this service mix IS osgi version of spring.
What is the difference of org.springframework.core and 
org.apache.servicemix.bundles.spring-core?


Best regards, Pavel

On 04.06.2017 22:59, 'Achim Nierbeck' via OPS4J wrote:

Hi Pavel,

those spring dependencies are valid OSGi bundles.

this is the manifest of the org.springframework.core bundle:

regards, Achim

Manifest-Version: 1.0
Export-Package: org.springframework.asm;version="3.2.3.RELEASE",org.sp
  ringframework.asm.commons;version="3.2.3.RELEASE";uses:="org.springfr
  amework.asm,org.springframework.asm.signature,org.springframework.asm
  .tree",org.springframework.asm.signature;version="3.2.3.RELEASE",org.
  springframework.asm.util;version="3.2.3.RELEASE";uses:="org.springfra
  mework.asm",org.springframework.cglib;version="3.2.3.RELEASE",org.spr
  ingframework.cglib.beans;version="3.2.3.RELEASE";uses:="org.springfra
  mework.asm,org.springframework.cglib.core",org.springframework.cglib.
  core;version="3.2.3.RELEASE";uses:="org.springframework.asm,org.sprin
  gframework.cglib.transform",org.springframework.cglib.proxy;version="
  3.2.3.RELEASE";uses:="org.springframework.asm,org.springframework.cgl
  ib.core,org.springframework.cglib.reflect",org.springframework.cglib.
  reflect;version="3.2.3.RELEASE";uses:="org.springframework.asm,org.sp
  ringframework.cglib.core",org.springframework.cglib.transform;version
  ="3.2.3.RELEASE";uses:="org.apache.tools.ant,org.apache.tools.ant.typ
  es,org.springframework.asm,org.springframework.cglib.core",org.spring
  framework.cglib.transform.impl;version="3.2.3.RELEASE";uses:="org.spr
  ingframework.asm,org.springframework.cglib.core,org.springframework.c
  glib.transform",org.springframework.cglib.util;version="3.2.3.RELEASE
  ";uses:="org.springframework.asm,org.springframework.cglib.core",org.
  springframework.core;version="3.2.3.RELEASE";uses:="org.springframewo
  rk.asm,org.springframework.util",org.springframework.core.annotation;
  version="3.2.3.RELEASE";uses:="org.springframework.core",org.springfr
  amework.core.convert;version="3.2.3.RELEASE";uses:="org.springframewo
  rk.core",org.springframework.core.convert.converter;version="3.2.3.RE
  LEASE";uses:="org.springframework.core.convert",org.springframework.c
  ore.convert.support;version="3.2.3.RELEASE";uses:="org.springframewor
  k.core.convert,org.springframework.core.convert.converter",org.spring
  framework.core.enums;version="3.2.3.RELEASE";uses:="org.springframewo
  rk.util",org.springframework.core.env;version="3.2.3.RELEASE";uses:="
  joptsimple,org.apache.commons.logging,org.springframework.core.conver
  t,org.springframework.core.convert.support,org.springframework.util",
  org.springframework.core.io;version="3.2.3.RELEASE";uses:="org.spring
  framework.core.env",org.springframework.core.io.support;version="3.2.
  3.RELEASE";uses:="org.springframework.core.env,org.springframework.co
  re.io,org.springframework.util",org.springframework.core.serializer;v
  ersion="3.2.3.RELEASE",org.springframework.core.serializer.support;ve
  rsion="3.2.3.RELEASE";uses:="org.springframework.core,org.springframe
  work.core.convert.converter,org.springframework.core.serializer",org.
  springframework.core.style;version="3.2.3.RELEASE",org.springframewor
  k.core.task;version="3.2.3.RELEASE";uses:="org.springframework.util",
  org.springframework.core.task.support;version="3.2.3.RELEASE";uses:="
  org.springframework.core.task",org.springframework.core.type;version=
  "3.2.3.RELEASE",org.springframework.core.type.classreading;version="3
  .2.3.RELEASE";uses:="org.springframework.asm,org.springframework.core
  .annotation,org.springframework.core.io,org.springframework.core.type
  ,org.springframework.util",org.springframework.core.type.filter;versi
  on="3.2.3.RELEASE";uses:="org.springframework.core.type,org.springfra
  mework.core.type.classreading",org.springfra

Re: [pax-web] JSP are not rendered with pax-web and Spring

2017-06-04 Thread Pavel Kastornyy


Hi Achim

Thank you for your answer.

I am now trying to resolve all these dependencies and I can't
understand one thing. The half of the dependencies are not
osgi bundles. How to explain it? I mean the following are
not osgi bundles (version 3.2.3.RELEASE):

mavenBundle().groupId("org.springframework")
.artifactId("org.springframework.beans").versionAsInProject().start(true),
mavenBundle().groupId("org.springframework")
.artifactId("org.springframework.core").versionAsInProject().start(true),
mavenBundle().groupId("org.springframework")
.artifactId("org.springframework.context").versionAsInProject().start(true),
mavenBundle().groupId("org.springframework")
.artifactId("org.springframework.context.support").versionAsInProject().start(true),
mavenBundle().groupId("org.aopalliance")
.artifactId("com.springsource.org.aopalliance").versionAsInProject().start(true),
mavenBundle().groupId("org.springframework")
.artifactId("org.springframework.aop").versionAsInProject().start(true),
mavenBundle().groupId("org.springframework")
.artifactId("org.springframework.expression").versionAsInProject().start(true),
mavenBundle().groupId("org.springframework")
.artifactId("org.springframework.web").versionAsInProject().start(true),
mavenBundle().groupId("org.springframework")
.artifactId("org.springframework.web.servlet").versionAsInProject().start(true),


On 04.06.2017 15:46, 'Achim Nierbeck' via OPS4J wrote:

Hi Pavel,

you'll need a setup like the one in the Karaf based Integration test.
This sample can only be run in an environment like that one [1].

So make sure you have the bundles like the following installed [2],
but keep in mind, Karaf will bring a lot Out-Of-The-Box features and
bundles which might not be listed here
but still required. So it might not be enough for your own application
solely based on Pax-Web.

regards, Achim

[1] -
https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-itest/pax-web-itest-karaf/src/test/java/org/ops4j/pax/web/itest/karaf/SpringOsgiKarafTest.java
[2] -
https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-itest/pax-web-itest-karaf/src/test/java/org/ops4j/pax/web/itest/karaf/SpringOsgiKarafTest.java#L58-L85

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


Hi all

There is a sample https://github.com/ops4j/org.ops4j.pax.web/tree/master/
samples/war-spring for spring.
  When I run it with pax-web 6.1.0 - SNAPSHOT and jetty-9.3.11 (spring libs
are inside sample jar)
I get the following in my *browser*:

<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%> I've been called by the controller Controller send
me the following message: ${message}

So we see that JSP pages are not rendered as JSP, but are placed as simple
text files.
Could anyone give any suggestions? Did anyone try to make this sample work?

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.






--
--
--
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] JSP are not rendered with pax-web and Spring

2017-06-04 Thread Pavel

Hi all

There is a sample 
https://github.com/ops4j/org.ops4j.pax.web/tree/master/samples/war-spring 
for spring.
 When I run it with pax-web 6.1.0 - SNAPSHOT and jetty-9.3.11 (spring libs 
are inside sample jar)
I get the following in my *browser*:

<%@ page language="java" contentType="text/html; charset=UTF-8" 
pageEncoding="UTF-8"%> I've been called by the controller Controller send 
me the following message: ${message} 

So we see that JSP pages are not rendered as JSP, but are placed as simple 
text files.
Could anyone give any suggestions? Did anyone try to make this sample work?

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] PAXWEB-760 and Weld

2017-06-02 Thread Pavel

Hi Achim

Thank you for your answer. Weld developers asked their questions
based on the last comments - where we found steps to reproduce the bug.

See from this point 

https://ops4j1.jira.com/browse/PAXWEB-760?focusedCommentId=35942=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-35942
 


What can you say about weld listeners? Can this be the problem? 

Maybe we should wait until you can get access to desktop PC?
What will you say? I am sure it is not problem to wait.

Best regards, Pavel

пятница, 2 июня 2017 г., 20:49:05 UTC+3 пользователь Achim Nierbeck написал:
>
> Hi 
>
> First of all right now I only have a mobile device so my explanations 
> might be a bit brief.
>
> The initial description of the bug doesn't say anything of a restart. 
> Therefore I'm not sure we're actually tall about the same issue. Maybe 
> similar but from your description this seems to be different.
>
> Any way regarding your questions below.
> 1. A bundle update does the following.
> The old bundle is stopped and replaced by the new bundle. BUT there is no 
> refresh or better rewiring. This means all existing references to the old 
> bundle, for example references to classes are not updated. This can only be 
> solved by a bundle update followed by a refresh on  all bundles referencing 
> this one. 
>
> 2. I'm not sure I understand the context. But if you are talking of 
> updating another bundle which is indirectly referenced by the web 
> application bundle which is part of the session. No, reason see above.
>
> 3. Again I do not fully understand the context. But taken from the first 
> question, an update of another bundle. No, again if there is no refresh 
> there is no reason.
>
> Regards, Achim 
>
> Pavel <pavelka...@gmail.com > schrieb am Do. 1. Juni 2017 um 
> 15:32:
>
>> Hi all
>>
>> The post is about https://ops4j1.jira.com/browse/PAXWEB-760 bug. I had 
>> an idea
>> that maybe Weld developers could give any hints to fix this bug and I 
>> asked
>> them what they think about this bug.
>>
>> That is what they wrote: 
>> "It looks like the Weld container is restarted but the Weld listener is 
>> reused and thus is referencing the previous container which is cleaned 
>> up and shutdown."
>>
>> Besides they asked the following questions:
>> 1) What does Bundle.update actually do? 
>> 2) Is the HTTP session destroyed? 
>> 3) Are the HttpSessionListener instances thrown away?
>>
>> If someone of Pax-Web developers give me answer and I resend
>> them maybe Weld developers could say something else.
>>
>> 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.
>>
> -- 
>
> 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] PAXWEB-760 and Weld

2017-06-01 Thread Pavel

Hi all

The post is about https://ops4j1.jira.com/browse/PAXWEB-760 bug. I had an 
idea
that maybe Weld developers could give any hints to fix this bug and I asked
them what they think about this bug.

That is what they wrote: 
"It looks like the Weld container is restarted but the Weld listener is 
reused and thus is referencing the previous container which is cleaned 
up and shutdown."

Besides they asked the following questions:
1) What does Bundle.update actually do? 
2) Is the HTTP session destroyed? 
3) Are the HttpSessionListener instances thrown away?

If someone of Pax-Web developers give me answer and I resend
them maybe Weld developers could say something else.

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?

2017-05-22 Thread 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?

2017-05-22 Thread 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?

2017-05-22 Thread 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

2017-05-22 Thread 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.

[pax-cdi] Application scoped bean and its lifecycle

2017-05-21 Thread 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?

2017-05-20 Thread 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

2017-05-10 Thread 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

2017-05-09 Thread 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

2017-05-09 Thread 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

2017-05-09 Thread 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

2017-05-09 Thread 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

2017-05-09 Thread 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

[pax-cdi] Thread dead lock with osgi refresh

2017-05-08 Thread 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

[pax-cdi] Approximate plan of bug fixing

2017-04-17 Thread 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"

2017-04-13 Thread 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: [pag-logging] Is it possible to completely turn off logging?

2017-03-31 Thread Pavel

I've just tested. No, the fix didn't help. 

I use two bundles - pax-logging-api and pax-logging-service and I set 
-Dorg.ops4j.pax.logging.DefaultServiceLog.level=NONE and in result I get 
debug level.

Maybe the problem in level mismatch is that 
https://osgi.org/javadoc/r4v42/org/osgi/service/log/LogService.html doesn't 
have NONE/OFF levels?

пятница, 31 марта 2017 г., 9:57:35 UTC+3 пользователь Guillaume Nodet 
написал:
>
> The problem raised by Pavel is actually on the default logger.  I haven't 
> tested, but I think the configuration for each backend will already support 
> OFF or NONE, depending on the provider.  It just needs to be configured 
> correctly.
>
> For the default logger, some stuff was missing, I've committed a fix:
>
> https://github.com/ops4j/org.ops4j.pax.logging/commit/71aac7ef3f628a8923e5d1b5e6955923967b44eb
>
> Pavel, let me know if this works for you.
>
> 2017-03-31 8:52 GMT+02:00 'Achim Nierbeck' via OPS4J <
> op...@googlegroups.com >:
>
>> In that case we have a bug that we don't forward this to the underlying 
>> implementations. 
>>
>> Someone just needs to file a bug in JIRA and we need a patch :D
>>
>> regards, Achim 
>>
>>
>> 2017-03-31 8:16 GMT+02:00 Guillaume Nodet <gno...@apache.org 
>> >:
>>
>>> It seems log4j, log4j2 and logback have some support for OFF.
>>>
>>> 2017-03-30 23:05 GMT+02:00 Matt Sicker <boa...@gmail.com >:
>>>
>>>> Log4j2 supports the "OFF" level which is higher than "FATAL" 
>>>> effectively disabling logging. I'm not sure if there's an equivalent in v1 
>>>> or Logback.
>>>>
>>>> On 30 March 2017 at 14:53, 'Achim Nierbeck' via OPS4J <
>>>> op...@googlegroups.com > wrote:
>>>>
>>>>> Well if you only install the api bundle you don't have any logging as 
>>>>> that is only the API bundle. 
>>>>> The implementation and the actual logging is done from the service 
>>>>> bundle. 
>>>>>
>>>>> regarding NONE beeing a bug, I doubt that this is a bug. 
>>>>> Pax Logging just leverages different logging apis to one provider 
>>>>> (log4j2, with the latest one) 
>>>>> afaik none of the logging frameworks I'm aware of right now does have 
>>>>> a log level NONE (might be wrong on that, but never seen it or used it) 
>>>>> Usually if you don't want to log a certain class or certain packages 
>>>>> exclude those. 
>>>>>
>>>>> take a look at the log4j project for details [1] 
>>>>>
>>>>> regards, Achim 
>>>>>
>>>>> [1] - 
>>>>> https://logging.apache.org/log4j/2.x/manual/configuration.html#Loggers
>>>>>
>>>>>
>>>>> 2017-03-30 11:22 GMT+02:00 Pavel <pavelka...@gmail.com >:
>>>>>
>>>>>> However, I have noticed that when I add to my project only 
>>>>>> pax-logging-api such problem doesn't appear.
>>>>>>
>>>>>> However, when I add also pax-logging-service such problem appears.
>>>>>>
>>>>>> After reading the source code it seems that it is bug in 
>>>>>> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl in method 
>>>>>> convertLevel.
>>>>>> There is no condition when levelName=NONE.
>>>>>>
>>>>>> See this code
>>>>>>
>>>>>> if( m_bundleContext == null )
>>>>>> {
>>>>>> levelName = System.getProperty( 
>>>>>> DEFAULT_SERVICE_LOG_LEVEL, "DEBUG" ).trim();
>>>>>> }
>>>>>> else
>>>>>> {
>>>>>> levelName = m_bundleContext.getProperty( 
>>>>>> DEFAULT_SERVICE_LOG_LEVEL );
>>>>>> if( levelName == null )
>>>>>> {
>>>>>> levelName = "DEBUG";
>>>>>> }
>>>>>> else
>>>>>> {
>>>>>> levelName = levelName.trim();
>>>>>> }
>>>>>> }
>>>>>> m_logLevel = convertLevel( levelName );
>>>>>>  .
>>>>>>
>>>>>> private static int convertLevel( String level

Re: [pag-logging] Is it possible to completely turn off logging?

2017-03-30 Thread Pavel

Hi Achim,

Thank you very much for your answer.

Best regards, Pavel

четверг, 30 марта 2017 г., 11:42:33 UTC+3 пользователь Achim Nierbeck 
написал:
>
> Hi Pavel, 
>
> I doubt the log providers used by Pax-Logging support this concept of 
> "disabling" the logging this way. 
> Usually you just don't define an appender, if no appender no output :) 
>
> Regards, Achim 
>
> 2017-03-29 16:24 GMT+02:00 Pavel <pavelka...@gmail.com >:
>
>> Hi all.
>>
>> I have the following problem. When I set 
>> -Dorg.ops4j.pax.logging.DefaultServiceLog.level=ERROR - I get error 
>> level
>> -Dorg.ops4j.pax.logging.DefaultServiceLog.level=DEBUG - I get debug 
>> level
>> -Dorg.ops4j.pax.logging.DefaultServiceLog.level=INFO - I get info 
>> level
>> -Dorg.ops4j.pax.logging.DefaultServiceLog.level=WARN - I get warn 
>> level
>>
>> However, when I set
>> -Dorg.ops4j.pax.logging.DefaultServiceLog.level=NONE - I get debug 
>> level
>> -Dorg.ops4j.pax.logging.DefaultServiceLog.level=OFF - I get debug 
>> level.
>>
>> I tried with pax-logging-ap 1.8.5 and 1.9.1. result is the same.
>>
>> Could anyone say how logging from API can be completely turned off? 
>>
>> 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.
>>
>
>
>
> -- 
>
> 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:WEB How many war bundles do pax-web support?

2016-10-02 Thread Pavel Kastornyy

Ok, Achim. Thank you for detailed answers.

I currently need and use only the following subprojects:

pax-web-api-6.0.0-SNAPSHOT.jar
pax-web-deployer-6.0.0-SNAPSHOT.jar
pax-web-descriptor-6.0.0-SNAPSHOT.jar
pax-web-extender-war-6.0.0-SNAPSHOT.jar
pax-web-extender-whiteboard-6.0.0-SNAPSHOT.jar
pax-web-jetty-6.0.0-SNAPSHOT.jar
pax-web-jsp-6.0.0-SNAPSHOT.jar
pax-web-runtime-6.0.0-SNAPSHOT.jar
pax-web-spi-6.0.0-SNAPSHOT.jar

Firstly I will take some time to study them. If after analysis I can
find and suggest some

solution which will require not so much time I will discuss it with you.

But I say in advance that if I will do something, it will be linked only
with subprojects

I need and use. I think the reason can be easily understood.

Best regards,

On 02.10.2016 19:35, 'Achim Nierbeck' via OPS4J wrote:

About a person year, with the prerequisite that the current implementation
is well known.

1) Not really, certain people working on the code are paid to do so.
2) Nope, it's an open source project most people working on this do this in
their private time.
Sometimes those people (like me) don't even work on any related stuf
anymore.
3) Hard to tell ... as we have people which get engaged for certain topics
which move off after a certain amount of time
Here's a complete list of recent developers [1]

regards, Achim

[1] - https://github.com/ops4j/org.ops4j.pax.web/graphs/contributors

2016-10-02 18:20 GMT+02:00 Pavel Kastornyy <pavelkastor...@gmail.com>:

Achim, thank you for the information. So about one person year
if I understand you right.

Could you also shortly answer the following questions:

1) is there any financial help from any companies?
2) has the community tried to draw investments into the product?
3) how many active developers are there at this time?

Best regards,

On 02.10.2016 18:47, 'Achim Nierbeck' via OPS4J wrote:

wow, that's a tough one ... :D

if you take a look at Openhub [1] ... it'll tell you it took about 57
years
[2], or at least it's the amount of work worth it ;)

Anyway it's hard to estimate as I've spent the last 6 years improving on
it. Never the less if I would work on it full time 8h day
with the knowledge I have right now. One person could redo it within maybe
a year. But it's a wild guess ... might be faster, might take longer ...
Of course I would expect it to have the same features and possibilities it
has which makes it different to other implementations of the HttpService
etc. Right now we have about 500 unit and integration tests running with
every build [3].
That functionality I would expect to be available after the re-write ;)

BUT, the nice thing is. We can always start with a new branch and work on
that in parallel.
If there are enough people to work on it it should work.

[1] - https://www.openhub.net/p/pax-web
[2] - https://www.openhub.net/p/pax-web/estimated_cost
[3] - http://ci.ops4j.org/jenkins/job/org.ops4j.pax.web/1028/testReport/

2016-10-02 15:39 GMT+02:00 iJava <pavelkastor...@gmail.com>:

Hi Achim

Could you say (from the top of your head) approximatively how many hours
may these changes need - 100/1000/5000/1?

Best regards,

воскресенье, 2 октября 2016 г., 15:40:23 UTC+3 пользователь Achim
Nierbeck
написал:

Sounds like a good and interesting idea ...
Right now only from the top of my head:
The Pax-Web Runtime and therefore the different Implementations aren't
made for this right now. So this would need a complete rewrite of how
we're
handling it. Another point would be how would web and white-board
extender
work with it. We could think about wiring those two closer to the core.
Never the less an application deploying servlets will always need to add
the virtual host environment, working with defaults could take care of
that.

We could consider to start this with a complete rewrite of Pax-Web and
therefore aim for a 7.0.

BUT ... I fear I won't have enough time to takle this. Considering the
amount of time I spent in the past and about what it would take to have
all
the functionalities of Pax-Web re-written, and especially with my
$dayJob +
Family.

regards, Achim

2016-10-02 5:35 GMT+02:00 Niclas Hedhman <nic...@hedhman.org>:

Honestly, if this is to be fixed, I think Pax Web should support Managed

Service Factory, and instantiate separate virtual host services
according
to a provided configuration. That configuration should contain which
WAB(s)
goes into that virtual host, together with any other virtual host
configuration.

To me, that seems to be the right solution forward, maintains OSGi
compatibility, doesn't introduce new config args on WABs and doesn't
treat
"one domain" different than another.

I think the tricky bit is to make the default case and the MSF
instantiations play nicely with each other, but that is an design
implementation detail at this stage.

Cheers
Niclas

On Sat, Oct 1, 2016 at 4:49 PM, iJava <pavelka...@gmail.com> wrote:

I analyzed situation again and I

Re: PAX:WEB How many war bundles do pax-web support?

2016-10-02 Thread Pavel Kastornyy

benefits of those underlying servers in the
same way. If you're not satisfied because you expect something
different. I'm sorry to hear
but nothing we can do about.

regards, Achim

2016-09-30 17:04 GMT+02:00 Achim Nierbeck <bcan...@googlemail.com>:

Well, in that case try to use GlassFish again.
GlassFish uses a complete different strategy.

Regards, Achim

2016-09-30 17:02 GMT+02:00 iJava <pavelka...@gmail.com>:

Something is wrong here. I worked with glassfish. Everything starts
with glassfish domain.
In one domain you usually have one http connector and one https
connector. After that in
one domain you can have multiple virtual hosts. When you deploy
osgi bundle you
in manifest have Web-ContextPath and VirtualServers. So you can
have N sites
(example.com, boo.org, blablabla.net) with WebContextPath / and it
is not necessary
to create new connectors for new ports.

I know it well, because I remember it took me some time to make it
work.
And I was very glad because it is easy to work with one port then
with N.

Now you suggest me to go back and again work with N ports. I am
shocked and killed.

пятница, 30 сентября 2016 г., 17:49:30 UTC+3 пользователь Achim
Nierbeck написал:

Hi,

yes, you can only have one Web-ContextPath per WAB. "/" is
especially tricky since you can also have HttpService servlets listening on
that one.

regards, Achim

2016-09-30 16:46 GMT+02:00 iJava <pavelka...@gmail.com>:

Hi Achim

Thank you for the links, I wil study them now. So, do I
understand it right -
accroding to specs I can have only one bundle with
web-contextpath / for one port ?

Best regards,

пятница, 30 сентября 2016 г., 17:37:55 UTC+3 пользователь Achim
Nierbeck написал:

It's in the spec ...

Now, if you want to run virtual hosts, take a look at the links
below.

regards, Achim

[1] - https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax
-web-itest/pax-web-itest-container/pax-web-itest-container-
jetty/src/test/java/org/ops4j/pax/web/itest/jetty/JettyConfi
gurationExtendedIntegrationTest.java
[2] - https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax
-web-itest/pax-web-itest-container/pax-web-itest-container-
jetty/src/test/java/org/ops4j/pax/web/itest/jetty/JettyConfi
gurationExtendedTwoIntegrationTest.java
[3] - http://notizblog.nierbeck.de/2013/01/bind-certain-web-appl
ications-to-specific-httpconnectors/

2016-09-30 16:23 GMT+02:00 Pavel Kastornyy <pavelka...@gmail.com

:
Achim, I understand you, but why? If the domains are different
why must I change web-contextpath? For example, lets suppose
I have five different sites on one osgi and for every site I
have
separate wab (which is logical) and every wab has only one
context
- /. It is normal situation - take a look at any web server.

Best regards,

On 30.09.2016 17:19, 'Achim Nierbeck' via OPS4J wrote:

The Manifest entry Web-ContextPath is the one in charge of
where the
application resides in.
So in that case you need to make sure of different
Web-ContextPaths.

regards, Achim

2016-09-30 16:09 GMT+02:00 iJava <pavelka...@gmail.com>:

Hi Achim,

Yes, you are right. The same web-contextpath in both bundles:
/

But it seems to be a bug because in bundle A I have
jetty-web.xml

example.com
www.example.com

and in bundle B I have jetty-web.xml

foo.example.com
www.foo.example.com

пятница, 30 сентября 2016 г., 16:54:24 UTC+3 пользователь
Achim Nierbeck
написал:

Hi,

this seems to be a rather strange bug. Do both of the war
maybe have the
same web-contextpath?

regards, Achim

2016-09-30 14:09 GMT+02:00 iJava <pavelka...@gmail.com>:

Hi all

It may seem to be funny question but I have the following
situation. I
have two war bundles A and B.
When I start and install only bundle A - it works ok. When
I start and
install only bundle B it works ok.

When I try to install both of them always only the first
works. The
servlet in the second bundle is not
instantiated. I tried to add 0
to
servlet config
in web.xml but it didn't help.

Any ideas? Does anyone try to deploy more then one war
bundle on the same
osgi framework with pax-web 6.0?

Best regards,

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

--
-

Re: Pax-web says it is available but it not available.

2016-08-09 Thread Pavel Kastornyy

Thank you. I solved the problem. Could you give a hint to another my 
thread - why jasper compiles jsp again and again?


On 09.08.2016 17:55, 'Achim Nierbeck' via OPS4J wrote:

Hi,

As I'm still on vacation only a quick hint.
Take a look at the PAX Web integration tests. They do use all of the
samples and show which bundles to use.

Regards, Achim

sent from mobile device

Am 09.08.2016 10:05 vorm. schrieb "iJava" :


Ok. I finally made it working: I added two bundles:
pax-web-extender-war-4.2.7.jar
pax-web-extender-whiteboard-4.2.7.jar

And the server started listen port. However, when I do
http://127.0.0.1:8080/wab-jetty-web/
I get
HTTP ERROR 403  Problem accessing /wab-jetty-web/. Reason:  Forbidden

Could anyone help me solve it? I doubt that I can solve this problem
without help.

My full log is:

org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Enabling SLF4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Enabling Jakarta Commons Logging API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Enabling Log4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Enabling Avalon Logger API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Enabling JULI Logger API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Enabling Log4J v2 API support. Ignored FQCN: org.apache.logging.log4j.spi.
AbstractLogger
[main] INFO org.ops4j.pax.web.service.internal.Activator - EventAdmin
support enabled, servlet events will be postet to topics.
[main] INFO org.ops4j.pax.web.service.internal.Activator - LogService
support enabled, log events will be created.
[main] INFO org.ops4j.pax.web.service.internal.Activator - Pax Web started
2016-08-09 10:58:10.915:INFO::pool-28-thread-1: Logging initialized
@1184ms
[pool-28-thread-1] INFO 
org.ops4j.pax.web.service.jetty.internal.JettyFactoryImpl
- SPDY not available, creating standard ServerConnector for Http
[pool-28-thread-1] INFO org.ops4j.pax.web.service.jetty.internal.JettyServerImpl
- Pax Web available at [0.0.0.0]:[8080]
[pool-28-thread-1] INFO 
org.ops4j.pax.web.service.internal.HttpServiceFactoryImpl
- Binding bundle: [org.ops4j.pax.web.samples.wab-jetty-web [41]] to http
service
[pool-28-thread-1] INFO 
org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper
- will add org.apache.jasper.servlet.JasperInitializer to
ServletContainerInitializers
[pool-28-thread-1] INFO 
org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper
- Skipt org.apache.jasper.servlet.JasperInitializer, because specialized
handler will be present
[pool-28-thread-1] INFO 
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext
- registering context WebAppHttpContext{org.ops4j.pax.web.samples.wab-jetty-web
- 41}, with context-name: wab-jetty-web
[pool-28-thread-1] INFO 
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext
- registering JasperInitializer
org.ops4j.pax.web.pax-web-jsp[org.apache.tomcat.util.digester.Digester] :
addRuleSet() with no namespace URI
org.ops4j.pax.web.pax-web-jsp[org.apache.tomcat.util.digester.Digester] :
addRuleSet() with no namespace URI
2016-08-09 10:58:11.372:WARN:oejs.ServletContextHandler:pool-28-thread-1:
ServletContextHandler.setHandler should not be called directly. Use
insertHandler or setSessionHandler etc.
[pool-28-thread-1] ERROR org.ops4j.pax.web.jsp.JspServletWrapper -
Ignored exception
java.lang.NullPointerException
 at org.ops4j.pax.web.jsp.JspServletWrapper$1.call(
JspServletWrapper.java:101)
 at org.ops4j.pax.web.jsp.JspServletWrapper$1.call(
JspServletWrapper.java:97)
 at org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.
doWithClassLoader(ContextClassLoaderUtils.java:60)
 at org.ops4j.pax.web.jsp.JspServletWrapper.init(
JspServletWrapper.java:96)
 at org.eclipse.jetty.servlet.ServletHolder.initServlet(
ServletHolder.java:640)
 at org.eclipse.jetty.servlet.ServletHolder.initialize(
ServletHolder.java:419)
 at org.eclipse.jetty.servlet.ServletHandler.initialize(
ServletHandler.java:875)
 at org.eclipse.jetty.servlet.ServletContextHandler.startContext(
ServletContextHandler.java:349)
 at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.
startContext(HttpServiceContext.java:590)
 at org.eclipse.jetty.server.handler.ContextHandler.
doStart(ContextHandler.java:772)
 at org.eclipse.jetty.servlet.ServletContextHandler.doStart(
ServletContextHandler.java:262)
 at org.ops4j.pax.web.service.jetty.internal.
HttpServiceContext.doStart(HttpServiceContext.java:249)
 at org.eclipse.jetty.util.component.AbstractLifeCycle.
start(AbstractLifeCycle.java:68)
 at org.ops4j.pax.web.service.jetty.internal.JettyServerImpl$1.start(
JettyServerImpl.java:273)
 at org.ops4j.pax.web.service.internal.HttpServiceStarted.

Re: PAX:WEB How many war bundles do pax-web support?

Re: Pax products and JPMS of Java 9

Pax products and JPMS of Java 9

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

Re: [pax-web] Osgi + Pax-web + Spring - is there any sense

Re: [pax-web] JSP are not rendered with pax-web and Spring

Re: [pax-web] JSP are not rendered with pax-web and Spring

[pax-web] JSP are not rendered with pax-web and Spring

Re: [pax-web] PAXWEB-760 and Weld

[pax-web] PAXWEB-760 and Weld

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

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

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

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

[pax-cdi] Application scoped bean and its lifecycle

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

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

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

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

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

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

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

[pax-cdi] Thread dead lock with osgi refresh

[pax-cdi] Approximate plan of bug fixing

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

Re: [pag-logging] Is it possible to completely turn off logging?

Re: [pag-logging] Is it possible to completely turn off logging?

Re: PAX:WEB How many war bundles do pax-web support?

Re: PAX:WEB How many war bundles do pax-web support?

Re: Pax-web says it is available but it not available.

30 matches

Site Navigation

Mail list logo

Footer information