from:"Joseph Bergmark"

Re: Build failed in Jenkins: OpenWebBeans » OpenWebBeans-trunk #38

2021-07-19 Thread Joseph Bergmark

I missed that there was a second build that needed to have its maven
version changed to 3.6.3.  I've gone ahead and made that change here as
well.

Just as before I don't think this is the right long term fix, but last I
looked I couldn't find where that repository was specified to update it to
https.

On Mon, Jul 19, 2021 at 7:02 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://ci-builds.apache.org/job/OpenWebBeans/job/OpenWebBeans-trunk/38/display/redirect?page=changes
> >
>
> Changes:
>
> [github] Improve handling of lineSeparator in ViolationMessageBuilder
>
>
> --
> [...truncated 687.77 KB...]
> at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)
> at
> hudson.maven.AbstractMavenBuilder.waitForAsynchronousExecutions(AbstractMavenBuilder.java:186)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:144)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:70)
> at hudson.remoting.UserRequest.perform(UserRequest.java:211)
> at hudson.remoting.UserRequest.perform(UserRequest.java:54)
> at hudson.remoting.Request$2.run(Request.java:375)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:73)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> ERROR: Asynchronous execution failure
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at hudson.remoting.Channel$2.adapt(Channel.java:1039)
> at hudson.remoting.Channel$2.adapt(Channel.java:1033)
> at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)
> at
> hudson.maven.AbstractMavenBuilder.waitForAsynchronousExecutions(AbstractMavenBuilder.java:186)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:144)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:70)
> at hudson.remoting.UserRequest.perform(UserRequest.java:211)
> at hudson.remoting.UserRequest.perform(UserRequest.java:54)
> at hudson.remoting.Request$2.run(Request.java:375)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:73)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> ERROR: Asynchronous execution failure
> java.util.concurrent.ExecutionException: java.io.IOException: Unexpected
> Fingerprint type. Expected class hudson.model.Fingerprint or subclass but
> got class hudson.model.Fingerprint$RangeSet
> at hudson.remoting.Channel$2.adapt(Channel.java:1039)
> at hudson.remoting.Channel$2.adapt(Channel.java:1033)
> at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)
> at
> hudson.maven.AbstractMavenBuilder.waitForAsynchronousExecutions(AbstractMavenBuilder.java:186)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:144)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:70)
> at hudson.remoting.UserRequest.perform(UserRequest.java:211)
> at hudson.remoting.UserRequest.perform(UserRequest.java:54)
> at hudson.remoting.Request$2.run(Request.java:375)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:73)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Unexpected Fingerprint type. Expected
> class hudson.model.Fingerprint or subclass but got class
> hudson.model.Fingerprint$RangeSet
> at
> jenkins.fingerprints.FileFingerprintStorage.load(FileFingerprintStorage.java:98)
> at
> jenkins.fingerprints.FileFingerprintStorage.load(FileFingerprintStorage.java:82)
> at hudson.model.Fingerprint.load(Fingerprint.java:1357)
> at hudson.model.FingerprintMap.load(FingerprintMap.java:90)
> at hudson.model.FingerprintMap.load(FingerprintMap.java:47)
> at hudson.util.KeyedDataStorage.get(KeyedDataStorage.java:161)
> at hudson.model.FingerprintMap.get(FingerprintMap.java:82)
> at hudson.model.FingerprintMap.get(FingerprintMap.java:47)
> at
>

Re: Build failed in Jenkins: OpenWebBeans » OpenWebBeans-trunk-deploy #35

2021-07-05 Thread Joseph Bergmark

That seemed to work around the issue for now, but should probably be
changed back.  I couldn't figure out where the
http://repository.jboss.org/nexus/content/groups/public repository was
specified to change it to https.  Might there be some global settings.xml
configuration shared across projects?

On Mon, Jul 5, 2021 at 3:12 PM Joseph Bergmark  wrote:

> To test this theory I've reconfigured the build to use maven 3.6.3 rather
> than maven_latest (probably 3.8.1?).  This isn't the right long term fix,
> but wanted to quickly check if that was in fact that cause of the error.
>
> On Mon, Jul 5, 2021 at 2:30 PM Joseph Bergmark  wrote:
>
>> I think the key part of the error is:
>>
>> [ERROR] Failed to execute goal on project openwebbeans-tck: Could not
>> resolve dependencies for project
>> org.apache.openwebbeans:openwebbeans-tck:jar:2.0.24-SNAPSHOT: Failed to
>> collect dependencies at org.jboss.cdi.tck:cdi-tck-impl:jar:2.0.3.Final ->
>> org.jboss.test-audit:jboss-test-audit-impl:jar:1.1.4.Final: Failed to read
>> artifact descriptor for
>> org.jboss.test-audit:jboss-test-audit-impl:jar:1.1.4.Final: Could not
>> transfer artifact
>> org.jboss.test-audit:jboss-test-audit-impl:pom:1.1.4.Final from/to
>> maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for
>> repositories: [jboss-public-repository-group (
>> http://repository.jboss.org/nexus/content/groups/public, default,
>> releases)] -> [Help 1]
>>
>> It may have been blocked for being an "http://; URL, rather than
>> "https://;.  This behavior might be dependent upon the version of Maven
>> used.  I don't think it is related to your change at all.
>>
>> On Mon, Jul 5, 2021 at 8:35 AM Arne Limburg <
>> arne.limb...@openknowledge.de> wrote:
>>
>>> Hi,
>>>
>>> since my commit triggered this build, I'll take a look at it, but
>>> actually from the Stacktrace I have no clue about the problem.
>>>
>>> Can anyone help me out?
>>>
>>>
>>> Cheers,
>>>
>>> Arne
>>>
>>>
>>> --
>>>
>>> Arne Limburg - Enterprise Architekt
>>>
>>>
>>>
>>>
>>> OPEN KNOWLEDGE GmbH
>>> Poststraße 1, 26122 Oldenburg
>>> Mobil: +49 151 - 108 22 942
>>> Tel: +49 441 - 4082-154
>>> Fax: +49 441 - 4082-111
>>> arne.limb...@openknowledge.de
>>> www.openknowledge.de <https://www.openknowledge.de/>
>>>
>>> Registergericht: Amtsgericht Oldenburg, HRB 4670
>>> Geschäftsführer: Lars Röwekamp, Jens Schumann
>>>
>>> Treffen Sie uns auf kommenden Konferenzen und Workshops:
>>>
>>> Zu unseren Events<https://www.openknowledge.de/event/>
>>>
>>>
>>>
>>>
>>>
>>> 
>>> Von: Apache Jenkins Server 
>>> Gesendet: Montag, 5. Juli 2021 12:02
>>> An: dev@openwebbeans.apache.org
>>> Betreff: Build failed in Jenkins: OpenWebBeans »
>>> OpenWebBeans-trunk-deploy #35
>>>
>>> See <
>>> https://ci-builds.apache.org/job/OpenWebBeans/job/OpenWebBeans-trunk-deploy/35/display/redirect?page=changes
>>> >
>>>
>>> Changes:
>>>
>>> [Arne Limburg] OWB-1387: Don't throw Lifecycle events for inactive
>>> contexts
>>>
>>>
>>> --
>>> [...truncated 763.94 KB...]
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>> at java.lang.Thread.run(Thread.java:748)
>>> Caused by: java.lang.NullPointerException
>>> ERROR: Asynchronous execution failure
>>> java.util.concurrent.ExecutionException: java.lang.NullPointerException
>>> at hudson.remoting.Channel$2.adapt(Channel.java:1039)
>>> at hudson.remoting.Channel$2.adapt(Channel.java:1033)
>>> at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)
>>> at
>>> hudson.maven.AbstractMavenBuilder.waitForAsynchronousExecutions(AbstractMavenBuilder.java:186)
>>> at hudson.maven.Maven3Builder.call(Maven3Builder.java:144)
>>> at hudson.maven.Maven3Builder.call(Maven3Builder.java:70)
>>> at hudson.remoting.UserRequest.perform(UserRequest.java:211)
>>> at hudson.remoting.UserRequest.perform(UserRequest.java:54)
>>> at hu

Re: Build failed in Jenkins: OpenWebBeans » OpenWebBeans-trunk-deploy #35

2021-07-05 Thread Joseph Bergmark

To test this theory I've reconfigured the build to use maven 3.6.3 rather
than maven_latest (probably 3.8.1?).  This isn't the right long term fix,
but wanted to quickly check if that was in fact that cause of the error.

On Mon, Jul 5, 2021 at 2:30 PM Joseph Bergmark  wrote:

> I think the key part of the error is:
>
> [ERROR] Failed to execute goal on project openwebbeans-tck: Could not
> resolve dependencies for project
> org.apache.openwebbeans:openwebbeans-tck:jar:2.0.24-SNAPSHOT: Failed to
> collect dependencies at org.jboss.cdi.tck:cdi-tck-impl:jar:2.0.3.Final ->
> org.jboss.test-audit:jboss-test-audit-impl:jar:1.1.4.Final: Failed to read
> artifact descriptor for
> org.jboss.test-audit:jboss-test-audit-impl:jar:1.1.4.Final: Could not
> transfer artifact
> org.jboss.test-audit:jboss-test-audit-impl:pom:1.1.4.Final from/to
> maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for
> repositories: [jboss-public-repository-group (
> http://repository.jboss.org/nexus/content/groups/public, default,
> releases)] -> [Help 1]
>
> It may have been blocked for being an "http://; URL, rather than "https://;.
> This behavior might be dependent upon the version of Maven used.  I don't
> think it is related to your change at all.
>
> On Mon, Jul 5, 2021 at 8:35 AM Arne Limburg 
> wrote:
>
>> Hi,
>>
>> since my commit triggered this build, I'll take a look at it, but
>> actually from the Stacktrace I have no clue about the problem.
>>
>> Can anyone help me out?
>>
>>
>> Cheers,
>>
>> Arne
>>
>>
>> --
>>
>> Arne Limburg - Enterprise Architekt
>>
>>
>>
>>
>> OPEN KNOWLEDGE GmbH
>> Poststraße 1, 26122 Oldenburg
>> Mobil: +49 151 - 108 22 942
>> Tel: +49 441 - 4082-154
>> Fax: +49 441 - 4082-111
>> arne.limb...@openknowledge.de
>> www.openknowledge.de <https://www.openknowledge.de/>
>>
>> Registergericht: Amtsgericht Oldenburg, HRB 4670
>> Geschäftsführer: Lars Röwekamp, Jens Schumann
>>
>> Treffen Sie uns auf kommenden Konferenzen und Workshops:
>>
>> Zu unseren Events<https://www.openknowledge.de/event/>
>>
>>
>>
>>
>>
>> 
>> Von: Apache Jenkins Server 
>> Gesendet: Montag, 5. Juli 2021 12:02
>> An: dev@openwebbeans.apache.org
>> Betreff: Build failed in Jenkins: OpenWebBeans »
>> OpenWebBeans-trunk-deploy #35
>>
>> See <
>> https://ci-builds.apache.org/job/OpenWebBeans/job/OpenWebBeans-trunk-deploy/35/display/redirect?page=changes
>> >
>>
>> Changes:
>>
>> [Arne Limburg] OWB-1387: Don't throw Lifecycle events for inactive
>> contexts
>>
>>
>> --
>> [...truncated 763.94 KB...]
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>> at java.lang.Thread.run(Thread.java:748)
>> Caused by: java.lang.NullPointerException
>> ERROR: Asynchronous execution failure
>> java.util.concurrent.ExecutionException: java.lang.NullPointerException
>> at hudson.remoting.Channel$2.adapt(Channel.java:1039)
>> at hudson.remoting.Channel$2.adapt(Channel.java:1033)
>> at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)
>> at
>> hudson.maven.AbstractMavenBuilder.waitForAsynchronousExecutions(AbstractMavenBuilder.java:186)
>> at hudson.maven.Maven3Builder.call(Maven3Builder.java:144)
>> at hudson.maven.Maven3Builder.call(Maven3Builder.java:70)
>> at hudson.remoting.UserRequest.perform(UserRequest.java:211)
>> at hudson.remoting.UserRequest.perform(UserRequest.java:54)
>> at hudson.remoting.Request$2.run(Request.java:375)
>> at
>> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:73)
>> [ERROR] Failed to execute goal on project openwebbeans-tck: Could not
>> resolve dependencies for project
>> org.apache.openwebbeans:openwebbeans-tck:jar:2.0.24-SNAPSHOT: Failed to
>> collect dependencies at org.jboss.cdi.tck:cdi-tck-impl:jar:2.0.3.Final ->
>> org.jboss.test-audit:jboss-test-audit-impl:jar:1.1.4.Final: Failed to read
>> artifact descriptor for
>> org.jboss.test-audit:jboss-test-audit-impl:jar:1.1.4.Final: Could not
>> transfer artifact
>> org.jboss.test-audit:jboss-test-audit-impl:pom:1.1.4.Final from/to
>> maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for
&

Re: Build failed in Jenkins: OpenWebBeans » OpenWebBeans-trunk-deploy #35

2021-07-05 Thread Joseph Bergmark

I think the key part of the error is:

[ERROR] Failed to execute goal on project openwebbeans-tck: Could not
resolve dependencies for project
org.apache.openwebbeans:openwebbeans-tck:jar:2.0.24-SNAPSHOT: Failed to
collect dependencies at org.jboss.cdi.tck:cdi-tck-impl:jar:2.0.3.Final ->
org.jboss.test-audit:jboss-test-audit-impl:jar:1.1.4.Final: Failed to read
artifact descriptor for
org.jboss.test-audit:jboss-test-audit-impl:jar:1.1.4.Final: Could not
transfer artifact
org.jboss.test-audit:jboss-test-audit-impl:pom:1.1.4.Final from/to
maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for
repositories: [jboss-public-repository-group (
http://repository.jboss.org/nexus/content/groups/public, default,
releases)] -> [Help 1]

It may have been blocked for being an "http://; URL, rather than "https://;.
This behavior might be dependent upon the version of Maven used.  I don't
think it is related to your change at all.

On Mon, Jul 5, 2021 at 8:35 AM Arne Limburg 
wrote:

> Hi,
>
> since my commit triggered this build, I'll take a look at it, but actually
> from the Stacktrace I have no clue about the problem.
>
> Can anyone help me out?
>
>
> Cheers,
>
> Arne
>
>
> --
>
> Arne Limburg - Enterprise Architekt
>
>
>
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limb...@openknowledge.de
> www.openknowledge.de 
>
> Registergericht: Amtsgericht Oldenburg, HRB 4670
> Geschäftsführer: Lars Röwekamp, Jens Schumann
>
> Treffen Sie uns auf kommenden Konferenzen und Workshops:
>
> Zu unseren Events
>
>
>
>
>
> 
> Von: Apache Jenkins Server 
> Gesendet: Montag, 5. Juli 2021 12:02
> An: dev@openwebbeans.apache.org
> Betreff: Build failed in Jenkins: OpenWebBeans » OpenWebBeans-trunk-deploy
> #35
>
> See <
> https://ci-builds.apache.org/job/OpenWebBeans/job/OpenWebBeans-trunk-deploy/35/display/redirect?page=changes
> >
>
> Changes:
>
> [Arne Limburg] OWB-1387: Don't throw Lifecycle events for inactive contexts
>
>
> --
> [...truncated 763.94 KB...]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> ERROR: Asynchronous execution failure
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at hudson.remoting.Channel$2.adapt(Channel.java:1039)
> at hudson.remoting.Channel$2.adapt(Channel.java:1033)
> at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)
> at
> hudson.maven.AbstractMavenBuilder.waitForAsynchronousExecutions(AbstractMavenBuilder.java:186)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:144)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:70)
> at hudson.remoting.UserRequest.perform(UserRequest.java:211)
> at hudson.remoting.UserRequest.perform(UserRequest.java:54)
> at hudson.remoting.Request$2.run(Request.java:375)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:73)
> [ERROR] Failed to execute goal on project openwebbeans-tck: Could not
> resolve dependencies for project
> org.apache.openwebbeans:openwebbeans-tck:jar:2.0.24-SNAPSHOT: Failed to
> collect dependencies at org.jboss.cdi.tck:cdi-tck-impl:jar:2.0.3.Final ->
> org.jboss.test-audit:jboss-test-audit-impl:jar:1.1.4.Final: Failed to read
> artifact descriptor for
> org.jboss.test-audit:jboss-test-audit-impl:jar:1.1.4.Final: Could not
> transfer artifact
> org.jboss.test-audit:jboss-test-audit-impl:pom:1.1.4.Final from/to
> maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for
> repositories: [jboss-public-repository-group (
> http://repository.jboss.org/nexus/content/groups/public, default,
> releases)] -> [Help 1]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [ERROR]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> at java.lang.Thread.run(Thread.java:748)
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> Caused by: java.lang.NullPointerException
> [ERROR]
> ERROR: [ERROR] For more information about the errors and possible
> solutions, please read the following articles:
> Asynchronous execution failure
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> [ERROR]
> java.util.concurrent.ExecutionException: java.io.IOException: Unexpected
> Fingerprint type. Expected class

Re: [VOTE] Release Apache OpenWebBeans-2.0.7

2018-08-30 Thread Joseph Bergmark

+1

On Tue, Aug 28, 2018 at 4:56 AM Mark Struberg 
wrote:

> Good morning ladies and gents!
>
> I'd like to call a VOTE on releasing Apache OpenWebBeans-2.0.7
>
> The following tickets got resolved:
>
> Bug
>
> [OWB-1247] - Update to XBean Asm 6 Shaded 4.9
> [OWB-1248] - defineClass used which is not supported by java 11
> [OWB-1251] - event.fireAsync hangs when there is no observer
>
> Improvement
>
> [OWB-1249] -
> org.apache.webbeans.config.OpenWebBeansConfiguration#overrideWithGlobalSettings
> environment overriding is not supported
> [OWB-1250] - Reduce the log level of anymous classes message when it
> cant be loaded
> [OWB-1252] - WebContextsService lazyStartRequestContext fails on first
> access.
> [OWB-1253] - Improve performance of BeforeDestroyed and Initialized
> Literals
> [OWB-1254] - destroying the Session doesn't fire
> BeforeDestroyed(SessionScoped.class) in our WebContextsService
> [OWB-1255] - update to apache-parent-21 for sha512
>
> The staging repo is:
>
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1045
>
> The source release is in
>
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1045/org/apache/openwebbeans/openwebbeans/2.0.7/
>
> The sha1 of openwebbeans-2.0.7-source-release.zip is
> c403e8510ebe7020042268d024247a9160fe1bce
>
> The sha512 is
> 26a2e7c10d0a62cc14bcf46c7560979bc9cfcea043af27a5725a5883ac6ac8a6dd2f39a1e0a8466a49670685ae90a92f91d2f1dfc5d285dd26603d23038bac12
>
> The tag in SVN is
> https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-2.0.7/
> -r1839409
>
>
> Please VOTE:
>
> [+1] go for it!
> [+0] meh, don't care
> [-1] nah, because there is a ${showstopper}
>
>
> The VOTE is open for 72h.
>
> txs and LieGrue,
> strub
>
>
>

Re: [VOTE] Apache OpenWebBeans-2.0.5

2018-04-28 Thread Joseph Bergmark

+1

On Sat, Apr 28, 2018 at 4:52 PM, Mark Struberg 
wrote:

> good evening!
>
> I'd like to call a VOTE to release Apache OpenWebBeans-2.0.5.
>
> The following tickets got resolved
>
> Bug
> • [OWB-1233] - WrappedValueExpression.equals(Object arg0) always
> false if arg0 is an instance of WrappedValueExpression
> • [OWB-1235] - ConversationScope destroyed upon session
> serialization/deserialization
> • [OWB-1241] - Bean cache ignores qualifier model defined through
> an AnnotatedType
>
> New Feature
> • [OWB-1242] - Add a configuration option to not proxy Principal
>
> Improvement
> • [OWB-1232] - replace warning about interceptors
> • [OWB-1238] - Our VersionVisitor shouldn't visit code
> • [OWB-1243] - improve event performance
>
> Task
> • [OWB-1240] - Non-static inner classes should not get picked up
> as CDI Beans
>
> Dependency upgrade
> • [OWB-1236] - Update to XBean Asm 6 Shaded 4.7
> • [OWB-1237] - upgrade to xbean-4.8
>
>
> The staging repo is
> https://repository.apache.org/content/repositories/
> orgapacheopenwebbeans-1041/
>
> The source distribution can be found here:
> https://repository.apache.org/content/repositories/
> orgapacheopenwebbeans-1041/org/apache/openwebbeans/openwebbeans/2.0.5/
>
> The sha1 is 7fed2fe13879270ce17ee711232bdca55b08d83b
>
> The tag is https://svn.apache.org/repos/asf/openwebbeans/tags/
> openwebbeans-2.0.5/
> -r 1830447
>
> Please VOTE
>
> [+1] yeah, let's ship it!
> [+0] meh, don't care
> [-1] stop there's a ${showstopper}
>
> The VOTE is open for 72h
>
> txs and LieGrue,
> strub
>
>
>

Re: [VOTE] Release Apache OpenWebBeans-1.7.5

2018-04-28 Thread Joseph Bergmark

+1

On Sat, Apr 28, 2018 at 8:10 AM, Mark Struberg 
wrote:

> Hi folks!
>
> I did run all required tasks for shipping an OWB-1.7.5 release.
> This version targets CDI-1.2 / EE7 and would fit for the TomEE-7.x line.
>
> The following tickets got resolved
>
> Bug
>
> • [OWB-1197] - OwbSWClassLoader creates wrong URL
> • [OWB-1205] - We should not fire ProcessInjectionPoint for CDI
> Extension Observers
> • [OWB-1209] - Custom bean with isAlternative()=true should not be
> automatically enabled
> • [OWB-1213] - producer of URI or other classes with private ct
> blow up with a NPE
> • [OWB-1222] - subclass proxy fails with Java9
>
> Improvement
>
> • [OWB-1218] - improve toString of producer beans to also log
> owner class
> Task
>
> • [OWB-1239] - update owb-1.7.x to java7
> • [OWB-1240] - Non-static inner classes should not get picked up
> as CDI Beans
>
> Dependency upgrade
>
> • [OWB-1236] - Update to XBean Asm 6 Shaded 4.7
> • [OWB-1237] - upgrade to xbean-4.8
>
> The source tag is -r1830409
> https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.7.5/
>
>
> The release staging repository can be found here:
>
> https://repository.apache.org/content/repositories/
> orgapacheopenwebbeans-1040/
>
> The source binary is in
> https://repository.apache.org/content/repositories/
> orgapacheopenwebbeans-1040/org/apache/openwebbeans/openwebbeans/1.7.5/
> It's sha1 is ddcf865490468e4e782fd596b815be9824ffe232
>
> I've used my standard sig and key.
>
>
> Please VOTE:
>
> [+1] let's ship it
> [+0] meh, don't care
> [-1] stop there is a ${showstopper}
>
> The VOTE is open for 72h.
>
> txs and LieGrue,
> strub
>
>

Re: [VOTE] Release Apache OpenWebBeans-2.0.2

2017-10-11 Thread Joseph Bergmark

+1

On Tue, Oct 10, 2017 at 7:58 PM, Romain Manni-Bucau 
wrote:

> +1 and thanks a lot for it!
>
> Side question: why CDI-SE? the controller is for EE as well I think
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  rmannibucau> |
> LinkedIn 
>
> 2017-10-10 23:06 GMT+02:00 Mark Struberg :
>
> > Hi folks!
> >
> > We fixed a bug for CDI-SE which we want to ship.
> >
> > The staging repo is
> > https://repository.apache.org/content/repositories/
> > orgapacheopenwebbeans-1033/
> >
> > The source release is
> > https://repository.apache.org/content/repositories/
> > orgapacheopenwebbeans-1033/org/apache/openwebbeans/openwebbeans/2.0.2/
> >
> > Please VOTE:
> >
> > [+1] yea, ship it
> > [+0] meh, don't care
> > [-1] nope, stop because ${reason}
> >
> > The vote is open for 72h.
> >
> > txs and LieGrue,
> > strub
>

Fwd: [VOTE] Release Apache OpenWebBeans-2.0.0

2017-07-11 Thread Joseph Bergmark

Sorry for sending to the wrong list!
-- Forwarded message --
From: Joseph Bergmark <bergm...@apache.org>
Date: Tue, Jul 11, 2017 at 9:14 AM
Subject: Re: [VOTE] Release Apache OpenWebBeans-2.0.0
To: u...@openwebbeans.apache.org


+1

On Mon, Jul 10, 2017 at 7:21 AM, Mark Struberg <strub...@yahoo.de> wrote:

> Good afternoon!
>
> We are proud to call a VOTE on releasing Apache OpenWebBeans-2.0.0
>
> This is an implementation of the CDI-2.0 specification (JSR-365) which
> just got released.
>
> We already tested it with DeltaSpike, BVal and quite a few other projects,
> and it really looks fine so far!
>
> Besides implenting CDI-2.0 the following bugs and enhancements got fixed
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> ctId=12310844=12333257
>
> Sub-task
>
> • [OWB-1185] - implement Annotated#getAnnotations
> • [OWB-1186] - update logic for bootstrapping-events
> • [OWB-1187] - implement configurators
> • [OWB-1188] - implement async events
> • [OWB-1189] - add new parts to the event-api
> • [OWB-1190] - implement java-se support
> • [OWB-1192] - update logic for Instance
> • [OWB-1193] - implement InterceptionFactory
> Bug
>
> • [OWB-1179] - OWB-Arquillian scanner doesn't ignore classes with
> ClassNotFound and NoClassDefFound
> • [OWB-1183] - OWB-Arquillian does not supports implicit bean
> discovery mode
> • [OWB-1184] - arquillian connector doesn't support BDAs
> • [OWB-1196] - Signed classes can't be proxied:
> java.lang.SecurityException: class "com.Foo$$OwbNormalScopeProxy0"'s
> signer information does not match signer information of other classes in
> the same package
> • [OWB-1197] - OwbSWClassLoader creates wrong URL
> Improvement
>
> • [OWB-1135] - Remove duplication for openwebbeans/Messages
> • [OWB-1195] - do a codestyle analysis check and apply fidings
> before releasing OWB-2.0.0
> Task
>
> • [OWB-1087] - fix failing integration tests with java 8
> • [OWB-1182] - Implement the CDI-2.0 API
>
>
>
> The staging repo is here
> https://repository.apache.org/content/repositories/orgapache
> openwebbeans-1030/
>
> The Source release can be found here
> https://repository.apache.org/content/repositories/orgapache
> openwebbeans-1030/org/apache/openwebbeans/openwebbeans/2.0.0/
>
>
>
> Please VOTE:
> [+1] yeah, let's ship it
> [+0] meh, don't care
> [-1] no, because I found a ${showstopper}
>
> The VOTE is open for 72h
>
>
> A special thanks to all who put their hard time into making this release
> possible!
>
> txs and LieGrue,
> the Apache OpenWebBeans team
>
>

Re: [VOTE] Release Apache OpenWebBeans-1.7.4

2017-07-07 Thread Joseph Bergmark

+1

built, mvn apache-rat:check, and ran a couple sample apps

On Fri, Jul 7, 2017 at 6:05 PM, Mark Struberg 
wrote:

> Dear lords and ladies!
>
> It's my pleasure to call a VOTE on releasing Apache OpenWebBeans-1.7.4.
> This is a maintenance release of our CDI-1.2 branch and a drop in
> replacement for OWB-1.7.3
>
> The following bugs got fixed:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12310844=12340364
>
> Bug
>
> • [OWB-1194] - @Interceptors (EJB style) + @AroundConstruct not
> fully supported
> • [OWB-1196] - Signed classes can't be proxied:
> java.lang.SecurityException: class "com.Foo$$OwbNormalScopeProxy0"'s
> signer information does not match signer information of other classes in
> the same package
> Improvement
>
> • [OWB-1180] - Use getDefinedPackage instead of getPackage if
> available (java 9)
> • [OWB-1181] - fallback on unsafe when defineClass is not
> accessible from ClassLoader
>
>
> Here is the staging repo:
>
> https://repository.apache.org/content/repositories/
> orgapacheopenwebbeans-1028/
>
>
> And here is the source release:
> https://repository.apache.org/content/repositories/
> orgapacheopenwebbeans-1028/org/apache/openwebbeans/openwebbeans/1.7.4/
>
> The tag in our repo is http://svn.apache.org/viewvc?rev=1801219=rev
>
> Please VOTE:
>
> [+1] yea, let's ship it!
> [+0] meeeh, don't care
> [-1] stop, I found a ${showstopper}
>
> The VOTE is open for 72h
>
> txs and LieGrue,
> strub

Re: [VOTE] Release Apache OpenWebBeans-1.7.3

2017-04-16 Thread Joseph Bergmark

+1

On Sat, Apr 15, 2017 at 6:56 PM, Mark Struberg 
wrote:

> Hi folks!
>
> I've run the tasks to ship OWB 1.7.3.
>
> The following bugs got fixed
>
> Bug
>
> • [OWB-1172] - getResources doesn't work in OWB Arquillian
> container for WebArchives
> • [OWB-1173] - InjectionPoint with no ownerBean fails on
> serialisation
> • [OWB-1175] - Duplicate registration of ServletContextBean
> • [OWB-1177] - producer should check runtime instance for
> Serializable constraint and not returned type
> Task
>
> • [OWB-1178] - Upgrade Arquillian to 1.1.13 and ShrinkWrap to 1.2.6
>
>
> The staging repo is:
> https://repository.apache.org/content/repositories/
> orgapacheopenwebbeans-1026/
>
> And here is the Source release:
> https://repository.apache.org/content/repositories/
> orgapacheopenwebbeans-1026/org/apache/openwebbeans/openwebbeans/1.7.3/
>
> And the SVN tag:
> http://svn.apache.org/viewvc?view=revision=1791551
>
>
>
> Please VOTE:
>
> [+1] Ship it!
> [+0] meh, don't care
> [-1] Stop, because ${showstopper}
>
> The VOTE is open for 72h
>
> txs and LieGrue,
> strub
>
>
>

Re: [VOTE] Release Apache OpenWebBeans-1.7.0 - take 2

2016-09-02 Thread Joseph Bergmark

+1

On Wed, Aug 31, 2016 at 4:50 PM, Mark Struberg 
wrote:

> New take for OWB-1.7.0
>
> Repo is
> https://repository.apache.org/content/repositories/
> orgapacheopenwebbeans-1018/
>
> Source release is
> https://repository.apache.org/content/repositories/
> orgapacheopenwebbeans-1018/org/apache/openwebbeans/openwebbeans/1.7.0/
>
> You gonna find the rest I'm sure :)
>
>
>
>
> [+1] let's ship it!
> [+0] meh, don't care
> [-1] nope, because ${blocker}
>
>
> The VOTE is open for 72h
>
>
>
> Here is my +1
>
> txs and LieGrue,
> strub
>
>
>
> > On Wednesday, 31 August 2016, 22:23, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
> > > 2016-08-31 22:18 GMT+02:00 Mark Struberg :
> >
> >>  No, it's really that we ditch the ThreadLocals in a place where we
> >>  shouldn't.
> >>
> >>  TCK passes even after my fix.
> >>
> >>
> > Shouldn't since the start object is broken in the context control - that
> > said we can move this over #deltaspike, doesn't affect OWB at all
> >
> >
> >
> >>
> >>  LieGrue,
> >>  strub
> >>
> >>
> >>
> >>
> >>
> >>  > On Wednesday, 31 August 2016, 22:17, Romain Manni-Bucau <
> >>  rmannibu...@gmail.com> wrote:
> >>  > > FYI CDI TCK are green on tomee project (embedded and standalone)
> >>  >
> >>  > @Gerhard: if still the same issue related to session/request scopes
> it
> >>  is a
> >>  > bug of CdiCtrl API more than an OWB one so can (should) be fixed in
> >>  > deltaspike not there (note that OpenWebBeansContextControl doesn't
> >>  respect
> >>  > the spec and therefore cdictrl behavior doesn't work and both
> > statements
> >>  > are very compatible).
> >>  >
> >>  >
> >>  > Romain Manni-Bucau
> >>  > @rmannibucau  |  Blog
> >>  >  | Old Wordpress Blog
> >>  >  | Github
> >>  >  |
> >>  > LinkedIn  | Tomitriber
> >>  >  | JavaEE Factory
> >>  > 
> >>  >
> >>  >
> >>  > 2016-08-31 22:09 GMT+02:00 Gerhard Petracek
> > :
> >>  >
> >>  >>  -1, because it still breaks
> >>  >>  org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest (as soon as
> > owb
> >>  is
> >>  >>  used with openejb).
> >>  >>
> >>  >>  regards,
> >>  >>  gerhard
> >>  >>
> >>  >>
> >>  >>
> >>  >>  2016-08-30 10:40 GMT+02:00 Mark Struberg
> > :
> >>  >>
> >>  >>  > Good morning!
> >>  >>  >
> >>  >>  > I'd like to call a VOTE on releasing Apache
> > OpenWebBeans-1.7.0.
> >>  >>  >
> >>  >>  >
> >>  >>  > The staging repo is:
> >>  >>  >
> >>  >>  > https://repository.apache.org/content/repositories/
> >>  >>  > orgapacheopenwebbeans-1017/
> >>  >>  >
> >>  >>  >
> >>  >>  > The source release can be found at
> >>  >>  > https://repository.apache.org/content/repositories/
> >>  >>  > orgapacheopenwebbeans-1017/org/apache/openwebbeans/
> >>  openwebbeans/1.7.0/
> >>  >>  >
> >>  >>  >
> >>  >>  > My Key can be found in
> >>  >>  > https://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS
> >>  >>  >
> >>  >>  > The tag in SVN is
> >>  >>  >
> >>  >>  > https://svn.apache.org/repos/asf/openwebbeans/tags/
> >>  openwebbeans-1.7.0/
> >>  >>  > Revision r1758342
> >>  >>  >
> >>  >>  >
> >>  >>  >
> >>  >>  > [+1] let's ship it!
> >>  >>  >
> >>  >>  > [+0] meh, don't care
> >>  >>  >
> >>  >>  > [-1] nope, because ${blocker}
> >>  >>  >
> >>  >>  >
> >>  >>  > The VOTE is open for 72h
> >>  >>  >
> >>  >>  >
> >>  >>  > txs and LieGrue,
> >>  >>  > strub
> >>  >>  >
> >>  >>
> >>  >
> >>
> >
>

Re: [VOTE] Release Apache OpenWebBeans-1.7.0

2016-08-30 Thread Joseph Bergmark

+1

built, mvn apache-rat:check, and ran a couple of the sample applications.
Looked good to me

On Tue, Aug 30, 2016 at 4:40 AM, Mark Struberg 
wrote:

> Good morning!
>
> I'd like to call a VOTE on releasing Apache OpenWebBeans-1.7.0.
>
>
> The staging repo is:
>
> https://repository.apache.org/content/repositories/
> orgapacheopenwebbeans-1017/
>
>
> The source release can be found at
> https://repository.apache.org/content/repositories/
> orgapacheopenwebbeans-1017/org/apache/openwebbeans/openwebbeans/1.7.0/
>
>
> My Key can be found in
> https://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS
>
> The tag in SVN is
>
> https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.7.0/
> Revision r1758342
>
>
>
> [+1] let's ship it!
>
> [+0] meh, don't care
>
> [-1] nope, because ${blocker}
>
>
> The VOTE is open for 72h
>
>
> txs and LieGrue,
> strub
>

Re: [DISCUSS] moving OpenWebBeans to GIT?

2016-01-23 Thread Joseph Bergmark

+0 I really like DVCSs. working in feature branches, and the git workflow
in general, but haven't been active at all in CDI-2.0 work so it makes more
sense to stick with the opinion of those that are.

On Sat, Jan 23, 2016 at 7:44 AM, Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> +0 - don't see any big benefit
>
> Am Samstag, 23. Januar 2016 schrieb Romain Manni-Bucau :
>
> > -0 doesnt bring anything IMO but dont care enough to fight on it
> > Le 23 janv. 2016 11:59, "Mark Struberg"  >
> > a écrit :
> >
> > > Hi!
> > >
> > > What do you think about moving openwebbeans to GIT.
> > > Of course hosted at the ASF.
> > >
> > > Would probably be helpful when working on the CDI-2.0 branch in the
> > future.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> >
>

Re: [VOTE] for Apache OpenWebBeans 1.6.1

2015-06-16 Thread Joseph Bergmark

+1

On Tue, Jun 16, 2015 at 3:10 AM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:

 +1


 Romain Manni-Bucau
 @rmannibucau https://twitter.com/rmannibucau |  Blog
 http://rmannibucau.wordpress.com | Github 
 https://github.com/rmannibucau |
 LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
 http://www.tomitribe.com

 2015-06-16 8:10 GMT+02:00 Mark Struberg strub...@yahoo.de:

  Hi!
 
  I’d like to call a VOTE on Apache OpenWebBeans-1.6.1.
 
  The staging repository is here
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1014/
 
  The source repo is available here
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1014/org/apache/openwebbeans/openwebbeans/1.6.1/openwebbeans-1.6.1-source-release.zip
 
 
  The binary distribution can be found at
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1014/org/apache/openwebbeans/openwebbeans-distribution/1.6.1/openwebbeans-distribution-1.6.1-binary.zip
 
  [+1] ship it
  [+0] meh, don’t care
  [-1] stop, because of ${blocker}
 
  The VOTE is open for 72h
 
  txs and LieGrue,
  strub

Re: do we like to drop servlet-2.5 support?

2015-04-26 Thread Joseph Bergmark

Perhaps I'm being dense, but tomcat 6 is at spec level servlet 2.5 and
tomcat 7 is at spec level servlet 3.0 right? Requiring Servlet 3.0 lets us
leverage ServletContainerInitializers.

On Sun, Apr 26, 2015 at 10:55 AM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:

 We  can/should drop t6 but not servlet 2.5

 Not sure i get your comment. Servlet 2 or 3 doesnt change anything for us

 Le 26 avr. 2015 16:33, Mark Struberg strub...@yahoo.de a écrit :
 
  Hi folks!
 
  I wonder if we still like to support tomcat6 and servlet-2.5. We are
 talking about technology which got introduced more than 10 years ago and is
 outdated since 5 years now.
 
  When switching to servlet-3.0++ we would have a few options:
 
  Make WebBeansConfigurationListener just implement the contextInitialized
 and destroy and register the BeginWebBeansListener and EndWebBeansListener
 dynamically as first respective last listener in the chain.
 
  Any objections?
 
  LieGrue,
  strub

Re: adding a web-fragment.xml to openwebbeans-web?

2015-04-25 Thread Joseph Bergmark

It should be well supported on any servlet 3.0 compliant container as its
part of the specification.  I suppose it could be inconvenient for
application servers that already have OWB integration, but in that case I
wouldn't expect the user to be including OWB in their application at all.

As long as we document that including the openwebbeans-web module into your
application will cause a ServletContainerInitializer to automatically be
added, I don't see any harm in it.  I guess the only loss is some amount of
ordering control you might have had if you included it in the parent
web.xml directly.

On Sat, Apr 25, 2015 at 5:14 PM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:

 Le 25 avr. 2015 21:58, Mark Struberg strub...@yahoo.de a écrit :
 
  Hi!
 
  Should we add the WebBeansConfigurationListener (or later the two split
 ones, see OWB-1055) into a web-fragment.xml inside our openwebbeasns-web
 module?
 
  Pro: no need to add any listener manually + we should be neatly able to
 define the default priorities (outermost listener).
  Con: not sure yet, that’s what I’m curious about :) Any input?
 

 Break container usage, not always well supported?

 That said could be done in another module. Would split lib and app
 artifacts which is good.

 Also the conversation filter needs to be handled prog so
 ServletContextInitializer sounds better.

 
  LieGrue,
  strub

Re: [VOTE] Release Apache OpenWebBeans-1.2.8

2015-04-24 Thread Joseph Bergmark

Forgot to add my +1

I'll open up a JIRA issue to take care of the README files and to ignore
the generated DEPENDENCIES file.

On Wed, Apr 22, 2015 at 9:37 AM, Mark Struberg strub...@yahoo.de wrote:

 I’d like to call a VOTE for releasing Apache OpenWebBeans-1.2.8

 This is a maintenance release of our 1.2.x branch which targsts JSR-299
 (CDI-1.0).

 The release notes:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12327470


 The staging repository:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1012/

 The sources release:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1012/org/apache/openwebbeans/openwebbeans/1.2.8/openwebbeans-1.2.8-source-release.zip

 The SVN tag (r1675359):
 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.8/


 The binary package:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1012/org/apache/openwebbeans/openwebbeans-distribution/1.2.8/openwebbeans-distribution-1.2.8-binary.zip


 My Key can be found here
 https://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS


 The VOTE will be open for 72 hours.
 [+1] approve
 [+0] meh, don’t care
 [-1] stop, I’ve found a ${fish} in there


 txs and LieGrue,
 your OpenWebBeans team

Re: [VOTE] Release Apache OpenWebBeans-1.2.8

2015-04-22 Thread Joseph Bergmark

Never mind, I'm seeing similar problems with the last release (1.5.0) when
I re-run it.  Not sure what I might have done differently before.

On Wed, Apr 22, 2015 at 7:36 PM, Joseph Bergmark bergm...@apache.org
wrote:

 I'm seeing some errors with mvn rat:check:

 [ERROR] Failed to execute goal
 org.codehaus.mojo:rat-maven-plugin:1.0-alpha-3:ch
 eck (default-cli) on project openwebbeans: Too many unapproved licenses:
 21 - [
 Help 1]

 From my quick glance at rat.txt, they appear to mostly be the readme/*
 files which shouldn't be new, but it also wasn't sure about DEPENDENCIES.
 I don't remember seeing these same problems with the 1.5 release last week.

 On Wed, Apr 22, 2015 at 2:33 PM, Romain Manni-Bucau rmannibu...@gmail.com
  wrote:

 +1


 Romain Manni-Bucau
 @rmannibucau https://twitter.com/rmannibucau |  Blog
 http://rmannibucau.wordpress.com | Github 
 https://github.com/rmannibucau |
 LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
 http://www.tomitribe.com

 2015-04-22 15:37 GMT+02:00 Mark Struberg strub...@yahoo.de:

  I’d like to call a VOTE for releasing Apache OpenWebBeans-1.2.8
 
  This is a maintenance release of our 1.2.x branch which targsts JSR-299
  (CDI-1.0).
 
  The release notes:
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12327470
 
 
  The staging repository:
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1012/
 
  The sources release:
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1012/org/apache/openwebbeans/openwebbeans/1.2.8/openwebbeans-1.2.8-source-release.zip
 
  The SVN tag (r1675359):
  https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.8/
 
 
  The binary package:
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1012/org/apache/openwebbeans/openwebbeans-distribution/1.2.8/openwebbeans-distribution-1.2.8-binary.zip
 
 
  My Key can be found here
  https://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS
 
 
  The VOTE will be open for 72 hours.
  [+1] approve
  [+0] meh, don’t care
  [-1] stop, I’ve found a ${fish} in there
 
 
  txs and LieGrue,
  your OpenWebBeans team

Re: [VOTE] Release Apache OpenWebBeans-1.2.8

2015-04-22 Thread Joseph Bergmark

I'm seeing some errors with mvn rat:check:

[ERROR] Failed to execute goal
org.codehaus.mojo:rat-maven-plugin:1.0-alpha-3:ch
eck (default-cli) on project openwebbeans: Too many unapproved licenses: 21
- [
Help 1]

From my quick glance at rat.txt, they appear to mostly be the readme/*
files which shouldn't be new, but it also wasn't sure about DEPENDENCIES.
I don't remember seeing these same problems with the 1.5 release last week.

On Wed, Apr 22, 2015 at 2:33 PM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:

 +1


 Romain Manni-Bucau
 @rmannibucau https://twitter.com/rmannibucau |  Blog
 http://rmannibucau.wordpress.com | Github 
 https://github.com/rmannibucau |
 LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
 http://www.tomitribe.com

 2015-04-22 15:37 GMT+02:00 Mark Struberg strub...@yahoo.de:

  I’d like to call a VOTE for releasing Apache OpenWebBeans-1.2.8
 
  This is a maintenance release of our 1.2.x branch which targsts JSR-299
  (CDI-1.0).
 
  The release notes:
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12327470
 
 
  The staging repository:
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1012/
 
  The sources release:
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1012/org/apache/openwebbeans/openwebbeans/1.2.8/openwebbeans-1.2.8-source-release.zip
 
  The SVN tag (r1675359):
  https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.8/
 
 
  The binary package:
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1012/org/apache/openwebbeans/openwebbeans-distribution/1.2.8/openwebbeans-distribution-1.2.8-binary.zip
 
 
  My Key can be found here
  https://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS
 
 
  The VOTE will be open for 72 hours.
  [+1] approve
  [+0] meh, don’t care
  [-1] stop, I’ve found a ${fish} in there
 
 
  txs and LieGrue,
  your OpenWebBeans team

Re: [DRAFT] OpenWebBeans board report 2015-03

2015-03-15 Thread Joseph Bergmark

If you haven't already sent it, I would make two trivial changes:

1) Fix the accidental typo of teh into the in the development section
2) In the community section, I might have chosen to used received instead
of got, as in we received quite a few bug reports and patches.

Very small things, and not a big deal at all if you've already sent.
Thanks for writing it up!

On Fri, Mar 13, 2015 at 5:43 PM, Mark Struberg 
markus.strutzenber...@rise-world.com wrote:

 Hi folks!

 Please review the prepared board report. Did not use wiki this time as I
 cannot login atm

 -

 Apache OpenWebBeans 1.x is an ALv2-licensed implementation of the
 Contexts and Dependency Injection for the Java EE platform
 specification which is defined as JSR-299 (CDI-1.0).
 OpenWebBeans 1.5.x also implements the CDI-1.1 and CDI-1.2 (MR)
 specifications(JSR-346)
 We will later also also implement CDI-2.0 (JSR-365) as OpenWebBeans-2.0.x.

 Board Issues
 There are no issues requiring board attention this time.

 Development
 Development of the first OpenWebBeans-1.5.x (CDI-1.2) version is already
 finished.
 We are finished with the SE parts and fully pass this TCK. We are currently
 working with the Apache TomEE team to solve hte last few broken CDI-1.2
 TCK tests.
 Once we finished those tasks (probably in the next 2 weeks) we will ship a
 1.5.0
 release.


 New Releases
 OpenWebBeans-1.2.7 on 2014-12-09

 Discussions.
 Nothing which requires board attention.

 Community
 Community activity is fine. We've got quite a few bug reports and patches.
 Last Committer: Reinhard Sandtner on Sept 23th, 2014
 Last PMC addition: Thomas Andraschko and Jean-Louis Monteiro on 2014-05-28


 ——
 plan to submit it tomorrow.

 LieGrue,
 strub

Re: [VOTE] Release Apache OpenWebBeans-1.2.6

2014-06-21 Thread Joseph Bergmark

+1


On Thu, Jun 19, 2014 at 4:57 PM, Mark Struberg strub...@yahoo.de wrote:

 I'd like to call a VOTE on releasing Apache OpenWebBeans-1.2.6 .

 This is a maintenance release of the owb_1.2.x branch and targets the
 CDI-1.0 specification.

 The ReleaseNotes are available online:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12326940

 Maven staging repo:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1005/


 SVN source tag:

 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.6/


 Source Release:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1005/org/apache/openwebbeans/openwebbeans/1.2.6/openwebbeans-1.2.6-source-release.zip


 Binary release:


 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1005/org/apache/openwebbeans/openwebbeans-distribution/1.2.6/openwebbeans-distribution-1.2.6-binary.zip


 PGP release key 2FDB81B1

 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS



 The VOTE will be open for 72 hours.
 [ ] +1 approve
 [ ] +0 no opinion
 [ ] -1 veto (and reason why)



 Here is my +1


 LieGrue,
 strub

Re: [VOTE] Release Apache OpenWebBeans 1.2.5

2014-05-25 Thread Joseph Bergmark

-1

From my (admittedly limited) perspective, in 1.2.4 you could use the
jetty:run target to run our samples, and in 1.2.5 you can't due to the
changes in OWB-953, which means we have regressed file:/ urls.  I'll be
the first to admit that may not be a pervasive use case.


On Sun, May 25, 2014 at 2:59 PM, Jean-Louis MONTEIRO jeano...@gmail.comwrote:

 Continue and here is my +1 then.

 JLouis


 2014-05-25 19:23 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:

  +1 since all other binaries are ok and this is pluggable (worse case)
 
 
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
  2014-05-25 19:19 GMT+02:00 Mark Struberg strub...@yahoo.de:
 
   hmm oki looked at it once again and it seems this has been broken since
   quite some time really.
   So it's not a recent regression since 1.2.4 but broken since quite some
   time.
  
   I'd say we can continue the VOTE? wdym?
  
   LieGrue,
   strub
  
  
  
  
  
On Sunday, 25 May 2014, 16:33, Mark Struberg strub...@yahoo.de
  wrote:

   
corrected subject: VOTE got cancelled.
   
   
   
   
   
 On , Mark Struberg strub...@yahoo.de wrote:
  oki reviewed it again and the effect is that we do not pick up
 WEB-INF/beans.xml.
 That means that we do not pass the TCK and as such must not ship
thisbinary.
   
 The VOTE is CANCELLED and I gonna fix it and re-roll the release.
   
 txs and LieGrue,
 strub
   
   
   
   
   
   
   
  On Sunday, 25 May 2014, 16:18, Mark Struberg strub...@yahoo.de
   
 wrote:
  t he question is whether this is a heavy regression or whether
 we
can
 defer this
  to 1.2.6...
  Given that 1.2.4 worked and we only fixed a few bugs I'd let it
run.
   
   
  LieGrue,
  strub
   
   
   
   
   
   
   On Saturday, 24 May 2014, 22:23, Joseph Bergmark
 bergm...@gmail.com
  wrote:
No problem, I've opened a JIRA issue and attached a
patch
 that
  resolves the
   issue in my testing.
   
   
   
   On Sat, May 24, 2014 at 3:57 PM, Mark Struberg
 strub...@yahoo.de
  wrote:
   
   
   
Hi Joe!
   
Thanks for checking. I'll try to reproduce tonight or
 tomorrow and
  will
abort the VOTE if I can reproduce it.
   
txs and LieGrue,
strub
   
   
 On Saturday, 24 May 2014, 21:22, Joseph Bergmark
   bergm...@gmail.com
wrote:
  I walked though the code in debug, and from what I
can
 tell
  it
   appears
to
 be an issue with the way the URLs are being generated
(at
 least
  on my
 machine).

 My breakpoints in AbstractMetaDataDiscovery 
CdiArchive
 are
   showing URLs
 for my classes directory that look like:

 file:file:/C:/workspaces/owb-1.2.5/samples/guess/target/classes/

 WebScannerService createURLFromMarkerFile has what
appears
 to be
  a
correct
 String
   
 file:/C:/workspaces/owb-1.2.5/samples/guess/target/classes/
 from
 findBeansXmlBases, but it prepends file:
again
 here
  on
   line 156:

 //X TODO check!
 addPath = file: + url +
 META-INF/beans.xml;

 OWB-953 changed this class so that addPath is what is
added
 to
  the
   list
of
 URLs as previously it used url, so it is possible this
is a
 small
 regression for non-jar based URLs in web modules.



 On Sat, May 24, 2014 at 2:47 PM, Gerhard Petracek 
 gerhard.petra...@gmail.com wrote:

  i've upgraded several projects to v1.2.5 (e.g.
[1]
 and
  [2])
   and all
 tests
  look fine.
  - +1

  regards,
  gerhard

  [1] https://github.com/CDIatWork/IdeaFork
  [2]



   
   
   
   
   
  
 
 https://git-wip-us.apache.org/repos/asf/deltaspike/repo?p=deltaspike.git;a=summary



  2014-05-24 20:24 GMT+02:00 Joseph Bergmark
   bergm...@apache.org:

   I set up my build environment on a new
machine, so
 its
   possible
 I'm
   fighting a configuration problem, but after a
   
  successful
   build from
 the
   1.2.5 source zip, I'm having trouble with
the
 guess
   
   sample app
 which is
  my
   normal go-to for quick testing.
  
   It looks like an EL or bean discovery
problem, as
  loginBean
   isn't
 being
   found.  I'll do a bit more digging but
was
 curious
  if
   anyone had

Re: [VOTE] Release Apache OpenWebBeans 1.2.5

2014-05-24 Thread Joseph Bergmark

I set up my build environment on a new machine, so its possible I'm
fighting a configuration problem, but after a successful build from the
1.2.5 source zip, I'm having trouble with the guess sample app which is my
normal go-to for quick testing.

It looks like an EL or bean discovery problem, as loginBean isn't being
found.  I'll do a bit more digging but was curious if anyone had luck with
the samples or the guess sample app in particular.


On Sat, May 24, 2014 at 1:42 PM, David Blevins david.blev...@gmail.comwrote:

 +1


 --
 David Blevins
 http://twitter.com/dblevins
 http://www.tomitribe.com

 On May 23, 2014, at 10:43 AM, Mark Struberg strub...@yahoo.de wrote:

 
  I'd like to call a VOTE on releasing Apache OpenWebBeans-1.2.5 .
 
  This is a maintenance release of the owb_1.2.x branch and targets the
 CDI-1.0 specification.
 
  The ReleaseNotes are available online:
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12326814
 
  Maven staging repo:
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1004/
 
 
  SVN source tag:
 
  https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.5/
 
 
  Source Release:
 
 http://repository.apache.org/content/repositories/orgapacheopenwebbeans-1004/org/apache/openwebbeans/openwebbeans/1.2.5/openwebbeans-1.2.5-source-release.zip
 
 
  Binary release:
 
 
 http://repository.apache.org/content/repositories/orgapacheopenwebbeans-1004/org/apache/openwebbeans/openwebbeans-distribution/1.2.5/openwebbeans-distribution-1.2.5-binary.zip
 
 
  PGP release key 2FDB81B1
 
  http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS
 
 
 
  The VOTE will be open for 72 hours.
  [ ] +1 approve
  [ ] +0 no opinion
  [ ] -1 veto (and reason why)
 
 
 
  Here is my +1
 
 
  LieGrue,
  strub

Re: [VOTE] Release Apache OpenWebBeans 1.2.5

2014-05-24 Thread Joseph Bergmark

I walked though the code in debug, and from what I can tell it appears to
be an issue with the way the URLs are being generated (at least on my
machine).

My breakpoints in AbstractMetaDataDiscovery  CdiArchive are showing URLs
for my classes directory that look like:
file:file:/C:/workspaces/owb-1.2.5/samples/guess/target/classes/

WebScannerService createURLFromMarkerFile has what appears to be a correct
String file:/C:/workspaces/owb-1.2.5/samples/guess/target/classes/ from
findBeansXmlBases, but it prepends file: again here on line 156:

//X TODO check!
addPath = file: + url + META-INF/beans.xml;

OWB-953 changed this class so that addPath is what is added to the list of
URLs as previously it used url, so it is possible this is a small
regression for non-jar based URLs in web modules.


On Sat, May 24, 2014 at 2:47 PM, Gerhard Petracek 
gerhard.petra...@gmail.com wrote:

 i've upgraded several projects to v1.2.5 (e.g. [1] and [2]) and all tests
 look fine.
 - +1

 regards,
 gerhard

 [1] https://github.com/CDIatWork/IdeaFork
 [2]

 https://git-wip-us.apache.org/repos/asf/deltaspike/repo?p=deltaspike.git;a=summary



 2014-05-24 20:24 GMT+02:00 Joseph Bergmark bergm...@apache.org:

  I set up my build environment on a new machine, so its possible I'm
  fighting a configuration problem, but after a successful build from the
  1.2.5 source zip, I'm having trouble with the guess sample app which is
 my
  normal go-to for quick testing.
 
  It looks like an EL or bean discovery problem, as loginBean isn't being
  found.  I'll do a bit more digging but was curious if anyone had luck
 with
  the samples or the guess sample app in particular.
 
 
  On Sat, May 24, 2014 at 1:42 PM, David Blevins david.blev...@gmail.com
  wrote:
 
   +1
  
  
   --
   David Blevins
   http://twitter.com/dblevins
   http://www.tomitribe.com
  
   On May 23, 2014, at 10:43 AM, Mark Struberg strub...@yahoo.de wrote:
  
   
I'd like to call a VOTE on releasing Apache OpenWebBeans-1.2.5 .
   
This is a maintenance release of the owb_1.2.x branch and targets the
   CDI-1.0 specification.
   
The ReleaseNotes are available online:
   
  
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12326814
   
Maven staging repo:
   
  
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1004/
   
   
SVN source tag:
   
   
 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.5/
   
   
Source Release:
   
  
 
 http://repository.apache.org/content/repositories/orgapacheopenwebbeans-1004/org/apache/openwebbeans/openwebbeans/1.2.5/openwebbeans-1.2.5-source-release.zip
   
   
Binary release:
   
   
  
 
 http://repository.apache.org/content/repositories/orgapacheopenwebbeans-1004/org/apache/openwebbeans/openwebbeans-distribution/1.2.5/openwebbeans-distribution-1.2.5-binary.zip
   
   
PGP release key 2FDB81B1
   
http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS
   
   
   
The VOTE will be open for 72 hours.
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 veto (and reason why)
   
   
   
Here is my +1
   
   
LieGrue,
strub

Re: [VOTE] Release Apache OpenWebBeans 1.2.5

2014-05-24 Thread Joseph Bergmark

No problem, I've opened a JIRA issue and attached a patch that resolves the
issue in my testing.


On Sat, May 24, 2014 at 3:57 PM, Mark Struberg strub...@yahoo.de wrote:



 Hi Joe!

 Thanks for checking. I'll try to reproduce tonight or tomorrow and will
 abort the VOTE if I can reproduce it.

 txs and LieGrue,
 strub


  On Saturday, 24 May 2014, 21:22, Joseph Bergmark bergm...@gmail.com
 wrote:
   I walked though the code in debug, and from what I can tell it appears
 to
  be an issue with the way the URLs are being generated (at least on my
  machine).
 
  My breakpoints in AbstractMetaDataDiscovery  CdiArchive are showing URLs
  for my classes directory that look like:
  file:file:/C:/workspaces/owb-1.2.5/samples/guess/target/classes/
 
  WebScannerService createURLFromMarkerFile has what appears to be a
 correct
  String file:/C:/workspaces/owb-1.2.5/samples/guess/target/classes/
  from
  findBeansXmlBases, but it prepends file: again here on line 156:
 
  //X TODO check!
  addPath = file: + url +
  META-INF/beans.xml;
 
  OWB-953 changed this class so that addPath is what is added to the list
 of
  URLs as previously it used url, so it is possible this is a small
  regression for non-jar based URLs in web modules.
 
 
 
  On Sat, May 24, 2014 at 2:47 PM, Gerhard Petracek 
  gerhard.petra...@gmail.com wrote:
 
   i've upgraded several projects to v1.2.5 (e.g. [1] and [2]) and all
  tests
   look fine.
   - +1
 
   regards,
   gerhard
 
   [1] https://github.com/CDIatWork/IdeaFork
   [2]
 
 
 
 https://git-wip-us.apache.org/repos/asf/deltaspike/repo?p=deltaspike.git;a=summary
 
 
 
   2014-05-24 20:24 GMT+02:00 Joseph Bergmark bergm...@apache.org:
 
I set up my build environment on a new machine, so its possible
  I'm
fighting a configuration problem, but after a successful build from
  the
1.2.5 source zip, I'm having trouble with the guess sample app
  which is
   my
normal go-to for quick testing.
   
It looks like an EL or bean discovery problem, as loginBean isn't
  being
found.  I'll do a bit more digging but was curious if anyone had
  luck
   with
the samples or the guess sample app in particular.
   
   
On Sat, May 24, 2014 at 1:42 PM, David Blevins
  david.blev...@gmail.com
wrote:
   
 +1


 --
 David Blevins
 http://twitter.com/dblevins
 http://www.tomitribe.com

 On May 23, 2014, at 10:43 AM, Mark Struberg
  strub...@yahoo.de wrote:

 
  I'd like to call a VOTE on releasing Apache
  OpenWebBeans-1.2.5 .
 
  This is a maintenance release of the owb_1.2.x branch and
  targets the
 CDI-1.0 specification.
 
  The ReleaseNotes are available online:
 

   
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12326814
 
  Maven staging repo:
 

   
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1004/
 
 
  SVN source tag:
 
 
   https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.5/
 
 
  Source Release:
 

   
 
 
 http://repository.apache.org/content/repositories/orgapacheopenwebbeans-1004/org/apache/openwebbeans/openwebbeans/1.2.5/openwebbeans-1.2.5-source-release.zip
 
 
  Binary release:
 
 

   
 
 
 http://repository.apache.org/content/repositories/orgapacheopenwebbeans-1004/org/apache/openwebbeans/openwebbeans-distribution/1.2.5/openwebbeans-distribution-1.2.5-binary.zip
 
 
  PGP release key 2FDB81B1
 
  http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS
 
 
 
  The VOTE will be open for 72 hours.
  [ ] +1 approve
  [ ] +0 no opinion
  [ ] -1 veto (and reason why)
 
 
 
  Here is my +1
 
 
  LieGrue,
  strub

Re: [VOTE] Release Apache OpenWebBeans-1.2.3

2014-04-24 Thread Joseph Bergmark

+1

On Wed, Apr 23, 2014 at 2:36 AM, Mark Struberg strub...@yahoo.de wrote:

 I'd like to call a VOTE on releasing Apache OpenWebBeans-1.2.2 .

 This is a maintenance release of the owb_1.2.x branch and targets the
 CDI-1.0 specification.

 The ReleaseNotes are available online:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12326295

 Maven staging repo:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1002/


 SVN source tag:

 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.3/


 Source Release:

 http://repository.apache.org/content/repositories/orgapacheopenwebbeans-1002/org/apache/openwebbeans/openwebbeans/1.2.3/openwebbeans-1.2.3-source-release.zip


 Binary release:


 http://repository.apache.org/content/repositories/orgapacheopenwebbeans-1002/org/apache/openwebbeans/openwebbeans-distribution/1.2.3/openwebbeans-distribution-1.2.3-binary.zip


 PGP release key 2FDB81B1

 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS


 The VOTE will be open for 72 hours.
 [ ] +1 approve
 [ ] +0 no opinion
 [ ] -1 veto (and reason why)



 Here is my +1


 LieGrue,
 strub

Re: [VOTE] Release Apache OpenWebBeans-1.2.2

2014-02-20 Thread Joseph Bergmark

+1


On Wed, Feb 19, 2014 at 4:09 AM, Mark Struberg strub...@yahoo.de wrote:



 I'd like to call a VOTE on releasing Apache OpenWebBeans-1.2.2 .

 This is a maintenance release of the owb_1.2.x branch and targets the
 CDI-1.0 specification.

 The ReleaseNotes are available in the README and online:


 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12325007


 Maven staging repo:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1001/


 SVN source tag:

 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.2/


 Source Release:

 http://repository.apache.org/content/repositories/orgapacheopenwebbeans-1001/org/apache/openwebbeans/openwebbeans/1.2.2/openwebbeans-1.2.2-source-release.zip


 Binary release:


 http://repository.apache.org/content/repositories/orgapacheopenwebbeans-1001/org/apache/openwebbeans/openwebbeans-distribution/1.2.2/openwebbeans-distribution-1.2.2-binary.zip


 PGP release key 2FDB81B1

 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS


 The VOTE will be open for 72 hours.
 [ ] +1 approve
 [ ] +0 no opinion
 [ ] -1 veto (and reason why)



 Here is my +1


 LieGrue,
 strub

Re: svn commit: r1552050 - in /openwebbeans/trunk/webbeans-impl/src: main/java/org/apache/webbeans/component/creation/BeanAttributesBuilder.java test/java/org/apache/webbeans/newtests/specalization/mu

2013-12-18 Thread Joseph Bergmark

Sorry, I'll try to be more clear.  Again, I'm not very experienced in this
area of OWB, so my interpretation could be wrong or this could be handled
in a different code path entirely.

The new code is looking directly at the Class itself for the @Specializes
annotation.  I'm suggesting that perhaps instead it should be looking at
the AnnotatedType for the annotation (AnnotatedType.isAnnotatationPresent)
in case a portable extension has called setAnnotatedType during a
ProcessAnnotatedType event and has added @Specializes.


On Wed, Dec 18, 2013 at 4:14 PM, Thomas Andraschko 
andraschko.tho...@gmail.com wrote:

 Hey,

 i'm not exactly sure if understand your question correctly but i will
 explain you my code change.

 I think specialization per se was working fine but the old code just looked
 for a @Named on the direct parent.

 e.g.

 @Named BeanA
 @Specializes BeanB extends BeanA
 @Specializes BeanC extends BeanC

 It tried to extract the name for BeanC from BeanB but actually it must look
 for @Named on BeanA.


 2013/12/18 Joseph Bergmark bergm...@gmail.com

  I'll be the first to admit I'm not very familiar with this code area, but
  is it possible that this change could mean that we miss @Specializes
 added
  to the AnnotatedType classes in the super class hierarchy, as you are
  walking up the class objects themselves looking for the annotation?

Re: OWB and generics

2013-07-06 Thread Joseph Bergmark

For some reason I believe the spec specifically says that Object should not
be in the list of types, which I believe is why your plain old java example
isn't valid.

Joe

On Sat, Jul 6, 2013 at 6:57 AM, Arne Limburg
arne.limb...@openknowledge.dewrote:

 Hi Romain,


 In plain old java the assignment does not work either:

 public class MyClassT
 {
   ArrayListT myTList = ...
   ArrayListString myStringList = myTList;
 }

 does not work...

 And if we have an injection point

 @Inject String myString;

 and a Producer

 @Produces Object myObject;

 then they don't match.

 So why should it match with generics?

 Cheers,
 Arne

 Am 06.07.13 12:50 schrieb Romain Manni-Bucau unter
 rmannibu...@gmail.com:

 So i confirm what i said, ArrayListT can be for String, Fooso i
 think
 classes should follow it, just match what i expect since i could do it in
 plain old java
 Le 6 juil. 2013 10:18, Arne Limburg arne.limb...@openknowledge.de a
 écrit :
 
  Forgot to mention that T is an unbound type variable at class level:
 
 
  public class MethodTypeProduces1T
 
  and there is no subclass of MethodTypeProduces1
 
 
  Am 06.07.13 10:12 schrieb Romain Manni-Bucau unter
  rmannibu...@gmail.com:
 
  Wait, not sure google ate a part of the code or not but if a T then T
  can
  be String (like ArrayList itself)
  Le 6 juil. 2013 09:18, Arne Limburg arne.limb...@openknowledge.de
 a
  écrit :
  
   Hi,
  
   I am currently struggling with the handling of generics in OWB,
 because
   CDI 1.1 TCK requires us to be much more clever than we are now in
 this
  area.
   However I stumbled about a test in our test-suite that seems to be
 wrong
   to me, but I would like to have another opinion.
   With my local implementation of the generic handling (which is much
  better
   than the one in trunk) the following tests fails:
   MethodProducer1Test.testPersonProducer
  
   Basically it tests if an ArrayList with an unbound type variable is
   injectable into an injection point of type ArrayListString:
  
   @Produces @Dependent @Named(ProMethodParameterized3)
  
   ArrayListT methodPT3() {...}
  
   and
  
   @Inject ArrayListString pt3;
  
   Reading 5.2.4 of the CDI 1.1 spec (the fourth bullet point) I would
   suggest that this should lead to an error since String is not
 assignable
   from Object (which is the upper bound of T).
  
  
   WDYT?
  
  
   Cheers,
  
   Arne

Re: OWB and generics

2013-07-06 Thread Joseph Bergmark

The e-mail I responded to had a non-generic example with plain old java
object which I specifically mentioned, and that is what I was referring to.

That said, I was incorrect.  Object should be in the list of bean types for
all objects.  The reason that example isn't valid is that the injection
point is specifically for a String and not for anything in String's
hierarchy.  I think the point Arne was trying to make is that you can't
assign less specific things (Object) to more specific type (String) in the
case of non-generics and was comparing that to the rules for generics.

Getting back to the point of the thread, the question is how the
introduction of generic types changes that, which I'll be the first to
admit I don't completely understand. Section 5.2.3 of CDI 1.0, and 5.2.4 of
CDI 1.1 seem to be the key.

Sincerely,

Joe

On Sat, Jul 6, 2013 at 10:47 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 Didnt get your answer, there is no link with Object. A produced generic
 type modelizes all possible subtypes IMO (otherwise it should be forbidden
 cause it doesnt match original java meaning then) + all beans match Object
 in the spec
 Le 6 juil. 2013 15:17, Joseph Bergmark bergm...@apache.org a écrit :

  For some reason I believe the spec specifically says that Object should
 not
  be in the list of types, which I believe is why your plain old java
 example
  isn't valid.
 
  Joe
 
  On Sat, Jul 6, 2013 at 6:57 AM, Arne Limburg
  arne.limb...@openknowledge.dewrote:
 
   Hi Romain,
  
  
   In plain old java the assignment does not work either:
  
   public class MyClassT
   {
 ArrayListT myTList = ...
 ArrayListString myStringList = myTList;
   }
  
   does not work...
  
   And if we have an injection point
  
   @Inject String myString;
  
   and a Producer
  
   @Produces Object myObject;
  
   then they don't match.
  
   So why should it match with generics?
  
   Cheers,
   Arne
  
   Am 06.07.13 12:50 schrieb Romain Manni-Bucau unter
   rmannibu...@gmail.com:
  
   So i confirm what i said, ArrayListT can be for String, Fooso i
   think
   classes should follow it, just match what i expect since i could do it
  in
   plain old java
   Le 6 juil. 2013 10:18, Arne Limburg arne.limb...@openknowledge.de
 a
   écrit :
   
Forgot to mention that T is an unbound type variable at class level:
   
   
public class MethodTypeProduces1T
   
and there is no subclass of MethodTypeProduces1
   
   
Am 06.07.13 10:12 schrieb Romain Manni-Bucau unter
rmannibu...@gmail.com:
   
Wait, not sure google ate a part of the code or not but if a T
  then T
can
be String (like ArrayList itself)
Le 6 juil. 2013 09:18, Arne Limburg 
 arne.limb...@openknowledge.de
  
   a
écrit :

 Hi,

 I am currently struggling with the handling of generics in OWB,
   because
 CDI 1.1 TCK requires us to be much more clever than we are now in
   this
area.
 However I stumbled about a test in our test-suite that seems to
 be
   wrong
 to me, but I would like to have another opinion.
 With my local implementation of the generic handling (which is
 much
better
 than the one in trunk) the following tests fails:
 MethodProducer1Test.testPersonProducer

 Basically it tests if an ArrayList with an unbound type variable
 is
 injectable into an injection point of type ArrayListString:

 @Produces @Dependent @Named(ProMethodParameterized3)

 ArrayListT methodPT3() {...}

 and

 @Inject ArrayListString pt3;

 Reading 5.2.4 of the CDI 1.1 spec (the fourth bullet point) I
 would
 suggest that this should lead to an error since String is not
   assignable
 from Object (which is the upper bound of T).


 WDYT?


 Cheers,

 Arne

Re: [VOTE] take 3: Release Apache OpenWebBeans-1.2.0

2013-05-21 Thread Joseph Bergmark

+1

On Sun, May 19, 2013 at 1:49 AM, Mark Struberg strub...@yahoo.de wrote:

 I'd like to call a 3rd take to VOTE on releasing Apache OpenWebBeans-1.2.0
 .

 This is the first release of the OpenWebBeans-1.2.x branch.
 This release changed many internal mechanics but still targets
 the CDI-1.0 specification.

 Please note that the source binary contains a few non-enabled modules like
 webbeans-cdi11. They do pass RAT though.


 The ReleaseNotes are available online:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12315461

 Maven staging repo:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-013/

 SVN source tag:
 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.0/

 Source Release:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-013/org/apache/openwebbeans/openwebbeans/1.2.0/openwebbeans-1.2.0-source-release.zip

 Binary release:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-013/org/apache/openwebbeans/openwebbeans-distribution/1.2.0/openwebbeans-distribution-1.2.0-binary.zip

 PGP release key 2FDB81B1
 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS

 The VOTE will be open for 72 hours.
 [ ] +1 approve
 [ ] +0 no opinion
 [ ] -1 veto (and reason why)

 LieGrue,
 strub

Re: [VOTE] Release Apache OpenWebBeans build-tools 1.3

2013-05-16 Thread Joseph Bergmark

+1

On Thu, May 16, 2013 at 5:05 AM, Gerhard Petracek 
gerhard.petra...@gmail.com wrote:

 +1

 regards,
 gerhard



 2013/5/14 Mark Struberg strub...@yahoo.de

  Hi!
 
  This is now a split VOTE for owb-build-tools-1.3
 
  The stating repo is up here:
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-016/
 
 
  The sources can be found at
 
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-016/org/apache/openwebbeans/build-tools/checkstyle-rules/1.3/checkstyle-rules-1.3-source-release.zip
 
  The tag in SVN is here
 
 
 
 https://svn.apache.org/repos/asf/openwebbeans/build-tools/tags/checkstyle-rules-1.3/
  The VOTE will be open for 72 hours.
  [ ] +1 approve
  [ ] +0 no opinion
  [ ] -1 veto (and reason why)
 
  LieGrue,
  strub

Re: svn commit: r1481253 - in /openwebbeans/trunk/webbeans-impl/src: main/java/org/apache/webbeans/portable/AnnotatedTypeImpl.java test/java/org/apache/webbeans/portable/AnnotatedTypeImplTest.java

2013-05-11 Thread Joseph Bergmark

On a side note, if you are creating fake beans by using
BeanManager.createInjectionTarget, at one point it had a side affect of
registering ObserMethodImpls with the NotificantManager.

Joe

On Sat, May 11, 2013 at 5:05 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 To explain a bit for people not having the details:

 Basically AT are not thread safe but owb startup objects by app neither. So
 that s ok.

 Then if we want it thread safe at runtime we should make AT immutable after
 startup and not do anything lazily.

 Finally if it was a fix for tomee please David show me it is the
 casewas the case because we were constructing fake beans at runtime but
 since i ensured it was thread safe now it is no more an issue.
 Le 11 mai 2013 10:23, Romain Manni-Bucau rmannibu...@gmail.com a
 écrit :

  Should be reverted IMO
  Le 11 mai 2013 05:21, dblev...@apache.org a écrit :
 
  Author: dblevins
  Date: Sat May 11 03:20:48 2013
  New Revision: 1481253
 
  URL: http://svn.apache.org/r1481253
  Log:
  OWB-858: AnnotatedTypeImpl not thread safe
  Fixed
 
  Modified:
 
 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/portable/AnnotatedTypeImpl.java
 
 
 openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/portable/AnnotatedTypeImplTest.java
 
  Modified:
 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/portable/AnnotatedTypeImpl.java
  URL:
 
 http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/portable/AnnotatedTypeImpl.java?rev=1481253r1=1481252r2=1481253view=diff
 
 
 ==
  ---
 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/portable/AnnotatedTypeImpl.java
  (original)
  +++
 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/portable/AnnotatedTypeImpl.java
  Sat May 11 03:20:48 2013
  @@ -28,6 +28,10 @@ import java.util.Collections;
   import java.util.HashSet;
   import java.util.List;
   import java.util.Set;
  +import java.util.concurrent.Callable;
  +import java.util.concurrent.ExecutionException;
  +import java.util.concurrent.FutureTask;
  +import java.util.concurrent.atomic.AtomicBoolean;
 
   import javax.enterprise.inject.spi.AnnotatedConstructor;
   import javax.enterprise.inject.spi.AnnotatedField;
  @@ -72,6 +76,19 @@ class AnnotatedTypeImplX
*/
   private SetAnnotatedMethod? super X methods = null;
 
  +private final AtomicBoolean notInitialized = new
 AtomicBoolean(true);
  +
  +private final FutureTask initializer = new FutureTask(new
 Callable()
  +{
  +public Object call()
  +throws Exception
  +{
  +init();
  +return null;
  +}
  +});
  +
  +
   /**
* Creates a new instance.
*
  @@ -192,11 +209,43 @@ class AnnotatedTypeImplX
*/
   void addAnnotatedConstructor(AnnotatedConstructorX constructor)
   {
  -if (constructors == null)
  +ensureInitialized();
  +constructors.add(constructor);
  +}
  +
  +private void ensureInitialized()
  +{
  +try
   {
  -init();
  +if (notInitialized.get())
  +{
  +do
  +{
  +// If this thread is the one to set the state to
  notInitialized=false,
  +// then this thread is also responsible for calling
  the initializer
  +if (notInitialized.compareAndSet(true, false))
  +{
  +initializer.run();
  +}
  +
  +// Try again.
  +}
  +while (notInitialized.get());
  +}
  +
  +// This is the magic blocking call that protects our read
  access
  +// The 'get' call will not return until the initializer has
  finished running
  +initializer.get();
  +}
  +catch (InterruptedException e)
  +{
  +Thread.interrupted();
  +throw new IllegalStateException(Lazy Initialization of
  AnnotatedType failed., e);
  +}
  +catch (ExecutionException e)
  +{
  +throw new IllegalStateException(Lazy Initialization of
  AnnotatedType failed., e);
   }
  -constructors.add(constructor);
   }
 
   /**
  @@ -206,10 +255,7 @@ class AnnotatedTypeImplX
*/
   void addAnnotatedField(AnnotatedField? super X field)
   {
  -if (constructors == null)
  -{
  -init();
  -}
  +ensureInitialized();
   fields.add(field);
   }
 
  @@ -220,10 +266,7 @@ class AnnotatedTypeImplX
*/
   void addAnnotatedMethod(AnnotatedMethod? super X method)
   {
  -if (constructors == null)
  -{
  -init();
  -}
  +

Re: classloader resolution

2013-04-04 Thread Joseph Bergmark

I like the idea of a flexible ClassLoaderResolverService, as long as can
obtain the information about the bean class (if any) and interfaces.  I'm
not sure if just knowing the WebBeansContext is enough.

For the old javassist proxies, one trick was using the bean class as long
as that classloader also had visibility to the necessary proxy
infrastructure classes (javassist.proxy.ProxyFactory I think was the key
one).  Otherwise I think we would fall back on using the TCCL which was
normally the module classloader.

I'm not familiar with the new proxy code, but I wonder if we have a similar
dependency.


On Thu, Apr 4, 2013 at 7:09 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote:

 Hi,

 just created https://issues.apache.org/jira/browse/OWB-812

 the issue is: how to get the right classloader for a Bean? when creating
 a proxy.

 ATM we use the bean class classloader but it will likely fail in a bunch of
 JavaEE server and OSGi.

 I thought to add a ClassLoaderResolverService (or sthg like it) or
 (probably better) link a ClassLoader to each WebBeansContext

 wdyt?

 *Romain Manni-Bucau*
 *Twitter: @rmannibucau https://twitter.com/rmannibucau*
 *Blog: **http://rmannibucau.wordpress.com/*
 http://rmannibucau.wordpress.com/
 *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*

Re: classloader resolution

2013-04-04 Thread Joseph Bergmark

I think the problem with using the TCCL all the time is that it will likely
be the module classloader, but the class we are proxying could exist in a
shared library of some form (ear/lib for example).  That would mean the
proxy class would end up defined in the different classloader than the
class it is proxying and therefore it wouldn't be able to override package
private methods.


On Thu, Apr 4, 2013 at 9:32 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote:

 using TCCL sounds fine too

 *Romain Manni-Bucau*
 *Twitter: @rmannibucau https://twitter.com/rmannibucau*
 *Blog: **http://rmannibucau.wordpress.com/*
 http://rmannibucau.wordpress.com/
 *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*



 2013/4/4 Joseph Bergmark bergm...@gmail.com

  I like the idea of a flexible ClassLoaderResolverService, as long as can
  obtain the information about the bean class (if any) and interfaces.  I'm
  not sure if just knowing the WebBeansContext is enough.
 
  For the old javassist proxies, one trick was using the bean class as long
  as that classloader also had visibility to the necessary proxy
  infrastructure classes (javassist.proxy.ProxyFactory I think was the key
  one).  Otherwise I think we would fall back on using the TCCL which was
  normally the module classloader.
 
  I'm not familiar with the new proxy code, but I wonder if we have a
 similar
  dependency.
 
 
  On Thu, Apr 4, 2013 at 7:09 AM, Romain Manni-Bucau 
 rmannibu...@gmail.com
  wrote:
 
   Hi,
  
   just created https://issues.apache.org/jira/browse/OWB-812
  
   the issue is: how to get the right classloader for a Bean? when
  creating
   a proxy.
  
   ATM we use the bean class classloader but it will likely fail in a
 bunch
  of
   JavaEE server and OSGi.
  
   I thought to add a ClassLoaderResolverService (or sthg like it) or
   (probably better) link a ClassLoader to each WebBeansContext
  
   wdyt?
  
   *Romain Manni-Bucau*
   *Twitter: @rmannibucau https://twitter.com/rmannibucau*
   *Blog: **http://rmannibucau.wordpress.com/*
   http://rmannibucau.wordpress.com/
   *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
   *Github: https://github.com/rmannibucau*

Re: interface, generics and interceptors

2013-04-03 Thread Joseph Bergmark

This looks like it might be the same as:
https://issues.apache.org/jira/browse/OWB-706

If so, the quick fix for Javassist based proxies is to add an exclusion for
bridge methods in our methodFilter.  I haven't looked at this for our
alternative proxy code.


On Wed, Apr 3, 2013 at 4:37 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote:

 Hi,

 here a test failling on owb_1.1.x (didn't test on trunk) with a fix inside
 the patch: https://gist.github.com/rmannibucau/0ce63358ce5a9b350405

 the case is basically calling an interface and when the invocation is done
 the impl have an interceptor binding defined (+ generics ;) - maybe look
 InheritanceWithGenericAsReturnedTypeTest in the patch to get a better idea
 of the issue, the failling assert ATM is assertNotNull(child.it(null));.

 It currently fails on owb_1.1.x and works on some weld servers.

 The question is: do we want to support it or not?

 *Romain Manni-Bucau*
 *Twitter: @rmannibucau https://twitter.com/rmannibucau*
 *Blog: **http://rmannibucau.wordpress.com/*
 http://rmannibucau.wordpress.com/
 *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*

Re: The pittfalls of ClassLoaders for proxies

2013-01-27 Thread Joseph Bergmark

Sorry for the late response, but I don't think you have to worry about
the hierarchical class loader scenario you described below.

At least in the server I'm aware of, the modules classloaders all
delegate up to the shared classloader.  If they didn't then each
module classloader would be loading a unique copy of that class, which
would defeat the purpose of having a shared library in the first
place.

Sincerely,

Joe

On Tue, Jan 22, 2013 at 6:33 AM, Mark Struberg strub...@yahoo.de wrote:
 Hi folks!

 A small culprit I found in our proxy code yesterday night:

 Consider the following (the 'protected' is important!)

 public class User {
   protected String getName() { return Hans;}
 }

 User$Proxy extends User
private User delegate;

   protected String getName {
 return delegate.getName();
   }
 }


 This code works perfect! But only as long as the User$Proxy and User classes 
 are loaded with the same ClassLoader. According to the JVM 2 classes are only 
 considered to be in the same package (and thus allows for protected access) 
 if they are loaded by the same ClassLoader.
 This is what caused problems in Javassist as well, and there we had to do 
 some weird hacks with the ClassLoaderProvider factory.

 The solution I did now is the following: I use the ClassLoader of the 
 original class to define the Proxy. This works perfectly fine, but only as 
 long as we don't proxy classes which are not meant to be 'shared'.  Imagine a 
 full-profile EE server where you have e.g. MyFaces in the servers lib folder, 
 which would result in a ClassLoader hierarchy similar to:

 SystemClassLoader
  - EE-server-internal (contains myfaces-*.jar)
 - EE-server-lib
   - EAR-A -warA1, warA2, etc
   - EAR-B -warB1, warB2, etc

 But any proxies for e.g. javax.faces.context.FacesContext should not be 
 loaded with the EE-server-internal ClassLoader but maximum with EAR-A or 
 EAR-B ClassLoaders.


 This means we should introduce an upper boundary ClassLoader detection 
 somehow. We might need the same for the HierarchicScannerService as well btw.

 I already added a detection if proxyClassLoader != proxiedClassClassLoader 
 and in that case I skip the proxying of protected methods. We might also 
 automatically switch to using reflection in that case, but this is imo not 
 required by the specs.

 Any objections? Any ideas?


 LieGrue,
 strub

Re: [VOTE] release OpenWebBeans-1.1.6

2012-12-06 Thread Joseph Bergmark

+1

On Thu, Dec 6, 2012 at 9:16 AM, Jean-Louis MONTEIRO jeano...@gmail.com wrote:
 +1

 Thanks again Mark.

 JLouis


 2012/12/6 Romain Manni-Bucau rmannibu...@gmail.com

 otherwise it seems fine for me and all TCK passed (even in tomee/openejb)

 +1

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/6 Mark Struberg strub...@yahoo.de:
  This is just them being wrongly tagged in JIRA.
 
  Will fix this there.
 
  LieGrue,
  strub
 
 
 
  - Original Message -
  From: Romain Manni-Bucau rmannibu...@gmail.com
  To: dev@openwebbeans.apache.org; Mark Struberg strub...@yahoo.de
  Cc:
  Sent: Wednesday, December 5, 2012 10:50 PM
  Subject: Re: [VOTE] release OpenWebBeans-1.1.6
 
  Mark,
 
  i think these improvements are not in the branch:
 
  [OWB-715] - Remove EL22 implementation from Core to Own Project
  [OWB-717] - Remove Failover implementation from Web to Own Project
 
  not blocking for the vote but the release note should be fixed
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
 
  2012/12/5 Mark Struberg strub...@yahoo.de:
   Hi!
   I'd like to call a VOTE on releasing Apache OpenWebBeans-1.1.7.
   This is a bugfix release of OpenWebBeans-1.1.x in the owb_1.1.x
 branch. It
  mainly contains compatibility/portability/performance improvements and
 small
  bugfixes.
 
   The ReleaseNotes are available online:
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12323362
 
 
   Maven staging repo:
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-117/
 
 
   SVN source tag :
 
 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.7/
 
 
   Source release:
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-117/org/apache/openwebbeans/openwebbeans/1.1.7/openwebbeans-1.1.7-source-release.zip
 
 
   Binary release:
 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-117/org/apache/openwebbeans/openwebbeans-distribution/1.1.7/openwebbeans-distribution-1.1.7-binary.tar.gz
 
 
   PGP release key 2FDB81B1
   http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS
 
 
   The VOTE will be open for 72 hours.
   [ ] +1 approve
   [ ] +0 no opinion
   [ ] -1 veto (and reason why)
 
   LieGrue,
   strub
 
 




 --
 Jean-Louis

Re: CDI-1.1 module handling

2012-11-27 Thread Joseph Bergmark

It doesn't sound incredibly dissimilar from the behavior that can be
enabled by turning on the by the use bda beans.xml scanner flag.  I
think currently that flag only controls interceptors, decorators 
alternatives based on what bean is being injected, but it could
feasibly also be aware of relationships between bdas and visibility
for injection purposes.

Sincerely,

Joe

On Tue, Nov 27, 2012 at 9:48 AM, Mark Struberg strub...@yahoo.de wrote:
 Hi folks!

 There is currently a VOTE on the CDI EG about how to implement modularity.
 It looks like a horizontal isolation approach will be selected.

 I personally don't like that as this will NOT be backward compatible. 
 Currently the BeanManager of the WebApp which receives the request will 
 determine the Beans and Contextual Instances resolved for InjectionPoints and 
 the Proxies.

 The EG likes to change this to switching the 'responsible' BeanManager 
 depending on the JAR you are in. Similar to what EJBs do with switching the 
 ThreadContextClassLoader.


 I'm not yet sure how to implement this to be honest. E.g. it's absolutely 
 impossible to do this for @Dependent Beans which gets created in a 
 producerMethod or field. @Dependent scoped beans do not have any proxy to 
 switch the TCCL around. I'm also strictly -1 for all this stuff in 
 performance hindsight. It will e.g. not be possible anymore to do some Bean 
 and instance caching in our resolvers and proxies. So we will be 5x slower in 
 this modus...


 At the end of the day we will need to implement a mode which is spec 
 compatible at least. But noone says that this must be the preferred modus for 
 OWB!


 I'll keep you updated about the final decision.

 LieGrue,
 strub

Re: Method in OpenWebBeansEjbPlugin

2012-11-08 Thread Joseph Bergmark

I believe this method is used to take the actual method annotated and
find which method that corresponds to in an EJB interface.  The one
place I see it used in the code is DefinitionUtil when its trying to
determine the producer/disposer methods.  I believe the concern is the
proxy that is built by the EJB container can only validly be called
from methods on the interface but not the method from the concrete
class (unless it is a NIV EJB).

svn blame seems to hint that David changed these lines most recently,
so I would defer to him on this.

Sincerely,

Joe

On Thu, Nov 8, 2012 at 3:50 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
 Hello

 There is a method Method resolveViewMethod(Bean? component, Method 
 declaredMethod); in OpenWebBeansEjbPlugin? What is the meaning of this 
 method? No comment there.


 Gurkan

Re: [VOTE] [take-2] release Apache OpenWebBeans 1.1.6

2012-09-27 Thread Joseph Bergmark

+1

On Tue, Sep 25, 2012 at 6:22 PM, Mark Struberg strub...@yahoo.de wrote:


  Hi!

 I'd again like to call a VOTE on releasing Apache OpenWebBeans-1.1.6 . I 
 fixed the issues which stopped our first attempt

 This
 is a bugfix release of OpenWebBeans-1.1.x, thus no branch has been
 created. It mainly contains compatibility/portability/performance
 improvements and small bugfixes.

 The ReleaseNotes are available online:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12322963


 Maven staging repo:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-043/


 SVN source tag (r 1390181):

 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.6/


 Source release:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-043/org/apache/openwebbeans/openwebbeans/1.1.6/openwebbeans-1.1.6-source-release.zip


 Binary release:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-043/org/apache/openwebbeans/openwebbeans-distribution/1.1.6/openwebbeans-distribution-1.1.6-binary.tar.gz


 PGP release key 2FDB81B1

 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS


 The VOTE will be open for 72 hours.

 [ ] +1 approve
 [ ] +0 no opinion
 [ ] -1 veto (and reason why)

 LieGrue,
 strub

Re: Eclipse/Checkstyle errors

2012-09-15 Thread Joseph Bergmark

Which test classes are you getting check style errors in?  When I
build on the command line I don't see any check style errors:

[INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
openwebbeans-web ---
[INFO]
[INFO]


[INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
openwebbeans-impl ---
[INFO]
[INFO]

etc..

Sincerely,

Joe

On Sat, Sep 15, 2012 at 12:26 PM, Thomas Andraschko zoi...@gmail.com wrote:
 Hi,

 we have many checkstyle errors (not warnings) in the test classes.
 Can i fix them or should i exclude (don't know if possible in Eclipse) the
 test classes from checkstyle?
 The most errors are { should be on a new line and naming errors of
 constants and variables.

 Also i have many eclipse errors that @PostConstruct, @PreDestory,
 @WebServiceRef etc are not accessible.
 Can we add this APIs with provided scope or is there any better solution?

 Regards,
 Thomas

Re: Eclipse/Checkstyle errors

2012-09-15 Thread Joseph Bergmark

I haven't used the checkstyle plugin for Eclipse, so afraid I can't
provide much advice here.  Its too bad it doesn't appear to follow the
same rules as the maven plugin.

Sincerely,

Joe

On Sat, Sep 15, 2012 at 1:15 PM, Thomas Andraschko zoi...@gmail.com wrote:
 It's only in test-classes because the won't be checked by maven.
 For example - AbstractUnitTest#addExtension

 2012/9/15 Joseph Bergmark bergm...@apache.org

 Which test classes are you getting check style errors in?  When I
 build on the command line I don't see any check style errors:

 [INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
 openwebbeans-web ---
 [INFO]
 [INFO]


 [INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
 openwebbeans-impl ---
 [INFO]
 [INFO]

 etc..

 Sincerely,

 Joe

 On Sat, Sep 15, 2012 at 12:26 PM, Thomas Andraschko zoi...@gmail.com
 wrote:
  Hi,
 
  we have many checkstyle errors (not warnings) in the test classes.
  Can i fix them or should i exclude (don't know if possible in Eclipse)
 the
  test classes from checkstyle?
  The most errors are { should be on a new line and naming errors of
  constants and variables.
 
  Also i have many eclipse errors that @PostConstruct, @PreDestory,
  @WebServiceRef etc are not accessible.
  Can we add this APIs with provided scope or is there any better solution?
 
  Regards,
  Thomas

Re: Fw: [DISCUSS] release OWB-1.1.6 end of this week?

2012-09-12 Thread Joseph Bergmark

I started to review the patch, and the changes I saw looked good, but
there is so much whitespace reformatting in that patch that its hard
to focus on just the implementation changes.

Sincerely,

Joe

On Wed, Sep 12, 2012 at 2:24 PM, Thomas Andraschko zoi...@gmail.com wrote:
 Hi Mark,

 it's already fixed but i attached an patch with some refactoring +
 unittests to #OWB-702.
 I know that i could commit it but it would be great if anyone could review
 it :)

 Regards,
 Thomas

 2012/9/12 Mark Struberg strub...@yahoo.de

 2nd try as my previous got eaten by the spam filter :/





 - Forwarded Message -
 From: Mark Struberg strub...@yahoo.de
 To: openwebbeans-dev dev@openwebbeans.apache.org
 Sent: Wednesday, September 12, 2012 7:49 PM
 Subject: [DISCUSS] releaese OWB-1.1.6 end of this week?
 
 
 Hi folks!
 
 I would like to start with a hot-fix release of OWB (version 1.1.6) end
 of this week.
 Thomas, is this an ok timeframe in which you can fix the issues you
 needed for your production?
 
 LIeGrue,
 strub

Re: [ANN] Welcome Thomas Andraschko as OpenWebBeans committer!

2012-09-12 Thread Joseph Bergmark

Welcome!

On Wed, Sep 12, 2012 at 2:11 PM, Romain Manni-Bucau
rmannibu...@gmail.com wrote:
 Welcome Thomas!

 *Romain Manni-Bucau*
 *Twitter: @rmannibucau*
 *Blog: http://rmannibucau.wordpress.com*




 2012/9/12 Mark Struberg strub...@yahoo.de



 Hi community!

 I'm happy to announce that Thomas will help us with making OWB even better.
 He is an expert on passivation and clustering and uses OWB in production
 for a few projects.

 Welcome Thomas!


 The Apache OpenWebBeans PMC

Re: Fw: [DISCUSS] release OWB-1.1.6 end of this week?

2012-09-12 Thread Joseph Bergmark

I'm not at all sure whats leading to the whitespace differences.  Do
you use Eclipse?  If so I can send you the eclipse formatter that
Gurkan sent me a couple years back.

Sincerely,

Joe

On Wed, Sep 12, 2012 at 2:38 PM, Thomas Andraschko zoi...@gmail.com wrote:
 i know, sorry. Should i deactivate remove trailing spaces in my IDE?

 2012/9/12 Joseph Bergmark bergm...@apache.org

 I started to review the patch, and the changes I saw looked good, but
 there is so much whitespace reformatting in that patch that its hard
 to focus on just the implementation changes.

 Sincerely,

 Joe

 On Wed, Sep 12, 2012 at 2:24 PM, Thomas Andraschko zoi...@gmail.com
 wrote:
  Hi Mark,
 
  it's already fixed but i attached an patch with some refactoring +
  unittests to #OWB-702.
  I know that i could commit it but it would be great if anyone could
 review
  it :)
 
  Regards,
  Thomas
 
  2012/9/12 Mark Struberg strub...@yahoo.de
 
  2nd try as my previous got eaten by the spam filter :/
 
 
 
 
 
  - Forwarded Message -
  From: Mark Struberg strub...@yahoo.de
  To: openwebbeans-dev dev@openwebbeans.apache.org
  Sent: Wednesday, September 12, 2012 7:49 PM
  Subject: [DISCUSS] releaese OWB-1.1.6 end of this week?
  
  
  Hi folks!
  
  I would like to start with a hot-fix release of OWB (version 1.1.6) end
  of this week.
  Thomas, is this an ok timeframe in which you can fix the issues you
  needed for your production?
  
  LIeGrue,
  strub

Re: svn commit: r1363887 - /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/logger/WebBeansLoggerFacade.java

2012-09-10 Thread Joseph Bergmark

That makes perfect sense, thanks!

On Mon, Sep 10, 2012 at 1:07 AM, Romain Manni-Bucau
rmannibu...@gmail.com wrote:
 Hi,

 Yeah it does exactly the same but the code is in a static block so it is
 executed when the class is loaded and the imports between both classes make
 it fail (circular dep). I didnt like to copy paste the code but it is a
 sure way to avoid linkageerror.

 About java 2 sec you are right it is ignored here.

 - Romain
 Le 10 sept. 2012 02:34, Joseph Bergmark bergm...@apache.org a écrit :

 I know was well over a month ago, but do you remember why:

  WebBeansUtil.getCurrentClassLoader().loadClass(factoryClassname)

 is problematic, but a direct call to:

 ClassLoader classloader = Thread.currentThread().getContextClassLoader();

 is not?  They appear basically the same.  Unless I'm missing
 something, both will fail when java 2 security is enabled as there
 doesn't appear to be a doPriv block or a hook into the security
 service.

 Sincerely,

 Joe

 On Fri, Jul 20, 2012 at 2:18 PM,  rmannibu...@apache.org wrote:
  Author: rmannibucau
  Date: Fri Jul 20 18:18:25 2012
  New Revision: 1363887
 
  URL: http://svn.apache.org/viewvc?rev=1363887view=rev
  Log:
  OWB-674 avoiding classes dependency which can fail with some JVM
 
  Modified:
 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/logger/WebBeansLoggerFacade.java
 
  Modified:
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/logger/WebBeansLoggerFacade.java
  URL:
 http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/logger/WebBeansLoggerFacade.java?rev=1363887r1=1363886r2=1363887view=diff
 
 ==
  ---
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/logger/WebBeansLoggerFacade.java
 (original)
  +++
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/logger/WebBeansLoggerFacade.java
 Fri Jul 20 18:18:25 2012
  @@ -23,7 +23,6 @@ package org.apache.webbeans.logger;
*/
 
   import org.apache.webbeans.config.OWBLogConst;
  -import org.apache.webbeans.util.WebBeansUtil;
 
   import java.text.MessageFormat;
   import java.util.Locale;
  @@ -57,7 +56,14 @@ public final class WebBeansLoggerFacade
   {
   try
   {
  -Class? factoryClazz =
 WebBeansUtil.getCurrentClassLoader().loadClass(factoryClassname);
  +// don't use the
 org.apache.webbeans.util.WebBeansUtil.getCurrentClassLoader()
  +// to avoid weird dependency and potential failing
  +ClassLoader classloader =
 Thread.currentThread().getContextClassLoader();
  +if(classloader == null)
  +{
  +classloader =
 WebBeansLoggerFacade.class.getClassLoader();
  +}
  +Class? factoryClazz =
 classloader.loadClass(factoryClassname);
   factory = (WebBeansLoggerFactory)
 factoryClazz.newInstance();
   }
   catch (Exception e)

Re: svn commit: r1363887 - /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/logger/WebBeansLoggerFacade.java

2012-09-09 Thread Joseph Bergmark

I know was well over a month ago, but do you remember why:

 WebBeansUtil.getCurrentClassLoader().loadClass(factoryClassname)

is problematic, but a direct call to:

ClassLoader classloader = Thread.currentThread().getContextClassLoader();

is not?  They appear basically the same.  Unless I'm missing
something, both will fail when java 2 security is enabled as there
doesn't appear to be a doPriv block or a hook into the security
service.

Sincerely,

Joe

On Fri, Jul 20, 2012 at 2:18 PM,  rmannibu...@apache.org wrote:
 Author: rmannibucau
 Date: Fri Jul 20 18:18:25 2012
 New Revision: 1363887

 URL: http://svn.apache.org/viewvc?rev=1363887view=rev
 Log:
 OWB-674 avoiding classes dependency which can fail with some JVM

 Modified:
 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/logger/WebBeansLoggerFacade.java

 Modified: 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/logger/WebBeansLoggerFacade.java
 URL: 
 http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/logger/WebBeansLoggerFacade.java?rev=1363887r1=1363886r2=1363887view=diff
 ==
 --- 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/logger/WebBeansLoggerFacade.java
  (original)
 +++ 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/logger/WebBeansLoggerFacade.java
  Fri Jul 20 18:18:25 2012
 @@ -23,7 +23,6 @@ package org.apache.webbeans.logger;
   */

  import org.apache.webbeans.config.OWBLogConst;
 -import org.apache.webbeans.util.WebBeansUtil;

  import java.text.MessageFormat;
  import java.util.Locale;
 @@ -57,7 +56,14 @@ public final class WebBeansLoggerFacade
  {
  try
  {
 -Class? factoryClazz = 
 WebBeansUtil.getCurrentClassLoader().loadClass(factoryClassname);
 +// don't use the 
 org.apache.webbeans.util.WebBeansUtil.getCurrentClassLoader()
 +// to avoid weird dependency and potential failing
 +ClassLoader classloader = 
 Thread.currentThread().getContextClassLoader();
 +if(classloader == null)
 +{
 +classloader = 
 WebBeansLoggerFacade.class.getClassLoader();
 +}
 +Class? factoryClazz = 
 classloader.loadClass(factoryClassname);
  factory = (WebBeansLoggerFactory) factoryClazz.newInstance();
  }
  catch (Exception e)

Re: [VOTE] release Apache OpenWebBeans 1.1.5

2012-08-09 Thread Joseph Bergmark

+1

On Wed, Aug 8, 2012 at 7:01 PM, Mark Struberg strub...@yahoo.de wrote:


 Hi!


 I'd like to call a VOTE on releasing Apache OpenWebBeans-1.1.5 .

 This is a bugfix release of OpenWebBeans-1.1.x, thus no branch has been 
 created.
 It mainly contains compatibility/portability/performance improvements and 
 small
 bugfixes.

 The ReleaseNotes are available online:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12320753

 Maven staging repo:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-126/


 SVN source tag (1309597):
 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.5/


 Source release:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-126/org/apache/openwebbeans/openwebbeans/1.1.5/openwebbeans-1.1.5-source-release.zip


 Binary release:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-126/org/apache/openwebbeans/openwebbeans-distribution/1.1.5/openwebbeans-distribution-1.1.5-binary.tar.gz


 PGP release key 2FDB81B1
 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS


 The VOTE will be open for 72 hours.

 [ ] +1 approve

 [ ] +0 no opinion

 [ ] -1 veto (and reason why)


 LieGrue,
 strub

Re: Build failed in Jenkins: OpenWebBeans_1.0.x #448

2012-02-29 Thread Joseph Bergmark

I did a little bit of poking around, and it appears this repository
has been taken down.  I think we need to update to point to the new
repositories here:
https://community.jboss.org/wiki/MavenRepository

If anyone has time to dig in, please feel free.  Otherwise I'll spend
some more time trying to sort out what needs to change tonight.

Sincerely,

Joe

On Tue, Feb 28, 2012 at 7:38 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
 See https://builds.apache.org/job/OpenWebBeans_1.0.x/448/

 --
 [...truncated 4380 lines...]
 [INFO] [INFO] Using 'UTF-8' encoding to copy filtered resources.
 [INFO] Copying 0 resource
 [INFO] Copying 3 resources

 [INFO] --- maven-resources-plugin:2.4:testResources (default-testResources) @ 
 openwebbeans-resource ---
 [INFO] [INFO] Nothing to compile - all classes are up to date

 [INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ 
 openwebbeans-resource ---
 [INFO] [INFO] Surefire report directory: 
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/target/surefire-reports

 [INFO] --- maven-surefire-plugin:2.6:test (default-test) @ 
 openwebbeans-resource ---

 ---
  T E S T S
 ---
 There are no tests to run.

 Results :

 Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

 [JENKINS] Recording test results
 [INFO]
 [INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ openwebbeans-resource 
 ---
 [INFO] Building jar: 
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/target/openwebbeans-resource-1.0.1-SNAPSHOT.jar
 Feb 29, 2012 12:37:53 AM hudson.maven.ExecutedMojo init
 WARNING: Failed to getClass for org.apache.maven.plugin.source.SourceJarMojo
 [INFO]
 [INFO] --- maven-source-plugin:2.1.2:jar (default) @ openwebbeans-resource ---
 [INFO] META-INF already added, skipping
 [INFO] META-INF/LICENSE already added, skipping
 [INFO] META-INF/DEPENDENCIES already added, skipping
 [INFO] META-INF/NOTICE already added, skipping
 [INFO] Building jar: 
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/target/openwebbeans-resource-1.0.1-SNAPSHOT-sources.jar
 [INFO] META-INF already added, skipping
 [INFO] META-INF/LICENSE already added, skipping
 [INFO] META-INF/DEPENDENCIES already added, skipping
 [INFO] META-INF/NOTICE already added, skipping
 [INFO]
 [INFO] --- maven-checkstyle-plugin:2.6:check (verify-style) @ 
 openwebbeans-resource ---
 [INFO]
 [INFO] [INFO] Exclude: **/*/MANIFEST.MF
 [INFO] Exclude: .git
 [INFO] Exclude: .gitignore

 [INFO] --- apache-rat-plugin:0.7:check (default) @ openwebbeans-resource ---
 [INFO] [INFO] Installing 
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/target/openwebbeans-resource-1.0.1-SNAPSHOT.jar
  to 
 /home/hudson/hudson-slave/maven-repositories/0/org/apache/openwebbeans/openwebbeans-resource/1.0.1-SNAPSHOT/openwebbeans-resource-1.0.1-SNAPSHOT.jar
 [INFO] Installing 
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/pom.xml
  to 
 /home/hudson/hudson-slave/maven-repositories/0/org/apache/openwebbeans/openwebbeans-resource/1.0.1-SNAPSHOT/openwebbeans-resource-1.0.1-SNAPSHOT.pom
 [INFO] Installing 
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/target/openwebbeans-resource-1.0.1-SNAPSHOT-sources.jar
  to 
 /home/hudson/hudson-slave/maven-repositories/0/org/apache/openwebbeans/openwebbeans-resource/1.0.1-SNAPSHOT/openwebbeans-resource-1.0.1-SNAPSHOT-sources.jar

 [INFO] --- maven-install-plugin:2.3:install (default-install) @ 
 openwebbeans-resource ---
 [JENKINS] Archiving 
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/pom.xml
  to 
 /home/hudson/hudson/jobs/OpenWebBeans_1.0.x/modules/org.apache.openwebbeans$openwebbeans-resource/builds/2012-02-29_00-35-56/archive/org.apache.openwebbeans/openwebbeans-resource/1.0.1-SNAPSHOT/openwebbeans-resource-1.0.1-SNAPSHOT.pom
 [JENKINS] Archiving 
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/target/openwebbeans-resource-1.0.1-SNAPSHOT.jar
  to 
 /home/hudson/hudson/jobs/OpenWebBeans_1.0.x/modules/org.apache.openwebbeans$openwebbeans-resource/builds/2012-02-29_00-35-56/archive/org.apache.openwebbeans/openwebbeans-resource/1.0.1-SNAPSHOT/openwebbeans-resource-1.0.1-SNAPSHOT.jar
 [JENKINS] Archiving 
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/target/openwebbeans-resource-1.0.1-SNAPSHOT-sources.jar
  to 
 /home/hudson/hudson/jobs/OpenWebBeans_1.0.x/modules/org.apache.openwebbeans$openwebbeans-resource/builds/2012-02-29_00-35-56/archive/org.apache.openwebbeans/openwebbeans-resource/1.0.1-SNAPSHOT/openwebbeans-resource-1.0.1-SNAPSHOT-sources.jar
 [INFO]
 [INFO] 
 
 [INFO]

Re: Build failed in Jenkins: OpenWebBeans_1.0.x #448

2012-02-29 Thread Joseph Bergmark

Why would his change cause:

Caused by: org.apache.maven.wagon.authorization.AuthorizationException:
Access denied to:
http://repository.jboss.org/maven2/org/jboss/test-harness/jboss-test-harness-api/1.1.0-CR5/jboss-test-harness-api-1.1.0-CR5.pom
   at 
org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:342)
   at 
org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:584)
   at 
org.sonatype.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:64)

Sincerely,

Joe

On Wed, Feb 29, 2012 at 12:21 PM, Mark Struberg strub...@yahoo.de wrote:
 Hi Joe!

 I think this has to do with the ThreadLocal stuff Rohit cleaned up. We 
 (Romain and I)fixed this in trunk already but I found no time to also apply 
 the patch to this branch. But it's on my list!

 LieGrue,
 strub



 - Original Message -
 From: Joseph Bergmark bergm...@apache.org
 To: dev@openwebbeans.apache.org
 Cc:
 Sent: Wednesday, February 29, 2012 3:56 PM
 Subject: Re: Build failed in Jenkins: OpenWebBeans_1.0.x #448

 I did a little bit of poking around, and it appears this repository
 has been taken down.  I think we need to update to point to the new
 repositories here:
 https://community.jboss.org/wiki/MavenRepository

 If anyone has time to dig in, please feel free.  Otherwise I'll spend
 some more time trying to sort out what needs to change tonight.

 Sincerely,

 Joe

 On Tue, Feb 28, 2012 at 7:38 PM, Apache Jenkins Server
 jenk...@builds.apache.org wrote:
  See https://builds.apache.org/job/OpenWebBeans_1.0.x/448/

  --
  [...truncated 4380 lines...]
  [INFO] [INFO] Using 'UTF-8' encoding to copy filtered resources.
  [INFO] Copying 0 resource
  [INFO] Copying 3 resources

  [INFO] --- maven-resources-plugin:2.4:testResources (default-testResources)
 @ openwebbeans-resource ---
  [INFO] [INFO] Nothing to compile - all classes are up to date

  [INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @
 openwebbeans-resource ---
  [INFO] [INFO] Surefire report directory:
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/target/surefire-reports

  [INFO] --- maven-surefire-plugin:2.6:test (default-test) @
 openwebbeans-resource ---

  ---
   T E S T S
  ---
  There are no tests to run.

  Results :

  Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

  [JENKINS] Recording test results
  [INFO]
  [INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ openwebbeans-resource
 ---
  [INFO] Building jar:
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/target/openwebbeans-resource-1.0.1-SNAPSHOT.jar
  Feb 29, 2012 12:37:53 AM hudson.maven.ExecutedMojo init
  WARNING: Failed to getClass for
 org.apache.maven.plugin.source.SourceJarMojo
  [INFO]
  [INFO] --- maven-source-plugin:2.1.2:jar (default) @ openwebbeans-resource
 ---
  [INFO] META-INF already added, skipping
  [INFO] META-INF/LICENSE already added, skipping
  [INFO] META-INF/DEPENDENCIES already added, skipping
  [INFO] META-INF/NOTICE already added, skipping
  [INFO] Building jar:
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/target/openwebbeans-resource-1.0.1-SNAPSHOT-sources.jar
  [INFO] META-INF already added, skipping
  [INFO] META-INF/LICENSE already added, skipping
  [INFO] META-INF/DEPENDENCIES already added, skipping
  [INFO] META-INF/NOTICE already added, skipping
  [INFO]
  [INFO] --- maven-checkstyle-plugin:2.6:check (verify-style) @
 openwebbeans-resource ---
  [INFO]
  [INFO] [INFO] Exclude: **/*/MANIFEST.MF
  [INFO] Exclude: .git
  [INFO] Exclude: .gitignore

  [INFO] --- apache-rat-plugin:0.7:check (default) @ openwebbeans-resource
 ---
  [INFO] [INFO] Installing
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/target/openwebbeans-resource-1.0.1-SNAPSHOT.jar
 to
 /home/hudson/hudson-slave/maven-repositories/0/org/apache/openwebbeans/openwebbeans-resource/1.0.1-SNAPSHOT/openwebbeans-resource-1.0.1-SNAPSHOT.jar
  [INFO] Installing
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/pom.xml
 to
 /home/hudson/hudson-slave/maven-repositories/0/org/apache/openwebbeans/openwebbeans-resource/1.0.1-SNAPSHOT/openwebbeans-resource-1.0.1-SNAPSHOT.pom
  [INFO] Installing
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0.x/webbeans-resource/target/openwebbeans-resource-1.0.1-SNAPSHOT-sources.jar
 to
 /home/hudson/hudson-slave/maven-repositories/0/org/apache/openwebbeans/openwebbeans-resource/1.0.1-SNAPSHOT/openwebbeans-resource-1.0.1-SNAPSHOT-sources.jar

  [INFO] --- maven-install-plugin:2.3:install (default-install) @
 openwebbeans-resource ---
  [JENKINS] Archiving
 https://builds.apache.org/job/OpenWebBeans_1.0.x/ws/owb_1.0

Re: [DISCUSS] implement a hierarchic BeanManager?

2012-02-14 Thread Joseph Bergmark

I agree, at the very minimum some way to associate bean managers as
having visibility into each other would allow us to build more complex
relationships.

In your example below, all 3 wars would have visibility into shared
jars in ear/lib, but have their own unique web-inf/lib jars.  This
mostly works now, given that we key things off of the Classloader.  If
we share the contexts (which are also looked by up class loader, so
you have to change that) then it pretty much works.

Where things start to fall apart a bit are ejb-jars in the ear.  In
some servers those jars share a single class loader, but they can be
started/stopped individually, which makes it difficult to key things
like BeanManagers  Lifecycles to the class loader that they all
share.  We need to be able to start/stop them individually, but still
somehow expose the fact that they have visibility into each others
classes.

Sincerely,

Joe


On Mon, Feb 13, 2012 at 4:45 PM, Mark Struberg strub...@yahoo.de wrote:
 Hi folks!

 We discussed abut the implications of EAR deployments for Geronimo and other 
 EE containers quite often already. The problematic area is also described in 
 CDI-18 and CDI-129 in the EG spec issue tracker. In other words: those are 
 not OWB specific issues but rather a lack in the specification itself.

 Consider having an EAR with 3 WARs (warA, warB, warC). Each of the 
 WebApplications have per JSR-316 recommendation an own WebApp-ClassLoader 
 whereas the shared EAR libs haven an own ClassLoader forming the parent of 
 the WebApps.
 Beans in the shared EAR libs are visible in the whole application. But beans 
 from a WEB-INF/lib/*.jar or WEB-INF/classes of warA are obviously not visible 
 to warB and warC. And neither to any shared EAR libs.

 Other problems arise if e.g a bean in warB @Specialices a bean of a shared 
 EAR lib. In this case the specialiced bean must only get used for warB. The 
 same is true for @Alternatives, Interceptors, etc.

 Currently most EE containers (Geronimo, JBossAS, Glassfish, ...) only have 
 one single BeanManager which manages the whole EAR. But this is obviously not 
 enough!

 What we need is a BeanManager tree which is in balance with the ClassLoader 
 hierarchy. That way all the shared EARs would get scanned with a BeanManager 
 which responsibility is only to manage those shared classes. Each 
 WebApplication would get an own BeanManager which has the shared BeanManager 
 as 'parent'.

 Our MetaDataService SPI might be perfectly fine for this stuff already, we 
 only need to make sure that we don't scan too much classes.
 For the lookup aspect we'd need to introduce a 'parent-first' lookup with an 
 additional 'DisabledBeans' list. This trick is needed to not pickup Beans 
 which are not enabled anymore in the webapps (they might have been 
 @Specialized by another bean in the WebApp already).

 wdyt?

 LieGrue,
 strub

Re: [DISCUSS] release owb-1.1.3?

2011-11-29 Thread Joseph Bergmark

+1

On Tue, Nov 29, 2011 at 6:08 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
 +1

 regards,
 gerhard

 http://www.irian.at

 Your JSF/JEE powerhouse -
 JEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces


 2011/11/29 Mark Struberg strub...@yahoo.de

 Hi folks!

 I'd like to ship a release of OWB soon.
 Is there any particular thing you are currently working on?

 I'm especially interested in OWB-625 [1] hitting the road as this makes
 using OWB with Arquillian and Seam almost impossible.

 If no ones is crying stop then I'll start the release job on Friday.


 LieGrue,
 strub



 [1] https://issues.apache.org/jira/browse/OWB-625

Re: [VOTE] Release Apache OpenWebBeans-1.1.2

2011-10-20 Thread Joseph Bergmark

+1

Sincerely,

Joe

On Mon, Oct 17, 2011 at 7:28 AM, Mark Struberg strub...@yahoo.de wrote:
 Hi!

 I'd like to call a VOTE on releasing Apache OpenWebBeans-1.1.2 .

 This is a bugfix release of OpenWebBeans-1.1.x, thus no branch has been 
 created.

 The ReleaseNotes are available online:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12317743

 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-072/

 SVN source tag (1185088):
 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.2/

 Source release:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-072/org/apache/openwebbeans/openwebbeans/1.1.2/openwebbeans-1.1.2-source-release.zip

 Binary release:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-072/org/apache/openwebbeans/openwebbeans-distribution/1.1.2/openwebbeans-distribution-1.1.2-binary.tar.gz

 PGP release key 2FDB81B1
 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS

 The VOTE will be open for 72 hours.
 [ ] +1 approve
 [ ] +0 no opinion
 [ ] -1 veto (and reason why)



 Guide for testing staged releases:
 -

 Add the following section to your ~/.m2/settings.xml

   profiles
     profile
   idowbstaging/id
   repositories
     repository
   idowbstaging/id
   
 urlhttps://repository.apache.org/content/repositories/orgapacheopenwebbeans-072//url
   releases
     enabledtrue/enabled
   /releases
   snapshots
     enabledfalse/enabled
   /snapshots
     /repository
   /repositories
     /profile
   /profiles

 You can use the new Apache OpenWebBeans version by just activating the 
 profile 'owbstaging' via
 $ mvn clean install -Powbstaging
 in your project.

 txs and LieGrue,
 strub

Re: [jira] [Created] (OWB-603) Incorporate enhanced BeanArchive handling of the preliminary CDI-1.1 specification

2011-08-12 Thread Joseph Bergmark

Should we separate owb 1.1 (which is an cdi 1.0 implementation) from
early cdi 1.1 work somehow?  A new branch perhaps?

Joe

On Fri, Aug 12, 2011 at 2:51 PM, Mark Struberg (JIRA) j...@apache.org wrote:
 Incorporate enhanced BeanArchive handling of the preliminary CDI-1.1 
 specification
 --

                 Key: OWB-603
                 URL: https://issues.apache.org/jira/browse/OWB-603
             Project: OpenWebBeans
          Issue Type: Improvement
          Components: Interceptor and Decorators
    Affects Versions: 1.1.0
            Reporter: Mark Struberg
            Assignee: Mark Struberg
             Fix For: 1.2.0


 This affects Interceptors, Decorators and Alternatives:

 The CDI-1.0 spec defines that Interceptors, Decorators and Alternatives must 
 only count for beans of the very the Bean Archive (BDA = the jar file) they 
 are defined in (via beans.xml). OWB currently ignores this (there is also no 
 TCK for it) because this behaviour is utterly broken.
 The CDI-1.1 (JSR-346) EG is working on improving this:
 https://issues.jboss.org/browse/CDI-18

 This is work in progress, but we should stay close to the new mechanism 
 because it's better than what we currently have.

 As a first step, we shall remove our DeploymentException when the same 
 Interceptor gets enabled in more than 1 beans.xml files on the classpath.

 --
 This message is automatically generated by JIRA.
 For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Snapshots

2011-06-23 Thread Joseph Bergmark

Last night I updated the Hudson configuration for OpenWebBeans-trunk and set
the Goals and options field to clean deploy.  Hopefully that will do the
trick!

Sincerely,

Joe

On Wed, Jun 22, 2011 at 7:51 PM, David Jencks david_jen...@yahoo.comwrote:

 Unless something has changed in the (rather long) time since I looked at
 this, you don't want to use that option because it doesn't use mvn deploy
 and doesn't end up with the right metadata.  Can you adjust hudson to run
 mvn clean deploy instead of mvn clean install?  This can result in only the
 first few modules of a broken build getting deployed, but I'm OK with that
 happening occasionally.

 thanks
 david jencks

 On Jun 22, 2011, at 4:26 PM, Joseph Bergmark wrote:

  I set up the Hudson builds for both OpenWebBeans-trunk
  and OpenWebBeans_1.0.x.  I suspect I could configure it to also configure
 it
  to publish them.  I see there is a Deploy artifacts to Maven repository
  option that takes a repository URL.
 
  Sincerely,
 
  Joe
 
  On Wed, Jun 22, 2011 at 6:02 PM, David Blevins david.blev...@gmail.com
 wrote:
 
 
  On Mar 10, 2011, at 1:43 AM, Mark Struberg wrote:
 
  Not sure if we like to do that. Of course it would be easier to handle,
  but this might break geronimo snapshot releases which assume that a
 current
  SPI doesn't got changed.
 
  I think we can leave it as is with our manual deploys. This way, we
 have
  the opportunity to tell the geronimo guys that something will change
 before
  we break their build ;)
 
  @geronimo folks, what is your opinion?
 
  Now that we have CI systems setup for both Geronimo and OpenEJB we're
  getting a fair amount of build failures due to out of date OWB snaps.
 
  Who has access to setup the OWB snapshots to automatically publish?
 
 
  -David
 
  --- On Thu, 3/10/11, David Blevins david.blev...@gmail.com wrote:
 
  From: David Blevins david.blev...@gmail.com
  Subject: Snapshots
  To: dev@openwebbeans.apache.org
  Date: Thursday, March 10, 2011, 1:06 AM
  Does our hudson setup deploy
  snapshots?  If not I could set that up in
  buildbot.  It's possible in buildbot to have it only
  deploy after a successful 'mvn clean install'
 
  -David

Re: Snapshots

2011-06-22 Thread Joseph Bergmark

I set up the Hudson builds for both OpenWebBeans-trunk
and OpenWebBeans_1.0.x.  I suspect I could configure it to also configure it
to publish them.  I see there is a Deploy artifacts to Maven repository
option that takes a repository URL.

Sincerely,

Joe

On Wed, Jun 22, 2011 at 6:02 PM, David Blevins david.blev...@gmail.comwrote:


 On Mar 10, 2011, at 1:43 AM, Mark Struberg wrote:

  Not sure if we like to do that. Of course it would be easier to handle,
 but this might break geronimo snapshot releases which assume that a current
 SPI doesn't got changed.
 
  I think we can leave it as is with our manual deploys. This way, we have
 the opportunity to tell the geronimo guys that something will change before
 we break their build ;)
 
  @geronimo folks, what is your opinion?

 Now that we have CI systems setup for both Geronimo and OpenEJB we're
 getting a fair amount of build failures due to out of date OWB snaps.

 Who has access to setup the OWB snapshots to automatically publish?


 -David

  --- On Thu, 3/10/11, David Blevins david.blev...@gmail.com wrote:
 
  From: David Blevins david.blev...@gmail.com
  Subject: Snapshots
  To: dev@openwebbeans.apache.org
  Date: Thursday, March 10, 2011, 1:06 AM
  Does our hudson setup deploy
  snapshots?  If not I could set that up in
  buildbot.  It's possible in buildbot to have it only
  deploy after a successful 'mvn clean install'
 
  -David

Re: [vote] project logo

2011-05-07 Thread Joseph Bergmark

+1 for #1
(also +1 for #3 from the dark background choices)

Sincerely,

Joe

On Sat, May 7, 2011 at 1:34 AM, Gerhard Petracek gpetra...@apache.orgwrote:

 hi @ all,

 please have a look at [1] and vote for your preferred logo.

 regards,
 gerhard

 [1] http://people.apache.org/~gpetracek/owb/logo_drafts/

Re: owb logo

2011-04-29 Thread Joseph Bergmark

Agreed, they are excellent!

Joe

On Fri, Apr 29, 2011 at 9:31 AM, Mark Struberg strub...@yahoo.de wrote:

 wow, they all look great!

 LieGrue,
 strub

 --- On Fri, 4/29/11, Gerhard Petracek gpetra...@apache.org wrote:

  From: Gerhard Petracek gpetra...@apache.org
  Subject: Re: owb logo
  To: dev@openwebbeans.apache.org
  Cc: Adonis Raduca adonis.rad...@codebeat.ro
  Date: Friday, April 29, 2011, 1:26 PM
  hi @ all,
 
  adonis sent me some nice drafts!
  i uploaded them to: http://people.apache.org/~gpetracek/owb/logo_drafts/
 
  regards,
  gerhard
 
 
 
  2011/4/18 Rohit Kelapure kelap...@gmail.com
 
   Very nice. Thank you Gerhard and Adonis!
  
   On Mon, Apr 18, 2011 at 2:59 AM, Gerhard Petracek
  
   gerhard.petra...@gmail.com
  wrote:
  
i've great news!
   
adonis will create a logo for us. he designed the
  whole style of apache
myfaces.
usually he comes up with an awesome draft. so we
  just have to wait some
time
until we can talk about the first draft.
   
regards,
gerhard
   
http://www.irian.at
   
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
   
Professional Support for Apache MyFaces
   
   
   
2011/4/9 Mark Struberg strub...@yahoo.de
   
 +1 This is on our list for too long ;) But
  who is going to do it?

 LieGrue,
 strub

 --- On Sat, 4/9/11, Gerhard Petracek gerhard.petra...@gmail.com
   wrote:

  From: Gerhard Petracek gerhard.petra...@gmail.com
  Subject: owb logo
  To: dev@openwebbeans.apache.org
  Date: Saturday, April 9, 2011, 6:31 PM
  hi @ all,
 
  what do you think about creating a new
  owb logo?
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache
  MyFaces

Re: [VOTE] release Apache OpenWebBeans 1.1.0

2011-03-27 Thread Joseph Bergmark

+1

On Thu, Mar 24, 2011 at 8:09 PM, Mark Struberg strub...@yahoo.de wrote:

 Hi!

 I'd like to call a VOTE on releasing Apache OpenWebBeans-1.1.0 .

 Maven staging repo:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-040/

 SVN source tag (1085208):
 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.0/

 Source release:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-040/org/apache/openwebbeans/openwebbeans/1.1.0/openwebbeans-1.1.0-source-release.zip

 Binary release:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-040/org/apache/openwebbeans/openwebbeans-distribution/1.1.0/openwebbeans-distribution-1.1.0-binary.tar.gz

 PGP release key 2FDB81B1
 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS

 Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1
 veto (and reason why)


 txs and LieGrue, strub

Re: NPE when calling BeanManagerImpl.isNormalScope(component.getScope())

2011-03-20 Thread Joseph Bergmark

I might be missing the point, but why are we calling OWB at all if this is a
non-cdi ejb module (which I assume means no beans.xml)?

Sincerely,

Joe

On Mon, Mar 21, 2011 at 12:05 AM, Shawn Jiang genspr...@gmail.com wrote:

 Could anyone shed some light on following issue ?


 I got a NPE when calling BeanManagerImpl.isNormalScope(null) when
 constructing a MDB instance in a non-webbean ejb module.   From the
 stacktrace, there's no chance the component.getScope() could return a
 non-null value.

 I'm wondering why there's no null param checking
 for BeanManagerImpl.isNormalScope()  method ?   Or could anyone advise how
 to make component.getScope() return a non-null value in following
 stacktrace
 methods ?


 
 org.apache.webbeans.container.BeanManagerImpl.isNormalScope(java.lang.Class?
  extends java.lang.annotation.Annotation) line: 1031
 
 org.apache.webbeans.config.DefinitionUtil.defineInternalInjectedFields(org.apache.webbeans.component.AbstractInjectionTargetBeanT,
  java.lang.ClassT, boolean) line: 991
 
 org.apache.webbeans.config.DefinitionUtil.defineInternalInjectedFieldsRecursively(org.apache.webbeans.component.AbstractInjectionTargetBeanT,
  java.lang.ClassT) line: 968
 
 org.apache.webbeans.util.WebBeansAnnotatedTypeUtil.defineInjectedFields(org.apache.webbeans.component.AbstractInjectionTargetBeanX,
  javax.enterprise.inject.spi.AnnotatedTypeX) line: 384
 
 org.apache.webbeans.component.creation.AnnotatedTypeBeanCreatorImplT(org.apache.webbeans.component.creation.AbstractInjectedTargetBeanCreatorT).defineInjectedFields()
  line: 80
 
 org.apache.webbeans.util.WebBeansAnnotatedTypeUtil.getJavaEeComponentInstanceInjectionPoints(org.apache.webbeans.config.WebBeansContext,
  javax.enterprise.inject.spi.AnnotatedTypeT) line: 724
  org.apache.webbeans.inject.OWBInjector.inject(java.lang.Object,
  javax.enterprise.context.spi.CreationalContext?) line: 126
  org.apache.webbeans.inject.OWBInjector.inject(java.lang.Object) line: 93
  org.apache.openejb.BeanContext.newInstance() line: 1122
  org.apache.openejb.core.mdb.MdbInstanceFactory.constructBean() line: 194
  org.apache.openejb.core.mdb.MdbInstanceFactory.createInstance(boolean)
  line: 124



 --
 Shawn



 --
 Shawn

Re: new site snapshot deployed

2011-03-20 Thread Joseph Bergmark

Thanks for doing this!

It appears the download link doesn't work.  I've had trouble with this
myself the couple times I've tried to use the site generating plugin before.
 I could sometimes get it to work for either relative or absolute URLs, but
never both.

At a minimum I think we need to update the site so the download link works,
and so that the 1.0 release is in the news.  Maybe we can hand edit the
download link from the staging location? I think I did that once before, but
its been a while.

Sincerely,

Joe

On Sun, Mar 20, 2011 at 2:48 PM, Mark Struberg strub...@yahoo.de wrote:

 hi folks!

 I've now deployed a new site of our 1.1.0-SNAPSHOT.
 I also changed the redirect to 1.1.
 Should get picked up with the next rsync in a few hours.

 Btw, anyone has more information about the new CMS used here?
 I'd like to use this as a landing page and move the generated info a stage
 deeper.

 LieGrue,
 strub

Re: Build failed in Hudson: OpenWebBeans_1.0.x #75

2011-01-28 Thread Joseph Bergmark

Thanks Mark!

Sincerely,

Joe

On Fri, Jan 28, 2011 at 5:43 AM, Mark Struberg strub...@yahoo.de wrote:

 I just moved on and upgraded the maven-checkstyle-plugin in the owb-1.0.x
 branch also.

 Hudson should now be happy again.

 LieGrue,
 strub

 --- On Fri, 1/28/11, Mark Struberg strub...@yahoo.de wrote:

  From: Mark Struberg strub...@yahoo.de
  Subject: Re: Build failed in Hudson: OpenWebBeans_1.0.x #75
  To: dev@openwebbeans.apache.org
  Date: Friday, January 28, 2011, 9:49 AM
  found the problem. apparently the 1.0
  job also got switched to maven3.
 
  But owb-1.0.x isn't ready for maven3 yet because the old
  checkstyle-plugin just doesn't work with maven 3 [1]
 
  So how to proceed?
  Move the 1.0.x branch also to the new checkstyle rules and
  upgrade to maven-checkstyle-plugin-2.6 or just move hudson
  back to maven2?
 
  LieGrue,
  strub
 
 
  [1]
 https://cwiki.apache.org/MAVEN/maven-3x-plugin-compatibility-matrix.html
 
  --- On Fri, 1/28/11, Mark Struberg strub...@yahoo.de
  wrote:
 
   From: Mark Struberg strub...@yahoo.de
   Subject: Re: Build failed in Hudson:
  OpenWebBeans_1.0.x #75
   To: dev@openwebbeans.apache.org
   Date: Friday, January 28, 2011, 9:27 AM
   oops, this happened in the 1.0 branch
   and not on trunk.
  
   I'll wait for the next build, maybe it was only a
  short
   outage of some resource.
  
   LieGrue,
   strub
  
   --- On Fri, 1/28/11, Mark Struberg strub...@yahoo.de
   wrote:
  
From: Mark Struberg strub...@yahoo.de
Subject: Re: Build failed in Hudson:
   OpenWebBeans_1.0.x #75
To: dev@openwebbeans.apache.org
Date: Friday, January 28, 2011, 9:24 AM
fixed the warning, but I guess there
is something else wrong too.
   
Maven wasn't able to fork the surefire runner...
Will investigate further.
   
LieGrue,
strub
   
--- On Fri, 1/28/11, Mark Struberg strub...@yahoo.de
wrote:
   
 From: Mark Struberg strub...@yahoo.de
 Subject: Re: Build failed in Hudson:
OpenWebBeans_1.0.x #75
 To: dev@openwebbeans.apache.org
 Date: Friday, January 28, 2011, 8:44 AM
 seems hudson got silently switched to
 maven3...

 I'll go on and fix the warnings

 LieGrue,
 strub

 --- On Fri, 1/28/11, Apache Hudson Server
  hud...@hudson.apache.org
 wrote:

  From: Apache Hudson Server hud...@hudson.apache.org
  Subject: Build failed in Hudson:
OpenWebBeans_1.0.x
 #75
  To: dev@openwebbeans.apache.org
  Date: Friday, January 28, 2011, 12:35
  AM
  See https://hudson.apache.org/hudson/job/OpenWebBeans_1.0.x/75/
 
 
 
  --
  [...truncated 25 lines...]
  [WARNING]
  'build.plugins.plugin.version'
   for
  org.codehaus.mojo:tomcat-maven-plugin
  is
   missing.
@
 line 38,
  column 21
  [WARNING]
  [WARNING] Some problems were
  encountered
   while
 building the
  effective model for
 

   
  
  org.apache.openwebbeans.samples:tomcat-sample:war:1.0.1-SNAPSHOT
  [WARNING]
  'build.plugins.plugin.version'
   for
  org.codehaus.mojo:tomcat-maven-plugin
  is
   missing.
@
 line 96,
  column 21
  [WARNING]
  [INFO] [WARNING] Some problems were
   encountered
while
  building the effective model for
 

   
  
  org.apache.openwebbeans.samples:tomcat7-sample:war:1.0.1-SNAPSHOT
  [WARNING]
  'build.plugins.plugin.version'
   for
  org.codehaus.mojo:tomcat-maven-plugin
  is
   missing.
@
 line 90,
  column 21
  [WARNING]
  [WARNING] It is highly recommended to
  fix
   these
 problems
  because they threaten the stability of
  your
build.
  [WARNING]
  [WARNING] For this reason, future
  Maven
   versions
might
 no
  longer support building such malformed
   projects.
  [WARNING]
 

   
  
  
  [INFO] Reactor Build Order:
  [INFO]
  [INFO] Apache OpenWebBeans
  [INFO] SPI definition
  [INFO] OpenWebBeans Core
  [INFO] EE Common plugin
  [INFO] Web plugin
  [INFO] EJB plugin
  [INFO] Java EE plugin
  [INFO] OpenEJB plugin
  [INFO] Tomcat 6 plugin
  [INFO] Tomcat 7 plugin
  [INFO] JMS plugin
  [INFO] JSF-2 plugin
  [INFO] EL 1.0 plugin
  [INFO] JSF 1.2 plugin
  [INFO] EE Resource plugin
  [INFO] OSGi plugin
  [INFO] TCK Porting Pkg
  [INFO] CDI Test Framework
  [INFO] CDI Testing API
  [INFO] OWB Testing plugin
  [INFO] OWB Samples
  [INFO] Apache OpenWebBeans :: Sample
  Guess
 Application
  [INFO] Apache OpenWebBeans :: JSF
   Conversation
Sample
  [INFO] Apache OpenWebBeans :: Sample
  JSF2
Application
  [INFO] Apache OpenWebBeans :: Sample
  Ejb
   Demo On
 OpenEJB in
  Tomcat
  [INFO] Apache OpenWebBeans :: Telephone
  Ejb
   Demo
On
 OpenEJB

Re: [VOTE] Release Apache OpenWebBeans checktyle-rules-1.1

2011-01-18 Thread Joseph Bergmark

+1

Sincerely,

Joe

On Mon, Jan 17, 2011 at 4:52 AM, Mark Struberg strub...@yahoo.de wrote:

 I missed the obvious vote footer, of course:

 Vote is open for 72h

 [+1] ship it
 [0] don't care
 [-1] re-roll (and reason why)

 LieGrue,
 strub

 --- On Mon, 1/17/11, Mark Struberg strub...@yahoo.de wrote:

  From: Mark Struberg strub...@yahoo.de
  Subject: [VOTE] Release Apache OpenWebBeans checktyle-rules-1.1
  To: dev@openwebbeans.apache.org
  Date: Monday, January 17, 2011, 9:50 AM
  Hi!
 
  I've re-rolled a release for Apache OpenWebBeans
  checkstyle-rules-1.1.
  The changes are needed for compatibility with newer
  maven-checkstyle-plugins which are necessary for maven 3
  compatibility (amongst lots of bug fixes).
 
 
  Maven staging repo:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-037/
 
  SVN source tag (1059833):
 https://svn.apache.org/repos/asf/openwebbeans/build-tools/tags/checkstyle-rules-1.1/
 
  Source release:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-037/org/apache/openwebbeans/build-tools/checkstyle-rules/1.1/checkstyle-rules-1.1-source-release.zip
 
  PGP release key 2FDB81B1
 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS
 
 
  LieGrue,
  strub

Re: Build failed in Hudson: OpenWebBeans-trunk #299

2010-11-26 Thread Joseph Bergmark

This still looks like we have some old artifacts hanging around from a few
weeks ago.

I've modified the build to not use svn update.  If that doesn't resolve the
problem, I'll set the maven goals to do a clean and then package.

Sorry for the piecemeal approach, but I'm still not quite sure what is
causing this problem as I can't recreate it myself.

Sincerely,

Joe

On Fri, Nov 26, 2010 at 3:39 AM, Apache Hudson Server 
hud...@hudson.apache.org wrote:

 See https://hudson.apache.org/hudson/job/OpenWebBeans-trunk/299/

 --
 java.lang.NoSuchMethodError:
 org.apache.webbeans.test.tck.mock.TCKMetaDataDiscoveryImpl.getAnnotationDB()Lorg/scannotation/AnnotationDB;
at
 org.apache.webbeans.test.tck.mock.TCKMetaDataDiscoveryImpl.addBeanClass(TCKMetaDataDiscoveryImpl.java:51)
at
 org.apache.webbeans.test.tck.StandaloneContainersImpl.deployInternal(StandaloneContainersImpl.java:83)
at
 org.apache.webbeans.test.tck.StandaloneContainersImpl.deploy(StandaloneContainersImpl.java:202)
at
 org.apache.webbeans.atinject.tck.container.AtInjectContainer.start(AtInjectContainer.java:70)
at
 org.apache.webbeans.atinject.tck.OpenWebBeansAtInjectTck.suite(OpenWebBeansAtInjectTck.java:29)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
 org.junit.internal.runners.SuiteMethod.testFromSuiteMethod(SuiteMethod.java:34)
at
 org.junit.internal.runners.SuiteMethod.init(SuiteMethod.java:23)
at
 org.junit.internal.builders.SuiteMethodBuilder.runnerForClass(SuiteMethodBuilder.java:14)
at
 org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at
 org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at
 org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at
 org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at
 org.apache.maven.surefire.junit4.JUnit4TestSet.init(JUnit4TestSet.java:45)
at
 org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56)
at
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96)
at
 org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209)
at org.apache.maven.surefire.Surefire.run(Surefire.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at
 org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
 org.jboss.testharness.api.DeploymentException: java.lang.NoSuchMethodError:
 org.apache.webbeans.test.tck.mock.TCKMetaDataDiscoveryImpl.getAnnotationDB()Lorg/scannotation/AnnotationDB;
at
 org.apache.webbeans.test.tck.StandaloneContainersImpl.deployInternal(StandaloneContainersImpl.java:92)
at
 org.apache.webbeans.test.tck.StandaloneContainersImpl.deploy(StandaloneContainersImpl.java:202)
at
 org.apache.webbeans.atinject.tck.container.AtInjectContainer.start(AtInjectContainer.java:70)
at
 org.apache.webbeans.atinject.tck.OpenWebBeansAtInjectTck.suite(OpenWebBeansAtInjectTck.java:29)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
 org.junit.internal.runners.SuiteMethod.testFromSuiteMethod(SuiteMethod.java:34)
at
 org.junit.internal.runners.SuiteMethod.init(SuiteMethod.java:23)
at
 org.junit.internal.builders.SuiteMethodBuilder.runnerForClass(SuiteMethodBuilder.java:14)
at
 org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at
 org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at
 org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at
 org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at
 org.apache.maven.surefire.junit4.JUnit4TestSet.init(JUnit4TestSet.java:45)
at

Re: Build failed in Hudson: OpenWebBeans-trunk #298

2010-11-25 Thread Joseph Bergmark

 Mark hit the nail on the head.  A hung build had prevented anything from
running since Nov 16th.  I opened a JIRA ticket for this a day or two ago,
and they quickly resolved it.

This is an odd error message though.  Looks related to the fix I committed a
week or two back, but I'm not seeing the problem locally in my sandbox.

I wonder if it had some old artifacts from a previous build that caused the
problem?  By default I think Hudson tries to reuse where possible rather
than running clean.

If we see it again then I'll try changing the Hudson build setting.

Sincerely,

Joe

On Thu, Nov 25, 2010 at 6:54 AM, Mark Struberg strub...@yahoo.de wrote:

 The Hudson build didn't run for a while now. Joe enabled it again only
 yesterday. So the problem might have been older...

 LieGrue,
 strub

 --- On Thu, 11/25/10, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:

  From: Gurkan Erdogdu gurkanerdo...@yahoo.com
  Subject: Re: Build failed in Hudson: OpenWebBeans-trunk #298
  To: dev@openwebbeans.apache.org
  Date: Thursday, November 25, 2010, 11:23 AM
  Weird error!
 
 
  Error Message
 
 org.apache.webbeans.lifecycle.test.OpenWebBeansTestMetaDataDiscoveryService.getAnnotationDB()Lorg/scannotation/AnnotationDB;
 
  Stacktrace
  java.lang.NoSuchMethodError:
 
 org.apache.webbeans.lifecycle.test.OpenWebBeansTestMetaDataDiscoveryService.getAnnotationDB()Lorg/scannotation/AnnotationDB;
 
  at
 
 org.apache.webbeans.lifecycle.test.OpenWebBeansTestMetaDataDiscoveryService.addBeanClass(OpenWebBeansTestMetaDataDiscoveryService.java:91)
 
  at
 
 org.apache.webbeans.lifecycle.test.OpenWebBeansTestMetaDataDiscoveryService.deployClasses(OpenWebBeansTestMetaDataDiscoveryService.java:58)
 
  at
 
 org.apache.webbeans.newtests.AbstractUnitTest.startContainer(AbstractUnitTest.java:61)
 
  at
 
 org.apache.webbeans.newtests.contexts.SerializationTest.testPersonalDataBean(SerializationTest.java:116)
 
  at
  sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  at
 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 
  at
  java.lang.reflect.Method.invoke(Method.java:597)
  at
 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
 
  at
 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 
  at
 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
 
  at
 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 
  at
 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
 
  at
 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
 
 
 
 
 
 
  - Original Message 
  From: Apache Hudson Server hud...@hudson.apache.org
  To: dev@openwebbeans.apache.org
  Sent: Thu, November 25, 2010 1:15:36 PM
  Subject: Build failed in Hudson: OpenWebBeans-trunk #298
 
  See https://hudson.apache.org/hudson/job/OpenWebBeans-trunk/298/changes
 
 
  Changes:
 
  [gerdogdu] Spec is wrong on generic parameter order. RI TCK
  test will be updated
  by RI Team
 
  [gerdogdu] Spec is wrong on generic parameter order. RI TCK
  test will be updated
  by RI Team
 
  [gpetracek] OWB-407 intermediate result
 
  [djencks] OWB-497 Warn but don't break deployment if
  annotation scanning throws
  an ArrayStoreException
 
  [djencks] OWB-496 don't replace the classloaderProvider
  without clear intention
 
  [bergmark] [OWB-472] Missed updating a file in
  webbeans-osgi
  Submitted by: Jacquelle Leggett
 
  [bergmark] [OWB-472] Make it clear that this functionality
  is disabled by
  default by updating the property file.
 
  [bergmark] [OWB-472] Add optional support for archive
  centric beans.xml
  Submitted by: Jacquelle Leggett
 
  [struberg] OWB-492 enable event notification for private
  @Observes methods
 
  --
  [...truncated 3260 lines...]
  Results :
 
  Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
 
  [HUDSON] Recording test results
  [INFO] [war:war {execution: default-war}]
  [INFO] Exploding webapp...
  [INFO] Assembling webapp tomcat7-sample in
  
 https://hudson.apache.org/hudson/job/OpenWebBeans-trunk/ws/trunk/samples/tomcat7-sample/target/tomcat-sample
 
 
  [INFO] Copy webapp webResources to
  
 https://hudson.apache.org/hudson/job/OpenWebBeans-trunk/ws/trunk/samples/tomcat7-sample/target/tomcat-sample
 
 
  [INFO] Copy webapp webResources to
  
 https://hudson.apache.org/hudson/job/OpenWebBeans-trunk/ws/trunk/samples/tomcat7-sample/target/tomcat-sample
 
 
  [INFO] Building jar:
  
 https://hudson.apache.org/hudson/job/OpenWebBeans-trunk/ws/trunk/samples/tomcat7-sample/target/tomcat-sample/WEB-INF/lib/tomcat-sample.jar
 
 
  [INFO] Generating war

Re: [ANNOUNCE] Welcome David Jencks as an OpenWebBeans committer

2010-11-04 Thread Joseph Bergmark

Welcome!

Sincerely,

Joe

On Thu, Nov 4, 2010 at 3:02 AM, Mark Struberg strub...@yahoo.de wrote:

 Hi folks!

 The Apache OpenWebBeans PMC is pleased to announce that David Jencks has
 accepted our invitation to join OpenWebBeans as a committer.

 Congratulations and welcome David!

 txs and LieGrue,
 the OpenWebBeans PMC

Hudson build e-mails

2010-11-04 Thread Joseph Bergmark

I added a new build task to hudson for the owb_1.0.x branch, and
updated the previous one to e-mail the development list on broken
builds.

According to the hudson wiki (http://wiki.apache.org/general/Hudson)
in order for that e-mail to reach the dev list we need to send an
e-mail from a moderator e-mail address.  I would volunteer to be a
moderator if we do not already have one.

Sincerely,

Joe

Re: svn commit: r1028219 - in /openwebbeans/branches/owb_1.0.x/webbeans-impl/src/main/java/org/apache/webbeans: component/ResourceBean.java proxy/JavassistProxyFactory.java

2010-11-03 Thread Joseph Bergmark

This change to ResourceBean doesn't compile.  It appears to be a partial
backport.  I attempted to quickly resolve it by bringing in the
ResourceProxyHandler from trunk but hit another set of failures.

In the meantime I have reverted it.

Sincerely,

Joe

On Thu, Oct 28, 2010 at 4:44 AM, gerdo...@apache.org wrote:

 Author: gerdogdu
 Date: Thu Oct 28 08:44:01 2010
 New Revision: 1028219

 URL: http://svn.apache.org/viewvc?rev=1028219view=rev
 Log:
 [OWB-486] ResourceBean tries to proxy final classes before testing them for
 being final, thanks to David Jencks, Also includes sync. problem that Ying
 has provided

 Modified:

  
 openwebbeans/branches/owb_1.0.x/webbeans-impl/src/main/java/org/apache/webbeans/component/ResourceBean.java

  
 openwebbeans/branches/owb_1.0.x/webbeans-impl/src/main/java/org/apache/webbeans/proxy/JavassistProxyFactory.java

 Modified:
 openwebbeans/branches/owb_1.0.x/webbeans-impl/src/main/java/org/apache/webbeans/component/ResourceBean.java
 URL:
 http://svn.apache.org/viewvc/openwebbeans/branches/owb_1.0.x/webbeans-impl/src/main/java/org/apache/webbeans/component/ResourceBean.java?rev=1028219r1=1028218r2=1028219view=diff

 ==
 ---
 openwebbeans/branches/owb_1.0.x/webbeans-impl/src/main/java/org/apache/webbeans/component/ResourceBean.java
 (original)
 +++
 openwebbeans/branches/owb_1.0.x/webbeans-impl/src/main/java/org/apache/webbeans/component/ResourceBean.java
 Thu Oct 28 08:44:01 2010
 @@ -21,8 +21,6 @@ package org.apache.webbeans.component;
  import java.lang.annotation.Annotation;
  import java.lang.reflect.Modifier;

 -import javassist.util.proxy.ProxyFactory;
 -
  import javax.enterprise.context.spi.CreationalContext;

  import javassist.util.proxy.ProxyObject;
 @@ -35,8 +33,6 @@ import org.apache.webbeans.spi.api.Resou

  public class ResourceBeanX, T extends Annotation extends
 ProducerFieldBeanX
  {
 -private X actualResourceReference = null;
 -
 private ResourceReferenceX,T resourceReference = null;

 public ResourceBean(ClassX returnType, InjectionTargetBean?
 ownerBean,
 @@ -55,37 +51,38 @@ public class ResourceBeanX, T extends A
 X instance = null;
 try
 {
 -//X TODO cache proxy class!
 -ProxyFactory proxyFactory =
 JavassistProxyFactory.getInstance().createProxyFactory(this);
 -
 ResourceInjectionService resourceService =
 ServiceLoader.getService(ResourceInjectionService.class);
 -this.actualResourceReference =
 resourceService.getResourceReference(this.resourceReference);
 +instance =
 resourceService.getResourceReference(this.resourceReference);

 -instance =
 (X)(JavassistProxyFactory.getInstance().getProxyClass(proxyFactory).newInstance());
 -((ProxyObject)instance).setHandler(new
 ResourceProxyHandler(this.actualResourceReference));
 -}
 -catch (Exception e)
 -{
 -//check type is final
 -//return actual resource
 -
  if(Modifier.isFinal(this.actualResourceReference.getClass().getModifiers()))
 +if (instance != null 
 Modifier.isFinal(instance.getClass().getModifiers()))
 {
 -return this.actualResourceReference;
 +return instance;
 }

 +instance = (X)
 JavassistProxyFactory.getInstance().getResourceBeanProxyClass(this).newInstance();
 +((ProxyObject) instance).setHandler(new
 ResourceProxyHandler(this,instance));
 +}
 +catch (Exception e)
 +{
 throw new WebBeansException(e);
 }
 -
 +
 return instance;
 }

 -@Override
 -protected void destroyInstance(X instance, CreationalContextX
 creationalContext)
 +/**
 + * Called after deserialization to get a new instance for some type of
 resource bean instance that are
 + * not serializable.
 + *
 + * @return a new instance of this resource bean.
 + */
 +public X getActualInstance()
 {
 -this.actualResourceReference = null;
 +ResourceInjectionService resourceService =
 ServiceLoader.getService(ResourceInjectionService.class);
 +X instance =
 resourceService.getResourceReference(this.resourceReference);
 +return instance;
 }
 -
 -
 +
 public boolean isPassivationCapable()
 {
 return true;

 Modified:
 openwebbeans/branches/owb_1.0.x/webbeans-impl/src/main/java/org/apache/webbeans/proxy/JavassistProxyFactory.java
 URL:
 http://svn.apache.org/viewvc/openwebbeans/branches/owb_1.0.x/webbeans-impl/src/main/java/org/apache/webbeans/proxy/JavassistProxyFactory.java?rev=1028219r1=1028218r2=1028219view=diff

 ==
 ---
 openwebbeans/branches/owb_1.0.x/webbeans-impl/src/main/java/org/apache/webbeans/proxy/JavassistProxyFactory.java
 (original)
 +++

Re: [VOTE] release Apache OpenWebBeans-1.0.0 2nd try

2010-10-12 Thread Joseph Bergmark

+1

Sincerely,

Joe

On Tue, Oct 12, 2010 at 8:08 AM, Mark Struberg strub...@yahoo.de wrote:
 Hi!

 I've re-rolled the release with the fixed readme and now like to call a 2nd 
 VOTE on releasing Apache OpenWebBeans-1.0.0 .

 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-002/

 SVN source tag (1021752):
 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.0.0/

 Source release:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-002/org/apache/openwebbeans/openwebbeans/1.0.0/openwebbeans-1.0.0-source-release.zip

 Binary release:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-002/org/apache/openwebbeans/openwebbeans-distribution/1.0.0/openwebbeans-distribution-1.0.0-binary.tar.gz

 PGP release key 2FDB81B1 
 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS

 Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 veto 
 (and reason why)

 still valid:
 A small note: I've created a owb_1.0.x branch which will contain
 the maintenance work on OWB-1.0.x.
 Feature development will be performed in trunk which
 now has a version of 1.1.0-SNAPSHOT

 txs and LieGrue,
 strub

Re: ambiguous dependencies when using multiple qualifiers

2010-09-29 Thread Joseph Bergmark

I think you hit the nail on the head with your last paragraph.
Basically it only matters that the bean (or producer in this case)
matches all of the qualifiers on the injection point.  From the
perspective of the specification it doesn't matter if the bean has
extra qualifiers beyond those on the injection point.  Section 5.3 is
another key section here.

Sincerely,

Joe

On Wed, Sep 29, 2010 at 12:30 PM, Jakob Korherr jakob.korh...@gmail.com wrote:
 Hi,

 I tested some scenarios when using multiple qualifiers for test-cases
 in MyFaces CODI and stumbled upon the following scenario, which is not
 totally clear to me.

 Image you have the following producer methods:

   �...@produces
   �...@qualifier2
   �...@applicationscoped
    public ProducerBean createWithQualifier2()
    {
        return new ProducerBean();
    }

   �...@produces
   �...@qualifier1
   �...@qualifier2
   �...@applicationscoped
    public ProducerBean createWithQualifier1And2()
    {
        return new ProducerBean();
    }


 and you want to inject the instances produced by these producers. Now
 you can use @Inject @Qualifier1 or @Inject @Qualifier1 @Qualifier2,
 but when using @Inject @Qualifier2 you will get an exception, because
 the injection point is ambiguous (both producers provide @Qualifier2).

 However I was wondering if this is really unresolvable ambiguous,
 because if you think about it, it would make sence to take the
 producer createWithQualifier2() in this scenario (because the other
 one provides additional qualifiers).

 I also took a look in the CDI spec about this, but could only find the
 following from section 2.3.4: A bean may only be injected to an
 injection point if it has all the qualifiers of the injection point.
 Of course this applies to both producers and thus, yes, it's kinda
 ambiguous.

 WDYT?

 Regards,
 Jakob

 --
 Jakob Korherr

 blog: http://www.jakobk.com
 twitter: http://twitter.com/jakobkorherr
 work: http://www.irian.at

Re: [DISCUSS] remove logging for Calling method on proxy is restricted except Object.toString()

2010-09-23 Thread Joseph Bergmark

I don't interpret that sentence in quite the same way.

When it says portable applications should not invoke any method
declared by java.lang.Object, except for toString(), on a client
proxy, I read that to say that this is behavior that the spec decided
it couldn't define, so they are basically telling the user not to do
it because they risk being broken.

It does appear to leave the behavior up to the implementation though.

Sincerely,

Joe

On Thu, Sep 23, 2010 at 10:43 AM, Mark Struberg strub...@yahoo.de wrote:
 The behavior of all methods declared by java.lang.Object,
 except for
 toString(), is undefined for a client proxy. Portable
 applications
 should not invoke any method declared by java.lang.Object,
 except for
 toString(), on a client proxy.

 I'm reading this as we should not allow the interception of Object methods, 
 because equals() and hashCode() are really important to use.

 LieGrue,
 strub

 --- On Thu, 9/23/10, Eric Covener cove...@gmail.com wrote:

 From: Eric Covener cove...@gmail.com
 Subject: Re: [DISCUSS] remove logging for Calling method on proxy is 
 restricted except Object.toString()
 To: dev@openwebbeans.apache.org
 Date: Thursday, September 23, 2010, 2:34 PM
 On Thu, Sep 23, 2010 at 10:31 AM,
 Mark Struberg strub...@yahoo.de
 wrote:
  I generally doubt that this is undefined/unintended!
 

 I thought this trace message and thread were in regards to
 this rule
 on contextual references:


 5.4.2. Client proxy invocation

 Every time a method of the bean is invoked upon a client
 proxy, the
 client proxy must:

 obtain a contextual instance of the bean, as defined in
 Section 6.5.2,
 “Contextual instance of a bean”, and

 invoke the method upon this instance.

 If the scope is not active, as specified in Section 6.5.1,
 “The active
 context object for a scope”, the client proxy rethrows
 the
 ContextNotActiveException or IllegalStateException.

 The behavior of all methods declared by java.lang.Object,
 except for
 toString(), is undefined for a client proxy. Portable
 applications
 should not invoke any method declared by java.lang.Object,
 except for
 toString(), on a client proxy.



 --
 Eric Covener
 cove...@gmail.com

Re: webbeans-tck in trunk

2010-09-02 Thread Joseph Bergmark

574 seems like the correct number for standalone, but your results do not
appear to match mine. I get back:

Failed tests:

testBindingTypesAppliedToDisposalMethodParameters(org.jboss.jsr299.tck.tests.implementation.disposal.method.definition.DisposalMethodDefinitionTest)

testContextCreatesNewInstanceForInjection(org.jboss.jsr299.tck.tests.implementation.simple.lifecycle.SimpleBeanLifecycleTest)

Tests run: 574, Failures: 2, Errors: 0, Skipped: 0

There are a couple steps I mentioned back in August that I needed to do,
that I still haven't updated the README with. I'll paste a link below to
that older dev mailing list e-mail.
http://mail-archives.apache.org/mod_mbox/openwebbeans-dev/201008.mbox/%3caanlktimyau27bldjhlg89rigk3ex7mff7b-2em52b...@mail.gmail.com%3e

Sincerely,

Joe

On Thu, Sep 2, 2010 at 11:05 AM, Lin Sun linsun@gmail.com wrote:

Hi!

I am new to the list and I did some searches on the titled topic and
was able to find the readme/TCK-RUNNING.txt. I was able to follow
the instruction.

I discovered that in order to run the tck standalone, I still need to
setup tomcat.home and have the tomcat server running. Also, I have to
start tomcat server with -ea to enable assertions as some tests seems
to run as servlet and need the assertions to be enabled.

My biggest prob right now is most of the tck in standalone failed for me.

Tests run: 574, Failures: 524, Errors: 0, Skipped: 0

Does the total # of tests look right? The good thing is test did run
instead of skipped but I am probably still missing something obvious
here. I remember seeing a post that says that openwebbeans has
passed all jsr299 tcks.

Thanks.

Lin

Re: webbeans-tck in trunk

2010-09-02 Thread Joseph Bergmark

Just to double check I updated my sandbox and then ran mvn clean install
from the root, before running the TCK again. I'm still getting the same
results with 574 tests and 2 failures.

It might be worth digging into the logs and trying to determine where things
are going wrong. The emailable-report.html
inside webbeans-tck/target/surefire-reports sometimes had some information
about the failure, and I believe it always has the failures first in the
section at the bottom.

Sincerely,

Joe

On Thu, Sep 2, 2010 at 1:46 PM, Lin Sun linsun@gmail.com wrote:

Hi Joe

Thanks for the pointer. I looked at your email closely and I think
I've done all things you mentioned (sorry I forgot to mention them).

The only extra thing I did was I had to add this -

org.jboss.testharness.api.TestLauncher=org.jboss.testharness.impl.runner.servlet.ServletTestLauncher

in the jboss-test-harness.properties file, otherwise, I'd get a build
failure.

There is a slight chance that things might have regressed in between
the last time you ran it and the current trunk, but I could still have
missed things obvious.

Thanks

Lin

On Thu, Sep 2, 2010 at 11:40 AM, Joseph Bergmark bergm...@apache.org
wrote:
574 seems like the correct number for standalone, but your results do not
appear to match mine. I get back:

Failed tests:

testBindingTypesAppliedToDisposalMethodParameters(org.jboss.jsr299.tck.tests.implementation.disposal.method.definition.DisposalMethodDefinitionTest)

testContextCreatesNewInstanceForInjection(org.jboss.jsr299.tck.tests.implementation.simple.lifecycle.SimpleBeanLifecycleTest)

Tests run: 574, Failures: 2, Errors: 0, Skipped: 0

There are a couple steps I mentioned back in August that I needed to do,
that I still haven't updated the README with. I'll paste a link below to
that older dev mailing list e-mail.

http://mail-archives.apache.org/mod_mbox/openwebbeans-dev/201008.mbox/%3caanlktimyau27bldjhlg89rigk3ex7mff7b-2em52b...@mail.gmail.com%3e

Sincerely,

Joe

On Thu, Sep 2, 2010 at 11:05 AM, Lin Sun linsun@gmail.com wrote:

Hi!

I am new to the list and I did some searches on the titled topic and
was able to find the readme/TCK-RUNNING.txt. I was able to follow
the instruction.

My biggest prob right now is most of the tck in standalone failed for
me.

Tests run: 574, Failures: 524, Errors: 0, Skipped: 0

Thanks.

Lin

Re: CDI TCK Issues

2010-08-31 Thread Joseph Bergmark

I agree with you.  The spec doesn't seem to provide any requirement
that decorators should be injected directly into a) The injection
point of the Decorated bean or b) each other.

I guess I'm sure sure how you can validate a TCK test with secondary
evidence and the intentions of the EG.  It seems to me that it needs
to verify something that is clearly spelled out in the spec.

I think the quote Eric pointed out certainly leaves some room for
implementation choices.

Sincerely,

Joe

On Mon, Aug 30, 2010 at 6:28 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
 Seems that RedHat rejects TCK challaenge that I did open. Rejection comment is
 given at https://jira.jboss.org/browse/CDITCK-137

 Joe, how could we go with this ? WDYT?

 Thanks;

 --Gurkan


 
 From: Eric Covener cove...@gmail.com
 To: dev@openwebbeans.apache.org
 Sent: Sun, August 29, 2010 3:42:12 PM
 Subject: Re: CDI TCK Issues

 On Sun, Aug 29, 2010 at 3:08 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com 
 wrote:
 Hello;

 We had problems with CDI-TCK 137 and CDI-TCK 138. I have put those issues 
 into
 table but not responded so far.

 Please have a look and tell WDYT?

 https://jira.jboss.org/browse/CDITCK-137
 https://jira.jboss.org/browse/CDITCK-138

 The tests don't seem to relate to any requirement in the spec. IMO the
 spec even alludes to the idea that the delegate injection points may
 not be the next member of the chain:

 The delegate object implements the delegate type and delegates method
 invocations to remaining uninvoked decorators and eventually to the
 bean


 --
 Eric Covener
 cove...@gmail.com

Re: ready for take off?

2010-08-24 Thread Joseph Bergmark

+1 for alpha-2

Sincerely,

Joe

On Mon, Aug 23, 2010 at 5:31 PM, Jakob Korherr jakob.korh...@gmail.com wrote:
 +1

 Regards,
 Jakob

 2010/8/21 Gerhard gerhard.petra...@gmail.com

 +1

 regards,
 gerhard

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2010/8/21 Mark Struberg strub...@yahoo.de

  given the fact that Gurkan currently refactors a few core components I'd
  now
  also in favour to -alpha-2. We can then test this release a few weeks and
  go for
  1.0.0 with only applying bugfixes.
 
  LieGrue,
  strub
 
 
 
  - Original Message 
   From: Gerhard gerhard.petra...@gmail.com
   To: dev@openwebbeans.apache.org
   Sent: Sat, August 21, 2010 4:41:16 PM
   Subject: Re: ready for take off?
  
   +1 for alpha2 (or  beta1)
  
   regards,
   gerhard
  
   http://www.irian.at
  
   Your JSF  powerhouse -
   JSF Consulting, Development and
   Courses in English and  German
  
   Professional Support for Apache MyFaces
  
  
  
   2010/8/21  Mark Struberg strub...@yahoo.de
  
I could  also release an -alpha-2, but given the fact that our code
 is
 currently
pretty stable otherwise, I'd prefer 1.0.0 and later ship a  1.0.1 and
  if all
those things are fixed a 1.1.0. To be honest - I pretty  much don't
  care
about
the version number as long as we ship  something working in the next
  week.
So
please gimme your  opinions :)
   
   
LieGrue,
 strub
   
   
   
   
- Original Message  
 From: Gerhard gerhard.petra...@gmail.com
  To: dev@openwebbeans.apache.org
  Sent: Sat, August 21, 2010 3:29:17 PM
 Subject: Re: ready for  take off?

 i would prefer a v1 which fixes e.g. OWB-338  and  OWB-444.

 regards,
  gerhard

 http://www.irian.at

 Your JSF  powerhouse  -
 JSF Consulting, Development and
 Courses in English  and  German

 Professional Support for Apache  MyFaces



 2010/8/21  Mark  Struberg strub...@yahoo.de

    Hoi
 
  I'd like to prepare the  OWB-1.0.0 release today, any Jiras  open
  which
you
   like
  to resolve before?
  Is all  well  tested and the quality didn't suffer in the last
  days?
  
   LieGrue,
  strub
  
 
 
 
 
   
   
   
   
  
 
 
 
 




 --
 Jakob Korherr

 blog: http://www.jakobk.com
 twitter: http://twitter.com/jakobkorherr
 work: http://www.irian.at

Re: Failover Service

2010-08-12 Thread Joseph Bergmark

I suspect a lot of servers proactively propagate the session
information across servers in case a failover occurs.  Once the
session itself has failed over then they will stay on that server,
but the data might have been moved over in lots of little chunks
before then.

Sincerely,

Joe

On Thu, Aug 12, 2010 at 2:02 PM, Mark Struberg strub...@yahoo.de wrote:
 hmm, how your cluster environment looks like, but mine definitely only allows
 1server at a time to handle a session!

 So after the WHOLE session got moved to a different node (moving only parts of
 the session will almost always break the system) it must _not_ be served by 
 this
 VM anymore. You will always end up with inconsistent data otherwise!

 LieGrue,
 strub



 - Original Message 
 From: YING WANG wangying...@gmail.com
 To: dev@openwebbeans.apache.org
 Sent: Thu, August 12, 2010 6:28:24 PM
 Subject: Re: Failover Service

 My original patch does use WebBeanConfigurationLister, but that requires  2
 attributes to be set on a sessionContext, one is  WebBeanConfigurationLister
 itself which will receive  HttpSessionActivationListener callbacks, the
 problem is that it could not  hold any session specific data for
 serialization. The other is the  FailoverBagWrapper/FailoverBag which holds
 serializable data for the  session.

 For failover, the container I use, it supports time-based  failover
 (serialize a session to another JVM every X seconds) or request  based
 failover (serialize a session when every request is done). So I need  at
 least FailoverBagWrapper/FailoverBag attribute being set on  the
 sessionContext to be ready for serialization at any time.  The
 sessionWillPassivate() is NOT invoked for the failover case since  the
 current session will continue handling requests on the
 current JVM.  SessionWillPassivate only be invoked when I gracefully shut
 down a server. In  the end, I make another change to move
 HttpSessionActivationListener to  FailoverBagWrapper, only use one attribute
 on the sessionContext and  WebBeanConfigurationLister's
 HttpSessionActivationListener is not  used.

 I could revert it back since both work for me.

 BTW,  BeanManager, Interceptor, Decorator, resources beans are not working
 yet. I  will fix these later..

 From: Gurkan Erdogdu gurkanerdo...@yahoo.com
 To: dev@openwebbeans.apache.org
 Date:  08/12/2010 11:11 AM
 Subject: Re: Failover  Service



 +1,

 what I was trying to say  :)


 
 From: Mark Struberg strub...@yahoo.de
 To: dev@openwebbeans.apache.org
 Sent:  Thu, August 12, 2010 6:08:25 PM
 Subject: Re: Failover Service

 What  about moving this function to the already  registerd
 WebBeansConfiguarionListener?

 LieGrue,
 strub



 -  Original Message 
  From: Gurkan Erdogdu gurkanerdo...@yahoo.com
   To: dev@openwebbeans.apache.org
   Sent: Thu, August 12, 2010 5:01:37 PM
  Subject: Failover  Service
 
  Hello Ying,
 
  How does failover service  work ? FailoverBagWrapper  implements
   HttpSessionActivationListener, I think that to use failover  service,  we
 add
  listener to web.xml ?
 
 
  Is it possible  to update  code to use WebBeansConfigurationListener for
   sessionWillPassivate and  sessionDidActivate methods instead of
   FailoverBagWrapper?
 
  thanks
 
   --Gurkan

Re: DefaultContextsService question

2010-08-11 Thread Joseph Bergmark

Makes sense to me.  Seems it should be shared across the whole app and
not ThreadLocal.

Sincerely,

Joe

On Wed, Aug 11, 2010 at 4:46 PM, Mark Struberg strub...@yahoo.de wrote:
 Hoi!

 Why is it needed to hold the ApplicationContext in a ThreadLocal?

    private static ThreadLocalApplicationContext applicationContext = null;

 Each BeanManager gets an own ContextService instance anyway, so a simple 
 private
 member would easily work!

 Any thoughts?

 LieGrue,
 strub

Re: [VOTE] 2nd try: release Apache OpenWebBeans-1.0.0-alpha-1

2010-07-06 Thread Joseph Bergmark

+1, looks good to me.

Sincerely,

Joe


On Tue, Jul 6, 2010 at 11:12 AM, Gurkan Erdogdu gurkanerdo...@yahoo.comwrote:

 Great job Mark!

 This is my +1;


 Thanks;

 --Gurkan


 
 From: Mark Struberg strub...@yahoo.de
 To: dev@openwebbeans.apache.org
 Sent: Tue, July 6, 2010 10:57:01 AM
 Subject: [VOTE] 2nd try: release Apache OpenWebBeans-1.0.0-alpha-1

 Hi!

 I'd like to call the 2nd round of the VOTE on releasing Apache
 OpenWebBeans-1.0.0-alpha-1 .

 Maven staging repo:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-035/

 SVN source tag (960821):

 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.0.0-alpha-1/

 Source release:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-035/org/apache/openwebbeans/openwebbeans/1.0.0-alpha-1/openwebbeans-1.0.0-alpha-1-source-release.zip


 Binary release:

 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-035/org/apache/openwebbeans/openwebbeans-distribution/1.0.0-alpha-1/openwebbeans-distribution-1.0.0-alpha-1-binary.tar.gz


 PGP release keys 2FDB81B1
 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS

 Vote will be open for 72 hours.

 [ ] +1 approve
 [ ] +0 no opinion
 [ ] -1 veto (and reason why)

 txs and LieGrue,
 strub

Re: [VOTE] release openwebbeans build-tools-1.0.0

2010-06-17 Thread Joseph Bergmark

+1

On Thu, Jun 17, 2010 at 12:55 PM, Eric Covener cove...@gmail.com wrote:

 On Wed, Jun 16, 2010 at 1:25 PM, Mark Struberg strub...@yahoo.de wrote:
  Source release:
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-057/org/apache/openwebbeans/build-tools/checkstyle-rules/1.0.0/checkstyle-rules-1.0.0-source-release.zip

 +1 for release

 --
 Eric Covener
 cove...@gmail.com

Re: forced checkstyle runs

2010-06-14 Thread Joseph Bergmark

I spoke with Paul, and he told me to delete my .m2/repository/org/apache
directory.

That appears to have resolved the problem.  It took a while to redownload
everything, but a mvn clean;mvn from the top of openwebbeans no longer
fails.

Sincerely,

Joe

On Mon, Jun 14, 2010 at 3:40 AM, Mark Struberg strub...@yahoo.de wrote:

 can you please post me the log you get?

 txs and LieGrue,
 strub

 --- On Mon, 6/14/10, Joseph Bergmark bergm...@gmail.com wrote:

  From: Joseph Bergmark bergm...@gmail.com
  Subject: Re: forced checkstyle runs
  To: dev@openwebbeans.apache.org
  Date: Monday, June 14, 2010, 2:27 AM
  Even with the snippet below in my
  settings.xml file, I appears to be having
  trouble finding some of the dependencies:
 
  Missing:
  --
  1)
  org.apache.openwebbeans.build-tools:checkstyle-rules:jar:1.0.0-SNAPSHOT
 
Path to dependency:
1)
  org.apache.maven.plugins:maven-checkstyle-plugin:maven-plugin:2.2
2)
  org.apache.openwebbeans.build-tools:checkstyle-rules:jar:1.0.0-SNAPSHOT
 
  Sincerely,
 
  Joe
 
  On Sun, Jun 13, 2010 at 4:57 PM, Mark Struberg strub...@yahoo.de
  wrote:
 
   Hi again!
  
   Since the old snapshot repo still makes a lot
  problems, you will most
   probably need to add the following section to your
  ~/.m2/settings.xml:
  
mirrors
  mirror
  
  idnew.apache.snapshots/id
namenew apache snapshots
  repository. We need this to skip the old
   ones/name
urlhttp://repository.apache.org/snapshots/url
  
  mirrorOfapache.snapshots/mirrorOf
  /mirror
/mirrors
  
  
   Apache infra + maven teams are currently searching
  what's going wrong here.
  
   LieGrue,
   strub
  
  
  
   --- On Sun, 6/13/10, Mark Struberg strub...@yahoo.de
  wrote:
  
From: Mark Struberg strub...@yahoo.de
Subject: Re: forced checkstyle runs
To: dev@openwebbeans.apache.org
Date: Sunday, June 13, 2010, 7:56 PM
ding :)
   
finally all checkstyle issues are solved and I've
  now
enabled the rules in the main pom.
   
Please report me any problems you face in the
  next few
days.
   
I'll then go on and release our new owb
  build-tools project
so we can start with the OWB-1.0.0-CR1 tasks.
   
LieGrue,
strub
   
--- On Mon, 6/7/10, Mark Struberg strub...@yahoo.de
wrote:
   
 From: Mark Struberg strub...@yahoo.de
 Subject: forced checkstyle runs
 To: dev@openwebbeans.apache.org
 Date: Monday, June 7, 2010, 11:53 AM
 Hi folks!

 I've prepared our build for automatically
  checking our
code
 style quality in the future.

 I've changed the settings of the
maven-checkstyle-plugin
 but currently left it disabled. I'll try to
  fix all
the
 issues tonight and then enable it in the
  next days.

 I created an own build-tools project which
  is _not_
in
 trunk but has an own SVN root in
   https://svn.apache.org/repos/asf/openwebbeans/build-tools/trunk

 We will need to release this upfront before
  we go on
and
 release owb.

 I already did a snapshot release to the
  apache
snapshots
 repo so there will be no need to build it
  manually.

 LieGrue,
 strub

Re: JIRA for OSGi things?

2010-05-19 Thread Joseph Bergmark

If there isn't an existing JIRA issue, I'd vote create a new one.

I found another small issue yesterday while working on Abstract Decorators.
Basically the JavassistProxyFactory uses a bunch of static maps for its
caches.  Those maps all get cleared when the AbstractLifecycle stop occurs.
It won't be a huge deal, but any other applications that don't get stopped
will have to re-create those classes to be put back into the cache.

One solution I was considering was to have the JavaassistProxyFactory be
another singleton we load using WebBeansFinder.  That way when we clear it
we are only clearing the factory that contains the cached classes for the
app stopping.  Just means we would have to stop caling into those methods
statically.

Sincerely,

Joe Bergmark


On Wed, May 19, 2010 at 12:44 PM, Mark Struberg strub...@yahoo.de wrote:

 Hi!

 I've seen we recently did add OSGi support, but I cannot find a Jira. Need
 to fix a small thing, so which to use?

 LieGrue,
 strub

Re: New Release

2010-05-18 Thread Joseph Bergmark

In general this sounds good.

Is the goal to have 100% TCK passing using the 1.0.X stream of the TCK?

We still have at least a couple of outstanding spec issues that I'm aware
of:
1) Abstract decorators don't work - I'm working on this now, my dog had to
be taken to the vet and lost my focus on this last week.
2) Interceptors  Decorators for Dependent scoped beans really shouldn't
function via a proxy.

I'm not sure if there are TCK test cases for either of the above, but would
be nice to fix the things we know of.

Sincerely,

Joe

On Tue, May 18, 2010 at 6:55 AM, Jean-Louis MONTEIRO jeano...@gmail.comwrote:

 That'd be great!

 Jean-Louis

 2010/5/18 Mark Struberg strub...@yahoo.de:
  +1
 
  LieGrue,
  strub
 
  --- On Tue, 5/18/10, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
 
  From: Gurkan Erdogdu gurkanerdo...@yahoo.com
  Subject: New Release
  To: dev@openwebbeans.apache.org
  Date: Tuesday, May 18, 2010, 10:07 AM
  Hello folks;
 
  I want to release a 1.0.0-CR1 next week. After a CR5 we can
  go to GA.
 
  WDYT?
 
  Thanks;
 
  --Gurkan

Re: tck artifacts not resolving?

2010-05-14 Thread Joseph Bergmark

Specifically about 1.0.x vs 1.1.x, I think 1.0.X is the version that needs
to be passed to be considered compliant right?  1.1.X is the stream they are
adding new test cases to as they go.

Sincerely,

Joe

On Fri, May 14, 2010 at 8:58 AM, Mark Struberg strub...@yahoo.de wrote:

 Yes, but in this case we must not include those versions in our pom.

 Basically our project should be compilable with

 mvn clean install

 without any tweaking. Instead we should keep our webbeans-porting on the
 latest _released_ version and please update your pom.xml locally.

 In addition 1.0.2-SNAPSHOT is an old version of the TCK. The latest version
 is 1.1.0-SNAPSHOT afaik.

 LieGrue,
 strub


 --- On Fri, 5/14/10, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:

  From: Gurkan Erdogdu gurkanerdo...@yahoo.com
  Subject: Re: tck artifacts not resolving?
  To: dev@openwebbeans.apache.org
  Date: Friday, May 14, 2010, 12:19 PM
  Hello,
 
  I have manually download  and install from
 http://anonsvn.jboss.org/repos/weld/cdi-tck/branches/1.0
 
  Thanks;
 
 
  --Gurkan
 
 
  
  From: Eric Covener cove...@gmail.com
  To: dev@openwebbeans.apache.org
  Sent: Fri, May 14, 2010 3:13:50 PM
  Subject: tck artifacts not resolving?
 
  My sandbox is unable to find
  org.jboss.jsr299.tck:jsr299-tck-api:jar:1.0.2-SNAPSHOT
 
  I manually poked around jboss'es repository and only saw
  what looked
  like very old TCK artifacts.  I mostly bluff my way
  through maven, but
  is -porting building for anyone else?
 
 
  --
  Eric Covener
  cove...@gmail.com

Re: Need to switch to subclassing?

2010-05-11 Thread Joseph Bergmark

I don't have Gurkan's experience in the spec, but this seems to be what
section 7.2 is all about.  When do you treat a method call as a business
method invocation, and how does that affect things like Decorators and
Interceptor invocation.

The only wording that hints this shouldn't work when calling another method
inside the bean is When the container invokes a method of a bean.

I do think there is a need for a subclassing approach, specifically for
dependent scoped objects that we can not proxy.

Sincerely,

Joe


On Tue, May 11, 2010 at 1:30 AM, Mark Struberg strub...@yahoo.de wrote:

 Hi!

 There is a subtle difference between implementing interceptors via proxy or
 via subclasses.

 I have the following service which imports data from a legacy system into
 my db. Since commits are very performance intense, they should get imported
 in packages of 100. So I'll get 100 'Employees' from my legacy system and
 then call a @Transactional method to store them in my own database.

 public void ImportService() {
  public void importEmployee() {
ListLegacyEmployee les;
while ((les = getNext100EmployeesFromLegacy()) != nul) {
  importLegacyEmployees(le);
}
  }

  @Transactional
  protected importLegacyEmployees(ListLegacyEmployee les) {
for (LegacyEmployee le: les) {
  employeeService.store(le);
}
  }
 }

 This would actually _not_ when using proxies for the interceptor handling,
 because calling a method on an own class doesn't invoke the proxyhandler.

 So is this expected to work?

 Sure, I could easily move the importLegacyEmployees() to an own service,
 but that would infringe classic OOP heavily imo.

 Gurkan, what does the spec say here, I did find nothing. The old spec
 explicitly mentioned that we need to use subclassing, but I cannot find this
 anymore.

 LieGrue,
 strub

Re: [jira] Commented: (OWB-369) Static ContextsService in ContextFactory causes wrong webContextService used for multiple applications

2010-05-07 Thread Joseph Bergmark

Perhaps it would be more clear if detailed what I think is happening in this
particular example:

1) WebBeansFinder loads a single WebContextService per application (happens
during the Lifecycle init).
2) WebContextService calls ConversationManager.getInstance();, which would
use the WebBeansFinder to load a single ConversationManager per class.
However, it then stores the result away in a static variable.

Once that ConversationManager is in a static variable of the WebBeansFinder,
its going to get used for ALL instances of the WebContextService, even
though each application will have its own instance.

Sincerely,

Joe

On Fri, May 7, 2010 at 10:54 AM, Joseph Bergmark bergm...@apache.orgwrote:

 I'm not sure I understand the point you are trying to make here Gurkan.
 Are you saying you do not want to make changes that will allow OpenWebBeans
 to work in tiered classloading environments?  This isn't the first time an
 issue like that has come up, and we have made several changes already.

 As we already have requests to publish the build artifacts as OSGi bundles,
 so there are people attempting to use OWB in exactly this way.

 In this case it is probably a very simple fix.  The code just has to treat
 static variables as something that gets shared between applications, and
 instance variables as things that get shared within an application.
 WebBeansFinder already provides a way of loading one instance of a class per
 classloader, so you get the one per app level of loading already.  I'm not
 sure what the additional value we are getting from static variables in
 WebContextService (as an example).

 From my perspective, I don't think we can expect every consumer of OWB to
 be bundling the jars inside of their application.

 Sincerely,

 Joe


 On Fri, May 7, 2010 at 10:02 AM, Gurkan Erdogdu (JIRA) j...@apache.orgwrote:


[
 https://issues.apache.org/jira/browse/OWB-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865159#action_12865159]

 Gurkan Erdogdu commented on OWB-369:
 

 Joe,

 As I said OWB not written for tiered-class loaders. So all of the loaded
 classes must be loaded by each web application classloaders therefore does
 not collide with each other.

 For example: Each web application has its own webbeans-finder class and
 different ConversationManager.

  Static ContextsService in ContextFactory causes wrong webContextService
 used for multiple applications
 
 --
 
  Key: OWB-369
  URL: https://issues.apache.org/jira/browse/OWB-369
  Project: OpenWebBeans
   Issue Type: Bug
 Affects Versions: M4
 Reporter: YING WANG
 Assignee: YING WANG
  Fix For: 1.0.0
 
 
  To reproduce,
  Application A, which does not support conversation, installed and tested
 without any issue. then stop and uninstalled.
  Application B, which support conversation, get installed and started.
  When test Application B, ApplicationA's contextService is used and
 causes conversation scope is not found since it does not support
 conversation.
  The problem is because of static variable used for contextsService in
 ContextFactory which is JVM-wide and only init once. While
 supportConversation flag is application-wide property.
  Probably we need contextService  variable to be  classloader based
 instead of static variable. or need some change to supportsConversation
 flag.

 --
 This message is automatically generated by JIRA.
 -
 You can reply to this email to add a comment to the issue online.

Re: svn commit: r933348 - in /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/intercept: ApplicationScopedBeanIntereptorHandler.java DependentScopedBeanInterceptorHandler.java Int

2010-04-13 Thread Joseph Bergmark

I know I'm jumping into the conversation a bit late, but Im trying to catch
up and get my head in the game a bit.

I looked over the code, and read over Mark's example scenario earlier, which
I'll paste a snippet of:


And now consider a webserver with 10.000 different users clicking on the
send button at the same time...

ALL those MailFormBean instances will use the same instance of MailService
since this is @ApplicationScoped, right?
And the MailService#user is a proxy to the User, still ok?
But there is only ONE instance of MailService#user! And this will got hit by
10.000 requests from different users concurrently.

I think the part I'm missing, is why it matters if there is only 1
MailService#User proxy, if every time that proxy is used we get the correct
instance of that User from the session scope?  That SessionScoped object
isn't stored in MailService's creational context is it (which I agree is
shared)?  I'm probably missing something obvious here.

Sincerely,

Joe



On Tue, Apr 13, 2010 at 5:14 AM, Gurkan Erdogdu gurkanerdo...@yahoo.comwrote:

 Anyway I have reverted to beginning, and create an issue. Because tinkering
 in somewhere must not destroy some other places as a side affect.

 At evening, we could discuss the current design of the OWB regarding CC and
 setup a plan how to handle this weird situation without not effecting other
 places. After that we can work on to update code if everybody understands
 the +/- of design.


 Thanks;

 --Gurkan


 
 From: Mark Struberg strub...@yahoo.de
 To: dev@openwebbeans.apache.org
 Sent: Tue, April 13, 2010 12:00:24 PM
 Subject: Re: svn commit: r933348 - in
 /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/intercept:
  ApplicationScopedBeanIntereptorHandler.java
 DependentScopedBeanInterceptorHandler.java  InterceptorHandler.java
 NormalScopedBeanInterceptorHand

 Which point of my argumentation chain?
 Which sentence?
 Which section in the spec does get injured?

 LieGrue,
 strub

 --- Gurkan Erdogdu gurkanerdo...@yahoo.com schrieb am Di, 13.4.2010:

  Von: Gurkan Erdogdu gurkanerdo...@yahoo.com
  Betreff: Re: svn commit: r933348 - in
 /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/intercept:
  ApplicationScopedBeanIntereptorHandler.java
 DependentScopedBeanInterceptorHandler.java  InterceptorHandler.java
 NormalScopedBeanInterceptorHand
  An: dev@openwebbeans.apache.org
  Datum: Dienstag, 13. April, 2010 10:57 Uhr
  Your points are not aligned with
  specification. You have viewed a different perspective on
  using CContexts from how TCK and OWB are implemented .
 
  :)
 
 
 
  
  From: Mark Struberg strub...@yahoo.de
  To: dev@openwebbeans.apache.org
  Sent: Tue, April 13, 2010 11:38:18 AM
  Subject: Re: svn commit: r933348 - in
 
 /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/intercept:
  ApplicationScopedBeanIntereptorHandler.java
  DependentScopedBeanInterceptorHandler.java
  InterceptorHandler.java NormalScopedBeanInterceptorHand
 
  Hoi!
 
  The problem is not that CreationalContext is not thread
  safe, but that NormalScopedBeanInterceptorHandler is not
  thread safe if you store the CreationalContext as member
  variable :)
 
  And yes, I'm eating the provided CreationalContext for
  NormalScoped bean proxies, because in my opinion it must not
  get used. The argument:
 
  1.) All contextual instances created within a
  CreationalContext hierarchy chain will get stored _within_
  that CreationalContext (for later being able to #destroy()
  them)
 
  2.) The CreationalContext will gets stored along with the
  uppermost contextual instance into the Context (the one who
  triggered Contextual#create(CreationalContext)), as an
  example in the JSF ViewMap (ViewScopedContext)
 
  3.) Only @Dependent objects must get stored in the same
  CreationalContext hierarchy, because they need to get stored
  on the same storage.
 
  4.) injected @NormalScoped contextual instances must _NOT_
  get added to the parents CreationalContext hierarchy chain,
  because otherwise this would lead to storing them alongside
  with the uppermost contextual instances CreationalContext.
  So if a @ViewScoped BeanV gets an @ApplicationScoped BeanA
  injected, a reference to BeanA would get stored in the
  ViewMap. And since BeanA is not serializable (application
  scoped beans most likely aren't) this did lead to the known
  serialization problems we faced.
 
  Imo a @NormalScoped bean _always_ breaks the
  CreationalContext hierarchy chain and _always_ gets it's own
  one.
 
  I think the whole wording of the CreationalContext in the
  spec is a bit obsolete and thus misleading now. This is from
  an area where we didn't have the mandatory proxying
  requisite in the spec - but never got cleared up properly.
 
  LieGrue,
  strub
 
 
  --- Gurkan Erdogdu gurkanerdo...@yahoo.com
  schrieb am Di, 13.4.2010:
 
   Von: Gurkan Erdogdu

Re: are @PostConstruct and @PreDestroy really interceptor functions?

2010-04-07 Thread Joseph Bergmark

I agree it may not be necessary, but Gavin has strongly hinted that he
expected Decorators (and maybe even Interceptors) to be implemented using
subclassing.  Seems our current solution works in a spec compliant way for
normal scoped beans though.  Not sure if any MRs to the spec will change
that.

Sincerely,

Joe

On Wed, Apr 7, 2010 at 3:48 PM, Gurkan Erdogdu gurkanerdo...@yahoo.comwrote:

 Actually, for normal scoped beans it is not necessary to add byte code
 injection altough it can be done. Because running code is there, you could
 concentrate on some other stuff. But it is handy way to use it on
 DependentScoped beans interceptors, because spec. talks about subclassing
 for dependent scoped beans.

 Thanks;

 --Gurkan




 
 From: Mark Struberg strub...@yahoo.de
 To: dev@openwebbeans.apache.org
 Sent: Wed, April 7, 2010 10:21:32 PM
 Subject: Re: are @PostConstruct and @PreDestroy really interceptor
 functions?

 Thanks Gurkan!

 I now also found the utility method who filters out the AROUND_INVOKE
 interceptors we need.

 Did you look at the test code which shows the principal way to create
 subclasses which I committed?
 wdyt?

 LieGrue,
 strub

 --- Gurkan Erdogdu gurkanerdo...@yahoo.com schrieb am Mi, 7.4.2010:

  Von: Gurkan Erdogdu gurkanerdo...@yahoo.com
  Betreff: Re: are @PostConstruct and @PreDestroy really interceptor
 functions?
  An: dev@openwebbeans.apache.org
  Datum: Mittwoch, 7. April, 2010 21:19 Uhr
  Those are not handled by
  InterceptorHandler. These are defined in
  AbstractInjectionTargetBean#postConstruct or preDestroy
 
 
 
 
  
  From: Mark Struberg strub...@yahoo.de
  To: dev@openwebbeans.apache.org
  Sent: Wed, April 7, 2010 7:56:37 PM
  Subject: are @PostConstruct and @PreDestroy really
  interceptor functions?
 
  Hi!
 
  Currently we handle @PostConstruct and @PreDestroy methods
  via the InterceptorHandler.
 
  Is this really necessary?
 
  Those functions are directly called by the container in
  very clear defined situations in the lifecycle. And they
  always get called from _inside_ the container and not
  triggered by any client code.
 
  So can we move those 2 out of the interceptor stack?
 
  wdyt?
 
  LieGrue,
  strub
 
  __
  Do You Yahoo!?
  Sie sind Spam leid? Yahoo! Mail verfügt über einen
  herausragenden Schutz gegen Massenmails.
  http://mail.yahoo.com
 
 
 
 
  ___
  Yahoo! Türkiye açıldı!  http://yahoo.com.tr
  İnternet üzerindeki en iyi içeriği Yahoo! Türkiye
  sizlere sunuyor!

 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
 gegen Massenmails.
 http://mail.yahoo.com



  ___
 Yahoo! Türkiye açıldı!  http://yahoo.com.tr
 İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!

Re: Build failures

2010-03-08 Thread Joseph Bergmark

The problematic library appears to be jboss-test-harness-api.  You can see
the error in the logs here:

http://hudson.zones.apache.org/hudson/job/OpenWebBeans-trunk/59/console

Sincerely,

Joe

On Mon, Mar 8, 2010 at 10:38 AM, Gurkan Erdogdu cgurkanerdo...@gmail.comwrote:

 Hello;

 Yeap, I will commit main pom I forgot.

 For other question please have a
 lookhttp://
 maven.apache.org/guides/mini/guide-central-repository-upload.html,
 FAQ and common mistakes.

 What is the problematic library that causes building failed? We can just
 add
 this into main pom.xml if there is no published version in the main central
 maven repository.

 Thanks;

 --Gurkan


 2010/3/8 Joseph Bergmark bergm...@apache.org

  It appears the last couple hudson build have been failing as the root
  pom.xml references webbeans-ee/pom.xml that doesn't exist.  Perhaps this
  file was missed in a recent commit?
 
  On a broader note, the hudson builds have been failing at a later point
 for
  a while now, apparently due to the removal of jboss repositories from the
  root pom.xml, and the assumption that these have been added to an
  individual's settings.xml.  What is the reasoning behind removing these
  from
  the root pom.xml, but still requiring them for the project to build?
 
  Sincerely,
 
  Joe Bergmark
 



 --
 Gurkan Erdogdu
 http://gurkanerdogdu.blogspot.com

Re: [VOTE] Release OpenWebBeans-M4

2010-03-03 Thread Joseph Bergmark

It looks like you need to add the JBoss repo both for the samples to work
from the binary archives, and for the source archives to build. Is that
acceptable for a milestone release?

I ran the reservation sample from a seperate machine (that didn't have
javaassist 3.11.0 in my local .m2 already), and I'm not seeing the NPE in
reservation once I added the jboss repositories to the pom.xml. That
problem does appear to have been isolated to my development machine.

Sincerely,

Joe

On Wed, Mar 3, 2010 at 7:03 AM, Jean-Louis MONTEIRO jeano...@gmail.comwrote:

Hey!

As a side note, the LICENCE file contains Copyright [] [name of
copyright owner].
Dunno if it's important for a milestone release.

To make samples working, you should add Gurkan's repo and JBoss repo
cause javassist 3.11.0.GA is not available in central.
Already discussed that point with Mark. I'll try to push javassist
3.11 to central repo.

jsf2sample: missing version in plugin jetty (same for
conversation-sample - at least).

In my opinion, it'd be great to add a plugin management section in the
sample parent pom defining jetty plugin version.

Good job guys.
Jean-Louis

2010/3/2 Gurkan Erdogdu gurkanerdo...@yahoo.com:
1* For errors: I have tried from source, binaries and tag versions. All
of them have worked.
Did the following
* Remove ~/.m2/repositories/org/apache/openwebbeans
* Add the following to reservation/pom.xml to use staged maven modules
repositories
repository
idsddfsnapshots.jboss.org/id

http://people.apache.org/~gerdogdu/staging-repo/OWB/1.0.0-M4/plugins/http://people.apache.org/%7Egerdogdu/staging-repo/OWB/1.0.0-M4/plugins/
/repository
/repositories
* mvn clean jetty:run -Pjetty
* It works

Also tried from distribution source version, and install it.
Also tried tag version.

All of them work in my machine JDK 1.6.0_14, Ubuntu 8.04 - the Hardy
Heron, Apache Maven 2.2.1

2* For second, repositories related with Jboss and third parties
generally setup on settings.xml instead of in pom.xml. Therefore we remove
JBoss related repos from pom.xml. But as you said, it is beneficial to
commen those repositories in README file. We can touch it on next release. I
think it is not a negative impact on vote. (Actually this repos are related
with TCK packages that are not directly used by users)

Thanks;

--Gurkan

From: Joseph Bergmark bergm...@apache.org
To: dev@openwebbeans.apache.org
Sent: Wed, March 3, 2010 12:24:34 AM
Subject: Re: [VOTE] Release OpenWebBeans-M4

I was able to verify the signature of the source and binary files.
However
I've run into a couple of problems

1) I added the M4 staging repo to the pom.xml of a couple of the samples
from the binary tar.gz and ran them to ensure they worked as expected.
Both
guess and jsf2sample worked fine, however when I tried to follow the Not
a
registered! Register here...
http://localhost:8080/reservation/register.jsf
in the reservation sample I hit a NPE:

Caused by: java.lang.NullPointerException
at
org.apache.webbeans.reservation.util.LogUtil.getLogger(LogUtil.java:33)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at
org.apache.webbeans.inject.InjectableMethods.doInjection(InjectableMethods.java:117)
at
org.apache.webbeans.component.ProducerMethodBean.createDefaultInstance(ProducerMethodBean.java:184)
at
org.apache.webbeans.component.ProducerMethodBean.createInstance(ProducerMethodBean.java:151)
at
org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:153)
at
org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:65)
at
org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:151)
at
org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:784)

I did a bit of debugging, and it appears the injected InjectionPoint is
null.

Gurkan is not able to reproduce this error, so it is possibly something
specific to my environment. Is anyone else seeing this problem? I'll
try
it on another machine later tonight.

2) I then tried to build from the source zip, and hit a missing
dependency
executing mvn clean install from the top level openwebbeans directory:
Missing:
--
1) org.jboss.test-harness:jboss-test-harness-api:jar:1.1.0-CR5

It appears this comes from the 299 TCK:

Path to dependency:
1) org.apache.openwebbeans:openwebbeans-porting:jar:1.0.0-M4
2) org.jboss.jsr299.tck:jsr299-tck-api:jar:1.0.1-Final
3) org.jboss.test

Re: [VOTE] Release OpenWebBeans-M4

2010-03-03 Thread Joseph Bergmark

+1 from me then.

This has been the case for a while, but previously the jboss repositories
were explicit in the top level pom.xml.

Sincerely,

Joe

2010/3/3 Matthias Wessendorf mat...@apache.org

 yes, IMO not a stopper! (isn't this already since a while?)
 (yeah, i have the jboss repos in my default profile (via settings.xml))

 -M

 2010/3/3 Jean-Louis MONTEIRO jeano...@gmail.com:
  Sounds good to me even if i definitely prefer self contained pom (ie.
  avoid necessary information in settings.xml).
  As it's not a release stopper issue, here is my
 
  +1
 
  JLouis
 
  2010/3/3 Gurkan Erdogdu cgurkanerdo...@gmail.com:
  And also same scenario exists to install from source (setting up some
 JBoss
  repos on settings.xml). In source version, we just tag the source from
  /trunk. This is also valid for us, committers. If we have not set those
  repos in settings.xml, not compile.
 
  We could add some comments to README on BUILD from source at next
 release.
 
  --Gurkan
 
  03 Mart 2010 17:17 tarihinde Gurkan Erdogdu cgurkanerdo...@gmail.com
 yazdı:
 
  Is that acceptable for a milestone release?
  Samples are given as a source not as a binary. Its the user
 responsibility
  to setup correct maven repository in his/her environments.  I think
 that
  this is not a release stopper issue.
 
  Thanks;
 
  --Gurkan
 
  2010/3/3 Joseph Bergmark bergm...@apache.org
 
  It looks like you need to add the JBoss repo both for the samples to
 work
  from the binary archives, and for the source archives to build.  Is
 that
  acceptable for a milestone release?
 
  I ran the reservation sample from a seperate machine (that didn't have
  javaassist 3.11.0 in my local .m2 already), and I'm not seeing the NPE
 in
  reservation once I added the jboss repositories to the pom.xml.  That
  problem does appear to have been isolated to my development machine.
 
  Sincerely,
 
  Joe
 
  On Wed, Mar 3, 2010 at 7:03 AM, Jean-Louis MONTEIRO 
 jeano...@gmail.com
  wrote:
 
   Hey!
  
   As a side note, the LICENCE file contains Copyright [] [name of
   copyright owner].
   Dunno if it's important for a milestone release.
  
   To make samples working, you should add Gurkan's repo and JBoss repo
   cause javassist 3.11.0.GA is not available in central.
   Already discussed that point with Mark. I'll try to push javassist
   3.11 to central repo.
  
   jsf2sample: missing version in plugin jetty (same for
   conversation-sample - at least).
  
   In my opinion, it'd be great to add a plugin management section in
 the
   sample parent pom defining jetty plugin version.
  
   Good job guys.
   Jean-Louis
  
  
  
  
   2010/3/2 Gurkan Erdogdu gurkanerdo...@yahoo.com:
1* For errors: I have tried from source, binaries and tag
 versions.
  All
   of them have worked.
   Did the following
   * Remove ~/.m2/repositories/org/apache/openwebbeans
   * Add the following to reservation/pom.xml to use staged maven
  modules
 repositories
   repository
   idsddfsnapshots.jboss.org/id
   
  
 http://people.apache.org/~gerdogdu/staging-repo/OWB/1.0.0-M4/plugins/http://people.apache.org/%7Egerdogdu/staging-repo/OWB/1.0.0-M4/plugins/
 http://people.apache.org/%7Egerdogdu/staging-repo/OWB/1.0.0-M4/plugins/
  
 http://people.apache.org/%7Egerdogdu/staging-repo/OWB/1.0.0-M4/plugins/
   /repository
   /repositories
  * mvn clean jetty:run -Pjetty
  * It works
   
Also tried from distribution source version, and install it.
Also tried tag version.
   
All of them work in my machine JDK 1.6.0_14,  Ubuntu 8.04  - the
 Hardy
   Heron, Apache Maven 2.2.1
   
2* For second, repositories related with Jboss and third parties
   generally setup on settings.xml instead of in pom.xml. Therefore we
  remove
   JBoss related repos from pom.xml. But as you said, it is beneficial
 to
   commen those repositories in README file. We can touch it on next
  release. I
   think it is not a negative impact on vote. (Actually this repos are
  related
   with TCK packages that are not directly used by users)
   
   
Thanks;
   
--Gurkan
   
   
   
   

From: Joseph Bergmark bergm...@apache.org
To: dev@openwebbeans.apache.org
Sent: Wed, March 3, 2010 12:24:34 AM
Subject: Re: [VOTE] Release OpenWebBeans-M4
   
I was able to verify the signature of the source and binary files.
However
I've run into a couple of problems
   
1) I added the M4 staging repo to the pom.xml of a couple of the
  samples
from the binary tar.gz and ran them to ensure they worked as
 expected.
Both
guess and jsf2sample worked fine, however when I tried to follow
 the
  Not
   a
registered! Register here...
   http://localhost:8080/reservation/register.jsf
in the reservation sample I hit a NPE:
   
Caused by: java.lang.NullPointerException

Re: [VOTE] Release OpenWebBeans-M4

2010-03-02 Thread Joseph Bergmark

I was able to verify the signature of the source and binary files.  However
I've run into a couple of problems

1) I added the M4 staging repo to the pom.xml of a couple of the samples
from the binary tar.gz and ran them to ensure they worked as expected.  Both
guess and jsf2sample worked fine, however when I tried to follow the Not a
registered! Register here...http://localhost:8080/reservation/register.jsf
in the reservation sample I hit a NPE:

Caused by: java.lang.NullPointerException
at 
org.apache.webbeans.reservation.util.LogUtil.getLogger(LogUtil.java:33)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at 
org.apache.webbeans.inject.InjectableMethods.doInjection(InjectableMethods.java:117)
at 
org.apache.webbeans.component.ProducerMethodBean.createDefaultInstance(ProducerMethodBean.java:184)
at 
org.apache.webbeans.component.ProducerMethodBean.createInstance(ProducerMethodBean.java:151)
at 
org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:153)
at 
org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:65)
at 
org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:151)
at 
org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:784)

I did a bit of debugging, and it appears the injected InjectionPoint is
null.

Gurkan is not able to reproduce this error, so it is possibly something
specific to my environment.  Is anyone else seeing this problem?  I'll try
it on another machine later tonight.

2) I then tried to build from the source zip, and hit a missing dependency
executing mvn clean install from the top level openwebbeans directory:
Missing:
--
1) org.jboss.test-harness:jboss-test-harness-api:jar:1.1.0-CR5

It appears this comes from the 299 TCK:

Path to dependency:
  1) org.apache.openwebbeans:openwebbeans-porting:jar:1.0.0-M4
  2) org.jboss.jsr299.tck:jsr299-tck-api:jar:1.0.1-Final
  3) org.jboss.test-harness:jboss-test-harness-api:jar:1.1.0-CR5

Should we document that JBoss repositories need to be added to your local
settings for the source zip to build?  I know we removed some repositories
from the top level pom.xml.

Sincerely,

Joe

On Tue, Mar 2, 2010 at 3:38 AM, Matthias Wessendorf mat...@apache.orgwrote:

 +1

 On Mon, Mar 1, 2010 at 10:01 PM, Mark Struberg strub...@yahoo.de wrote:
  +1 from me too.
 
 
  PS: @OWB-289: since I now know _what_ the problem is, it  is really easy
 to do a workaround by moving my other producerMethod to an own class. The
 problem was that this is part of a pretty complicated usecase, and I only
 did see my program fail randomly, which made me frankly said a bit nervous
  ;)
 
  LieGrue,
  strub
 
  --- Gurkan Erdogdu gurkanerdo...@yahoo.com schrieb am Mo, 1.3.2010:
 
  Von: Gurkan Erdogdu gurkanerdo...@yahoo.com
  Betreff: [VOTE] Release OpenWebBeans-M4
  An: dev@openwebbeans.apache.org
  Datum: Montag, 1. März, 2010 21:52 Uhr
  Hi;
 
  Finally  release time  :)
 
  This is the OpenWebBeans M4 release [VOTE] process.
 
  I've staged the releases artifacts here:
 
  Plugins repository
  --
 
 http://people.apache.org/~gerdogdu/staging-repo/OWB/1.0.0-M4/plugins/org/apache/openwebbeanshttp://people.apache.org/%7Egerdogdu/staging-repo/OWB/1.0.0-M4/plugins/org/apache/openwebbeans
 
  Distribution content
  
 
 http://people.apache.org/~gerdogdu/staging-repo/OWB/1.0.0-M4/distribution/org/apache/openwebbeans/apache-openwebbeans/1.0.0-M4/http://people.apache.org/%7Egerdogdu/staging-repo/OWB/1.0.0-M4/distribution/org/apache/openwebbeans/apache-openwebbeans/1.0.0-M4/
 
  SVN Tag (Revision: 917708)
  
  http://svn.apache.org/repos/asf/openwebbeans/tags/1.0.0-M4/
 
  This is the README file for the M4 release for quick
  review:
 
 
 http://svn.apache.org/repos/asf/openwebbeans/tags/1.0.0-M4/readme/README_M4.txt
 
  Please verify that this release package is correct and vote
  for the
  motion to publish this as a OpenWebBeans M4 release.
  All votes are welcome and will be counted.
 
  VOTE is open for 72 hours
 
  This is my +1
 
  Thanks;
 
  /Gurkan
 
 
 
  ___
  Yahoo! Türkiye açıldı!  http://yahoo.com.tr
  İnternet üzerindeki en iyi içeriği Yahoo! Türkiye
  sizlere sunuyor!
 
  __
  Do You Yahoo!?
  Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
 gegen Massenmails.
  http://mail.yahoo.com
 



 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf

Re: TCK Report Before M4

2010-02-24 Thread Joseph Bergmark

As I am sure you are already aware I've been working on some of the
Decorator based TCK tests.  I've even opened at least one bug to find out
you fixed it a few hours beforehand :)

Primarily I've been focused on:

org.jboss.jsr299.tck.tests.decorators.invocation.DecoratorInvocationTests
(opened OWB-302 that is currently blocking one test here)
org.jboss.jsr299.tck.tests.decorators.resolution.DecoratorResolutionTest

and the DecoratorDefinition tests that all pass now.

Sincerely,

Joe


On Wed, Feb 24, 2010 at 2:39 PM, Gurkan Erdogdu gurkanerdo...@yahoo.comwrote:

 Hello folks;

 I have been  working on standalone TCK (standalone means that not running
 in container but includes EJB tests using OpenEJB) for a long time and
 decreased the number of failed tests considerably. Some of those failed
 tests are related with CDI-TCK bug and reported to CDI-TCK team. Some of
 them are not correctlyy implemented in OWB. I give the failed tests and
 their reasons why they have failed:

 I have so tired  and I invite all of you to help me to pass it :) Working
 on TCK likes walking on spiny road. Please create a JIRA for any test you
 want to work on to pass it :)

 I have tested with the CDI-TCK 1.0.1-Final, and I have used TestNG plugin
 for Eclipse.

 Please do not commit big changes to current code base. I will start to
 release procedure by tomorrow evening maybe Saturday.

 Total Test: 582
 Failed Test: 28

 Thanks;

 --Gurkan
 

 org.jboss.jsr299.tck.tests.lookup.byname.duplicatePrefixResolution.DuplicateNamePrefixResolutionTest
 -- NOT IMPLEMENTED (EL Names)
 org.jboss.jsr299.tck.tests.lookup.typesafe.resolution.ResolutionByTypeTest
  -- I really do not understand. Sometimes work, sometimes not
 org.jboss.jsr299.tck.tests.lookup.byname.duplicateNameResolution.DuplicateNameResolutionTest
 --NOT IMPLMENTED (EL Names)
 org.jboss.jsr299.tck.tests.lookup.circular.CircularDependencyTest
 org.jboss.jsr299.tck.tests.lookup.injectionpoint.InjectionPointTest --
 InjectionPoint with Decorators delegate problem!

 --OpenEJB Does not support beans without definining interface
 org.jboss.jsr299.tck.tests.implementation.enterprise.broken.singletonWithSessionScope.SingletonWithSessionScopeTest
 --NOT CLient Interface
 org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest
 --NOT ClientInterface --NOT CLient Interface
 org.jboss.jsr299.tck.tests.implementation.enterprise.broken.singletonWithRequestScope.SingletonWithRequestScopeTest
 --NOT CLient Interface


 org.jboss.jsr299.tck.tests.context.dependent.DependentContextTest
 org.jboss.jsr299.tck.tests.context.passivating.broken.enterpriseBeanWithNonPassivatingInjectedFieldInInterceptor.EnterpriseBeanWithNonPassivatingInjectedFieldInInterceptorTest
 -- EJB Interceptor Injections Not Supported

 org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingBeanConstructor.DecoratorWithNonPassivatingBeanConstructorTest
 -- Seems a bug in TCK
 org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInitializerMethod.DecoratorWithNonPassivatingInitializerMethodTest
 -- Seems a bug in TCK
 org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInjectedField.DecoratorWithNonPassivatingInjectedFieldTest--
 Seems a bug in TCK


 org.jboss.jsr299.tck.tests.context.passivating.broken.passivatingProducerMethodWithNonPassivatingParameter.PassivatingProducerMethodWithNonPassivatingParameterTest


 org.jboss.jsr299.tck.tests.event.observer.wildcardAndTypeVariable.ObserverMethodWithParametertizedTypeTest

 org.jboss.jsr299.tck.tests.extensions.beanManager.BeanManagerTest --
 CDITCK-121

 org.jboss.jsr299.tck.tests.decorators.invocation.DecoratorInvocationTest
 org.jboss.jsr299.tck.tests.decorators.resolution.DecoratorResolutionTest


 org.jboss.jsr299.tck.tests.inheritance.specialization.simple.broken.extendejb.testSpecializingClassDirectlyExtendsEnterpriseBean

 org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.directlyExtendsSimpleBean.DirectlyExtendsSimpleBeanTest

 org.jboss.jsr299.tck.tests.inheritance.specialization.producer.method.ProducerMethodSpecializationTest

 org.jboss.jsr299.tck.tests.inheritance.specialization.simple.broken.extendejb.SpecializingBeanExtendsEnterpriseBeanTest



  ___
 Yahoo! Türkiye açıldı!  http://yahoo.com.tr
 İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!

Re: testng in eclipse -- can't debug from 'failed tests'

2010-02-24 Thread Joseph Bergmark

I've been running individual classes by going to either Debug or Run and
then the Run Configurations (or equivalent debug configurations) and then
typing in the class name beside the class radio button for a TestNG type.  I
haven't tried running a single class or method from inside the result tab
however.

Sincerely,

Joe

On Wed, Feb 24, 2010 at 8:52 PM, Eric Covener cove...@gmail.com wrote:

 Hoping someone can get me on the right track. I'm using eclipse 3.5.1
 and latest testng. I can right-click the openwebbeans-tck/jsr299...xml
 and run with 33/549 failures.

 When i look in the testNG results tab, neither run or debug of
 individual failers responds at all in the GUI. I get a very
 un-googleable error on $workspace/.metadata/.log:

 !ENTRY org.eclipse.ui 4 0 2010-02-24 20:47:29.914
 !MESSAGE Unhandled event loop exception
 !STACK 0
 java.lang.NullPointerException
at org.testng.eclipse.util.JDTUtil.parse(JDTUtil.java:470)
at
 org.testng.eclipse.util.JDTUtil.solveDependencies(JDTUtil.java:439)
at
 org.testng.eclipse.util.JDTUtil.solveDependencies(JDTUtil.java:428)
at
 org.testng.eclipse.util.LaunchUtil.solveDependsOn(LaunchUtil.java:479)
at
 org.testng.eclipse.util.LaunchUtil.launchMethodConfiguration(LaunchUtil.java:238)
at org.testng.eclipse.ui.QuickRunAction.run(QuickRunAction.java:76)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
at
 org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
at
 org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
at
 org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)


 I'm on Ubuntu Karmic with an otherwise healthy workspace.

 --
 Eric Covener
 cove...@gmail.com

Re: InjectionResolver.implResolveByName performance

2010-02-23 Thread Joseph Bergmark

Along with the ordering idea, I wonder if we couldn't optimize this code
path somewhat.  We know that we are going to be invoked on almost every EL
expression (if not every EL expression).  It seems like copying that list of
all beans, just to iterate over it looking for a bean with a given name is
kind of expensive.  I wonder if we couldn't have a less expensive operation
we could call internally when we aren't afraid of exposing the list.

Sincerely,

Joe


On Tue, Feb 23, 2010 at 7:05 AM, Mark Struberg strub...@yahoo.de wrote:

 oki sure, I will defer this patch until after we ship M4!

 txs and LieGrue,
 strub

 --- Gurkan Erdogdu cgurkanerdo...@gmail.com schrieb am Di, 23.2.2010:

  Von: Gurkan Erdogdu cgurkanerdo...@gmail.com
  Betreff: Re: InjectionResolver.implResolveByName performance
  An: dev@openwebbeans.apache.org
  Datum: Dienstag, 23. Februar, 2010 12:54 Uhr
  @all: please note that
  this will make webbeans-jsf a JSF-2.0 component.
  Is this ok? We could still provide a JSF-1.2 branch of that
  later if we
  like.
  What is the meaning of  +
  nameorg.apache.openwebbeans/name?
 
  Look at it after M4 release. I do not break something huge
  before M4
  release.
 
  2010/2/23 Mark Struberg strub...@yahoo.de
 
   Martin, can you please fill a Jira?
  
   I already implemented that (with Jakob helping me).
  
   The only thing we need to do is to upgrade our
  faces-config.xml in
   webbeans-jsf:
  
   -faces-config version=1.2 xmlns=http://java.sun.com/xml/ns/javaee;
   +faces-config version=2.0 xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xi=http://www.w3.org/2001/XInclude;
   - xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
   http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd;
   + xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
   http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd;
   + nameorg.apache.openwebbeans/name
application
  
  
 
 view-handlerorg.apache.webbeans.jsf.ConversationAwareViewHandler/view-handler
 el-resolverorg.apache.webbeans.el.WebBeansELResolver/el-resolver
  
  
   @all: please note that this will make webbeans-jsf a
  JSF-2.0 component. Is
   this ok? We could still provide a JSF-1.2 branch of
  that later if we like.
  
   LieGrue,
   strub
  
  
   --- Martin Koci martin.k...@aura.cz
  schrieb am Mo, 22.2.2010:
  
Von: Martin Koci martin.k...@aura.cz
Betreff: Re: InjectionResolver.implResolveByName
  performance
An: dev@openwebbeans.apache.org
Datum: Montag, 22. Februar, 2010 22:01 Uhr
   
Yes, WebBeansELResolver tries to resolve every
  bean.
Very simple solution was to use JSF 2.0 artifact
  ordering
and put
others/ element as last one but this
  solution
unfortunately has
influence on other unnamed or JSF 1.2 based
  artifact.
   
Do you think it is possible to modify  OWB
  built for
delivering JSF 2.0
named artifact? It will help many projects with
  migration
from managed
beans and spring to CDI.
   
Example:
   
absolute-ordering
   
namemy_excelent_renderkit/name
   
 nameopenwebbeans/name
others /
/absolute-ordering
   
   
Joseph Bergmark píše v Po 22. 02. 2010 v 15:34
  -0500:
 I believe the issue is that our EL resolver
  is first
in the chain, so gets
 called every single time even if the
  expression does
not turn out to be one
 that references a CDI bean.  2 million
  does seem
like a very large number of
 times though.

 Sincerely,

 Joe

 On Mon, Feb 22, 2010 at 3:32 PM, Mark
  Struberg strub...@yahoo.de
wrote:

  Thanks Martin!
 
  And yes, this may be a problem, though
  not sure
where it comes from ...
 
  :)
 
  LieGrue,
  strub
 
  --- Martin Koci martin.k...@aura.cz
schrieb am Mo, 22.2.2010:
 
   Von: Martin Koci martin.k...@aura.cz
   Betreff:
  InjectionResolver.implResolveByName
performance
   An: dev@openwebbeans.apache.org
   Datum: Montag, 22. Februar, 2010
  21:28 Uhr
   Hi,
  
   I did some profiling and
  YourKitProfiler
always marks
  
  InjectionResolver.implResolveByName as
hotspot. It is
   called over 2
   mills. times per request/response.
  All those
calls come
   from
   ELResolver.getValue() - its is a
  very non
trivial JSF
   view  so it is
   probably ok (even two milions) and
  in
application is no CDI
   bean yet
   (all are  still spring and
  jsf
managed).
   Do you think it is a problem?
  
   Regards,
  
   Martin Kočí
  
  
  
 
 
   
  __
  Do You Yahoo!?
  Sie sind Spam leid? Yahoo! Mail
  verfügt über
einen herausragenden Schutz
  gegen Massenmails.
  http

Re: [jira] Commented: (OWB-286) java.lang.NoClassDefFoundError: javax/validation/Validator

2010-02-18 Thread Joseph Bergmark

I agree that the 3rd and 4th bullets in 3.6 make this a hard requirement.

It seems the tradeoff to me is:
1) Additional complexity of another plugin based approach to avoid this
scenario.
or
2) Handling of the CNF exception inside OWB with a warning message

vs.

The user having to bundle an API jar they don't necessarily care about
inside their application when running in a not full JEE environment.

While the latter doesn't seem like a huge burden, I've seen cases where
users have dozens on API jars inside their application and sometimes they
don't even know why or what side affects that may cause when they later run
inside a JEE environment and start changing classloader settings.

Sincerely,

Joe

On Thu, Feb 18, 2010 at 8:24 AM, Gurkan Erdogdu cgurkanerdo...@gmail.comwrote:

Pretty harsh :-)
Not intended :)

he 299 spec _require_ validator API
Yes. Look at specification 3.6 Additional Beans

does weld (candi) also have this *hard* dependency on the
javax.validation API ?
For weld -- yes

http://anonsvn.jboss.org/repos/weld/core/trunk/impl/src/main/java/org/jboss/weld/bean/builtin/ee/DefaultValidatorBean.java
http://anonsvn.jboss.org/repos/weld/core/trunk/impl/pom.xml

Thanks;

--Gurkan

2010/2/18 Matthias Wessendorf mat...@apache.org

Pretty harsh :-)

IMO JSF2 is doing better here.
It just checks if the dependency in question (yeah, javax.validation) is
present
if not = don't bother...
But... I have to say that JSF 2.0 was released _before_ the JAvaEE6
was available.

I understand your motivation for closing the ticket, but I wonder if
there actual
interest in solving this in a more convenient way.

Regarding JSF2 and Validation API:
Not only JSF2 was there _before_ JavaEE6. Playing nice here is a
gained experience when targeting a JAva EE platform (kinda)
independent release;

Interesting q:
-the 299 spec _require_ validator API

if yes = OK :)

If no =
-does weld (candi) also have this *hard* dependency on the
javax.validation API ?

-Matthias

On Thu, Feb 18, 2010 at 2:00 PM, Gurkan Erdogdu
cgurkanerdo...@gmail.com wrote:
I have remarked several times about issues related with Java EE 6
dependencies. I emphasize the fact that JSR-299 is a Java EE 6
specification
not for Jetty, Tomcat or any other containers that is not Java EE 6.
But
we
are doing the best to run it possible on those containers.

But we must not create plugins for every Java EE service dependency
because
of this does not work in some containers that are not Java EE 6
compatible.

Therefore, if you would like to use it you have to add validation-api
or
any
dependent api to your container. In our samples we add those dependent
Java
EE dependencies to our WEB-INF/lib.

Therefore this is not a bug, I will close this issue.

2010/2/18 Mark Struberg (JIRA) j...@apache.org

[

https://issues.apache.org/jira/browse/OWB-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835162#action_12835162
]

Mark Struberg commented on OWB-286:
---

too bad, this slipped into webbeans-core.
We have to move all this stuff into an own plugin.

java.lang.NoClassDefFoundError: javax/validation/Validator
--

Key: OWB-286
URL: https://issues.apache.org/jira/browse/OWB-286
Project: OpenWebBeans
Issue Type: Bug
Reporter: Matthias Weßendorf
Assignee: Gurkan Erdogdu

deploying OWB (trunk) on Jetty (w/ myfaces2 (trunk)) gives me the
following exception.
I understand that JavaEE has some requirement on this, but I
actually
don't care about
JSR 303 (in this scenario).
Should there be a more lenient way? E.g. logging a WARNING ?
IMO this also cause trouble when one want's to use OWB on older
app-servers.
My (little) project is here:
https://facesgoodies.googlecode.com/svn/MS/trunk
run = mvn -Pmyfaces
java.lang.NoClassDefFoundError: javax/validation/Validator
at

org.apache.webbeans.component.javaee.ValidatorBean.init(ValidatorBean.java:36)
at

org.apache.webbeans.config.BeansDeployer.configureDefaultBeans(BeansDeployer.java:196)
at

org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:137)
at

org.apache.webbeans.lifecycle.DefaultLifecycle.applicationStarted(DefaultLifecycle.java:202)
at

org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60)
at

org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
at
org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
at

Re: Code Conventions

2010-02-10 Thread Joseph Bergmark

Along these lines, what is the general feeling about committing changes
without an associated JIRA issue?  I've been opening sometimes trivial JIRA
issues in order to associate them with any commit I do, but I'm not sure if
this is required or not.

Also I've found the Eclipse formatter you sent a while back to be very
useful for auto-formatting new files.  Perhaps we should add a link to this
from the website for any new developers.

Sincerely,

Joe

On Wed, Feb 10, 2010 at 12:44 AM, Gurkan Erdogdu gurkanerdo...@yahoo.comwrote:

 Hello folks;

 While committing code into our code base, it is good idea to have following
 and obey our formatter rules

 1* Remove unused imports
 2* Try to get rid of generic warnings
 3* Use correct line bracing and tab space
 4* Use SVN properties

 Thanks;

 --Gurkan



  ___
 Yahoo! Türkiye açıldı!  http://yahoo.com.tr
 İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!

Re: constructor invocations while creating proxy

2010-02-09 Thread Joseph Bergmark

I think this is a side affect of the way the proxy subclasses the original
class and still tries to maintain the constructors (which aren't inherited
in java).

Sincerely,

Joe

On Tue, Feb 9, 2010 at 12:24 PM, Mark Struberg strub...@yahoo.de wrote:

 Just a funny observation while debugging through proxy code:

 While creating a proxy with our JavassistProxyFactory, the constructor of
 the wrapped class runs. This might have some unexpected side effects - like
 it has in the CallingBusinessInConstructorTest.

 LieGrue,
 strub

 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
 gegen Massenmails.
 http://mail.yahoo.com

Re: [jira] Closed: (OWB-239) JavaBeans property getter naming convention with Producer Methods gives UnsatisfiedResolutionException

2010-01-19 Thread Joseph Bergmark

Lets ignore the @Inject @Named for a minute, as I think it is distracting
from the main issue of the producer methods default name.

If I have a bean with a producer field:

@Produces @Named Products getProducts()

You would agree its el-name should be products and I should be able to
reference it in a EL-expression as products.  For example

h:outputText value=#{products/?

I'll give this a try later today to be sure it works.

Sincerely,

Joe

On Tue, Jan 19, 2010 at 2:33 AM, Gurkan Erdogdu cgurkanerdo...@gmail.comwrote:

 As specified in specification, this is solely used for integration with
 legacy code that uses @Named annotation as differentiating beans with
 strings. For example,if you use JSR-330 impl and @Named(value), to
 differentiate beans, you could resolve those beans with JSR-299 using
 @Named(value). So using value annotation member is required for injection
 points that use @Named annotation as qualifiers

 I have also tried this via Weld, it does not work with too. But if you add
 @Named(products) into producer method, it works like in OWB!

 Thanks;

 --Gurkan


 2010/1/19 Gurkan Erdogdu cgurkanerdo...@gmail.com

  Joe, you are right that producer method name is getting from  method name
  if there is no Named(value).
 
  In the example, default name of the producer bean is products. There is
  no problem in this. The problem is how to resolve this producer method.
 In
  the example, tried with qualifiers, public @Inject @Named(products)
 String
  N3;. This does not work because there is no bean with qualifier
  @Named(products). In other words, this producer method has a Qualifier
  @Named(value=) and name is products.
 
  If you get producer method bean with name, as such,
  BeanManager.getBeans(products), it works!
 
  Thanks;
 
  2010/1/18 Joseph Bergmark bergm...@apache.org
 
  While I agree that injecting using the @Name with the String value isn't
  recommended, it works right now.
 
  That said, section 3.3.8 seems to clearly indicate that the @Named
  qualifier
  for a producer method should provide a default value that follows
 JavaBean
  property getter names.  IE a method named getProducts() should get the
  default name (if annotated with @Named) of products and not
  getProducts
  which appears to be what is happening now.
 
  I do not believe this Issue is invalid, but perhaps I am misreading
 3.3.8?
 
  Sincerely,
 
  Joe
 
  On Mon, Jan 18, 2010 at 4:10 PM, Gurkan Erdogdu (JIRA) j...@apache.org
  wrote:
 
  
   [
  
 
 https://issues.apache.org/jira/browse/OWB-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
  ]
  
   Gurkan Erdogdu closed OWB-239.
   --
  
  Resolution: Invalid
  
   This is true action. @Named is a qualifier. You have to give it a
   @Named(value) in producer method. So you have to define producer
 method
  as
  
  @Produces
  @Named(products)
  public String getProducts()
  {
  return Sucess from getProducts;
  }
  
   @Named value does not get producer method name automatically.
  
   Also using @Named with string members are not recommended usage. See
   specification 3.11. The qualifier @Named at injection points
  
  
JavaBeans property getter naming convention with Producer Methods
  gives
   UnsatisfiedResolutionException
   
  
 
 --
   
Key: OWB-239
URL: https://issues.apache.org/jira/browse/OWB-239
Project: OpenWebBeans
 Issue Type: Bug
 Components: Injection and Lookup
   Affects Versions: M3
Environment: Windows,  Eclipse running Jetty
   Reporter: Bill Wigger
   Assignee: Gurkan Erdogdu
Fix For: M3
   
   
Problem:
JavaBeans property getter naming convention with Producer Methods
  gives
   UnsatisfiedResolutionException
Injection in class X:
  @Produces @Named public String getProducts() {
  return Sucess from getProducts;
  }
Injection Point in  Y:
  public @Inject @Named(products) String N3;
  public String getTestNamed3() {
  String y = N3;
return y;
}
Actual Results when getTestNamed3 is called from a JSP:
javax.enterprise.inject.UnsatisfiedResolutionException: Api type
   [java.lang.String] is not found with the qualifiers
   [...@javax.inject.named(value=products)]
  at
  
 
 org.apache.webbeans.container.ResolutionUtil.checkResolvedBeans(ResolutionUtil.java:93)
  at
  
 
 org.apache.webbeans.container.InjectionResolver.getInjectionPointBean(InjectionResolver.java:232)
  at
  
 
 org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:90)
etc
   
Desired Results:
Sucess from getProducts
  
   --
   This message

1 2 >

1 - 100 of 102 matches

Mail list logo