Re: [VOTE] JB Onofre takes over ops4j domains

[Niclas Hedhman]

Yes, and I wish OPS4J another 15 years of success going forward.

Keep up the good work, everyone!

On Sat, Apr 4, 2020, 12:48 Jean-Baptiste Onofré <
jeanbaptiste.ono...@gmail.com> wrote:

> Hi,
>
> Just to let you know that domains transfer is now effective. Niclas and I
> have manage the transfer.
>
> Regards
> JB
>
> On Fri, Apr 3, 2020 at 8:45 AM Niclas Hedhman  wrote:
>
>> I think we have consensus, and I will initiate domain transfer off-list
>> with JB
>>
>> Thanks everyone for giving your support.
>>
>> On Thu, Apr 2, 2020 at 9:12 PM Freeman Fang 
>> wrote:
>>
>>> +1 and thanks for JB to take over.
>>>
>>> Thanks Niclas!
>>> Freeman
>>>
>>> On Tue, Mar 31, 2020 at 2:23 AM Niclas Hedhman 
>>> wrote:
>>>
>>>>
>>>> Since the OPS4J inception in 2005, I have paid the ops4j domain names.
>>>> I think 15-16 years is enough, and have recently announced that I am no
>>>> longer willing to be the custodian of these domain names.
>>>>
>>>> JB Onofre has offered to take over.
>>>>
>>>> Vote;
>>>>
>>>> [ ] - JB Onofre as new custodian
>>>> [ ] - No. Let's find some other solution.
>>>>
>>>>
>>>> // Niclas
>>>>
>>>> --
>>>> --
>>>> --
>>>> 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.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/ops4j/CADmm%2BKc%2BU1zrh162G2ohMDO2Vr3WP4TkFkHZ2QWe1KC5G9Mz-A%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/ops4j/CADmm%2BKc%2BU1zrh162G2ohMDO2Vr3WP4TkFkHZ2QWe1KC5G9Mz-A%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>>> --
>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/ops4j/CAM0LEOaHLVubGKcNYNyCjtFWYrKrkKWatMcP_hc8cWaAeSFMNQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/ops4j/CAM0LEOaHLVubGKcNYNyCjtFWYrKrkKWatMcP_hc8cWaAeSFMNQ%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> --
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ops4j/CADmm%2BKe%2BsfeUh59rw7gRvyy1QEJ0g3RsCZ7gErRQHmY-Wfm78Q%40mail.gmail.com
>> <https://groups.google.com/d/msgid/ops4j/CADmm%2BKe%2BsfeUh59rw7gRvyy1QEJ0g3RsCZ7gErRQHmY-Wfm78Q%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ops4j/CAB8EV3Q0z-5%2BUdTM%3Dd24meOo7ChX-%3Dff15vxM4897Bxyc_-zCQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/ops4j/CAB8EV3Q0z-5%2BUdTM%3Dd24meOo7ChX-%3Dff15vxM4897Bxyc_-zCQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
-- 
--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CADmm%2BKenLUD1zO_BntXti0d-eMnPU2ByEdVuF-k8F5y3rcaP%2BQ%40mail.gmail.com.

Re: [VOTE] JB Onofre takes over ops4j domains

[Niclas Hedhman]

I think we have consensus, and I will initiate domain transfer off-list
with JB

Thanks everyone for giving your support.

On Thu, Apr 2, 2020 at 9:12 PM Freeman Fang  wrote:

> +1 and thanks for JB to take over.
>
> Thanks Niclas!
> Freeman
>
> On Tue, Mar 31, 2020 at 2:23 AM Niclas Hedhman  wrote:
>
>>
>> Since the OPS4J inception in 2005, I have paid the ops4j domain names. I
>> think 15-16 years is enough, and have recently announced that I am no
>> longer willing to be the custodian of these domain names.
>>
>> JB Onofre has offered to take over.
>>
>> Vote;
>>
>> [ ] - JB Onofre as new custodian
>> [ ] - No. Let's find some other solution.
>>
>>
>> // Niclas
>>
>> --
>> --
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ops4j/CADmm%2BKc%2BU1zrh162G2ohMDO2Vr3WP4TkFkHZ2QWe1KC5G9Mz-A%40mail.gmail.com
>> <https://groups.google.com/d/msgid/ops4j/CADmm%2BKc%2BU1zrh162G2ohMDO2Vr3WP4TkFkHZ2QWe1KC5G9Mz-A%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ops4j/CAM0LEOaHLVubGKcNYNyCjtFWYrKrkKWatMcP_hc8cWaAeSFMNQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/ops4j/CAM0LEOaHLVubGKcNYNyCjtFWYrKrkKWatMcP_hc8cWaAeSFMNQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
-- 
--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CADmm%2BKe%2BsfeUh59rw7gRvyy1QEJ0g3RsCZ7gErRQHmY-Wfm78Q%40mail.gmail.com.

[VOTE] JB Onofre takes over ops4j domains

[Niclas Hedhman]

Since the OPS4J inception in 2005, I have paid the ops4j domain names. I
think 15-16 years is enough, and have recently announced that I am no
longer willing to be the custodian of these domain names.

JB Onofre has offered to take over.

Vote;

[ ] - JB Onofre as new custodian
[ ] - No. Let's find some other solution.


// Niclas

-- 
-- 
--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CADmm%2BKc%2BU1zrh162G2ohMDO2Vr3WP4TkFkHZ2QWe1KC5G9Mz-A%40mail.gmail.com.

Re: ops4j domain names

[Niclas Hedhman]

I am... That is then what the vote is for...



On Tue, Mar 31, 2020 at 1:39 PM Jean-Baptiste Onofré <
jeanbaptiste.ono...@gmail.com> wrote:

> Even if we go to ops4j.github.com, I think it will be helpful to redirect
> from ops4j.org. So, I volunteer to "take" the ops4j domain. It will give
> us time to "transfer" resources to github.
>
> OK with that ?
>
> Regards
> JB
>
> On Tue, Mar 31, 2020 at 4:15 AM Niclas Hedhman  wrote:
>
>>
>> The thread's primary question is;
>>
>> Shall I a) let the ops4j domain names expire, or b) transfer them to
>> someone else? If b), then Who/What?
>>
>> The rest is "interesting" but actually "out of scope" for something very
>> concrete in 10 weeks time. The full structure of community can in principle
>> be discussed/decided later, or not...
>>
>>
>> // Niclas
>>
>> On Mon, Mar 30, 2020 at 10:37 PM Jean-Baptiste Onofré <
>> jeanbaptiste.ono...@gmail.com> wrote:
>>
>>> I agree.
>>>
>>> What do you think I start a vote on the mailing list to propose to move
>>> to ops4j.github.com ?
>>>
>>> Regards
>>> JB
>>>
>>> On Mon, Mar 30, 2020 at 4:34 PM Peter Neubauer 
>>> wrote:
>>>
>>>> Thanks Niclas for bringing up the issue!
>>>>
>>>> FWIW - I think Github is basically what OPS4J set out to be
>>>> code-contribution-wise. IMHO going back to Apache is a matter of the
>>>> community deciding if the barriers for governance/contribution are lower
>>>> now. Otherwise - I think just moving everything to Github - only would be
>>>> the lowest-threshold option here.
>>>>
>>>> /peter
>>>>
>>>> On Monday, March 23, 2020 at 8:50:52 AM UTC+1, Guillaume Nodet wrote:
>>>>>
>>>>> Imho, we should switch everything to github.  I wouldn't even bother
>>>>> paying for a domain, i think something like ops4j.github.org is
>>>>> enough.
>>>>>
>>>>> Le mer. 19 févr. 2020 à 13:01, Toni Menzel  a
>>>>> écrit :
>>>>>
>>>>>> *TL/TR:*
>>>>>> I'd be also happy to pay for ops4j.org (the one that is actively
>>>>>> used atm).
>>>>>>
>>>>>> *Long version:*
>>>>>> Since this is coming up now, there is a general question were to go
>>>>>> with OPS4J in general.
>>>>>>
>>>>>> It predated github and probably was back then the easiest way to get
>>>>>> hands dirty in a non-trivial java based OSS community where trust was
>>>>>> default. Think about it, back then everyone could get write access to the
>>>>>> subversion repo and start hacking on new or existing projects. Including
>>>>>> admin access to jira and whatever else was existing back then. Pax URL, 
>>>>>> Pax
>>>>>> Runner, Pax Exam, Pax Construct etc. all got initiated by individuals
>>>>>> without asking for permission. I mean.. thats Names like Pax Tinybundles
>>>>>> got to life.. but oh well.
>>>>>>
>>>>>> Now, why am I writing this: there is - at least for pax url, web and
>>>>>> exam - a huge user base that seems to be quite healthy. Even if there is
>>>>>> just that "ops4j" name of the github organization now, no website etc.
>>>>>>
>>>>>> So, question: what are the options? Let me just drop them here that
>>>>>> come to my mind (ordered from easy-as-py to more complicated options):
>>>>>>
>>>>>>- keep things as is, find individual sponsors like I do with the
>>>>>>Build Server (who uses that still by the way??), and JB or me (this 
>>>>>> means
>>>>>>I'd be also fine to pay for the org domain that is in active use,too 
>>>>>> btw).
>>>>>>It would be good to have two different companies or legal entities 
>>>>>> backing
>>>>>>this anyway.
>>>>>>- Modernize OPS4J a bit. Get it a landing page at least and a
>>>>>>clear who is behind all this, who pays etc. Maybe look at Github 
>>>>>> Sponsoring
>>>>>>to spread costs across user base - avoid single entity control.
>>>>>>- Maybe look into makin

Re: ops4j domain names

[Niclas Hedhman]

The thread's primary question is;

Shall I a) let the ops4j domain names expire, or b) transfer them to
someone else? If b), then Who/What?

The rest is "interesting" but actually "out of scope" for something very
concrete in 10 weeks time. The full structure of community can in principle
be discussed/decided later, or not...


// Niclas

On Mon, Mar 30, 2020 at 10:37 PM Jean-Baptiste Onofré <
jeanbaptiste.ono...@gmail.com> wrote:

> I agree.
>
> What do you think I start a vote on the mailing list to propose to move to
> ops4j.github.com ?
>
> Regards
> JB
>
> On Mon, Mar 30, 2020 at 4:34 PM Peter Neubauer 
> wrote:
>
>> Thanks Niclas for bringing up the issue!
>>
>> FWIW - I think Github is basically what OPS4J set out to be
>> code-contribution-wise. IMHO going back to Apache is a matter of the
>> community deciding if the barriers for governance/contribution are lower
>> now. Otherwise - I think just moving everything to Github - only would be
>> the lowest-threshold option here.
>>
>> /peter
>>
>> On Monday, March 23, 2020 at 8:50:52 AM UTC+1, Guillaume Nodet wrote:
>>>
>>> Imho, we should switch everything to github.  I wouldn't even bother
>>> paying for a domain, i think something like ops4j.github.org is enough.
>>>
>>> Le mer. 19 févr. 2020 à 13:01, Toni Menzel  a
>>> écrit :
>>>
>>>> *TL/TR:*
>>>> I'd be also happy to pay for ops4j.org (the one that is actively used
>>>> atm).
>>>>
>>>> *Long version:*
>>>> Since this is coming up now, there is a general question were to go
>>>> with OPS4J in general.
>>>>
>>>> It predated github and probably was back then the easiest way to get
>>>> hands dirty in a non-trivial java based OSS community where trust was
>>>> default. Think about it, back then everyone could get write access to the
>>>> subversion repo and start hacking on new or existing projects. Including
>>>> admin access to jira and whatever else was existing back then. Pax URL, Pax
>>>> Runner, Pax Exam, Pax Construct etc. all got initiated by individuals
>>>> without asking for permission. I mean.. thats Names like Pax Tinybundles
>>>> got to life.. but oh well.
>>>>
>>>> Now, why am I writing this: there is - at least for pax url, web and
>>>> exam - a huge user base that seems to be quite healthy. Even if there is
>>>> just that "ops4j" name of the github organization now, no website etc.
>>>>
>>>> So, question: what are the options? Let me just drop them here that
>>>> come to my mind (ordered from easy-as-py to more complicated options):
>>>>
>>>>- keep things as is, find individual sponsors like I do with the
>>>>Build Server (who uses that still by the way??), and JB or me (this 
>>>> means
>>>>I'd be also fine to pay for the org domain that is in active use,too 
>>>> btw).
>>>>It would be good to have two different companies or legal entities 
>>>> backing
>>>>this anyway.
>>>>- Modernize OPS4J a bit. Get it a landing page at least and a clear
>>>>who is behind all this, who pays etc. Maybe look at Github Sponsoring to
>>>>spread costs across user base - avoid single entity control.
>>>>- Maybe look into making it a proper foundation or at least an
>>>>entity that makes the work here eligible for future donations. I am not
>>>>sure of this is worth it. But i feel Open Source != Open Governance.
>>>>- Retire non active projects and donate active projects to apache.
>>>>Probably difficult because of Intellectual Property)
>>>>
>>>> wdyt?
>>>> Toni
>>>>
>>>>
>>>>
>>>>
>>>> *Toni Menzel | rebaze.com <https://www.rebaze.com> | growing developer
>>>> culture*
>>>>
>>>>
>>>> On Wed, Feb 19, 2020 at 12:37 PM Jean-Baptiste Onofré <
>>>> jeanbapti...@gmail.com> wrote:
>>>>
>>>>> Hi Niclas
>>>>>
>>>>> First of all, thanks a lot for all what you did (and still doing ).
>>>>>
>>>>> I’m ready to take the hand for the domain and finance them.
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> Le mer. 19 févr. 202

Re: ops4j domain names

[Niclas Hedhman]

Since I know one thing or two about Apache and the Apache License...
perhaps I should chime in.

1. Pax Logger was actually donated to Felix once before, but nothing came
out of it. It was a simple IP clearance paper to fill in and upload
together with a tarball. This was simple because no community came with it.

2. Since re-licensing is not needed, all contributions in OPS4J can be
handed over to Apache Software Foundation without getting approvals from
individuals. Legally, Karaf could take the bits it wants and continue "over
there", but that is against the tradition in Apache to not fork if the
community doesn't want it.

3. IMHO, the main issue with Apache (or any other foundation) would be the
"community". I would expect that everyone that has contributed anything
would "come along" to Apache, in which case Karaf PMC might not be OK of
accepting that many committers in one go, although they could do it. Going
in via the Incubator is something I probably would recommend against. I
haven't checked recently, but many years ago there were >100 contributors
that had made commits to the Pax codebase. Of course, many just showed up
for a single commit, and many are no longer around. But they shouldn't be
ignored.

Niclas

On Thu, Feb 20, 2020 at 4:22 PM 'Christoph Läubrich' via OPS4J <
ops4j@googlegroups.com> wrote:

> This does not mean that it would only be possible under any
> "governance-umbrella", but I also understand that Karaf is the main
> consumer and/or driver of current development.
>
> Thus I'm not completely against it (and would not have any obligations
> to give any organization the required permission for any contribution I
> have made to pax projects), my only fear is that this process will even
> be going further so things are getting more and more "karaf-like" and
> other requirements are not taken into account anymore.
>
> So whatever is decided, I have really enjoyed all the years even though
> contributions from my side are not always constant over time it was the
> entry-point for me to getting started with OpenSource contributions.
>
>

-- 
-- 
--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CADmm%2BKdr%3DgFHo5d7_aSLTm_uucaHW%3DyrEeQat%3DjjUth_BJDdGw%40mail.gmail.com.

ops4j domain names

[Niclas Hedhman]

Everyone,
In a few months time (June), the OPS4J domain names are up for renewal. And
I have been paying for those for 15 years now, and since I no longer
participate in OPS4J I would like to transfer the domain names. But where
to??

Ideally a foundation that would be Ok to take it over, otherwise to a
trusted community member.

Ideas are welcome, and should be discussed. I have no opinion and will
simply follow what you all can agree on.

ops4j.org
ops4j.net
ops4j.com


Cheers
Niclas

-- 
-- 
--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CADmm%2BKf7a0rzdkro7v-rxBV1p1-KkSMTE_BQT2HhUZyOUM9jyA%40mail.gmail.com.

Re: [PAX EXAM] file name too long?

[Niclas Hedhman]

Never mind, I found part of the answer inside ~/.m2/repository and realize
that the BND instructions are placed as file names somehow, and not into a
bnd file, so line breaks doesn't work.

Making it into a single line, the exception changes to

Caused by: java.net.MalformedURLException: Invalid syntax for instruction
[Require-Capability:
osgi.extender;filter:="(osgi.extender=osgi.serviceloader.processor)",osgi.serviceloader;filter:="(osgi.serviceloader=javax.json.spi.JsonProvider)";cardinality:=multiple]


even though I have copied that verbatim from
https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html


Any thoughts?


On Thu, Aug 15, 2019 at 10:56 AM Niclas Hedhman  wrote:

>
> Gang,
> I got the exception below, when using wrappedBundle() to add handling for
> Javax JSON API service loader, without rewriting the original bundle
> manifest.
>
> Does anyone understand what is happening and what can be done about it?
>
> Code is
>
> wrappedBundle( mavenBundle( "javax.json", "javax.json-api", "1.1" ).getURL() )
> .overwriteManifest( WrappedUrlProvisionOption.OverwriteMode.MERGE )
> .instructions( "Require-Capability: osgi.extender;\\\n"
>+ "
> filter:=\"(osgi.extender=osgi.serviceloader.processor)\",\\\n"
>+ "  osgi.serviceloader;\\\n"
>+ "
> filter:=\"(osgi.serviceloader=javax.json.spi.JsonProvider)\";\\\n"
>+ "cardinality:=multiple" ),
> mavenBundle( "org.apache.johnzon", "johnzon-core", "1.1.1" ),
>
>
>
> Exception in thread "main" org.ops4j.pax.exam.TestContainerException:
> Problem starting test container.
> at
> org.ops4j.pax.exam.nat.internal.NativeTestContainer.start(NativeTestContainer.java:212)
> at
> com.spicter.niclas1.test.integration.PaxExamStarter.main(PaxExamStarter.java:26)
> Caused by: org.osgi.framework.BundleException: Unable to cache bundle:
> wrap:mvn:javax.json/javax.json-api/1.1$overwrite=MERGE:
> osgi.extender;\
> filter:="(osgi.extender=osgi.serviceloader.processor)",\
>   osgi.serviceloader;\
> filter:="(osgi.serviceloader=javax.json.spi.JsonProvider)";\
> cardinality:=multiple
> at org.apache.felix.framework.Felix.installBundle(Felix.java:3013)
> at
> org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:167)
> at
> org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:140)
> at
> org.ops4j.pax.exam.nat.internal.NativeTestContainer.installAndStartBundles(NativeTestContainer.java:340)
> at
> org.ops4j.pax.exam.nat.internal.NativeTestContainer.start(NativeTestContainer.java:209)
> ... 1 more
> Caused by: java.io.IOException: Error resolving artifact
> javax.json:javax.json-api:jar:1.1$overwrite=MERGE:
> osgi.extender;\
> filter:="(osgi.extender=osgi.serviceloader.processor)",\
>   osgi.serviceloader;\
> filter:="(osgi.serviceloader=javax.json.spi.JsonProvider)";\
> cardinality:=multiple: Could not transfer artifact
> javax.json:javax.json-api:jar:1.1$overwrite=MERGE:
> osgi.extender;\
> filter:="(osgi.extender=osgi.serviceloader.processor)",\
>   osgi.serviceloader;\
> filter:="(osgi.serviceloader=javax.json.spi.JsonProvider)";\
> cardinality:=multiple from/to central (http://repo1.maven.org/maven2/):
> /home/niclas/.m2/repository/javax/json/javax.json-api/1.1$overwrite=MERGE:
> osgi.extender;\
> filter:="(osgi.extender=osgi.serviceloader.processor)",\
>   osgi.serviceloader;\
> filter:="(osgi.serviceloader=javax.json.spi.JsonProvider)";\
>
> cardinality:=multiple/javax.json-api-1.1$overwrite=MERGE:
> osgi.extender;\
> filter:="(osgi.extender=osgi.serviceloader.processor)",\
>   osgi.serviceloader;\
> filter:="(osgi.serviceloader=javax.json.spi.JsonProvider)";\
> cardinality:=multiple.jar.part.lock (File name too long)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:626)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:570)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:548)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:523)
> at
> org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:123)
> at org.ops4j.net.URLUtils.prepareInputStream(URLUtils.java:180)
> at
> org.ops4j.pax.url.wrap.internal.Connection.getInputStream(Connection.java:83)
> at
> org.apache.felix.fr

[PAX EXAM] file name too long?

[Niclas Hedhman]

Gang,
I got the exception below, when using wrappedBundle() to add handling for
Javax JSON API service loader, without rewriting the original bundle
manifest.

Does anyone understand what is happening and what can be done about it?

Code is

wrappedBundle( mavenBundle( "javax.json", "javax.json-api", "1.1" ).getURL() )
.overwriteManifest( WrappedUrlProvisionOption.OverwriteMode.MERGE )
.instructions( "Require-Capability: osgi.extender;\\\n"
   + "
filter:=\"(osgi.extender=osgi.serviceloader.processor)\",\\\n"
   + "  osgi.serviceloader;\\\n"
   + "
filter:=\"(osgi.serviceloader=javax.json.spi.JsonProvider)\";\\\n"
   + "cardinality:=multiple" ),
mavenBundle( "org.apache.johnzon", "johnzon-core", "1.1.1" ),



Exception in thread "main" org.ops4j.pax.exam.TestContainerException:
Problem starting test container.
at
org.ops4j.pax.exam.nat.internal.NativeTestContainer.start(NativeTestContainer.java:212)
at
com.spicter.niclas1.test.integration.PaxExamStarter.main(PaxExamStarter.java:26)
Caused by: org.osgi.framework.BundleException: Unable to cache bundle:
wrap:mvn:javax.json/javax.json-api/1.1$overwrite=MERGE:
osgi.extender;\
filter:="(osgi.extender=osgi.serviceloader.processor)",\
  osgi.serviceloader;\
filter:="(osgi.serviceloader=javax.json.spi.JsonProvider)";\
cardinality:=multiple
at org.apache.felix.framework.Felix.installBundle(Felix.java:3013)
at
org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:167)
at
org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:140)
at
org.ops4j.pax.exam.nat.internal.NativeTestContainer.installAndStartBundles(NativeTestContainer.java:340)
at
org.ops4j.pax.exam.nat.internal.NativeTestContainer.start(NativeTestContainer.java:209)
... 1 more
Caused by: java.io.IOException: Error resolving artifact
javax.json:javax.json-api:jar:1.1$overwrite=MERGE:
osgi.extender;\
filter:="(osgi.extender=osgi.serviceloader.processor)",\
  osgi.serviceloader;\
filter:="(osgi.serviceloader=javax.json.spi.JsonProvider)";\
cardinality:=multiple: Could not transfer artifact
javax.json:javax.json-api:jar:1.1$overwrite=MERGE:
osgi.extender;\
filter:="(osgi.extender=osgi.serviceloader.processor)",\
  osgi.serviceloader;\
filter:="(osgi.serviceloader=javax.json.spi.JsonProvider)";\
cardinality:=multiple from/to central (http://repo1.maven.org/maven2/):
/home/niclas/.m2/repository/javax/json/javax.json-api/1.1$overwrite=MERGE:
osgi.extender;\
filter:="(osgi.extender=osgi.serviceloader.processor)",\
  osgi.serviceloader;\
filter:="(osgi.serviceloader=javax.json.spi.JsonProvider)";\

cardinality:=multiple/javax.json-api-1.1$overwrite=MERGE:
osgi.extender;\
filter:="(osgi.extender=osgi.serviceloader.processor)",\
  osgi.serviceloader;\
filter:="(osgi.serviceloader=javax.json.spi.JsonProvider)";\
cardinality:=multiple.jar.part.lock (File name too long)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:626)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:570)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:548)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:523)
at
org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:123)
at org.ops4j.net.URLUtils.prepareInputStream(URLUtils.java:180)
at
org.ops4j.pax.url.wrap.internal.Connection.getInputStream(Connection.java:83)
at
org.apache.felix.framework.util.SecureAction.getURLConnectionInputStream(SecureAction.java:525)
at
org.apache.felix.framework.cache.JarRevision.initialize(JarRevision.java:166)

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

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

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CADmm%2BKdtw_5vC8jHm_ps3DZv2BA1FpJ-61y9EcTbxgrQVRwPhA%40mail.gmail.com.

Re: Eclipse/PDE-Container

[Niclas Hedhman]

First paragraph mentions that it is "work in progress" and that artifacts
would only exist in snapshot repository.

On Thu, Aug 8, 2019, 19:18 Velganesh Subramanian <
alsoajavaprogram...@gmail.com> wrote:

> I read this article
> 
> about using bundles from p2 repositories but I am not able to locate
> the pax-exam-container-eclipse artifact in maven central. I am looking at a
> pax-exam example that uses OSGi bundles from a p2 repo, can someone help?
>
> --
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ops4j/f5e2c4a4-3144-44ac-89ff-67b07f1a0831%40googlegroups.com
> 
> .
>

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

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CADmm%2BKc8stpg%2BeZhiUO-JhenSkr0FTF7%2Bbh%3DTOrgqiPvECQ%3Dmw%40mail.gmail.com.

GitHub JIRA access to Organization?

[Niclas Hedhman]

I have just approved a permission request for "Github Jira" to gain
"read-only access" to the "Organization members".

1. If you have a problem, raise your voice...

2. What is Github Jira? Do we use it?

// Niclas

-- 
-- 
--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CADmm%2BKc91WNrJ472GmMXZdk03dtvGX7_Ljvb-QTFPepCUTC4pg%40mail.gmail.com.

Re: Export Packages not able to see in 1.11.0 version

[Niclas Hedhman]

Implementation details are not expected to be Exported, and I assume that
someone noticed this mistake.

Perhaps you could explain what you are accessing in there, and we'll work
out a solution for the usecase, rather than blanket expose the inner guts.

Cheers
Niclas

On Tue, Jul 30, 2019 at 2:16 AM 'Tharindu Dharmarathna' via OPS4J <
ops4j@googlegroups.com> wrote:

> Hi All,
>
> We are using pax-logging 1.10.1 version currently. When we going to update
> into the latest pax-logging version which is 1.11.0 it did not have the
> log4j2 core "*org.apache.logging.log4j.core.impl*" doesn't expose outside
> from bundle.
>
> When Comparing *MANIFEST.MF *in pax-logging-log4j2 jars we cold able to
> see Export-Packages are missing in the 1.11.0 version.
>
> Could you, please let us know on way of getting above fixed ?.
>
> Thanks
> Tharindu
>
> --
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ops4j/ebfc2603-334f-4594-9244-2de040faf318%40googlegroups.com
> <https://groups.google.com/d/msgid/ops4j/ebfc2603-334f-4594-9244-2de040faf318%40googlegroups.com?utm_medium=email_source=footer>
> .
>


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

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

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CADmm%2BKfmnX5De9vJU9LbtVMzz%3DwOj4cXu720uFpeaH3vaWvLSQ%40mail.gmail.com.

Re: PaxLocationInfo.getLineNumber() performance

[Niclas Hedhman]

Theoretically, it might be possible to somehow "remember" the lines
involved, so the Throwable is only done once. Since the performance
improvement would be massive, it might be interesting to look at that. no
ideal solution comes to my mind.

Niclas

On Mon, Jun 24, 2019 at 1:01 PM Grzegorz Grzybek 
wrote:

> Hello
>
> This method is called once per LogEvent created. And LogEvent is created
> in log() (or info() or warn() or ...) statement every time it's called. New
> LogEvent is required because there's new timestamp.
>
> regards
> Grzegorz Grzybek
>
> pon., 24 cze 2019 o 06:56 RU  napisał(a):
>
>> Thanks, this seems to be called when using Karaf Decanter - the appender
>> writes logs with the log line number for all logs. Is there any detail on
>> how the subsequent calls are cached and is it correct to say the new
>> Throwable() is executed once per log?
>>
>> On Monday, June 24, 2019 at 2:42:28 PM UTC+10, Grzegorz Grzybek wrote:
>>>
>>> Helo
>>>
>>> It's not pax-logging, it's log4j1 itself. You'd have this code invoked
>>> also outside of OSGi. Logback and Log4j2 have similar "expensive" code.
>>>
>>> When exactly is this called? Not every time. If you decide to use
>>> PatternLayout (frameworks specific - different for log4j1, log4j2 and
>>> logback) *and* use location-aware pattern (%C, %L, %F) then
>>> getLocationInformation() will be called. Otherwise (like with standard
>>> TTCCLayout for example, where you use %c (lower case "c" meaning
>>> "category", not "Class"), %m, %p, ...) this code is *not* called.
>>>
>>> regards
>>> Grzegorz Grzybek
>>>
>>> pon., 24 cze 2019 o 06:11 Ravi Undupitiya 
>>> napisał(a):
>>>
>>>> Does this particular line which seems to be executed by Karaf for every
>>>> log in our system cause performance issues? Our understanding is that to
>>>> get the line number you need the stack trace, getting which is an expensive
>>>> operation.
>>>>
>>>> org.apache.log4j.spi.LoggingEvent has the following method that does the 
>>>> expensive Throwable():
>>>>
>>>>
>>>> /**
>>>>Set the location information for this logging event. The collected
>>>>information is cached for future use.
>>>>  */
>>>> public LocationInfo getLocationInformation() {
>>>>   if(locationInfo == null) {
>>>> locationInfo = new LocationInfo(new Throwable(), fqnOfCategoryClass);
>>>>   }
>>>>   return locationInfo;
>>>> }
>>>>
>>>>
>>>>
>>>> How is this cached and does that mean the new Throwable() is only running 
>>>> once per log statement?
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>> --
>>>> --
>>>> --
>>>> 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 op...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/ops4j/4ac5e2e5-6012-4699-be04-f794de47a94d%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/ops4j/4ac5e2e5-6012-4699-be04-f794de47a94d%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ops4j/6ba4d6a6-3b91-487c-9fff-ccd5f664cd8e%40googlegroups.com
>> <https://groups.google.com/d/msgid/ops4j/6ba4d6a6-3b91-487c-9fff-ccd5f664cd8e%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because 

Re: [PAX-LOGGING] Log4J2 problem

[Niclas Hedhman]

  > and no idea if the log4j2 and logback impls have tried.
> >  >
> >  >
> >  > It holds. Both for log4j1 and logback and I'm just finishing to
> > ensure
> >  > that it's working for log4j2 too.
> >  > Private-Packaging without exporting of classes from "impl" jars
> > (indeed
> >  > it wasn't easy with log4j1) was and still is (IMO) good idea.
> >  >
> >  > The fact that something is OSGi bundle, doesn't mean that original
> >  > author took care of everything. For example log4j2 has
> "log4j-osgi"
> >  > subproject, but it's simply:
> >  >   -
> org.apache.logging.log4j.osgi.tests.felix.FelixLoadApiBundleTest
> >  >   -
> > org.apache.logging.log4j.osgi.tests.equinox.EquinoxLoadApiBundleTest
> >  >
> >  > both these "tests" just install log4j-api, log4j-core,
> > log4j-samples and
> >  > log4j-1.2-api.
> >  >
> >  > best regards
> >  > Grzegorz Grzybek
> >  >
> >  > pt., 24 maj 2019 o 04:13 Niclas Hedhman  > <mailto:nic...@hedhman.org>
> >  > <mailto:nic...@hedhman.org <mailto:nic...@hedhman.org>>>
> napisał(a):
> >  >
> >  >
> >  > Just because someone added a BND descriptor to Maven/Gradle,
> > doesn't
> >  > mean that the library is OSGi-capable, let alone
> OSGi-friendly.
> >  > Please see https://articles.qos.ch/classloader.html for the
> > starting
> >  > point, and although the article discusses Java EE
> > classloading, the
> >  > OSGi scenario isn't any better for many libraries out there.
> Pax
> >  > Logging made an attempt at overcoming the issues for all
> logging
> >  > frameworks when running in OSGi, and it was a particularly
> >  > meticulous beginning, when I ensured that nothing was left
> > behind in
> >  > the class space and that one should even be able to replace
> the
> >  > pax-logging-service without stopping all the bundles, i.e.
> > the whole
> >  > app. Whether or not this goal has been maintained is unknown
> > to me,
> >  > I don't know if it stills hold true for the original
> > implementation,
> >  > and no idea if the log4j2 and logback impls have tried.
> >  >
> >  > Almost all the 'embedding', and more importantly the
> > replacements,
> >  > have origins in the above.
> >  >
> >  > Niclas
> >  >
> >  > On Thu, May 23, 2019 at 2:50 PM 'Christoph Läubrich' via OPS4J
> >  > mailto:ops4j@googlegroups.com>
> > <mailto:ops4j@googlegroups.com <mailto:ops4j@googlegroups.com>>>
> wrote:
> >  >
> >  > WHat is teh reason for merging the META-INF at all?
> >  > Beside that why embeeed log4j at all if it is already an
> OSGi
> >  > Bundle?
> >  >
> >  > I think that people do embeed a way to much stuff in the
> OSGi
> >  > world that
> >  > does not make sense. Embedding should only be used if the
> > lib is
> >  > not an
> >  > OSGi-Jar (where I prefere to open a PR on the project ot
> > add the
> >  > required headers).
> >  > In all other cases a proper version import does the job
> > much better
> >  > beside the fact that embedding might cuase problems with
> >  > licensing and
> >  > maintaining stuff (e.g. security updates).
> >  >
> >  > Am 22.05.19 um 17:21 schrieb Grzegorz Grzybek:
> >  >  > Hello
> >  >  >
> >  >  > (sorry for writing to two mailing lists, but I think
> it's
> >  > important).
> >  >  >
> >  >  > I've just found nasty problem.
> >  >  >
> >  >  > After having lots of fun with pax-logging-service and
> >  >  > pax-logging-logback I wanted to clean up
> > pax-logging-log4j2.
> >  > But I found
> >  >  > that original, already available pax-logging-log4j2
> bundle
&g

Re: [PAX-LOGGING] Log4J2 problem

[Niclas Hedhman]

I have seen that you have done a lot of good work, and the only thing I can
contribute nowadays is history/background and initial conditions/goals.


Cheers
Niclas

On Fri, May 24, 2019 at 12:52 PM Grzegorz Grzybek 
wrote:

> Hello
>
> Yes - in ideal world, every jar in Maven Central should be OSGi bundle and
> every closure of dependencies should be consistent.
> Also, everyone forced to use OSGi hates it and switches to beautiful
> one-line µservices written in go-lang.
> 
>
> org.apache.logging.log4j:log4j-api and log4j-core (log4j2) are indeed OSGi
> bundles, but with own activators that do something not related to
> pax-logging.
> Also nothing in Log4J2 implements org.osgi.service.log.LogService.
>
> log4j-core does for example this:
>
> private static void scanInstalledBundlesForPlugins(final BundleContext
> context) {
> final Bundle[] bundles = context.getBundles();
> for (final Bundle bundle : bundles) {
> *// TODO: bundle state can change during this*
> scanBundleForPlugins(bundle);
> }
> }
>
> As for pax-logging, Niclas - since last email I wrote >60 integration
> tests that check various assumptions you probably made when starting this
> project. There are tests for example that check how a piece of code using
> loggers from different frameworks/facades (JCL, JUL, Slf4J, JULI, Avalon,
> Log4j1 "api", ...) behaves when pax-logging-api or pax-logging-
> (or both) bundles are restarted/refreshed.
> There are tests for extending log4j1/logback (log4j2 tests coming soon)
> via org.ops4j.pax.logging.spi interfaces or via fragments that just contain
> e.g., classes inheriting the Appender interface(s) (or filters, or error
> handlers, or layouts).
>
> I'm getting more confident about pax-logging architecture and approach.
>
> Soon we'll (Jean Baptiste Onofre is working on it) get R7 support
> (org.osgi.service.log 1.4).
>
> Whether or not this goal has been maintained is unknown to me, I don't
>> know if it stills hold true for the original implementation, and no idea if
>> the log4j2 and logback impls have tried.
>>
>
> It holds. Both for log4j1 and logback and I'm just finishing to ensure
> that it's working for log4j2 too.
> Private-Packaging without exporting of classes from "impl" jars (indeed it
> wasn't easy with log4j1) was and still is (IMO) good idea.
>
> The fact that something is OSGi bundle, doesn't mean that original author
> took care of everything. For example log4j2 has "log4j-osgi" subproject,
> but it's simply:
>  - org.apache.logging.log4j.osgi.tests.felix.FelixLoadApiBundleTest
>  - org.apache.logging.log4j.osgi.tests.equinox.EquinoxLoadApiBundleTest
>
> both these "tests" just install log4j-api, log4j-core, log4j-samples and
> log4j-1.2-api.
>
> best regards
> Grzegorz Grzybek
>
> pt., 24 maj 2019 o 04:13 Niclas Hedhman  napisał(a):
>
>>
>> Just because someone added a BND descriptor to Maven/Gradle, doesn't mean
>> that the library is OSGi-capable, let alone OSGi-friendly. Please see
>> https://articles.qos.ch/classloader.html for the starting point, and
>> although the article discusses Java EE classloading, the OSGi scenario
>> isn't any better for many libraries out there. Pax Logging made an attempt
>> at overcoming the issues for all logging frameworks when running in OSGi,
>> and it was a particularly meticulous beginning, when I ensured that nothing
>> was left behind in the class space and that one should even be able to
>> replace the pax-logging-service without stopping all the bundles, i.e. the
>> whole app. Whether or not this goal has been maintained is unknown to me, I
>> don't know if it stills hold true for the original implementation, and no
>> idea if the log4j2 and logback impls have tried.
>>
>> Almost all the 'embedding', and more importantly the replacements, have
>> origins in the above.
>>
>> Niclas
>>
>> On Thu, May 23, 2019 at 2:50 PM 'Christoph Läubrich' via OPS4J <
>> ops4j@googlegroups.com> wrote:
>>
>>> WHat is teh reason for merging the META-INF at all?
>>> Beside that why embeeed log4j at all if it is already an OSGi Bundle?
>>>
>>> I think that people do embeed a way to much stuff in the OSGi world that
>>> does not make sense. Embedding should only be used if the lib is not an
>>> OSGi-Jar (where I prefere to open a PR on the project ot add the
>>> required headers).
>>> In all other cases a proper version import does the job much better
>>> beside the fact that embedding might cuase problems with licensing and
>>> maintaining stuff (e.g. security u

Re: [PAX-LOGGING] Log4J2 problem

[Niclas Hedhman]

Just because someone added a BND descriptor to Maven/Gradle, doesn't mean
that the library is OSGi-capable, let alone OSGi-friendly. Please see
https://articles.qos.ch/classloader.html for the starting point, and
although the article discusses Java EE classloading, the OSGi scenario
isn't any better for many libraries out there. Pax Logging made an attempt
at overcoming the issues for all logging frameworks when running in OSGi,
and it was a particularly meticulous beginning, when I ensured that nothing
was left behind in the class space and that one should even be able to
replace the pax-logging-service without stopping all the bundles, i.e. the
whole app. Whether or not this goal has been maintained is unknown to me, I
don't know if it stills hold true for the original implementation, and no
idea if the log4j2 and logback impls have tried.

Almost all the 'embedding', and more importantly the replacements, have
origins in the above.

Niclas

On Thu, May 23, 2019 at 2:50 PM 'Christoph Läubrich' via OPS4J <
ops4j@googlegroups.com> wrote:

> WHat is teh reason for merging the META-INF at all?
> Beside that why embeeed log4j at all if it is already an OSGi Bundle?
>
> I think that people do embeed a way to much stuff in the OSGi world that
> does not make sense. Embedding should only be used if the lib is not an
> OSGi-Jar (where I prefere to open a PR on the project ot add the
> required headers).
> In all other cases a proper version import does the job much better
> beside the fact that embedding might cuase problems with licensing and
> maintaining stuff (e.g. security updates).
>
> Am 22.05.19 um 17:21 schrieb Grzegorz Grzybek:
> > Hello
> >
> > (sorry for writing to two mailing lists, but I think it's important).
> >
> > I've just found nasty problem.
> >
> > After having lots of fun with pax-logging-service and
> > pax-logging-logback I wanted to clean up pax-logging-log4j2. But I found
> > that original, already available pax-logging-log4j2 bundle actually has
> > Export-Package header (pax-logging-service and pax-logging-logback don't
> > export anything).
> >
> > The strange thing was that all bundles have:
> >
> > Export-Package: \
> >   !*
> >
> > The difference is that pax-logging-log4j2 additionally has
> > <
> https://github.com/ops4j/org.ops4j.pax.logging/blob/b8c9137/pax-logging-log4j2/osgi.bnd#L5
> >:
> >
> > Private-Package: \
> > ...
> > META-INF; -split-package:=merge-first, \
> > ...
> >
> > So it ... took the META-INF/MANIFEST.MF from
> > org.apache.logging.log4j:log4j-core. It wouldn't be a problem if
> > pax-logging-log4j2 exported something - even single package.
> >
> > Here's why
> > <
> https://github.com/bndtools/bnd/blob/4.2.0.REL/biz.aQute.bndlib/src/aQute/bnd/osgi/Analyzer.java#L1063-L1065>
>
> > (aQute.lib.osgi.Analyzer#calcManifest()):
> >
> > // Copy old values into new manifest, when they
> > // exist in the old one, but not in the new one
> > merge(manifest, dot.getManifest());
> >
> > pax-logging-log4j2 bundle didn't have any Export-Package (as intended),
> > so it just inherited it from org.apache.logging.log4j:log4j-core
> > (definitely *not* as intended...).
> >
> > This is related to https://ops4j1.jira.com/browse/PAXLOGGING-240 and
> the
> > discussion here[1].
> >
> > To be honest, the only thing I think is sensible here is to stop
> > exporting anything from pax-logging-log4j2... Extensions should be done
> > via fragments or pax-logging-api's org.ops4j.pax.logging.spi interfaces
> > (like PaxAppender).
> >
> > WDYT?
> >
> > regards
> > Grzegorz Grzybek
> > ===
> > [1]:
> https://groups.google.com/forum/#!msg/ops4j/yjqOzvrKRkc/t5BXmfyoBgAJ
> >
> > --
> > --
> > --
> > 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
> > <mailto:ops4j+unsubscr...@googlegroups.com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/ops4j/CAAdXmhr1W2_3y56mpUUiErHFgKs13jFb2bd4CoC0rvcfaE9M8A%40mail.gmail.com
> > <
> https://groups.google.com/d/msgid/ops4j/CAAdXmhr1W2_3y56mpUUiErHFgKs13jFb2bd4CoC0rvcfaE9M8A%40mail.gmail.com?utm_medium=email_source=footer
> >.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> --
> --
> OPS4J - 

Re: Pax Runner

[Niclas Hedhman]

I can chime in;

I started Pax Runner because back in the day, because it was really hard to
write a bundle that worked on all available frameworks, and it was even
harder to automate it. Alin Dreghiciu took over at some point and made Pax
Runner into what it still is. That was in 2007 or so...

When Alin, I and Toni Menzel were on a project together, Toni and Alin
proceeded to create/expand Pax Exam, a testing framework that leveraged Pax
Runner to run your tests against all of the frameworks. In parallel a
"native" test launcher was made in Pax Exam and at some point the Pax
Runner launcher was dropped, and Pax Runner basically ended up being
unmaintained from then on, mostly because it wasn't too hard to do the same
thing with Pax Exam. I even used Pax Exam in 2011 as launcher on a project
where we couldn't decide which framework to use.

So, most things that Pax Runner can do, can be done in Pax Exam (at least
ver 2.x). But there is nothing stopping you from reviving it and take over
maintenance. If one prefers config files over code, then that could make
sense.


HTH
Niclas

On Fri, May 3, 2019 at 11:56 PM  wrote:

> is there any way to find out who was maintaing that pax runner and to see
> why the project was discontinued.
>
> it was able to let eclipse know how to trigger an osgi run configuration
> with a different framework than equinox. i want that :D
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


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

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

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CADmm%2BKcmsE%3DoK1hvoT0YUhg2c00gO03yR1o%3DG0m2szh%3D9pGmPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PAX-LOGGING] log4j1: API / Impl separation

[Niclas Hedhman]

I should encourage you to stop. In essence, log4j v1.x is not well-defined
when it comes to API/impl separation or modularization in general. I made
an attempt to have a pax-logging-spi, which purpose was to allow custom
components, Appenders primarily, to be runtime deployable and used by
Log4j, but I don't think it ever came to working.

The export list of Log4j is simply BND by default exporting all packages
that are not named .internal or .impl. People in Log4j never had any OSGi
interest and have not spent many minutes on the topic.

And IF you let the log4j bundle be used directly, then you strongly tie the
user's of Logger to Log4j in runtime, and replacement can't happen without
stopping all bundles.

Niclas

On Tue, Apr 23, 2019 at 8:43 PM Grzegorz Grzybek 
wrote:

> Hello
>
> I reviewed what's included (possibly after changing) from original
> log4j:log4j (and log4j:apache-log4j-extras) in:
>  – pax-logging-api
>  – pax-logging-service
>
> The investigation result is interesting...
>  – most changed files are in org.apache.log4j package itself, which is
> obvious, but for example, org.apache.log4j.Category class is both in
> pax-logging-api and pax-logging-service
>  – some source files are copied from log4j to pax-logging-service without
> changes (which is strange, because even the ones that are not copied at
> source code level are eventually in pax-logging-service jar because of
> `org.apache.log4j` Private-Package and maven dependency on log4j:log4j)
>  – original log4j:log4j:1.2.17 is actually proper OSGi bundle, but has
> different set of exports (i.e., public API)
>
> I checked what's exported from log4j:log4j (and log4j:apache-log4j-extras)
> and:
>
> pax-logging-service doesn't export anything, which is fine - we only miss
> some real integration tests that show how to extend log4j (layouts,
> appenders, patterns, filters) using fragment jars
>
> pax-logging-api exports only:
>  – org.apache.log4j
>  – org.apache.log4j.spi
>  – org.apache.log4j.xml
>
> but log4j itself exports additionally:
>  – org.apache.log4j.config
>  – org.apache.log4j.helpers
>  – org.apache.log4j.jdbc
>  – org.apache.log4j.jmx
>  – org.apache.log4j.net
>  – org.apache.log4j.nt
>  – org.apache.log4j.or
>  – org.apache.log4j.or.jms
>  – org.apache.log4j.or.sax
>  – org.apache.log4j.pattern
>  – org.apache.log4j.rewrite
>  – org.apache.log4j.varia
>
> Even if we should stick to the 3 ones, some classes from spi use
> (uses:="...") other packages which are not exported.
>
> Let me continue reviewing and separating properly API and Impl or tell me
> to stop ;)
>
> regards
> Grzegorz Grzybek
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


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

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

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

Re: [PAX-LOGGING] Cleanup

[Niclas Hedhman]

The reason for Log4j original classes not used was very simple; Didn't work.

So, the underlying requirement that makes everything "trickier than normal"
is that you need to allow for the pax-logging-service to be
reloaded/replaced without stopping pax-logging-api, as that would in turn
stop everything else. AND that classes+classloader are correctly removed
from the JVM memory.

So the "actually correct" might mean different to you, than it did to us...

Niclas

On Thu, Apr 25, 2019 at 11:26 PM Grzegorz Grzybek 
wrote:

> Ah - fireplace stories ;)
>
> I'm continuing my work. It's a bit painful with log4j1. There's one jar
> (apache-log4j-extras duplicates the packages from log4j and adds some
> classes to some packages) and currently pax-logging-api exports these
> packages:
>  - org.apache.log4j
>  - org.apache.log4j.spi
>  - org.apache.log4j.xml
>
> However, original log4j:log4j:1.2.17 jar is also proper OSGi bundle and
> exports more packages.
> And:
>  - some classes from log4j included and exported by pax-logging-api use
> (in "uses" sens of Export-Package) classes from packages that are not
> exported
>  - some shaded classes have simply removed methods (instead of for example
> changed to throw UnsupportedOperationException).
>  - some classes, like org.apache.log4j.Category is included both in
> pax-logging-api *and* in pax-logging-service - completely different
>  - LogManager doesn't work (similarly to a problem we have with
> PAXLOGGING-240)
>  - some logging methods from org.apache.log4j.Category are reimplemented
> (to call super version) in org.apache.log4j.Logger to properly handle
> org.apache.log4j.spi.LocationInfo when detecting class/method/source file -
> but not all. If you call generic log() method, wrong LocationInfo is
> calculated.
>
> What I'm now doing is to properly split log4j (and apache-log4j-extras)
> classes between pax-logging-api and pax-logging-service, trying to make it
> both backward compatible *and* actually correct.
> Also I'm waiting for Imperator: Rome from Paradox - it'll be released in
> ~1 hour!
>
> regards
> Grzegorz Grzybek
>
>
> czw., 25 kwi 2019 o 17:04 Niclas Hedhman  napisał(a):
>
>>
>> :-)
>>
>> The good old days actually we're different...
>>
>> Apache Avalon was the breeding ground for Separation of Concern,
>> Inversion of Control and Separation of Interface and Implementation. We had
>> a Logging API, that was quite popular, and allowed a pluggable
>> implementations.
>> When java.util.logging showed up, I tried to convince Ceki Gulcu that
>> separation of interface and implementation was powerful, and spinning some
>> ideas around that... can't remember exactly what was discussed, but it was
>> cool, I am sure. We also discussed a lot around classloading issues that
>> commons-logging exacerbated for Tomcat and other classloading-heavy
>> systems, and he wrote a good piece on that at some point.
>>
>> And a year or two later, Avalon had died and slf4j showed up (I think he
>> did one before that), but since Log4j community was deadlocked in what
>> should be done, he went on and created LogBack outside of Apache.
>>
>> History is fun!
>>
>>
>> On Tue, Apr 23, 2019, 14:21 Grzegorz Grzybek 
>> wrote:
>>
>>> Hello
>>>
>>> After I entered my 40s, I became history nerd, so thanks for some
>>> insight. I was there when there was only log4j and here's what I wrote in
>>> readme.adoc about this:
>>>
>>>  – Log4j: the grandfather of all configurable Logging frameworks.
>>> Created when there was no logging bridges/facades around. Actually first
>>> facades (Commons Logging) was created to bridge common logging API to one
>>> of different logging frameworks (back then, it was only Log4j1 and Java
>>> Util Logging (JUL) from JDK1.4).
>>>  – Logback: Logback was created after the logging-bridge (r)evolution
>>> and even if it may be used without any logging facade/bridge, it is very
>>> uncommon to do so.
>>>  – Log4j2: After huge (in my humble, subjective opinion) success of
>>> Logback, Log4j2 was created as modernized version of original Log4j project
>>> with full awareness of logging bridges/facades and weird properties file
>>> syntax.
>>>
>>> One of the things I always did when forking/shading/changing external
>>> sources (like zookeeper in fabric8) was to create git commit with _exact_
>>> original version and then to use separate commits for better _diffability_
>>> (preserving formatting even if I didn't like the original one). It's the
&

Re: [PAX-LOGGING] Cleanup

[Niclas Hedhman]

:-)

The good old days actually we're different...

Apache Avalon was the breeding ground for Separation of Concern, Inversion
of Control and Separation of Interface and Implementation. We had a Logging
API, that was quite popular, and allowed a pluggable implementations.
When java.util.logging showed up, I tried to convince Ceki Gulcu that
separation of interface and implementation was powerful, and spinning some
ideas around that... can't remember exactly what was discussed, but it was
cool, I am sure. We also discussed a lot around classloading issues that
commons-logging exacerbated for Tomcat and other classloading-heavy
systems, and he wrote a good piece on that at some point.

And a year or two later, Avalon had died and slf4j showed up (I think he
did one before that), but since Log4j community was deadlocked in what
should be done, he went on and created LogBack outside of Apache.

History is fun!


On Tue, Apr 23, 2019, 14:21 Grzegorz Grzybek  wrote:

> Hello
>
> After I entered my 40s, I became history nerd, so thanks for some insight.
> I was there when there was only log4j and here's what I wrote in
> readme.adoc about this:
>
>  – Log4j: the grandfather of all configurable Logging frameworks. Created
> when there was no logging bridges/facades around. Actually first facades
> (Commons Logging) was created to bridge common logging API to one of
> different logging frameworks (back then, it was only Log4j1 and Java Util
> Logging (JUL) from JDK1.4).
>  – Logback: Logback was created after the logging-bridge (r)evolution and
> even if it may be used without any logging facade/bridge, it is very
> uncommon to do so.
>  – Log4j2: After huge (in my humble, subjective opinion) success of
> Logback, Log4j2 was created as modernized version of original Log4j project
> with full awareness of logging bridges/facades and weird properties file
> syntax.
>
> One of the things I always did when forking/shading/changing external
> sources (like zookeeper in fabric8) was to create git commit with _exact_
> original version and then to use separate commits for better _diffability_
> (preserving formatting even if I didn't like the original one). It's the
> best (IMO) way to track what really has changed comparing to original and
> to make it easier (or even possible) to backport future changes to original
> library.
>
> Log4j doesn't change much, but I see the classes are from around 2006
> (matching roughly 1.2.13 version) - but even first commit is already
> reformatted and doesn't have the way to diff consecutive changes.
>
> I'm currently reviewing itests (there are not many of them) and API/Impl
> separation (both for Log4j and Log4j2).
>
> regards
> Grzegorz Grzybek
>
>
> pon., 22 kwi 2019 o 01:41 Niclas Hedhman  napisał(a):
>
>>
>> I can answer the "Why?" question, and for the "When?" the original work
>> is from 2005.
>>
>> At that time there was a plethora of logging frameworks, and we had more
>> and more "facades" that tried to "solve" the problem of "too many" by
>> adding one more.
>>
>> At that time the two most popular ones were Log4j and commons-logging,
>> and both of these are not OSGi friendly at all. In fact, Ceki wrote a piece
>> about the commons-logging classloading problem and reloading of classes.
>>
>> Pax Logging started as an internal need with the project I was working on
>> at the time. In a world with an Apache Avalon application to be ported to
>> Knopflerfish OSGi framework, with many legacy parts pre-dating Avalon. And
>> the only way to make all that work properly in OSGi (something that most
>> people don't care about nowadays) was to re-write some of those logging
>> frameworks, and in the initial version, all features that we didn't need
>> were simply left out, such as MDC/NDC, and other people have added that
>> over time.
>>
>> Pax Logging were able (not sure if that is still true) to upgrade or
>> replace the service without stopping any other bundle and cleanly remove
>> all classes from memory. At that time, that was an important aspect of all
>> bundles in that project.
>>
>> Hope that brings some additional background to why things are the way
>> they are.
>>
>>
>> Niclas
>>
>> On Sat, Apr 20, 2019, 01:44 Grzegorz Grzybek 
>> wrote:
>>
>>> Hello
>>>
>>> Thanks for response. By no means I want to "take over" pax logging. I
>>> just recently released several aligned versions of pax-web, pax-cdi,
>>> pax-tools, pax-jdbc, pax-jms, pax-transx and pax-tipi and I found
>>> pax-logging a bit behind. Parent org.ops4j:master pom versi

Re: OS

[Niclas Hedhman]

I am sure that there is no support in Windows for Pax projects.

But the listed projects can run on Windows of any version that has network
connection and a functional JVM.

On Tue, Apr 23, 2019, 11:26 liname...@outlook.com 
wrote:

> Hello, I am doing an investigation.
>
> Does Windows Server 2019 support the following products:
>
>
>
> PAX CDI 0.7.0
>
> PAX SWISSBOX  1.6.0
>
> PAX SWISSBOX  1.7.0
>
> PAX URL   1.6.0
>
> PAX WEB   3.1.0
>
> PAX Logging 1.7.2
>
>
>
> Can it be installed on windows2019?
>
> Is the other version supported?
>
> Can you tell me, thank you very much.
>
>
>
>
>
>
>
> --
> --
> --
> 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-LOGGING] Cleanup

[Niclas Hedhman]

I can answer the "Why?" question, and for the "When?" the original work is
from 2005.

At that time there was a plethora of logging frameworks, and we had more
and more "facades" that tried to "solve" the problem of "too many" by
adding one more.

At that time the two most popular ones were Log4j and commons-logging, and
both of these are not OSGi friendly at all. In fact, Ceki wrote a piece
about the commons-logging classloading problem and reloading of classes.

Pax Logging started as an internal need with the project I was working on
at the time. In a world with an Apache Avalon application to be ported to
Knopflerfish OSGi framework, with many legacy parts pre-dating Avalon. And
the only way to make all that work properly in OSGi (something that most
people don't care about nowadays) was to re-write some of those logging
frameworks, and in the initial version, all features that we didn't need
were simply left out, such as MDC/NDC, and other people have added that
over time.

Pax Logging were able (not sure if that is still true) to upgrade or
replace the service without stopping any other bundle and cleanly remove
all classes from memory. At that time, that was an important aspect of all
bundles in that project.

Hope that brings some additional background to why things are the way they
are.


Niclas

On Sat, Apr 20, 2019, 01:44 Grzegorz Grzybek  wrote:

> Hello
>
> Thanks for response. By no means I want to "take over" pax logging. I just
> recently released several aligned versions of pax-web, pax-cdi, pax-tools,
> pax-jdbc, pax-jms, pax-transx and pax-tipi and I found pax-logging a bit
> behind. Parent org.ops4j:master pom version could be an indication ;)
>
> For pax logging it was hard for me to find out when (and why) so many
> source files from external projects were simply copied without a hint of
> the version/tag of source files/library. It's hard to maintain and keep in
> sync such libraries.
>
> I'll definitely present a PR with comments and ask for review.
>
> kind regards
> Grzegorz Grzybek
>
> pt., 19 kwi 2019 o 16:12 Niclas Hedhman  napisał(a):
>
>>
>> I let go of being the daddy of Pax Logging more than 10 years ago, and
>> overall trust the community to do the right thing... That said, every
>> now and then I feel like I want a bigger part of it again, so my previous
>> comment was more about my desire to contribute than to tell people what
>> should be done.
>>
>> Still alive and dying. Carry on as you were.
>>
>> Niclas
>>
>> On Fri, Apr 19, 2019, 12:50 Grzegorz Grzybek 
>> wrote:
>>
>>> Hello
>>>
>>> pt., 19 kwi 2019 o 04:19 Niclas Hedhman  napisał(a):
>>>
>>>> For your last point; OSGIPaxLoggingManager becoming a singleton... The
>>>> amount of memory or other overhead you save with that is minimal, and I
>>>> recommend against the proposed change. In general, we don't try to maximize
>>>> the utilization of trackers in OSGi, but let each client handle its own
>>>> tracker to keep responsibilities near the usages. IF you decide to do it
>>>> anyway, you will still need to keep the public constructor as it is part of
>>>> the official API and don't want to break compatibility over such a minor
>>>> thing.
>>>>
>>>
>>> Thanks for technical suggestions. I already started checking the
>>> "singleton" version of OSGIPaxLoggingManager. I wasn't that much concerned
>>> about number of trackers created, but with general code organization.
>>> There are six _clients_ but OSGIPaxLoggingManager was not created once
>>> for every client - for example with SLF4J, the manager was created both
>>> inside Slf4jLoggerFactory and in Slf4jMDCAdapter. That's one thing. Another
>>> was that most (not all) of these "manager keepers" were holding Map>> ClientSpecificLogger> m_loggers - only to ensure that loggers created
>>> between static client/factory was created and OSGIPaxLoggingManager was set.
>>> For now, I extracted "setPaxLoggingManager" method to
>>> PaxLoggingManagerAwareLogger interface and I can keep single Map>> PaxLoggingManagerAwareLogger> m_loggers map in the Activator itself (I can
>>> think of moving it somewhere else) - so far, all _clients_ contains the
>>> same code related to m_loggers.
>>>
>>> So less optimization (because it's not a problem here), but code
>>> cleanup, comments and consistency.
>>>
>>> In addition, I was able (so far) to:
>>> - keep only those sources from slf4j/commons-logging/... that are
>>> n

Re: [PAX-LOGGING] Cleanup

[Niclas Hedhman]

I let go of being the daddy of Pax Logging more than 10 years ago, and
overall trust the community to do the right thing... That said, every
now and then I feel like I want a bigger part of it again, so my previous
comment was more about my desire to contribute than to tell people what
should be done.

Still alive and dying. Carry on as you were.

Niclas

On Fri, Apr 19, 2019, 12:50 Grzegorz Grzybek  wrote:

> Hello
>
> pt., 19 kwi 2019 o 04:19 Niclas Hedhman  napisał(a):
>
>> For your last point; OSGIPaxLoggingManager becoming a singleton... The
>> amount of memory or other overhead you save with that is minimal, and I
>> recommend against the proposed change. In general, we don't try to maximize
>> the utilization of trackers in OSGi, but let each client handle its own
>> tracker to keep responsibilities near the usages. IF you decide to do it
>> anyway, you will still need to keep the public constructor as it is part of
>> the official API and don't want to break compatibility over such a minor
>> thing.
>>
>
> Thanks for technical suggestions. I already started checking the
> "singleton" version of OSGIPaxLoggingManager. I wasn't that much concerned
> about number of trackers created, but with general code organization.
> There are six _clients_ but OSGIPaxLoggingManager was not created once for
> every client - for example with SLF4J, the manager was created both inside
> Slf4jLoggerFactory and in Slf4jMDCAdapter. That's one thing. Another was
> that most (not all) of these "manager keepers" were holding Map ClientSpecificLogger> m_loggers - only to ensure that loggers created
> between static client/factory was created and OSGIPaxLoggingManager was set.
> For now, I extracted "setPaxLoggingManager" method to
> PaxLoggingManagerAwareLogger interface and I can keep single Map PaxLoggingManagerAwareLogger> m_loggers map in the Activator itself (I can
> think of moving it somewhere else) - so far, all _clients_ contains the
> same code related to m_loggers.
>
> So less optimization (because it's not a problem here), but code cleanup,
> comments and consistency.
>
> In addition, I was able (so far) to:
> - keep only those sources from slf4j/commons-logging/... that are needed,
> other classes from original _clients_ are simply private-packaged (and
> exported)
> - enforce a convention that _client_ specific overrides are in their
> original package and supporting classes (like
> org.ops4j.pax.logging.slf4j.Slf4jLoggerFactory) are kept in
> org.ops4j.pax.logging._clientid_. IMO these packages should not be exported
> (I have to be delicate here) - org.ops4j.pax.logging.slf4j is exported but
> org.ops4j.pax.logging.log4jv2 not.
> - additionally, I added pax-logging-api-test project which has
> maven-invoker based tests to show different API usages and ensure that
> pax-logging-api adheres to these idioms. For example (no pax-logging-api
> usage, just awareness of the implementation):
>
> package org.ops4j.pax.logging.test.slf4j;
>
> import org.junit.Test;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> import org.slf4j.MDC;
>
> import static org.junit.Assert.assertTrue;
>
> public class FactoryTest {
>
> @Test
> public void paxLoggingSpecificSlf4jFactory() {
> Logger log = LoggerFactory.getLogger(this.getClass());
> log.info("Factory: {}", LoggerFactory.getILoggerFactory());
>
>
> assertTrue(LoggerFactory.getILoggerFactory().getClass().getName().startsWith("
> *org.ops4j.pax.logging.slf4j*"));
> }
>
> @Test
> public void paxLoggingSpecificMDC() {
> assertTrue(MDC.getMDCAdapter().getClass().getName().startsWith("
> *org.ops4j.pax.logging.slf4j*"));
> }
>
> }
>
> pax-logging didn't have maven-bundle-plugin:baseline verification (like
> pax-web) and I'm not (yet) sure if adding new interface (and not touching
> previous exported packages) requires bumping version to 2.0 (I don't think
> so). There's no pax-logging 1.11.0 yet, so minor version upgrade allows
> _some_ API changes.
> I'll keep you informed.
>
> Also there's this PAXLOGGING-240 ("ClassCastException with log4j2 on
> org.apache.logging.log4j.core.LoggerContext") issue which _may_ require
> some API reorganization.
>
> I just have some time now and want to do some maintenance work for pax
> project (I'm working on https://ops4j1.jira.com/browse/PAXWEB-1190 as
> well).
>
> regards
> Grzegorz Grzybek
>
>
>>
>> Cheers
>> Niclas
>>
>> On Thu, Apr 18, 2019 at 1:54 PM Grzegorz Grzybek 
>> wrote:
>>
>>> Hello
>>>
>>> I have few issues backlogged f

Re: [PAX-LOGGING] Cleanup

[Niclas Hedhman]

For your last point; OSGIPaxLoggingManager becoming a singleton... The
amount of memory or other overhead you save with that is minimal, and I
recommend against the proposed change. In general, we don't try to maximize
the utilization of trackers in OSGi, but let each client handle its own
tracker to keep responsibilities near the usages. IF you decide to do it
anyway, you will still need to keep the public constructor as it is part of
the official API and don't want to break compatibility over such a minor
thing.

Cheers
Niclas

On Thu, Apr 18, 2019 at 1:54 PM Grzegorz Grzybek 
wrote:

> Hello
>
> I have few issues backlogged for PAXLOGGING Jira:
>  – PAXLOGGING-243: Incorrect bundle names in the logs in case of the logs
> come from embeded lib
>  – PAXLOGGING-247: pax-logging-api/Slf4jMDCAdapter uses stale MDC after
> refreshing service bundle
>  – PAXLOGGING-249: JUL loggers are not properly configured if used before
> calling PaxLoggingServiceImpl#setJULLevel
>  – PAXLOGGING-250: Log4j2 - JNDI based JDBC appender should be more lazy
>
> So I started to review the code (licenses, deps, upgrading from old
> org.ops4j:master:3.3.0, ...).
>
> I see some code could be refreshed and improved. Here are my concerns
> which I'll try to handle if I won't get any feedback):
>  – should we switch compiler settings to Java8? Not necessary
>  – I want to upgrade log4j2, slf4j, logback and jboss logging deps
>  – I want to get rid of those source files from external libs which can be
> simply private packaged
>  – I want to switch org.ops4j.pax.logging.OSGIPaxLoggingManager usage to
> singleton - now, each logging facade uses own copy of this manager, which
> is effectively a tracker for given PaxLoggingService.
>
> What do you think?
>
> regards
> Grzegorz Grzybek
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


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

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

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

Re: Optimize JasperInitializer/TldScanner performance

[Niclas Hedhman]

I would look for DTD and/or schema download timeouts...

Niclas

On Tue, Nov 27, 2018, 15:21 Grzegorz Grzybek  Hello
>
> On Linux it's 19 milliseconds:
>
> 15:14:01.151 INFO  {paxweb-extender-1-thread-1}
> [org.ops4j.pax.web.service.jetty.internal.HttpServiceContext]
> (HttpServiceContext.java:174) : *registering JasperInitializer*
> 15:14:01.156 DEBUG {paxweb-extender-1-thread-1}
> [org.ops4j.pax.web.jsp.JasperInitializer] (JasperInitializer.java:79) :
> Initializing Jasper for context [default]
> ...
> 15:14:01.170 INFO  {paxweb-extender-1-thread-1}
> [org.ops4j.pax.web.jsp.TldScanner] (TldScanner.java:268) : found TLD
> bundle://37.0:1/META-INF/c-1_0-rt.tld
> 15:14:01.190 INFO  {paxweb-extender-1-thread-1}
> [org.ops4j.pax.web.jsp.TldScanner] (TldScanner.java:268) : found TLD
> bundle://37.0:1/META-INF/c-1_0.tld
> 15:14:01.202 INFO  {paxweb-extender-1-thread-1}
> [org.ops4j.pax.web.jsp.TldScanner] (TldScanner.java:268) : found TLD
> bundle://37.0:1/META-INF/c.tld
> 15:14:01.209 INFO  {paxweb-extender-1-thread-1}
> [org.ops4j.pax.web.jsp.TldScanner] (TldScanner.java:268) : found TLD
> bundle://37.0:1/META-INF/fmt-1_0-rt.tld
> ...
>
> No idea what's your problem - can you take a thread dump after your
> container is stuck after "registering JasperInitializer"? Use "jstack -l
> " command.
>
> regards
> Grzegorz Grzybek
>
> pon., 26 lis 2018 o 18:34 Oleg Cohen  napisał(a):
>
>> Greetings,
>>
>> When my webapp bundle loads, I notice that quite a bit of time is spent
>> (on Windows close to 30sec) between
>>
>> registering JasperInitializer
>>
>> and the first
>>
>> found TLD bundle://...
>>
>> What is in involved in the Jasper initialization and searching for TLDs?
>> Is there any way to optimize this operation?
>>
>> Thank you!
>> Oleg
>>
>>
>> --
>> --
>> --
>> 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.
>

-- 
-- 
--
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: Log4j2 logging uncaught exceptions to logfile

[Niclas Hedhman]

That is a generic Java topic, and basically you need to add a handler to
the JVM. Something like this;

Thread.setDefaultUncaughtExceptionHandler( new Thread.UncaughtExceptionHandler()
{public void uncaughtException(Thread t, Throwable e){
log.error( "Uncaught Exception in thread " + t, e );}});

Of course, you might need to have a bit logic to get hold of a specific
Logger, possibly through reflection.

Niclas

On Tue, Sep 11, 2018 at 3:49 AM, Asma Zinneera Jabir 
wrote:

> I am using pax logging 1.10.1 with Log4J2 as the backend. At the moment,
> the exceptions are only being logged to the console and not to the log file
> unless they are caught. But I want to log the uncaught exceptions also to
> the log file. For example when BundleActivator#*start(BundleContext
> bundleContext) throws Exception* method throws an exception, this should
> be logged to the log file. How can this be done?
>
> Thanks.
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

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

Re: ops4j jenkins down?

[Niclas Hedhman]

 timeout if I try to access it.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Stephan
>>>>>>> --
>>>>>>> --
>>>>>>> --
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> --
>>>>>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>>>>>
>>>>>> ---
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "OPS4J" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to ops4j+unsubscr...@googlegroups.com.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Apache Member
>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>> Committer & Project Lead
>>>>> blog <http://notizblog.nierbeck.de/>
>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>
>>>>> Software Architect / Project Manager / Scrum Master
>>>>>
>>>>> --
>>>>> --
>>>>> --
>>>>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>>>>
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "OPS4J" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to ops4j+unsubscr...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>> --
>>>> --
>>>> --
>>>> 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.
>>>>
>>>
>>> --
>>> --
>>> --
>>> 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.
>



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

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

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

Re: Requesting a JIRA login

[Niclas Hedhman]

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



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

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

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

Re: Need a JIRA Account Please

[Niclas Hedhman]

Because I added him 45 minutes ago :-)

On Thu, Dec 14, 2017 at 4:49 PM, 'Achim Nierbeck' via OPS4J <
ops4j@googlegroups.com> wrote:

> Interesting, it said you're already registered.
> I just resend your Invitation.
>
> regards, Achim
>
> 2017-12-14 3:02 GMT+01:00 Brian Bezanson <brian.bezan...@gmail.com>:
>
>> I tried creating a JIRA account but upon using my Gmail address, I
>> was told my email address "doesn't have access to ops4j1.jira.com". I
>> already registered my Gmail account for the Atlassian public JIRA site --
>> so that is why it is seeing me in their system and I can't create a new
>> account. Seems Atlassian's multi-tenant isn't keeping my email segregated
>> between various systems.
>>
>> Would you please add me to the ops4j.jira.com account. I need to create
>> a JIRA ticket regarding documentation issues.
>>
>>- SSL section references codehaus.org which no longer exists, links
>>should point to Jetty pages: http://www.eclipse.org/
>>jetty/documentation/current/
>>- https://github.com/ops4j/org.ops4j.pax.web/search?q=codehaus
>>   =Code=%E2%9C%93
>>
>> Yes, the above is also for my reference for the Ticket creation and
>> changes. :-)
>>
>> Thanks in advance.
>>
>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to ops4j+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

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

Re: Issues in various OPS4J Confluence pages

[Niclas Hedhman]

Thanks for making all that effort. I have added you as a user, and you
should now be able to make changes accordingly.

Cheers
Niclas

On Thu, Dec 14, 2017 at 10:53 AM, Brian Bezanson <brian.bezan...@gmail.com>
wrote:

> I found the following issues in the OPS4J Confluence pages and do not see
> the process to have those fixed, so I'll post them here for discussion or
> fixing ;-)
>
>
>- Issue Tracker Links
>   - The correct link for the Issue Trackers appears to be:
>  - https://ops4j1.jira.com/browse/
>  - http://team.ops4j.org/browse/
>  - Redirects to: https://ops4j1.jira.com/projects//
> issues/-?filter=
> allopenissues
> - For example, the following all redirect to the same final
> page, though the first link is a faster path through JIRA.
>- https://ops4j1.jira.com/browse/PAXEXAM
>- http://team.ops4j.org/browse/PAXEXAM
>- https://ops4j1.jira.com/projects/PAXEXAM/issues
> - On the PAXWEB Support page: https://ops4j1.jira.com/wiki/
>   spaces/paxweb/pages/12059116/Support
>   <https://ops4j1.jira.com/wiki/spaces/paxweb/pages/12059116/Support> the
>   link is bad (http://issues.ops4j.org/jira/browse/PAXWEB)
>  - At http://issues.ops4j.org/ is a "single-page" web site that
>  should probably be shut down as JIRA is being used to track issues.
>   - On the Introduction page: https://ops4j1.jira.com/wiki/spaces/
>   ops4j/pages/3834265/Introduction
>   <https://ops4j1.jira.com/wiki/spaces/ops4j/pages/3834265/Introduction> 
> the
>   link is bad
>- Support Page - https://ops4j1.jira.com/wiki/spaces/paxweb/pages/
>12059116/Support
>   - At the bottom of the page is the following text:
>
> *Before asking for help with your issue, it's a very good idea to search
> for your issue in the mailing list archives and the FAQ. The majority of
> issues can be solved in this manner without having to send an email to the
> mailing list. If you don't find an answer, use the guidelines below when
> writing the e-mail.*
>
>
>- Issues I see:
> - The FAQ
> <https://ops4j1.jira.com/wiki/spaces/paxweb/pages/5046923/FAQ>
> has three items listed, so not overly helpful.
> - There are no guidelines on the page as the last sentence
> says.
>  - The Committers page is really out of date:
>https://ops4j1.jira.com/wiki/spaces/ops4j/pages/48/Committers
><https://ops4j1.jira.com/wiki/spaces/ops4j/pages/48/Committers>
>   - Mentions SVN, it should be changed to GitHub
>   - The Code Standards page would benefit by having Eclipse and
>   IntelliJ configuration files that match/enforce the standards.
>- On https://github.com/ops4j/org.ops4j.pax.logging the link for the
>Wiki is wrong (http://wiki.ops4j.org/display/paxlogging/Pax+Logging)
>   - It should be: https://ops4j1.jira.com/wiki/spaces/paxlogging/
>   overview
>- Page Ordering/Location: https://ops4j1.jira.com/wiki/spaces/
>ops4j/pages <https://ops4j1.jira.com/wiki/spaces/ops4j/pages>
>   - Articles
>   <https://ops4j1.jira.com/wiki/spaces/ops4j/pages/57/Articles> and
>   How-To-Articles
>   
> <https://ops4j1.jira.com/wiki/spaces/ops4j/pages/73662474/How-to+articles>
>   should be merged as How-To is a newer Confluence feature over the older
>   "Articles".
>   - https://ops4j1.jira.com/wiki/spaces/ops4j/pages/73662475/
>   Using+pax+logging should be nested under the merged Page
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

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

Re: Blocking threads in log4j appender

[Niclas Hedhman]

Andrei,

In case it is not clear; pax-logging-log4j2 is a replacement implementation
for the pax-logging-service.

On Wed, Nov 8, 2017 at 1:58 AM, Matt Sicker <boa...@gmail.com> wrote:

> If you use pax-logging-log4j2, you can migrate easily, though the version
> of log4j2 in there is somewhat out of date.
>
> Async appender will certainly alleviate some issues, but it can't do much
> about APIs that publicly add the synchronized keyword to hot spots like in
> log4j1.
>
> On 7 November 2017 at 11:53, Andrei Shakirin <andrei.shaki...@gmail.com>
> wrote:
>
>> Hi Matt,
>>
>> Thanks for quick response, but I don't use log4j directly, only through
>> the pax-logging-service.jar.
>> And the issue is still there even with last released pax-logging-service
>> version (1.10.1).
>>
>> Async appender is an option, will definitely try that.
>>
>> Regards,
>> Andrei.
>>
>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to ops4j+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Matt Sicker <boa...@gmail.com>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

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

Re: Any plans on extending the 4.4.x stream?

[Niclas Hedhman]

I suggest that you submit the PR. That is the easy part. Question is if
there is someone willing to do the release. If you are, then great... if
not, you would need to convince (charm, beer, bribe, threat...) someone to
do it.

Cheers
Niclas

On Sat, Sep 16, 2017 at 5:04 AM, Trevor Brown <tbr...@securityfirstcorp.com>
wrote:

> Hi all,
>
> My company is using Pax Web 4.2.7 right now. Unfortunately the version of
> Jetty in that release (and actually all Pax Web releases, it seems) is
> vulnerable to a timing channel attack (see https://github.com/
> eclipse/jetty.project/issues/1556 for details).
>
> I started looking at options, and right now it looks like the only upgrade
> path I have that won't require a lot of effort on my part (I experimented
> and failed using any of the 6.x releases) is to upgrade within the 4.x
> releases of Pax Web. I just rebuilt 4.4.1 locally with Jetty 9.2.22 and all
> the unit tests passed.
>
> So I'm wondering whether I should open a JIRA and submit a pull request
> for the upgrade in the 4.4.x stream, or whether I should just consider this
> a one-off fork for now and maybe work to pick up the Jetty 9.4.x work in
> the 6.0.x stream?
>
> Thanks in advance.
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

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

Re: Pax exam. Proposal to allow catch Exception in checkstyle rules

[Niclas Hedhman]

Is there no @SuppressWarning to Mark the exceptions (pun intended)?

On Aug 23, 2017 11:36, "Christian Schneider" 
wrote:

> Currently the checkstyle rules forbid to catch Exception.
>
> I propose to change this as catching Exception is sometimes very useful
> when for example a called method throws Exception or we simply want to map
> to RuntimeException to avoid having throws Exception in every caller.
>
> Christian
>
> --
> 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 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: new ops4j repro/project - how to perform initial setup

[Niclas Hedhman]

AS noted, when we left the "version 1.0" of infrastructure (where basically
everyone, with enough knowledge, could do anything on our own systems),
there has been a division between admins and committers (or what the term
is on each system).

In principle, I (and probably others) have no problem promoting active
members of the community to admin. It just lessens the work on someone else.

And I think Achim is (or has) elevated you for that purpose.


Cheers
Niclas


On Fri, Aug 11, 2017 at 2:02 AM, 'Christoph Läubrich' via OPS4J <
ops4j@googlegroups.com> wrote:

> I'd like to start a new OPS4j pax project that is about remote control of
> OSGi, maybe it will implements (but not restricted to) "Remote Services"
> and "Remote Service Admin" Specification.
> The main goal for now would be to provide support for new container
> abstraction in pax-exam but I think this could be usefull for others as
> well so I'd like to work on it under an own pax-project.
>
> But how is this done? It seems there are special right required to setup a
> project (github, jira, confluence, add it to
> https://ops4j1.jira.com/wiki/display/ops4j/Pax ... more?).
> If I can't do it on my own, can someone with apropiat rights please create
> a new "pax-remote" project for me?
>
> thanks in advance :-)
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> --- You received this message because you are subscribed to the Google
> Groups "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

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

Re: [pax-exam] How to simulate beforeClass / afterClass hook *outside* of the OSGi container

[Niclas Hedhman]

I thought I should chip in and point out that Junit 5 ahs received the
entire extension mechanism, and both Rules and RunWith constructs are
deprecated, and implemented using the new extension system.

Perhaps it would make more sense for new functionality in Pax Exam to look
forward to JUnit 5.

Just my 2 sen.

On Aug 4, 2017 20:39, "Nicolas Brasey"  wrote:

> Hi Tony,
>
> Thanks a lot for your answer.
>
> I think what you are working on is absolutely great, and I think it would
> also perfectly fit for our needs. Starting the OSGi container from a junit
> rule makes the tests cleaner. I guess this would also work with Karaf,
> right ? But, just for the curiosity, how do you plan to access the OSGi
> service from outside the container ? And when do you plan to push your
> local branch ? :-)
>
> 2) Yes I tried booting neo4j from the @Configuration method, but there 2
> issues IMHO:
> a) It provides only a way to start neo4j, obviously no hook to run some
> post tests code
> b) since the configure code is also deployed as an OSGi bundle, it forces
> you to make sure the  does not include the neo4j
> packages, which cannot be resolved. It is feasible, but this is hard work
> and I'm not sure about the maintainability of this over the time
>
> 3) Not sure I understood your proposal with the RunWith. Do you mean
> implementing my own Junit runner that wraps the PaxExam runner, and run my
> tests with it ?
>
>
> Cheers,
> Nicolas
>
>
> On Fri, Aug 4, 2017 at 12:47 PM, Toni Menzel 
> wrote:
>
>> Hey Nicolas,
>>
>> I think you are looking at something like the (new) acceptance test api
>> that runs from outside of
>> osgi: https://github.com/ops4j/org.ops4j.pax.exam2/blob/
>> master/drivers/pax-exam-acceptance/src/test/java/org/ops4j/
>> pax/exam/acceptance/AcceptanceTestApiTest.java
>>
>> This is currently in active development and is lacking some features like
>> smooth access to OSGi Services from the outside.
>> Currently, only the rest client is available (using RestAssured), but I a
>> new one making internal services available to the test automatically is
>> already on my local branch.
>>
>> In any way, we also could think of making out-of-container setup code
>> available in regular "@RunWith(PaxExam.class)" tests. Did you try booting
>> Neo4j inside the @Configuration method? that is executed before the OSGi
>> container is launched, so it does run in plain java.
>>
>> Another try: did you try using a Junit Rule with "@RunWith()"? this
>> should work, too.
>>
>> Toni
>>
>>
>>
>>
>> *www.rebaze.de  | www.rebaze.com
>>  | @rebazeio *
>>
>> On Fri, Aug 4, 2017 at 11:59 AM, Nicolas Brasey > > wrote:
>>
>>> Hi,
>>>
>>> Context: I want to use pax-exam for our business integration tests that
>>> needs to have a database (neo4j) that is not OSGi friendly running before
>>> the test are executed. we use maven.
>>>
>>> Also, neo4j provides a embedded server that works extremely well outside
>>> of an OSGi container, but I can't find a way to start this embedded server
>>> with pax-exam outside of the container before the pax-exam machinery is
>>> starting.
>>>
>>> The idea is to start the database in the non-OSGi context when the
>>> pax-runner is starting, something like the beforeClass, and stop the
>>> database after all the tests are finished ala afterClass.
>>>
>>> Does anyone has an idea how to do this ?
>>>
>>> Thanks
>>> Nicolas
>>>
>>> --
>>> --
>>> --
>>> 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 a topic in the
>> Google Groups "OPS4J" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/ops4j/RlgwSX04-O8/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.
>

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

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

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

[Niclas Hedhman]

r.impl.CdiExtender.addingBundle(CdiExtender.java:64)
>   at 
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:469)
>   at 
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:415)
>   at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
>   at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
>   at 
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517)
>   at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2172)
>   at 
> org.apache.felix.framework.Felix$RefreshHelper.restart(Felix.java:5063)
>   at org.apache.felix.framework.Felix.refreshPackages(Felix.java:4253)
>   at 
> org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:188)
>   at java.lang.Thread.run(Thread.java:745)
>
>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

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

Fwd: Travis CI

[Niclas Hedhman]

-- Forwarded message --
From: Michael Vorburger.ch <m...@vorburger.ch>
Date: Sat, Apr 8, 2017 at 6:58 PM
Subject: Travis CI
To: OPS4J Infrastructure <ops4j-in...@googlegroups.com>


Hello,

how about we activate Travis CI <https://travis-ci.org> on the repos?

I'm willing to help setting it up, at least e.g. for Pax Exam, but lack the
admin permission for the repo on Git Hub:

https://travis-ci.org/ops4j/org.ops4j.pax.exam2 :

This is not an active repository
You don't have sufficient rights to enable this repo on Travis.

Please contact the admin to enable it or to receive admin rights yourself.


Once it's been added, I can contribute the required configuration, if
needed, like https://github.com/vorburger/MariaDB4j/blob/master/.travis.yml


We can then enable it to run and comment on pull requests.


Tx,
M.

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



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

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

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

Pax UserAdmin

[Niclas Hedhman]

Gang,
I am on a project where we need Pax UserAdmin, and I dusting it off and
would like to proceed with a release.

Does anyone have anything in the pipeline, sitting around locally or want
to get in before the release?

I also added the documentation to https://ops4j.github.io/ which is
generated by Maven APT.


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

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

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

Re: pax-web class not found in jetty

[Niclas Hedhman]

Hi,

from my experience with "inside"/"outside" set ups, I can feel your pain.
Have you considered to package all the "outside" into a single large bundle
and deploy that "inside" ??

Niclas

On Fri, Nov 4, 2016 at 5:41 AM, Benson Margulies <ben...@basistech.com>
wrote:

> In the failing case,
>
> Thread[paxweb-config-1-thread-1,5,main]
>
> has a context class loader that is not an OSGi bundle class loader at
> all. Jetty uses the context class loader, and things go badly.
>
> I can make this problem appear and disappear by changing what is in
> the classpath _outside_ the container -- if I put CXF both inside and
> outside, I get this.
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

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

Re: Introduction and release of pax-jdbc

[Niclas Hedhman]

On Thu, Nov 3, 2016 at 6:08 PM, Jean-Baptiste Onofré <
jeanbaptiste.ono...@gmail.com> wrote:
> No objection for a 0.10.0 release.
> On the other hand, I think we can consider 1.0.0 release after a 0.11.0.

I think it would be great to figure out if there are any "breaking changes"
needed. If not, it has been >4years since Pax JDBC saw the light of day,
and I think it is time for a 1.0 release, and that there is no need to wait
until "after a 0.11.0".


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

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

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

Re: pax-logging-logback and connecting to logback outside the container

[Niclas Hedhman]

Benson,
I think you will have serious problems getting this to work, for reasons
that you mention.

I think that you could make this work if you,
a. Create your own Pax Logging Service implementation bundle. SLF4J is not
part of the Pax Logging API, so that conflict is not inherently there.

b. Figure out how to bind that bundle to SLF4J on the outside. I have not
read up on OSGi classloading tricks since 4.1, so I don't know if it is now
possible to instruct a single bundle to go to system classloader somehow,
instead of importing from framework.

I *might* be easier to proved a logger factory provider (can't recall the
exact term) in the outside SLF4J world and that factory is tied into the
Pax Logging API on the inside. IF that is an option, my guess is that it is
easier to make working. But I am also aware that such tricks may be out of
scope...

HTH
Niclas

On Wed, Nov 2, 2016 at 3:15 AM, Benson Margulies <ben...@basistech.com>
wrote:

> I think I'm asking the wrong question here. I'll post a more relevant one.
>
> On Tue, Nov 1, 2016 at 1:52 PM, Benson Margulies <ben...@basistech.com>
> wrote:
> > I think I want to do the following: I want to embed an OSGi container
> > in an application that logs with logback, I want to list logback as a
> > system bundle package, and have pax-logging route the output to the
> > 'outside' by using the logback thus exported.
> >
> > This seems intrinsically a bit tricky, since the API to logback is
> > generally just slf4j.
> >
> > However, the fact that pax-logging-logback embeds the logback code,
> > and then does not have Import-Package instructions to allow that embed
> > to be overriden, also seems potentially problematic.
> >
> > In the code in its current form, can I do this? I could just try
> > system-bundling slf4j itself and see if pax-logging-logback ends up
> > doing what I want; I thought I'd ask in case someone had some prior
> > experience to share.
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

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

Re: pax-exam failing to shut down karaf

[Niclas Hedhman]

Then I leave it to the experts... :-(

On Tue, Oct 18, 2016 at 8:43 AM, Benson Margulies <ben...@basistech.com>
wrote:

> On Mon, Oct 17, 2016 at 7:58 PM, Niclas Hedhman <nic...@hedhman.org>
> wrote:
> > It doesn't even timeout after 10, 20, 60 minutes?
>
> Nope. And it's not failing to start: in the exam plugin case, it
> starts, the tests run that talk to the Karaf instance, and then it
> hangs in stop. And even if I use the Linux kill command to kill the
> karaf process, the exam-maven-plugin remains stuck waiting for
> something on the shutdown side.
>
>
>
> >
> > On Tue, Oct 18, 2016 at 3:39 AM, Benson Margulies <ben...@basistech.com>
> > wrote:
> >>
> >> Using pax-exam 4.9.1, we suffer from unpredictable hangs on shutdown.
> >> We've seen this with the exam-maven-plugin and when using
> >>
> >> @ClassRule
> >> public static PaxExamServer exam = new PaxExamServer();
> >>
> >>
> >> to launch karaf 4.0.6. Most of the time, everything works as expected,
> but
> >> when it goes wrong, it just gets stuck, sitting there. We're on the
> verge of
> >> implementing a thread waiting for a connection that will just stop the
> OSGi
> >> framework forcibly. That's pretty ugly. Can anyone suggest a debugging
> >> strategy? The non-reproducibility of this is, of course, a barrier.
> >>
> >> --
> >> --
> >> --
> >> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
> >>
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups
> >> "OPS4J" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to ops4j+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://zest.apache.org - New Energy for Java
> >
> > --
> > --
> > --
> > OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
> >
> > ---
> > You received this message because you are subscribed to a topic in the
> > Google Groups "OPS4J" group.
> > To unsubscribe from this topic, visit
> > https://groups.google.com/d/topic/ops4j/GlyXQeXcwmY/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.
>



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

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

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

Re: pax-exam failing to shut down karaf

[Niclas Hedhman]

My guess is that the shutdown is happening before the startup is completed,
or something to that effect. Try to capture the relative timing of getting
there and the signal to shutdown.

Right now, no suggestion how to solve this, if it is he case.

On Tue, Oct 18, 2016 at 7:58 AM, Niclas Hedhman <nic...@hedhman.org> wrote:

> It doesn't even timeout after 10, 20, 60 minutes?
>
> On Tue, Oct 18, 2016 at 3:39 AM, Benson Margulies <ben...@basistech.com>
> wrote:
>
>> Using pax-exam 4.9.1, we suffer from unpredictable hangs on shutdown.
>> We've seen this with the exam-maven-plugin and when using
>>
>> @ClassRule
>> public static PaxExamServer exam = new PaxExamServer();
>>
>>
>> to launch karaf 4.0.6. Most of the time, everything works as expected,
>> but when it goes wrong, it just gets stuck, sitting there. We're on the
>> verge of implementing a thread waiting for a connection that will just stop
>> the OSGi framework forcibly. That's pretty ugly. Can anyone suggest a
>> debugging strategy? The non-reproducibility of this is, of course, a
>> barrier.
>>
>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to ops4j+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>



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

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

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

Re: pax-exam failing to shut down karaf

[Niclas Hedhman]

It doesn't even timeout after 10, 20, 60 minutes?

On Tue, Oct 18, 2016 at 3:39 AM, Benson Margulies <ben...@basistech.com>
wrote:

> Using pax-exam 4.9.1, we suffer from unpredictable hangs on shutdown.
> We've seen this with the exam-maven-plugin and when using
>
> @ClassRule
> public static PaxExamServer exam = new PaxExamServer();
>
>
> to launch karaf 4.0.6. Most of the time, everything works as expected, but
> when it goes wrong, it just gets stuck, sitting there. We're on the verge
> of implementing a thread waiting for a connection that will just stop the
> OSGi framework forcibly. That's pretty ugly. Can anyone suggest a debugging
> strategy? The non-reproducibility of this is, of course, a barrier.
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

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

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

[Niclas Hedhman]

Hold on a sec... Looking at JIRAs and I see;

https://ops4j1.jira.com/browse/PAXWEB-396
https://ops4j1.jira.com/browse/PAXWEB-490

Isn't that exactly the same thing?

Niclas


On Sun, Oct 9, 2016 at 3:34 PM, iJava <pavelkastor...@gmail.com> wrote:

> Niclas, besides look, all current settings are in bundle:
> 1) virtual hosts in bundle jetty-web.xml
> 2) context-path - in bundle manifest
> 3) web.xml - in bundle
> So, I suggest to put it there - let all the settings be in one place - in
> bundle.
>
> воскресенье, 9 октября 2016 г., 9:26:29 UTC+3 пользователь Niclas Hedhman
> написал:
>>
>> Hi,
>> I would like to suggest that it is not advisable to put the virtual host
>> name into the bundle. That is IMNSHO at odds with the normal flexibility
>> available. I think that one way of doing it is through configuration of Pax
>> Web, such as an optional map of "Bundle-SymbolicName" to "Virtual Host
>> Name". There might be other...
>>
>> Niclas
>>
>> On Sun, Oct 9, 2016 at 11:03 AM, iJava <pavelka...@gmail.com> wrote:
>>
>>> Hi Achim,
>>>
>>> I had some free time (it is 5 am now :) ) to take a look at pax-web
>>> sources.
>>> 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.
>>>
>>>
>>> понедельник, 3 октября 2016 г., 21:43:15 UTC+3 пользователь Achim
>>> Nierbeck написал:
>>>>
>>>> Niclas ... I have no clue why he isn't shown ... according to
>>>> openhub.net he still is [1]
>>>>
>>>> Pavel, one could also always have 15 Microservices taking care of those
>>>> 15 domains.
>>>>
>>>> regards, Achim
>>>>
>>>> [1] - https://www.openhub.net/p/pax-web/users
>>>>
>>>> 2016-10-03 6:54 GMT+02:00 Pavel Kastornyy <pavelka...@gmail.com>:
>>>>
>>>>> Hi Marc
>>>>>
>>>>> You are absolutely right - it is possible to use frontend server
>>>>> and use pax-web as backend server. But in this case pax-web
>>>>> in any serious production use can be used only as backend +
>>>>> if you have 15 domains you will manage 15 ports.
>>>>>
>>>>> Best regards,
>>>>>
>>>>>
>>>>> On 02.10.2016 21:46, Marc Schlegel wrote:
>>>>>
>>>>>> Here are my two cents
>>>>>>
>>>>>> Regarding the whiteboard-extender, I was actually thinking of moving
>>>>>> this
>>>>>> into the webcontainer, because due to the whiteboard-dto spec those
>>>>>> two are
>>>>>> closely related anyways. My idea was to deprecate the (upcoming)
>>>>>> WhiteboardManager-service right away in order to merge those two
>>>>>> modules in
>>>>>> a 7.0 release. So that might solve one pain-point.
>>>>>>
>>>>>> But another question is: do we need to rewrite everything in order to
>>>>>> get a
>>>>>> feature which might no be needed? Without knowing the business-case
>>>>>> behind
>>>>>> registering multiple contexts with the same name in different
>>>>>> virtual-hosts, I still think that there are much cheaper alternatives:
>>>>>> everything

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

[Niclas Hedhman]

Hi,
I would like to suggest that it is not advisable to put the virtual host
name into the bundle. That is IMNSHO at odds with the normal flexibility
available. I think that one way of doing it is through configuration of Pax
Web, such as an optional map of "Bundle-SymbolicName" to "Virtual Host
Name". There might be other...

Niclas

On Sun, Oct 9, 2016 at 11:03 AM, iJava <pavelkastor...@gmail.com> wrote:

> Hi Achim,
>
> I had some free time (it is 5 am now :) ) to take a look at pax-web
> sources.
> 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.
>
>
> понедельник, 3 октября 2016 г., 21:43:15 UTC+3 пользователь Achim Nierbeck
> написал:
>>
>> Niclas ... I have no clue why he isn't shown ... according to openhub.net
>> he still is [1]
>>
>> Pavel, one could also always have 15 Microservices taking care of those
>> 15 domains.
>>
>> regards, Achim
>>
>> [1] - https://www.openhub.net/p/pax-web/users
>>
>> 2016-10-03 6:54 GMT+02:00 Pavel Kastornyy <pavelka...@gmail.com>:
>>
>>> Hi Marc
>>>
>>> You are absolutely right - it is possible to use frontend server
>>> and use pax-web as backend server. But in this case pax-web
>>> in any serious production use can be used only as backend +
>>> if you have 15 domains you will manage 15 ports.
>>>
>>> Best regards,
>>>
>>>
>>> On 02.10.2016 21:46, Marc Schlegel wrote:
>>>
>>>> Here are my two cents
>>>>
>>>> Regarding the whiteboard-extender, I was actually thinking of moving
>>>> this
>>>> into the webcontainer, because due to the whiteboard-dto spec those two
>>>> are
>>>> closely related anyways. My idea was to deprecate the (upcoming)
>>>> WhiteboardManager-service right away in order to merge those two
>>>> modules in
>>>> a 7.0 release. So that might solve one pain-point.
>>>>
>>>> But another question is: do we need to rewrite everything in order to
>>>> get a
>>>> feature which might no be needed? Without knowing the business-case
>>>> behind
>>>> registering multiple contexts with the same name in different
>>>> virtual-hosts, I still think that there are much cheaper alternatives:
>>>> everything today moves away from heavy-installations (AppServers) in
>>>> favor
>>>> of dedicated containers. With OSGi and Pax-Web you can easily spawn
>>>> multiple VMs, and have some proxy/webserver in front which manages the
>>>> site/domain to look like one.
>>>>
>>>> regards
>>>> Marc
>>>>
>>>>
>>>> Am Sonntag, 2. Oktober 2016 15:39:45 UTC+2 schrieb iJava:
>>>>
>>>>> 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
>>>>&g

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

[Niclas Hedhman]

"Microservices" is the latest hype in the DevOps world. You run small
networked services in their own Docker containers, and then use
programmable Load Balancers and other tricks to treat your machines like
"cattle" instead of "pets".
Search "Microservices" on YouTube and you will find many excellent
explanations of the details.

Cheers
Niclas

On Tue, Oct 4, 2016 at 6:44 PM, iJava <pavelkastor...@gmail.com> wrote:

> Hi Achim
>
> What do you mean by "Microservice". Could you give a concrete example?
>
> Best regards,
>
> понедельник, 3 октября 2016 г., 21:43:15 UTC+3 пользователь Achim Nierbeck
> написал:
>>
>> Niclas ... I have no clue why he isn't shown ... according to openhub.net
>> he still is [1]
>>
>> Pavel, one could also always have 15 Microservices taking care of those
>> 15 domains.
>>
>> regards, Achim
>>
>> [1] - https://www.openhub.net/p/pax-web/users
>>
>> 2016-10-03 6:54 GMT+02:00 Pavel Kastornyy <pavelka...@gmail.com>:
>>
>>> Hi Marc
>>>
>>> You are absolutely right - it is possible to use frontend server
>>> and use pax-web as backend server. But in this case pax-web
>>> in any serious production use can be used only as backend +
>>> if you have 15 domains you will manage 15 ports.
>>>
>>> Best regards,
>>>
>>>
>>> On 02.10.2016 21:46, Marc Schlegel wrote:
>>>
>>>> Here are my two cents
>>>>
>>>> Regarding the whiteboard-extender, I was actually thinking of moving
>>>> this
>>>> into the webcontainer, because due to the whiteboard-dto spec those two
>>>> are
>>>> closely related anyways. My idea was to deprecate the (upcoming)
>>>> WhiteboardManager-service right away in order to merge those two
>>>> modules in
>>>> a 7.0 release. So that might solve one pain-point.
>>>>
>>>> But another question is: do we need to rewrite everything in order to
>>>> get a
>>>> feature which might no be needed? Without knowing the business-case
>>>> behind
>>>> registering multiple contexts with the same name in different
>>>> virtual-hosts, I still think that there are much cheaper alternatives:
>>>> everything today moves away from heavy-installations (AppServers) in
>>>> favor
>>>> of dedicated containers. With OSGi and Pax-Web you can easily spawn
>>>> multiple VMs, and have some proxy/webserver in front which manages the
>>>> site/domain to look like one.
>>>>
>>>> regards
>>>> Marc
>>>>
>>>>
>>>> Am Sonntag, 2. Oktober 2016 15:39:45 UTC+2 schrieb iJava:
>>>>
>>>>> 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,

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

[Niclas Hedhman]

Wasn't history preserved when we moved to Github? I don't see Alin's work
pre-2010...

Niclas

On Mon, Oct 3, 2016 at 12:35 AM, 'Achim Nierbeck' via OPS4J <
ops4j@googlegroups.com> 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>:
>>>>>
>>>>> Hon

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

[Niclas Hedhman]

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



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

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

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

Re: [DISCUSS] Pax-Web 6.0.RC1 release

[Niclas Hedhman]

It is a learning experience/opportunity, and next time it will be smoother.
Also, almost without exceptions, someone who is working on fixing something
get answers when they ask, often quickly, because everyone here wants new
people to succeed and become more productive over time.

Achim, Guilaume and others were not the originators of Pax Web either. They
dug into what we had at that time, and made improvements (or was it a
complete rewrite?)... I don't recall how much help they needed, but if they
needed it, "we" (who were more active then) tried our best to help us much
as we could. And I am sure this tradition still runs in this community, and
many others "out there"...

Cheers
Niclas

Niclas

On Sun, Sep 25, 2016 at 6:15 PM, iJava <pavelkastor...@gmail.com> wrote:

> Hi Achim
>
> If no one of the developers do it in the nearest future then I will spend
> about 20 hours trying to fix it.
> It is obvious that it will be much more difficult for me because I don't
> know the inner architecture of pax-cdi
> and pax-web.
>
> But firstly I need Guillaume Nodet update pax-cdi 1.x branch to align
> with pax-web 6.x.
>
> Best regards,
>
>
> воскресенье, 25 сентября 2016 г., 12:20:02 UTC+3 пользователь Achim
> Nierbeck написал:
>>
>> Alexander,
>>
>> I still fear you miss the point of Open Source Software. And what the
>> free in free software means. [1]
>> It isn't about free as in free beer it is about free as in freedom to
>> read the sources, about the freedom to participate.
>>
>> And as I already stated previously to you. It certainly isn't a one-way
>> street where on the one end the "stupid" developers reside and the other
>> end is a consumer that just needs to bark loud enough. It's a give and
>> take, so think more about what you can give the community[2].
>> How about you take some of your private time and try to fix the issue
>> which bothers you so much in your productive environment?
>> Maybe your employer, who obviously earns money while using this open
>> source software, gives you some time to fix the issue?
>> Or as Niclas already stated, find someone to do it for you and pay that
>> person.
>>
>> regards, Achim
>>
>>
>> [1] - http://www.gnu.org/philosophy/free-sw.en.html
>> [2] - http://www.merriam-webster.com/dictionary/community
>>
>> 2016-09-25 9:04 GMT+02:00 iJava <pavelka...@gmail.com>:
>>
>>> Hi Niclas
>>>
>>> Thank you for detailed answers to my questions.  Now I understand how
>>> this community is managed -
>>> to say more correctly how this community is unmanaged.
>>>
>>> To tell the truth it is a very strange for me - but this is of course my
>>> private opinion. I believe
>>> that bad plan is better then the absence of the plan. It is clear why -
>>> because with bad
>>>  plan actions at least are coordinated.
>>>
>>> I am not a contributor and "don't dare" to make any suggestions. But
>>> about "dare" to use open sources
>>> projects. You know - I am developer,  I develop some products and use
>>> other products. When I use some
>>> products it is clear that I want to know the future of the product, And
>>> it is quite common to see the roadmap
>>>  of the project. Please, note it is quite common and in open source
>>> projects.
>>>
>>> By the way it would be helpful not only for users who "dare" to use the
>>> products. It would be helpful and for
>>> developers and they would have the questions like in this thread
>>> https://groups.google.com/forum/#!topic/ops4j/q8A4qniAtCg
>>>
>>> Best regards,
>>>
>>> воскресенье, 25 сентября 2016 г., 2:34:03 UTC+3 пользователь Niclas
>>> Hedhman написал:
>>>>
>>>> Alexander,
>>>>
>>>> To the question on how things are prioritized; It is very simple. The
>>>> person who wants to work on an issue places the priority on the issue.
>>>> Before anyone puts down his/her own name on the issue, it should actually
>>>> be marked "not prioritized" and if you disagree, simply change it, assign
>>>> the issue to yourself and work on it. There is a "Participation" in the
>>>> name here for a reason.
>>>>
>>>> Perhaps so much time has passed that you and other relatively new
>>>> people to this community are unaware of the early principles and purpose of
>>>> OPS4J, the "Flock of Birds" metaphor, the "If you are committed en

Re: Some logs are missing when the Configuration is updated via ConfigurationAdmin

[Niclas Hedhman]

You could try setting the org.ops4j.pax.logging.useBufferingLogFallback
property to true. That should give you a PaxLogger that buffers logging
events while backend service is not available.
No idea how stable that is compared to the default one, so be prepared to
fix any issues you might encounter.

Niclas

On Wed, Aug 31, 2016 at 9:33 PM, Jayanga Dissanayake <jsdjaya...@gmail.com>
wrote:

> Hi All,
>
> I am trying to update the configuration via 
> "org.osgi.service.cm.Configuration"
> and once I update the configuration, some logs are missing (while the debug
> logs are enabled it should log all the bundle "BundleEvent INSTALLED",
> "BundleEvent RESOLVED" logs but these are missing in the logs.)
>
> I temporally add a thread sleep to the BundleActivatior start() after
> updating the configuration and then I can see all the bundles that I
> install, logging the above-mentioned output.
> It seems once I update the Configuration it takes a little time to get
> reflected. Has anyone faced the same thing before?
>
> I tried to register a "SynchronousConfigurationListener" and wait until
> the configuration update is received by this bundle. But still, the problem
> is there.
>
> Following is an extract from my code,
>
> //
> ServiceReference reference = bundleContext.getServiceReference(
> ConfigurationAdmin.class);
> if (reference != null) {
> ConfigurationAdmin configurationAdmin = (ConfigurationAdmin)
> bundleContext.getService(reference);
> Configuration configuration = configurationAdmin.
> getConfiguration("org.ops4j.pax.logging", null);
> ...
> Hashtable loggingProperties;
> ...
> // Loading the loggingProperties with log4j file location
> //  "org.ops4j.pax.logging.log4j2.config.file" ->
> "[path_to_the_log4j_file]/log4j2.xml"
> configuration.update(loggingProperties);
> //=
>
> Does anyone has an idea what is happening? Or know how to guarantee that
> the configurations are updates before installing the other bundles?
>
> Thanks,
> Jayanga.
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

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

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

[Niclas Hedhman]

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

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


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

Cheers

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

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



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

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

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

Re: Pax exam - how does it create bundle with integration tests?

[Niclas Hedhman]

A.k.a ToniBundles  ;-)

On Fri, Jul 22, 2016 at 2:54 PM, 'Achim Nierbeck' via OPS4J <
ops4j@googlegroups.com> wrote:

> Hi that's the tiny bundles project. [1]
>
> regards, Achim
>
> [1] - https://ops4j1.jira.com/wiki/display/ops4j/Pax+Tinybundles+-+1.0.0
>
> 2016-07-21 15:09 GMT+02:00 iJava <pavelkastor...@gmail.com>:
>
>> Hello all
>>
>> As I understand pax exam takes integration tests and puts them in
>> separate bundle. So , as I understand, pax exam can create osgi bundles on
>> the fly. Can anyone say what code does it (library, project, packages etc).
>> Just a place I could take look at.
>>
>> Best regards
>>
>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to ops4j+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

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

Re: Httpoxy

[Niclas Hedhman]

The link I gave in the OP contains a section of Tomcat's position. Default
it is not an issue, but depends on how Pax Web sets it up.

I don't use it myself at the moment, just thought I should forward this
info from ASF.

Cheers
Niclas

On Fri, Jul 22, 2016 at 4:46 PM, 'Achim Nierbeck' via OPS4J <
ops4j@googlegroups.com> wrote:

> Hi,
>
> just to give some feedback on this.
> Jetty seems to look into it, if it's actually an issue.
> Couldn't find any details about, if it's actually an issue of Tomcat or
> undertow.
>
> regards, Achim
>
> [1] - http://dev.eclipse.org/mhonarc/lists/jetty-dev/msg02770.html
>
> 2016-07-21 0:06 GMT+02:00 Achim Nierbeck <bcanh...@googlemail.com>:
>
>> Hi Niclas,
>>
>> we would need to inspect how Jetty, Tomcat and Undertow do handle that
>> ...
>>
>> regards, Achim
>>
>>
>> 2016-07-20 23:59 GMT+02:00 Niclas Hedhman <nic...@hedhman.org>:
>>
>>> In regards to this; https://httpoxy.org/
>>>
>>> Is there anything in Pax Web that should be considered?
>>>
>>> Apache Software Foundation made am investigation and is available;
>>> https://www.apache.org/security/asf-httpoxy-response.txt
>>>
>>> Cheers
>>> --
>>> Niclas Hedhman, Software Developer
>>> http://zest.apache.org - New Energy for Java
>>>
>>> --
>>> --
>>> --
>>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "OPS4J" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to ops4j+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>>
>> 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
>>
>>
>
>
> --
>
> 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.
>



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

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

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

Httpoxy

[Niclas Hedhman]

In regards to this; https://httpoxy.org/

Is there anything in Pax Web that should be considered?

Apache Software Foundation made am investigation and is available;
https://www.apache.org/security/asf-httpoxy-response.txt

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

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

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