Re: PAX Wicket 4 (moving to wicket 8)

2017-06-20 Thread nino martinez wael
Hi Christoph

Looks like WICKET-6402 already are resolved?



On Tue, Jun 20, 2017 at 10:03 AM, 'Christoph Läubrich' via OPS4J <
ops4j@googlegroups.com> wrote:

> As long as there are no API-breaks within Pax-Wicket it doesen't matter,
> client-code has to choose of course if the want 7 or 8, but I can only
> check this if Wicket adds OSGi-Headers, so sign up at the Wicket JIRA and
> vote for the issue ;-)
>
> Am 19.06.2017 20:44, schrieb nino martinez wael:
>
> Ahh I see most of the changes where from 6.x to 7.x..
>
> But what about the Websocket stuff, as I remember it has been changed alot
> in Wicket 8..?
>
> On Mon, Jun 19, 2017 at 2:55 PM, 'Christoph Läubrich' via OPS4J <
> ops4j@googlegroups.com> wrote:
>
>> I opened a bug to Wicket 8: https://issues.apache.org/jira
>> /browse/WICKET-6402 it seems they lost the OSGi Manifest information in
>> Wicket 8 what is bad. Beside thsi there seem no API changes that influence
>> Pax-Wicket so once Wicket 8 is release we can raise the version range
>> instead of supply a 5.0 version, pax-wicket 4 will the support Wicket 7 +
>> Wicket 8!
>>
>>
> --
> --
> --
> 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/A3x7_4ktoqk/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.
>



-- 
Best regards / Med venlig hilsen
Nino Martinez

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

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


Re: [pax-web-jsp] Can pax-web-jsp handle simple custom tags with .tag (not .tld) extension in a WAB (not WAR)?

2017-06-20 Thread Eben Stewart
If the ticket comments can explain what *should* work (esp from an 
annotation perspective), given the scenario, I can try and help dig around.

On Tuesday, June 20, 2017 at 3:58:48 PM UTC-4, Achim Nierbeck wrote:
>
> Hi, 
>
> first of all thanks for the issue and the detailed description :) 
> regarding your first mail, I don't mind questions at all, so shoot as much 
> as possible at me, I try to answer as much as possible, sometimes I might 
> not know the answer :) 
>
> Regarding the tracker, yes I really would like to have it backward 
> compatible, as we just introduced the OSGi compliance with 6, we might 
> start to deprecate with 7, and maybe get rid of it with 8 ... but that's 
> something to be worth to consider in the future :) 
> The ExtenderConstants should always work, we might have missed some 
> details while bringing those to the HttpWhiteboardConstants ... 
> Especially the pattern, it might be possible that we missed out on those, 
> need to check though. 
>
> regards, Achim
>
>
>
> 2017-06-20 21:26 GMT+02:00 Eben Stewart  >:
>
>> Created https://ops4j1.jira.com/projects/PAXWEB/issues/PAXWEB-1106 to 
>> report what I found (was able to trim it down to one Java file, plus the 
>> jsp/tag files)
>>
>>
>> On Tuesday, June 20, 2017 at 10:15:26 AM UTC-4, Eben Stewart wrote:
>>>
>>> (I hope you don't mind all these questions - I am trying to figure out 
>>> the right way of doing this, and eventually might be able to contribute a 
>>> patch)
>>>
>>> So, for that tracker, it should be using both, for backwards compat and 
>>> OSGI spec, right?
>>>
>>> Also - for the JspMapping, which HttpWhiteboardConstants should it be 
>>> looking for to handle url mappings, etc?  
>>>
>>> Same for ResourceMapping.  in the sample, I had to do this:
>>>
>>> public ResourceMappingService() {
>>> setAlias("/");
>>> setPath("");
>>> setHttpContextId(MyHttpContextMapping.HTTP_CONTEXT_ID);
>>> }
>>>
>>> What would be the expected HttpWhiteboardConstants way of doing this?  
>>> I would expect something like:
>>>
>>> HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PATTERN + "=/",
>>> HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PREFIX + "=",
>>>
>>> But I still have not been able to get that to work (hence the original 
>>> post of this thread)
>>>
>>> On Tuesday, June 20, 2017 at 2:56:08 AM UTC-4, Achim Nierbeck wrote:

 Hi, 

 they actually should use the extender constants, but also the new 
 HttpWhiteboardConstants :) 

 regards, Achim 

 2017-06-20 2:22 GMT+02:00 Eben Stewart :

> ok, correct me if I am wrong
>
> in HttpContextTracker 
> (org.ops4j.pax.web.extender.whiteboard.internal.tracker)
>
> HttpContextElement createHttpContextElement(final 
> ServiceReference serviceReference, final HttpContext 
> published) {
> String httpContextId = 
> ServicePropertiesUtils.getStringProperty(serviceReference, 
> ExtenderConstants.PROPERTY_HTTP_CONTEXT_ID);
> String httpContextPath = 
> ServicePropertiesUtils.getStringProperty(serviceReference, 
> ExtenderConstants.PROPERTY_HTTP_CONTEXT_PATH);
>
> those should not be using ExtenderConstants?
>
> ...
>
> On Monday, June 19, 2017 at 7:11:20 PM UTC-4, Eben Stewart wrote:
>
>> Sounds good... knowing the history, and the future dev plans, 
>> especially if they make it into the OSGI spec, is always good :D
>>
>> I'm taking from your comments that the ExtenderConstants are not long 
>> term?  It would be better to have an HttpWhiteboardConstants way of 
>> doing 
>> it?
>>
>> I think all the annotations are there - I will look into seeing what 
>> I can do to contribute - still wrapping my head around it all, so I want 
>> to 
>> have a good understanding of how it's all *supposed* to work.
>>
>> On Monday, June 19, 2017 at 3:07:53 PM UTC-4, Achim Nierbeck wrote:
>>
>>> Hi,
>>>
>>> thanks for the sample, will see to it. 
>>> regarding the comments/remarks, see my comments inline :) 
>>>
>>> Achim 
>>>
>>> 2017-06-19 14:50 GMT+02:00 Eben Stewart :
>>>
 Attached is a working example, the smallest I could get it (project 
 is bndtools under Eclipse)

 A few points that threw me off, that did not seem clear at first 
 (although they make sense now) - a lot of it had to do with the 
 whiteboard 
 extensions to get resources and jsp support - I am not aware if the 
 OSGI 
 spec even handles those concepts (although the WAR/WAB is).  I do like 
 this 
 way better, as it doesn't make the bundle "special" in the way in 
 handles 
 servlets, jsps and resources... they are all just services.

>>>
>>> Just a bit of History, it might make the picture clearer 

Re: [pax-web-jsp] Can pax-web-jsp handle simple custom tags with .tag (not .tld) extension in a WAB (not WAR)?

2017-06-20 Thread 'Achim Nierbeck' via OPS4J
Hi,

first of all thanks for the issue and the detailed description :)
regarding your first mail, I don't mind questions at all, so shoot as much
as possible at me, I try to answer as much as possible, sometimes I might
not know the answer :)

Regarding the tracker, yes I really would like to have it backward
compatible, as we just introduced the OSGi compliance with 6, we might
start to deprecate with 7, and maybe get rid of it with 8 ... but that's
something to be worth to consider in the future :)
The ExtenderConstants should always work, we might have missed some details
while bringing those to the HttpWhiteboardConstants ...
Especially the pattern, it might be possible that we missed out on those,
need to check though.

regards, Achim



2017-06-20 21:26 GMT+02:00 Eben Stewart :

> Created https://ops4j1.jira.com/projects/PAXWEB/issues/PAXWEB-1106 to
> report what I found (was able to trim it down to one Java file, plus the
> jsp/tag files)
>
>
> On Tuesday, June 20, 2017 at 10:15:26 AM UTC-4, Eben Stewart wrote:
>>
>> (I hope you don't mind all these questions - I am trying to figure out
>> the right way of doing this, and eventually might be able to contribute a
>> patch)
>>
>> So, for that tracker, it should be using both, for backwards compat and
>> OSGI spec, right?
>>
>> Also - for the JspMapping, which HttpWhiteboardConstants should it be
>> looking for to handle url mappings, etc?
>>
>> Same for ResourceMapping.  in the sample, I had to do this:
>>
>> public ResourceMappingService() {
>> setAlias("/");
>> setPath("");
>> setHttpContextId(MyHttpContextMapping.HTTP_CONTEXT_ID);
>> }
>>
>> What would be the expected HttpWhiteboardConstants way of doing this?  I
>> would expect something like:
>>
>> HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PATTERN + "=/",
>> HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PREFIX + "=",
>>
>> But I still have not been able to get that to work (hence the original
>> post of this thread)
>>
>> On Tuesday, June 20, 2017 at 2:56:08 AM UTC-4, Achim Nierbeck wrote:
>>>
>>> Hi,
>>>
>>> they actually should use the extender constants, but also the new
>>> HttpWhiteboardConstants :)
>>>
>>> regards, Achim
>>>
>>> 2017-06-20 2:22 GMT+02:00 Eben Stewart :
>>>
 ok, correct me if I am wrong

 in HttpContextTracker (org.ops4j.pax.web.extender.wh
 iteboard.internal.tracker)

 HttpContextElement createHttpContextElement(final
 ServiceReference serviceReference, final HttpContext
 published) {
 String httpContextId = 
 ServicePropertiesUtils.getStringProperty(serviceReference,
 ExtenderConstants.PROPERTY_HTTP_CONTEXT_ID);
 String httpContextPath = 
 ServicePropertiesUtils.getStringProperty(serviceReference,
 ExtenderConstants.PROPERTY_HTTP_CONTEXT_PATH);

 those should not be using ExtenderConstants?

 ...

 On Monday, June 19, 2017 at 7:11:20 PM UTC-4, Eben Stewart wrote:

> Sounds good... knowing the history, and the future dev plans,
> especially if they make it into the OSGI spec, is always good :D
>
> I'm taking from your comments that the ExtenderConstants are not long
> term?  It would be better to have an HttpWhiteboardConstants way of doing
> it?
>
> I think all the annotations are there - I will look into seeing what I
> can do to contribute - still wrapping my head around it all, so I want to
> have a good understanding of how it's all *supposed* to work.
>
> On Monday, June 19, 2017 at 3:07:53 PM UTC-4, Achim Nierbeck wrote:
>
>> Hi,
>>
>> thanks for the sample, will see to it.
>> regarding the comments/remarks, see my comments inline :)
>>
>> Achim
>>
>> 2017-06-19 14:50 GMT+02:00 Eben Stewart :
>>
>>> Attached is a working example, the smallest I could get it (project
>>> is bndtools under Eclipse)
>>>
>>> A few points that threw me off, that did not seem clear at first
>>> (although they make sense now) - a lot of it had to do with the 
>>> whiteboard
>>> extensions to get resources and jsp support - I am not aware if the OSGI
>>> spec even handles those concepts (although the WAR/WAB is).  I do like 
>>> this
>>> way better, as it doesn't make the bundle "special" in the way in 
>>> handles
>>> servlets, jsps and resources... they are all just services.
>>>
>>
>> Just a bit of History, it might make the picture clearer for you.
>> The Pax Web Whiteboard extender exists since the WAR/WAB part has
>> been implemented, and at the time beeing that part also moved into the 
>> OSGi
>> spec. If you take a look at it, Pax Web and the Pax Url war URL-Handler 
>> are
>> part of the reference implementation for that part of the OSGi Spec.
>> So actually the Pax Web Whiteboard extension mechanism is "pretty"
>> old :)

Re: [pax-web-jsp] Can pax-web-jsp handle simple custom tags with .tag (not .tld) extension in a WAB (not WAR)?

2017-06-20 Thread Eben Stewart
Created https://ops4j1.jira.com/projects/PAXWEB/issues/PAXWEB-1106 to 
report what I found (was able to trim it down to one Java file, plus the 
jsp/tag files)

On Tuesday, June 20, 2017 at 10:15:26 AM UTC-4, Eben Stewart wrote:
>
> (I hope you don't mind all these questions - I am trying to figure out the 
> right way of doing this, and eventually might be able to contribute a patch)
>
> So, for that tracker, it should be using both, for backwards compat and 
> OSGI spec, right?
>
> Also - for the JspMapping, which HttpWhiteboardConstants should it be 
> looking for to handle url mappings, etc?  
>
> Same for ResourceMapping.  in the sample, I had to do this:
>
> public ResourceMappingService() {
> setAlias("/");
> setPath("");
> setHttpContextId(MyHttpContextMapping.HTTP_CONTEXT_ID);
> }
>
> What would be the expected HttpWhiteboardConstants way of doing this?  I 
> would expect something like:
>
> HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PATTERN + "=/",
> HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PREFIX + "=",
>
> But I still have not been able to get that to work (hence the original 
> post of this thread)
>
> On Tuesday, June 20, 2017 at 2:56:08 AM UTC-4, Achim Nierbeck wrote:
>>
>> Hi, 
>>
>> they actually should use the extender constants, but also the new 
>> HttpWhiteboardConstants :) 
>>
>> regards, Achim 
>>
>> 2017-06-20 2:22 GMT+02:00 Eben Stewart :
>>
>>> ok, correct me if I am wrong
>>>
>>> in HttpContextTracker 
>>> (org.ops4j.pax.web.extender.whiteboard.internal.tracker)
>>>
>>> HttpContextElement createHttpContextElement(final 
>>> ServiceReference serviceReference, final HttpContext 
>>> published) {
>>> String httpContextId = 
>>> ServicePropertiesUtils.getStringProperty(serviceReference, 
>>> ExtenderConstants.PROPERTY_HTTP_CONTEXT_ID);
>>> String httpContextPath = 
>>> ServicePropertiesUtils.getStringProperty(serviceReference, 
>>> ExtenderConstants.PROPERTY_HTTP_CONTEXT_PATH);
>>>
>>> those should not be using ExtenderConstants?
>>>
>>> ...
>>>
>>> On Monday, June 19, 2017 at 7:11:20 PM UTC-4, Eben Stewart wrote:
>>>
 Sounds good... knowing the history, and the future dev plans, 
 especially if they make it into the OSGI spec, is always good :D

 I'm taking from your comments that the ExtenderConstants are not long 
 term?  It would be better to have an HttpWhiteboardConstants way of doing 
 it?

 I think all the annotations are there - I will look into seeing what I 
 can do to contribute - still wrapping my head around it all, so I want to 
 have a good understanding of how it's all *supposed* to work.

 On Monday, June 19, 2017 at 3:07:53 PM UTC-4, Achim Nierbeck wrote:

> Hi,
>
> thanks for the sample, will see to it. 
> regarding the comments/remarks, see my comments inline :) 
>
> Achim 
>
> 2017-06-19 14:50 GMT+02:00 Eben Stewart :
>
>> Attached is a working example, the smallest I could get it (project 
>> is bndtools under Eclipse)
>>
>> A few points that threw me off, that did not seem clear at first 
>> (although they make sense now) - a lot of it had to do with the 
>> whiteboard 
>> extensions to get resources and jsp support - I am not aware if the OSGI 
>> spec even handles those concepts (although the WAR/WAB is).  I do like 
>> this 
>> way better, as it doesn't make the bundle "special" in the way in 
>> handles 
>> servlets, jsps and resources... they are all just services.
>>
>
> Just a bit of History, it might make the picture clearer for you. 
> The Pax Web Whiteboard extender exists since the WAR/WAB part has been 
> implemented, and at the time beeing that part also moved into the OSGi 
> spec. If you take a look at it, Pax Web and the Pax Url war URL-Handler 
> are 
> part of the reference implementation for that part of the OSGi Spec. 
> So actually the Pax Web Whiteboard extension mechanism is "pretty" old 
> :) 
> About 2 years ago an Whiteboard extender mechanism had been added to 
> the OSGi spec, so we working on Pax Web tried to adapt the existing code 
> to 
> the new spec. 
>  
>
>>
>> 1) The use of HttpContextMapping
>>
>>- There is no default implementation of this, like JspMapping and 
>>ResourceMapping, so also cannot use annotations to initialize?
>>- How to use HttpContextMapping, DefaultHttpContext (or shared), 
>>and still be able to get to handleSecurity()
>>
>>
> You can retrieve a DefaultHttpContext Instance from the HttpService 
> (or WebContainer Service), register it as your own HttpContext. Maybe 
> that 
> helps to what your are looking for? 
>  
>
>> 2) No DefaultHttpContext (that can be extended as an annotated 
>> Service)
>>
>>- DefaultHttpContext is package 

Re: [REGISTER] Joining ops4j1.jira.com and discussing feature request

2017-06-20 Thread 'Achim Nierbeck' via OPS4J
Regarding the HttpContext issue.
The HttpService spec says what can be done, and what can't be done.
If you want to have a different behavior then the osgi spec regarding the
HttpService please use the WebContainer,
or use what is possible according to the OSGi Whiteboard specification.

regards, Achim

2017-06-20 12:17 GMT+02:00 Achim Nierbeck :

> Let me take care of that ... did that now a couple times.
> I'm using the email address you used to subscribe to this list.
>
> an invitation should be there in any minute :)
>
> regards, Achim
>
>
>
> 2017-06-20 12:13 GMT+02:00 Jean-Baptiste Onofré <
> jeanbaptiste.ono...@gmail.com>:
>
>> Hi,
>>
>> We can create your account, just need your preferred ID.
>>
>> Regards
>> JB
>>
>> On 06/20/2017 12:06 PM, Lukasz Lech wrote:
>>
>> I’ve registerd in Attlassian, and then I’ve got the message when I logged
>> in and went to ops4j1:
>>
>>
>>
>> Due to increased SPAM and fake accounts, the self-registration has been
>> disabled. Sorry for the inconvenience.
>> Contact the OPS4J General list to have an account created.
>>
>>
>>
>> *From:* ops4j@googlegroups.com [mailto:ops4j@googlegroups.com
>> ] *On Behalf Of *Jean-Baptiste Onofré
>> *Sent:* Dienstag, 20. Juni 2017 11:56
>> *To:* ops4j@googlegroups.com
>> *Subject:* Re: [REGISTER] Joining ops4j1.jira.com and discussing feature
>> request
>>
>>
>>
>> Hi,
>>
>> Did you already request an id on Jira ?
>>
>>
>>
>> Regards
>>
>> JB
>>
>>
>>
>> On 06/20/2017 11:50 AM, Lukasz Lech wrote:
>>
>> Hello,
>>
>>
>>
>> I’d like to join https://ops4j1.jira.com and as the message states, I
>> need to apply here to register.
>>
>>
>>
>> The background is the problem with pax-web behavior of creating separate
>> HttpContext for  each bundle when createDefaultHttpContext() is called.
>>
>> I’d like to be able to change that behavior in config file, so that the
>> shared http context instance would be returned.
>>
>>
>>
>> WebContainer interface has a method for that, but quite obviously, only
>> non-agnostic instances can call that method. In my case, I have
>> JaxRS-Publisher that is agnostic and uses only methods exposed in
>> HttpService.
>>
>>
>>
>> The eclipse jetty bundle (org.eclipse.equinox.http.servlet) does that by 
>> default.
>>
>>
>>
>> I understand the reasons for each bundle having separate HttpContext, but 
>> both solutions have their pros, and it should be the architect that decides 
>> which way to choose.
>>
>>
>>
>> Best Regards,
>>
>> Lukasz Lech
>>
>> --
>> --
>> --
>> 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.
>>
>
>
>
> --
>
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 
>
> Software Architect / Project Manager / Scrum Master
>
>


-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

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 

Re: [REGISTER] Joining ops4j1.jira.com and discussing feature request

2017-06-20 Thread Jean-Baptiste Onofré

Hi,

We can create your account, just need your preferred ID.

Regards
JB


On 06/20/2017 12:06 PM, Lukasz Lech wrote:


I’ve registerd in Attlassian, and then I’ve got the message when I logged in 
and went to ops4j1:


Due to increased SPAM and fake accounts, the self-registration has been 
disabled. Sorry for the inconvenience.

Contact the OPS4J General list to have an account created.

*From:*ops4j@googlegroups.com [mailto:ops4j@googlegroups.com] *On Behalf Of 
*Jean-Baptiste Onofré

*Sent:* Dienstag, 20. Juni 2017 11:56
*To:* ops4j@googlegroups.com
*Subject:* Re: [REGISTER] Joining ops4j1.jira.com and discussing feature request

Hi,

Did you already request an id on Jira ?

Regards

JB

On 06/20/2017 11:50 AM, Lukasz Lech wrote:

Hello,

I’d like to join https://ops4j1.jira.com  and as
the message states, I need to apply here to register.

The background is the problem with pax-web behavior of creating separate
HttpContext for  each bundle when createDefaultHttpContext() is called.

I’d like to be able to change that behavior in config file, so that the
shared http context instance would be returned.

WebContainer interface has a method for that, but quite obviously, only
non-agnostic instances can call that method. In my case, I have
JaxRS-Publisher that is agnostic and uses only methods exposed in
HttpService.

The eclipse jetty bundle (org.eclipse.equinox.http.servlet) does that by
default.

I understand the reasons for each bundle having separate HttpContext, but
both solutions have their pros, and it should be the architect that
decides which way to choose.

Best Regards,

Lukasz Lech

-- 
-- 
--

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.


RE: [REGISTER] Joining ops4j1.jira.com and discussing feature request

2017-06-20 Thread Lukasz Lech
I’ve registerd in Attlassian, and then I’ve got the message when I logged in 
and went to ops4j1:

Due to increased SPAM and fake accounts, the self-registration has been 
disabled. Sorry for the inconvenience.
Contact the OPS4J General list to have an account created.

From: ops4j@googlegroups.com [mailto:ops4j@googlegroups.com] On Behalf Of 
Jean-Baptiste Onofré
Sent: Dienstag, 20. Juni 2017 11:56
To: ops4j@googlegroups.com
Subject: Re: [REGISTER] Joining ops4j1.jira.com and discussing feature request


Hi,

Did you already request an id on Jira ?



Regards

JB

On 06/20/2017 11:50 AM, Lukasz Lech wrote:
Hello,

I’d like to join https://ops4j1.jira.com and as the message states, I need to 
apply here to register.

The background is the problem with pax-web behavior of creating separate 
HttpContext for  each bundle when createDefaultHttpContext() is called.
I’d like to be able to change that behavior in config file, so that the shared 
http context instance would be returned.

WebContainer interface has a method for that, but quite obviously, only 
non-agnostic instances can call that method. In my case, I have JaxRS-Publisher 
that is agnostic and uses only methods exposed in HttpService.


The eclipse jetty bundle (org.eclipse.equinox.http.servlet) does that by 
default.



I understand the reasons for each bundle having separate HttpContext, but both 
solutions have their pros, and it should be the architect that decides which 
way to choose.



Best Regards,

Lukasz Lech
--
--
--
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: [REGISTER] Joining ops4j1.jira.com and discussing feature request

2017-06-20 Thread Jean-Baptiste Onofré

Hi,

Did you already request an id on Jira ?


Regards

JB


On 06/20/2017 11:50 AM, Lukasz Lech wrote:


Hello,

I’d like to join https://ops4j1.jira.com  and as the 
message states, I need to apply here to register.


The background is the problem with pax-web behavior of creating separate 
HttpContext for  each bundle when createDefaultHttpContext() is called.


I’d like to be able to change that behavior in config file, so that the shared 
http context instance would be returned.


WebContainer interface has a method for that, but quite obviously, only 
non-agnostic instances can call that method. In my case, I have 
JaxRS-Publisher that is agnostic and uses only methods exposed in HttpService.


The eclipse jetty bundle (org.eclipse.equinox.http.servlet) does that by 
default.
I understand the reasons for each bundle having separate HttpContext, but both 
solutions have their pros, and it should be the architect that decides which 
way to choose.

Best Regards,
Lukasz Lech
--
--
--
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.


[REGISTER] Joining ops4j1.jira.com and discussing feature request

2017-06-20 Thread Lukasz Lech
Hello,

I'd like to join https://ops4j1.jira.com and as the message states, I need to 
apply here to register.

The background is the problem with pax-web behavior of creating separate 
HttpContext for  each bundle when createDefaultHttpContext() is called.
I'd like to be able to change that behavior in config file, so that the shared 
http context instance would be returned.

WebContainer interface has a method for that, but quite obviously, only 
non-agnostic instances can call that method. In my case, I have JaxRS-Publisher 
that is agnostic and uses only methods exposed in HttpService.


The eclipse jetty bundle (org.eclipse.equinox.http.servlet) does that by 
default.



I understand the reasons for each bundle having separate HttpContext, but both 
solutions have their pros, and it should be the architect that decides which 
way to choose.



Best Regards,

Lukasz Lech

-- 
-- 
--
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: [PROPOSAL] New pax project 'transx'

2017-06-20 Thread 'Christoph Läubrich' via OPS4J
I already started https://github.com/ops4j/org.ops4j.pax.jms for JMS a 
while ago so you are maybe interested in adding the pooling-feature 
there also?


In fact pooling and recovery can be nicly integrated into OSGi using the 
service factory, so a switch over would be simply register/unregister a 
service with a new underlying connection, pooling can be done with 
ServiceFactorys that share a fixed set of connections. Just don't know 
if this works well with XA


Am 15.06.2017 09:57, schrieb Guillaume Nodet:
I began to work on a small project which aims at providing support for 
pooled XA-enabled connections for JDBC and JMS.


For JDBC, the problem was already solved in pax-jdbc by using either 
pax-jdbc-pool-aries when deploying the Aries/Geronimo transaction 
manager, and by using pax-jdbc-pool-narayana when using the Narayana 
transaction manager.


However, there's absolutely no support for JMS.

So what I've been doing is to reuse the geronimo JCA connector, make 
it independent on Geronimo TM and add support for Narayana, use a 
clone of the old tranql adapter for JDBC and rewrite a new JMS 2.0 
compatible adapter for JMS.


It's not in a usable state yet, but I wanted to give an heads-up.
My plan is to make the pooling almost transparent in OSGi, and reuse 
it instead of the connection pooling I added to Karaf a few weeks ago 
which does not support XA or recovery:

https://github.com/apache/karaf/tree/master/jms/pool
and maybe to plug it into pax-jdbc to replace pax-jdbc-pool-aries and 
pax-jdbc-pool-narayana.


The source code is currently available at:
https://github.com/gnodet/org.ops4j.pax.transx


Cheers,
--

Guillaume Nodet

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

---
You received this message because you are subscribed to the Google 
Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to ops4j+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
--
--
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 Wicket 4 (moving to wicket 8)

2017-06-20 Thread 'Christoph Läubrich' via OPS4J
As long as there are no API-breaks within Pax-Wicket it doesen't matter, 
client-code has to choose of course if the want 7 or 8, but I can only 
check this if Wicket adds OSGi-Headers, so sign up at the Wicket JIRA 
and vote for the issue ;-)


Am 19.06.2017 20:44, schrieb nino martinez wael:

Ahh I see most of the changes where from 6.x to 7.x..

But what about the Websocket stuff, as I remember it has been changed 
alot in Wicket 8..?


On Mon, Jun 19, 2017 at 2:55 PM, 'Christoph Läubrich' via OPS4J 
> wrote:


I opened a bug to Wicket 8:
https://issues.apache.org/jira/browse/WICKET-6402
 it seems they
lost the OSGi Manifest information in Wicket 8 what is bad. Beside
thsi there seem no API changes that influence Pax-Wicket so once
Wicket 8 is release we can raise the version range instead of
supply a 5.0 version, pax-wicket 4 will the support Wicket 7 +
Wicket 8!



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