btw, the tag is already uploaded for some hours now (if you cant wait
for the m2 version and want to use it locally). I'll send the official
release mails once the artifacts reach m2 central.

Kind regards,
Andreas

On Wed, Oct 24, 2012 at 8:44 AM, Bram Pouwelse <b...@pouwelse.com> wrote:
> Thanks
>
> 2012/10/23 Andreas Pieber <anpie...@gmail.com>:
>> well, then I start the release. at least all my tests doesnt show up
>> any problems... and this looks at least better than it was before...
>> I'll notify via this list once the release had been done
>>
>> kind regards,
>> Andreas
>>
>> On Tue, Oct 23, 2012 at 8:27 PM, Achim Nierbeck <bcanh...@googlemail.com> 
>> wrote:
>>> Yep, that should do it, at least that's the part I tested
>>>
>>> a long running test in the coming week will show how good :-)
>>>
>>> regards, Achim
>>>
>>> 2012/10/23 Andreas Pieber <anpie...@gmail.com>:
>>>> OK, this [1] should do it. WDYT? Out with it?
>>>>
>>>> Kind regards,
>>>> Andreas
>>>>
>>>> [1] 
>>>> https://github.com/ops4j/org.ops4j.pax.wicket/commit/a2a103355e6c480864dcf1bd748b197fe695b0db
>>>>
>>>> On Tue, Oct 23, 2012 at 7:16 PM, Bram Pouwelse <b...@pouwelse.com> wrote:
>>>>> Hi Andreas,
>>>>>
>>>>> The fix seems to work, the only concern I have is that this may cause
>>>>> exceptions in a case where a custom property is set on the application
>>>>> in the application factory. This property would not be set by Pax
>>>>> Wicket when the "enhanced" version of the application is created.  But
>>>>> even without the fix this would cause some unexpected behaviour.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Kind regards,
>>>>> Bram
>>>>>
>>>>>
>>>>> 2012/10/23 Andreas Pieber <anpie...@gmail.com>:
>>>>>> perfect! I just want to get a second feedback from Bram. If he also
>>>>>> confirms the trick working I'll commit and release PaxWicket 1.1.1
>>>>>> tonight.
>>>>>>
>>>>>> Thank you very much for discovering and testing this one!
>>>>>>
>>>>>> Kind regards,
>>>>>> Andreas
>>>>>>
>>>>>> On Tue, Oct 23, 2012 at 5:03 PM, Achim Nierbeck 
>>>>>> <bcanh...@googlemail.com> wrote:
>>>>>>> Hi Guys,
>>>>>>>
>>>>>>> I changed it according to the idea of Bram,
>>>>>>> and tested it with my application that was consuming far to much
>>>>>>> memory (reproducable).
>>>>>>> It's now stable below 300 MB of Heap.
>>>>>>>
>>>>>>> @Bram thanks for pointing to this, this really safed my day :-D
>>>>>>>
>>>>>>> regards, Achim
>>>>>>>
>>>>>>> 2012/10/23 Achim Nierbeck <bcanh...@googlemail.com>:
>>>>>>>> Hi Andreas,
>>>>>>>>
>>>>>>>> I did change this locally and I'm testing it right now.
>>>>>>>> Will give feedback later ...
>>>>>>>>
>>>>>>>> regards, Achim
>>>>>>>>
>>>>>>>> 2012/10/23 Andreas Pieber <anpie...@gmail.com>:
>>>>>>>>> Well, I can commit your proposed changes, but you would still have to 
>>>>>>>>> build
>>>>>>>>> pax wicket locally and use the snapshots. When you confirm that the 
>>>>>>>>> problem
>>>>>>>>> I really fixed I can push a release to Central within a Max of 8 
>>>>>>>>> hours...
>>>>>>>>>
>>>>>>>>> Let me know of I can help you in any way.
>>>>>>>>>
>>>>>>>>> Kind regards, Andreas
>>>>>>>>>
>>>>>>>>> On Oct 22, 2012 6:23 PM, "Bram Pouwelse" <b...@pouwelse.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Andreas,
>>>>>>>>>>
>>>>>>>>>> I've looked at the PropertyResolver at line 1447 a key is determined
>>>>>>>>>> to use in a ConcurrentHashMap [1]. This key is the application
>>>>>>>>>> returned by getApplication() after some testing I found out that
>>>>>>>>>> equals on application doesn't work by putting
>>>>>>>>>> getApplication().equals(getApplication())  in a sample application.
>>>>>>>>>>
>>>>>>>>>> If I remove the special case for equals, hashCode and toString from
>>>>>>>>>> the intercept method [2]  getApplication().equals(getApplication())
>>>>>>>>>> returns true as I would expect. I've created a similar HashMap in my
>>>>>>>>>> test application and a map with Application as a key seems to work
>>>>>>>>>> after the change. Didn't have a chance to do any real world test with
>>>>>>>>>> this.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Bram
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/core/util/lang/PropertyResolver.java#L1447
>>>>>>>>>> [2]
>>>>>>>>>> https://github.com/ops4j/org.ops4j.pax.wicket/blob/master/service/src/main/java/org/ops4j/pax/wicket/internal/PaxWicketApplicationFactory.java#L115
>>>>>>>>>>
>>>>>>>>>> 2012/10/22 Andreas Pieber <anpie...@gmail.com>:
>>>>>>>>>> > well, it's quite possible that the CG lib does some quircks here. 
>>>>>>>>>> > Has
>>>>>>>>>> > anyone already tried to set breakpoints into the PropertyResolver 
>>>>>>>>>> > [1]
>>>>>>>>>> > checking what's exactly the problem? I'll start tomorrow morning by
>>>>>>>>>> > doing exactly this...
>>>>>>>>>> >
>>>>>>>>>> > If getApplication().equals(getApplication()) is really the problem
>>>>>>>>>> > (where did you find that code btw?) I might find a workaround for 
>>>>>>>>>> > that
>>>>>>>>>> > case... let's see to nail down the problem first.
>>>>>>>>>> >
>>>>>>>>>> > Kind regards,
>>>>>>>>>> > Andreas
>>>>>>>>>> >
>>>>>>>>>> > [1]
>>>>>>>>>> > https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/core/util/lang/PropertyResolver.java
>>>>>>>>>> >
>>>>>>>>>> > On Mon, Oct 22, 2012 at 5:07 PM, Achim Nierbeck
>>>>>>>>>> > <bcanh...@googlemail.com> wrote:
>>>>>>>>>> >> Oh, one more,
>>>>>>>>>> >>
>>>>>>>>>> >> after running a Component Report i got the following info about 
>>>>>>>>>> >> it:
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> Empty Collections
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> Detected the following empty collections:
>>>>>>>>>> >> •6.482.518 instances of 
>>>>>>>>>> >> java.util.concurrent.ConcurrentHashMap$Segment
>>>>>>>>>> >> retain >= 829.762.448 bytes.
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>  Collection Fill Ratios
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> Detected the following collections with fill ratios below 20%:
>>>>>>>>>> >> •432.156 instances of java.util.concurrent.ConcurrentHashMap 
>>>>>>>>>> >> retain >=
>>>>>>>>>> >> 1.018.329.768 bytes.
>>>>>>>>>> >>
>>>>>>>>>> >> Map Collision Ratios
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> Detected the following maps with collision ratios above 80%:
>>>>>>>>>> >> •1 instances of java.util.concurrent.ConcurrentHashMap retain
>>>>>>>>>> >> 1.038.046.920 bytes.
>>>>>>>>>> >> •1 instances of java.util.concurrent.ConcurrentHashMap$Segment 
>>>>>>>>>> >> retain
>>>>>>>>>> >> 296 bytes.
>>>>>>>>>> >>
>>>>>>>>>> >> I haven't found the root cause of it, but somehow I have the
>>>>>>>>>> >> impression this might be an issue of Pax-Wicket?
>>>>>>>>>> >>
>>>>>>>>>> >> btw. I'm using Pax-Wicket in Version 1.0.2
>>>>>>>>>> >>
>>>>>>>>>> >> regards, Achim
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> 2012/10/22 Achim Nierbeck <bcanh...@googlemail.com>:
>>>>>>>>>> >>> Here a little update to this, cause today my application did run 
>>>>>>>>>> >>> into
>>>>>>>>>> >>> an OOM due to this (with 1GB Heap)
>>>>>>>>>> >>> The current HeapDump shows me
>>>>>>>>>> >>>
>>>>>>>>>> >>> That the wicket PropertyResolver uses about 1GB Ram, from those 
>>>>>>>>>> >>> are
>>>>>>>>>> >>> about 62MB for
>>>>>>>>>> >>>
>>>>>>>>>> >>>
>>>>>>>>>> >>> ------------------------------------------------------------------------------------------------------------------
>>>>>>>>>> >>> ref
>>>>>>>>>> >>> |CGLIB$CALLBACK_0|org.ops4j.pax.wicket.internal.PaxWicketApplicationFactory$WebApplicationWrapper
>>>>>>>>>> >>> @ 0xf2b693d0
>>>>>>>>>> >>>
>>>>>>>>>> >>> ------------------------------------------------------------------------------------------------------------------
>>>>>>>>>> >>>
>>>>>>>>>> >>> I guess those are basically the session, looks OK right now.
>>>>>>>>>> >>> But the rest is consumed by about 260000 ConcurrentHashMap 
>>>>>>>>>> >>> Entries.
>>>>>>>>>> >>>
>>>>>>>>>> >>> For example:
>>>>>>>>>> >>>
>>>>>>>>>> >>> Type|Name            |Value
>>>>>>>>>> >>>
>>>>>>>>>> >>> ------------------------------------------------------------------------------------------------------------------
>>>>>>>>>> >>> ref
>>>>>>>>>> >>> |CGLIB$CALLBACK_0|org.ops4j.pax.wicket.internal.PaxWicketApplicationFactory$WebApplicationWrapper
>>>>>>>>>> >>> @ 0xc1fa0250
>>>>>>>>>> >>>
>>>>>>>>>> >>> ------------------------------------------------------------------------------------------------------------------
>>>>>>>>>> >>>
>>>>>>>>>> >>> I don't know how to say this, but it seems awfully wrong right 
>>>>>>>>>> >>> now ...
>>>>>>>>>> >>>
>>>>>>>>>> >>> regards, Achim
>>>>>>>>>> >>>
>>>>>>>>>> >>> 2012/10/22 Achim Nierbeck <bcanh...@googlemail.com>:
>>>>>>>>>> >>>> Hi,
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> I've seen the exact thing but didn't have the time (yet) to get 
>>>>>>>>>> >>>> a
>>>>>>>>>> >>>> hold of it.
>>>>>>>>>> >>>> But since it's mostly Wicket classes involved I had the 
>>>>>>>>>> >>>> impression
>>>>>>>>>> >>>> it's wicket itself
>>>>>>>>>> >>>> that does this.
>>>>>>>>>> >>>> To prove something like it, I wanted to create an example which 
>>>>>>>>>> >>>> would
>>>>>>>>>> >>>> work
>>>>>>>>>> >>>> in both world (pax-wicket and wicket) but due to lack of time I
>>>>>>>>>> >>>> wasn't able to
>>>>>>>>>> >>>> get to it.
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> But since I'm not the only one I'd guess this is something 
>>>>>>>>>> >>>> worthy to
>>>>>>>>>> >>>> investigate :)
>>>>>>>>>> >>>> My next test would have been to switch to Wicket 6 (pax-wicket 
>>>>>>>>>> >>>> 2.0)
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> regards, Achim
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> 2012/10/22 Bram Pouwelse <b...@pouwelse.com>:
>>>>>>>>>> >>>>> Hi,
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> I'm working on an application that's using Pax Wicket (version
>>>>>>>>>> >>>>> 1.1.0).
>>>>>>>>>> >>>>> Because the application is using more memory than expected I'm
>>>>>>>>>> >>>>> running
>>>>>>>>>> >>>>> some tests and analysing heap dumps for a few days now.
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> While analysing the heap of my "weekend test" I've found this 
>>>>>>>>>> >>>>> at the
>>>>>>>>>> >>>>> top of the Pax Wicket bundle class loader at the top of the
>>>>>>>>>> >>>>> dominator
>>>>>>>>>> >>>>> tree, seems to me that the PropertyResolver is creating new
>>>>>>>>>> >>>>> DefaultClassCache instances all the time but I don't 
>>>>>>>>>> >>>>> understand why.
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Below I've pasted a few selections from Eclipse Memory 
>>>>>>>>>> >>>>> Analyzer:
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Dominator tree:
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Class Name
>>>>>>>>>> >>>>>                                   | Shallow Heap | Retained 
>>>>>>>>>> >>>>> Heap |
>>>>>>>>>> >>>>> Percentage
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> -----------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>>>>>> >>>>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5
>>>>>>>>>> >>>>>  @
>>>>>>>>>> >>>>> 0xc123ee58                          |           88 |   
>>>>>>>>>> >>>>> 643,602,288 |
>>>>>>>>>> >>>>>   89.39%
>>>>>>>>>> >>>>> |- java.util.Vector @ 0xc1252208
>>>>>>>>>> >>>>>                                   |           32 |   
>>>>>>>>>> >>>>> 643,566,800 |
>>>>>>>>>> >>>>> 89.38%
>>>>>>>>>> >>>>> |  '- java.lang.Object[1280] @ 0xc2445ee8
>>>>>>>>>> >>>>>                                   |        5,136 |   
>>>>>>>>>> >>>>> 643,566,768 |
>>>>>>>>>> >>>>> 89.38%
>>>>>>>>>> >>>>> |     |- class org.apache.wicket.util.lang.PropertyResolver @
>>>>>>>>>> >>>>> 0xb9b5d330                                 |           32 |
>>>>>>>>>> >>>>> 643,420,472 |     89.36% *
>>>>>>>>>> >>>>> |     |  '- java.util.concurrent.ConcurrentHashMap @ 0xc2962bf8
>>>>>>>>>> >>>>>                                   |           48 |   
>>>>>>>>>> >>>>> 643,420,440 |
>>>>>>>>>> >>>>> 89.36%
>>>>>>>>>> >>>>> |     |     '- 
>>>>>>>>>> >>>>> java.util.concurrent.ConcurrentHashMap$Segment[16] @
>>>>>>>>>> >>>>> 0xc2962c28                           |           80 |   
>>>>>>>>>> >>>>> 643,420,392
>>>>>>>>>> >>>>> |
>>>>>>>>>> >>>>>    89.36%
>>>>>>>>>> >>>>> |     |        |- 
>>>>>>>>>> >>>>> java.util.concurrent.ConcurrentHashMap$Segment @
>>>>>>>>>> >>>>> 0xc2963098                            |           40 |   
>>>>>>>>>> >>>>> 643,418,872
>>>>>>>>>> >>>>> |
>>>>>>>>>> >>>>>     89.36% **
>>>>>>>>>> >>>>> |     |        |  |-
>>>>>>>>>> >>>>> java.util.concurrent.ConcurrentHashMap$HashEntry[262144] @
>>>>>>>>>> >>>>> 0xd8674190
>>>>>>>>>> >>>>>              |    1,048,592 |   643,418,768 |     89.36%
>>>>>>>>>> >>>>> |     |        |  |  '-
>>>>>>>>>> >>>>> java.util.concurrent.ConcurrentHashMap$HashEntry @ 0xea9687a8
>>>>>>>>>> >>>>>           |           32 |   642,370,176 |     89.22%
>>>>>>>>>> >>>>> |     |        |  |     |-
>>>>>>>>>> >>>>> java.util.concurrent.ConcurrentHashMap$HashEntry @ 0xea967a28
>>>>>>>>>> >>>>>        |           32 |   642,366,720 |     89.22%
>>>>>>>>>> >>>>> |     |        |  |     |  |-
>>>>>>>>>> >>>>> java.util.concurrent.ConcurrentHashMap$HashEntry @ 0xea966ca8
>>>>>>>>>> >>>>>     |           32 |   642,363,264 |     89.22% ***
>>>>>>>>>> >>>>> |     |        |  |     |  |-
>>>>>>>>>> >>>>> org.apache.wicket.util.lang.PropertyResolver$DefaultClassCache 
>>>>>>>>>> >>>>> @
>>>>>>>>>> >>>>> 0xea967398|           16 |         3,424 |      0.00%
>>>>>>>>>> >>>>> |     |        |  |     |  '- Total: 2 entries
>>>>>>>>>> >>>>>                                   |              |             
>>>>>>>>>> >>>>>   |
>>>>>>>>>> >>>>> |     |        |  |     |-
>>>>>>>>>> >>>>> org.apache.wicket.util.lang.PropertyResolver$DefaultClassCache 
>>>>>>>>>> >>>>> @
>>>>>>>>>> >>>>> 0xea968118   |           16 |         3,424 |      0.00%
>>>>>>>>>> >>>>> |     |        |  |     '- Total: 2 entries
>>>>>>>>>> >>>>>                                   |              |             
>>>>>>>>>> >>>>>   |
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> -----------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> * class org.apache.wicket.util.lang.PropertyResolver @ 
>>>>>>>>>> >>>>> 0xb9b5d330
>>>>>>>>>> >>>>> [statics]:
>>>>>>>>>> >>>>> Type|Name                               |Value
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> ---------------------------------------------------------------------------------------------
>>>>>>>>>> >>>>> ref |SET                                |set
>>>>>>>>>> >>>>> ref |IS                                 |is
>>>>>>>>>> >>>>> ref |GET                                |get
>>>>>>>>>> >>>>> ref
>>>>>>>>>> >>>>> |applicationToClassesToGetAndSetters|java.util.concurrent.ConcurrentHashMap
>>>>>>>>>> >>>>> @ 0xc2962bf8
>>>>>>>>>> >>>>> int |RESOLVE_CLASS                      |2
>>>>>>>>>> >>>>> int |CREATE_NEW_VALUE                   |1
>>>>>>>>>> >>>>> int |RETURN_NULL                        |0
>>>>>>>>>> >>>>> ref |log
>>>>>>>>>> >>>>> |org.ops4j.pax.logging.slf4j.Slf4jLogger @ 0xc2972ba0
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> ---------------------------------------------------------------------------------------------
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> ** java.util.concurrent.ConcurrentHashMap$HashEntry[262144] @
>>>>>>>>>> >>>>> 0xd8674190 [attributes]
>>>>>>>>>> >>>>> Type |Name      |Value
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> --------------------------------------------------------------------------------------
>>>>>>>>>> >>>>> float|loadFactor|0.75
>>>>>>>>>> >>>>> ref  |table
>>>>>>>>>> >>>>> |java.util.concurrent.ConcurrentHashMap$HashEntry[262144] @
>>>>>>>>>> >>>>> 0xd8674190
>>>>>>>>>> >>>>> int  |threshold |196608
>>>>>>>>>> >>>>> int  |modCount  |185871
>>>>>>>>>> >>>>> int  |count     |185871
>>>>>>>>>> >>>>> ref  |sync
>>>>>>>>>> >>>>> |java.util.concurrent.locks.ReentrantLock$NonfairSync
>>>>>>>>>> >>>>> @ 0xc29630c0
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> --------------------------------------------------------------------------------------
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> *** java.util.concurrent.ConcurrentHashMap$HashEntry @ 
>>>>>>>>>> >>>>> 0xea966ca8
>>>>>>>>>> >>>>> [attributes]
>>>>>>>>>> >>>>> Type|Name |Value
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> ---------------------------------------------------------------------------------------------------
>>>>>>>>>> >>>>> ref |next |java.util.concurrent.ConcurrentHashMap$HashEntry @
>>>>>>>>>> >>>>> 0xea965f28
>>>>>>>>>> >>>>> ref
>>>>>>>>>> >>>>> |value|org.apache.wicket.util.lang.PropertyResolver$DefaultClassCache
>>>>>>>>>> >>>>> @ 0xea966618
>>>>>>>>>> >>>>> int |hash |1234246985
>>>>>>>>>> >>>>> ref |key
>>>>>>>>>> >>>>> |nl.ditp.fabuland.core.internal.WicketApplication$$EnhancerByCGLIB$$4188d86a
>>>>>>>>>> >>>>> @ 0xc22bcc88
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> ---------------------------------------------------------------------------------------------------
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Is this caused by a coding error in the application or a bug in
>>>>>>>>>> >>>>> Wicket
>>>>>>>>>> >>>>> / Pax Wicket?
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Thanks,
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Bram Pouwelse
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> _______________________________________________
>>>>>>>>>> >>>>> general mailing list
>>>>>>>>>> >>>>> general@lists.ops4j.org
>>>>>>>>>> >>>>> http://lists.ops4j.org/mailman/listinfo/general
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> --
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>>>>> >>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>>>>> >>>> Committer & Project Lead
>>>>>>>>>> >>>> OPS4J Pax for Vaadin
>>>>>>>>>> >>>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter &
>>>>>>>>>> >>>> Project
>>>>>>>>>> >>>> Lead
>>>>>>>>>> >>>> blog <http://notizblog.nierbeck.de/>
>>>>>>>>>> >>>
>>>>>>>>>> >>>
>>>>>>>>>> >>>
>>>>>>>>>> >>> --
>>>>>>>>>> >>>
>>>>>>>>>> >>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>>>>> >>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>>>>> >>> Committer & Project Lead
>>>>>>>>>> >>> OPS4J Pax for Vaadin
>>>>>>>>>> >>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & 
>>>>>>>>>> >>> Project
>>>>>>>>>> >>> Lead
>>>>>>>>>> >>> blog <http://notizblog.nierbeck.de/>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> --
>>>>>>>>>> >>
>>>>>>>>>> >> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>>>>> >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>>>>> >> Committer & Project Lead
>>>>>>>>>> >> OPS4J Pax for Vaadin
>>>>>>>>>> >> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & 
>>>>>>>>>> >> Project
>>>>>>>>>> >> Lead
>>>>>>>>>> >> blog <http://notizblog.nierbeck.de/>
>>>>>>>>>> >>
>>>>>>>>>> >> _______________________________________________
>>>>>>>>>> >> general mailing list
>>>>>>>>>> >> general@lists.ops4j.org
>>>>>>>>>> >> http://lists.ops4j.org/mailman/listinfo/general
>>>>>>>>>> >
>>>>>>>>>> > _______________________________________________
>>>>>>>>>> > general mailing list
>>>>>>>>>> > general@lists.ops4j.org
>>>>>>>>>> > http://lists.ops4j.org/mailman/listinfo/general
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> general mailing list
>>>>>>>>>> general@lists.ops4j.org
>>>>>>>>>> http://lists.ops4j.org/mailman/listinfo/general
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> general mailing list
>>>>>>>>> general@lists.ops4j.org
>>>>>>>>> http://lists.ops4j.org/mailman/listinfo/general
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>>> Committer & Project Lead
>>>>>>>> OPS4J Pax for Vaadin
>>>>>>>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
>>>>>>>> Lead
>>>>>>>> blog <http://notizblog.nierbeck.de/>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>> Committer & Project Lead
>>>>>>> OPS4J Pax for Vaadin
>>>>>>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
>>>>>>> Lead
>>>>>>> blog <http://notizblog.nierbeck.de/>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> general mailing list
>>>>>>> general@lists.ops4j.org
>>>>>>> http://lists.ops4j.org/mailman/listinfo/general
>>>>>>
>>>>>> _______________________________________________
>>>>>> general mailing list
>>>>>> general@lists.ops4j.org
>>>>>> http://lists.ops4j.org/mailman/listinfo/general
>>>>>
>>>>> _______________________________________________
>>>>> general mailing list
>>>>> general@lists.ops4j.org
>>>>> http://lists.ops4j.org/mailman/listinfo/general
>>>>
>>>> _______________________________________________
>>>> general mailing list
>>>> general@lists.ops4j.org
>>>> http://lists.ops4j.org/mailman/listinfo/general
>>>
>>>
>>>
>>> --
>>>
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>> Committer & Project Lead
>>> OPS4J Pax for Vaadin
>>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
>>> Lead
>>> blog <http://notizblog.nierbeck.de/>
>>>
>>> _______________________________________________
>>> general mailing list
>>> general@lists.ops4j.org
>>> http://lists.ops4j.org/mailman/listinfo/general
>>
>> _______________________________________________
>> general mailing list
>> general@lists.ops4j.org
>> http://lists.ops4j.org/mailman/listinfo/general
>
> _______________________________________________
> general mailing list
> general@lists.ops4j.org
> http://lists.ops4j.org/mailman/listinfo/general

_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general

Reply via email to