Re: [DISCUSS] Release OWB-4.0.0?

[David Blevins]

Both CDI 4.0 and the Jakarta EE Core/Webprofile/Platform specs all support Java 
11 or higher in the spec and on the spec page.

 - https://jakarta.ee/specifications/cdi/4.0/
 - https://jakarta.ee/specifications/coreprofile/10/


-David

> On Feb 8, 2023, at 10:48 PM, Romain Manni-Bucau  wrote:
> 
> Hi David,
> 
> Guess 17 is a prerequisite of the spec so no real choice afaik until we
> dont comply to the api.
> For j11/cdi3 our previous shades do the job.
> 
> Tck filters+jira links are in the testng xml config if it helps.
> 
> Romain
> 
> Le jeu. 9 févr. 2023 à 02:17, David Blevins  a
> écrit :
> 
>> 
>> 
>>> On Jan 30, 2023, at 5:40 AM, Mark Struberg 
>> wrote:
>>> * Some challenged tests, some unspecified behaviour in some tests. E.g.
>> they assume a specified order class annotations before method annotations
>> for Interceptors. But the spec *explicitly* says that for Interceptors with
>> the same @Priority the order is unspecified.
>> 
>> Do you have links to the challenges you filed and does it look like
>> they’ll be accepted?
>> 
>> 
>> -David
>> 
>> 

Re: [DISCUSS] Release OWB-4.0.0?

[David Blevins]

> On Jan 30, 2023, at 5:40 AM, Mark Struberg  wrote:
> * Some challenged tests, some unspecified behaviour in some tests. E.g. they 
> assume a specified order class annotations before method annotations for 
> Interceptors. But the spec *explicitly* says that for Interceptors with the 
> same @Priority the order is unspecified.

Do you have links to the challenges you filed and does it look like they’ll be 
accepted?


-David

Re: [DISCUSS] Release OWB-4.0.0?

[David Blevins]

Looks like we’ve set the Java version to 17.  I can confirm it does build fine 
with 11.

Are we open to using 11 for 4.0.0 and waiting till the next release to go to 17?


-David


> On Jan 30, 2023, at 5:40 AM, Mark Struberg  wrote:
> 
> hi folks!
> 
> We are up and running with passing most CDI-4.0 TCK tests.
> There are a few areas where we have excluded some tests:
> 
> * CDI-lite. I'll not gonna implement this in OWB as it is purely for Quarkus 
> and I don't care. It should be straight forward to implement the 
> functionality as  OWB plugin if someone really needs it though.
> * Some challenged tests, some unspecified behaviour in some tests. E.g. they 
> assume a specified order class annotations before method annotations for 
> Interceptors. But the spec *explicitly* says that for Interceptors with the 
> same @Priority the order is unspecified.
> * backward incompatible reversing the default bean-discovery-mode for empty 
> beans.xmls. I'll not gonna implement this as it also did break the JakartaEE 
> rules alltogether.
> 
> 
> Things I want to change yet before the release:
> 
> * Decide about the jetty9 plugin. Tbh I'd keep it excluded until someone 
> wants to contribute fixes to it.
> * provide a shaded version of the CDI api jar without all the CDI-lite parts.
> 
> 
> Wdyt?
> 
> LieGrue,
> strub
> 
> 

Re: InjectionResolver query

[David Blevins]

> On Nov 8, 2022, at 7:50 AM, Romain Manni-Bucau  wrote:
> 
> Hi Jon,
> 
> It is intended to not cache the missed hits since they shouldn't occur at
> runtime and would open the door to OOME issues.
> I looked at your sample, there is indeed a bug in ActionServlet#process
> which should do that resolution in init().
> 
> From my XP frameworks using that kind of resolution cache it themselves
> (JSF for ex) if relevant or don't cache it cause it is not a big perf issue
> (could be for jbatch) else it looks like bugs.

My experience is a bit different.  Systems like DNS will cache both hits and 
misses.  There's an entire RFC dedicated to caching misses specifically: 
https://www.rfc-editor.org/rfc/rfc2308

Yes, it can result in OOME issues, but some users may prefer that issue to the 
performance issue.

A reasonable way to implement this could be to count the misses we've cached 
and if the number exceeds a certain threshold we could do any of the following:

 - stop caching misses
 - log warnings
 - purge old cache misses

There could be a flag to control the desired behavior with the default to be 
the current strategy no caching of misses.


-David





smime.p7s
Description: S/MIME cryptographic signature

Re: [DISCUSS] CDI-4.0 core

[David Blevins]

Thanks Romain and Mark for the insights.  Note, if something like this happens 
again, let me know.  When wearing the day-job hat we do get a vote on if specs 
should go final.

In terms of Jakarta EE 10, it strangely looks like the Jakarta EE 10 Platform 
spec is still using CDI 3.0 while the Jakarta EE 10 Core Profile uses CDI 4.0.  
Not sure how we'll work that out on the TomEE side.

The Core Profile spec says CDI lite is required:

"Jakarta Contexts and Dependency Injection (CDI) 4.0 (CDI Lite section)"


https://jakarta.ee/specifications/coreprofile/10/jakarta-coreprofile-spec-10.0.html#required_components

Whereas the optional section says there are some classes that are not required:

"The Java SE section of the CDI 4.0 specification is not required for Core 
Profile 
implementations. Only Full CDI implementations are required to support the 
(CDI) 
Java SE API classes."


https://jakarta.ee/specifications/coreprofile/10/jakarta-coreprofile-spec-10.0.html#optional-components

Do you have any insight as to what "Java SE" classes are excluded and if that 
eliminates the need to implement the APIs we don't like?

Unrelated side note that annoys the heck out of me: the Spec Committee 
literally had a vote that no specs could have optional parts (I voted -1 on 
that) and then now I'm looking at an "Optional Components" section in the new 
Core Profile spec.  


-David


> On Oct 13, 2022, at 8:14 AM, Mark Struberg  wrote:
> 
> To be very clear: imo the CDI-4.0 spec should never have been released that 
> way. Sorry for the hard words.
> 
> The whole part of the 'cdi-lite' is actually not a subpart of CDI but extends 
> CDI with a (partly vendor specific) build time api. Which is also not really 
> technically necessary imo. So far Helidon, Meecrowave, micronaut, etc managed 
> to run on Graalvm quite fine without this api. 
> 
> Here is my PR which got rejected. It proves that there is no technical 
> requirement to have all this crap in the same spec api jar!
> https://github.com/jakartaee/cdi/pull/582 
> <https://github.com/jakartaee/cdi/pull/582>
> 
> 
> My personal approach would be the following:
> 1.) Enhance our geronimo-jcdi spec api to include the few new changes they 
> made to BeanManager etc.
> 
> 2.) Take the official cdi api (with the lite parts) and 'extract' those lite 
> parts into an own jcdi-lite-api.jar
> 
> 3.) provide a maven plugin and standard CDI Extension to handle the lite 
> parts. This is perfectly doable!
> 
> 4.) It is even possible to support the whole non-reflection features by using 
> a dedicated ScannerService etc.
> 
> That way almost no code change to OWB would be needed. Almost all of the 
> changes could be done via an Extension. That way OWB would still remain quite 
> small and not get as bloated as other implementations.
> 
> 
> It's actually a shame that those changes got pushed so hard despite a lot of 
> EG members heavily objecting with good arguments!
> 
> LieGrue,
> strub
> 
> 
> 
>> Am 13.10.2022 um 08:25 schrieb Romain Manni-Bucau :
>> 
>> Hi David,
>> 
>> It is not about perf but about the cdi "lite" part (build time spec).
>> We explained why it was unecessary technically on cdi bugtracker and
>> requested that at least it was excluded from cdi spec jar and considered
>> another subspec since it is fully unrelated to CDI but it got rejected by a
>> few pushing their vendor API to the spec.
>> 
>> The idea is to not expose an API we'll not support I guess and bundle
>> properly the API.
>> 
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> 
>> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>> 
>> 
>> Le jeu. 13 oct. 2022 à 02:47, David Blevins  a
>> écrit :
>> 
>>>> On Jun 2, 2022, at 12:03 PM, Mark Struberg 
>>> wrote:
>>>> 
>>>> I had an idea about how we could implement CDI-4.0 without all the
>>> overhead it brings.
>>> 
>>> Can you elaborate on the overhead you're concerned about? (not a challenge
>>> -- I'm not very familiar with the details yet)
>>> 
>>> 
>>> -David
>>> 
>>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [DISCUSS] CDI-4.0 core

[David Blevins]

> On Jun 2, 2022, at 12:03 PM, Mark Struberg  wrote:
> 
> I had an idea about how we could implement CDI-4.0 without all the overhead 
> it brings.

Can you elaborate on the overhead you're concerned about? (not a challenge -- 
I'm not very familiar with the details yet)


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: OpenWebBeans 2.0.22 Certification Request

[David Blevins]

> On Mar 18, 2021, at 12:28 AM, Romain Manni-Bucau  
> wrote:
> 
> Hi David,
> 
> Not 100% sure but last time I edited the website I just used vi
> https://svn.apache.org/repos/infra/websites/production/openwebbeans/content/download.html
> .
> Guess https://svn.apache.org/repos/asf/openwebbeans/cms-site/trunk/content/
> is dead due to cms shutdown.

Looks like the CMS still works.  I added a test page and it showed up in 
staging:

 - http://openwebbeans.staging.apache.org/test.html

I visited here to publish after waiting a good 5 minutes (it's slow)

 - https://cms.apache.org/openwebbeans/publish

Then it showed up here

 - http://openwebbeans.apache.org/test.html

I'll delete that page, but all looks functional.

You may want to check that any manual changes you made were not overwritten.


-David



smime.p7s
Description: S/MIME cryptographic signature

OpenWebBeans 2.0.22 Certification Request

[David Blevins]

Since we're running and passing the official Jakarta CDI 3.0 TCK we can file a 
certification request and get OpenWebBeans listed as a compatible implement on 
this page:

 - https://jakarta.ee/specifications/cdi/3.0/

If we update our CDI 2.0 TCK from the JBoss version to this one we can also get 
listed on the Jakarta CDI 2.0 page:

 - https://mvnrepository.com/artifact/jakarta.enterprise/cdi-tck-impl/2.0.7.SP1

The primary thing we need to do that is new is create a "Public TCK Results 
Summary" page on our website for this OWB version and TCK version.  This could 
be on our actual download page if we wanted.  That data we need to show is:

 - Product Name, Version and download URL (already on the download page)
 - Specification Name, Version and download URL
 - TCK Version, digital SHA-256 fingerprint and download URL
 - Java runtime used to run the implementation
 - Summary of the information for the certification environment, operating 
system, cloud, …​
 - List of tests passed (can be a link to another page, say the xml output from 
running the TCK)

My recommendation is that we find a way to do this on the download page in a 
short addition to the 2.0.22 section.  It's quite perfect that the download 
page is not a table, so it'll be easy to sneak in the extra info.  I think we 
can get it done in a sentence or two and a link to the TCK results.

After the release is up and we've put the above information somewhere on our 
site we then 1) file an issue in the CDI spec project labeled 'certification' 
and wait for an approval or for the approval period to timeout. Once it's been 
approved we send an email to t...@eclipse.org with a link to the approved issue.

I wrote a lot of this process so I'm happy to do the first one if someone can 
point me to instructions on how to update the website.

Here's the full documentation on the process:

 - https://jakarta.ee/committees/specification/tckprocess/


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



smime.p7s
Description: S/MIME cryptographic signature

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

[David Blevins]

+1


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

> On Mar 17, 2021, at 7:56 AM, Mark Struberg  wrote:
> 
> Hi lords and ladies!
> 
> I'd like to call a 2nd  VOTE for releasing Apache OpenWebBeans 2.0.22
> 
> We did fix the following tickets:
> 
> Bug
> 
> [OWB-1371 <https://issues.apache.org/jira/browse/OWB-1371 
> <https://issues.apache.org/jira/browse/OWB-1371>>] - review getCurrentContext 
> to automatically create Contexts
> [OWB-1372 <https://issues.apache.org/jira/browse/OWB-1372 
> <https://issues.apache.org/jira/browse/OWB-1372>>] - 
> RequestContextController#deactivate must be a nop if the context was already 
> active before
> [OWB-1373 <https://issues.apache.org/jira/browse/OWB-1373 
> <https://issues.apache.org/jira/browse/OWB-1373>>] - EventImpl does not 
> resolve Observers properly when running with ParentBM setup
> [OWB-1374 <https://issues.apache.org/jira/browse/OWB-1374 
> <https://issues.apache.org/jira/browse/OWB-1374>>] - Container Lifecycle 
> events right now only work during startup
> [OWB-1376 <https://issues.apache.org/jira/browse/OWB-1376 
> <https://issues.apache.org/jira/browse/OWB-1376>>] - Unsafe usage is broken
> [OWB-1377 <https://issues.apache.org/jira/browse/OWB-1377 
> <https://issues.apache.org/jira/browse/OWB-1377>>] - Enable to configure the 
> reserved packages for proxies
> [OWB-1378 <https://issues.apache.org/jira/browse/OWB-1378 
> <https://issues.apache.org/jira/browse/OWB-1378>>] - Ensure 
> @initialized(appscoped) and its symmetric events can be skipped in se mode
> New Feature
> 
> [OWB-1369 <https://issues.apache.org/jira/browse/OWB-1369 
> <https://issues.apache.org/jira/browse/OWB-1369>>] - Ensure OWB-web module 
> configuration wins over OWB-se module
> [OWB-1370 <https://issues.apache.org/jira/browse/OWB-1370 
> <https://issues.apache.org/jira/browse/OWB-1370>>] - Enable to select the CDI 
> SE provider
> Improvement
> 
> [OWB-1367 <https://issues.apache.org/jira/browse/OWB-1367 
> <https://issues.apache.org/jira/browse/OWB-1367>>] - Bad filter url-pattern 
> in demos
> [OWB-1375 <https://issues.apache.org/jira/browse/OWB-1375 
> <https://issues.apache.org/jira/browse/OWB-1375>>] - improve support for Java 
> 9++ hacks
> Task
> 
> [OWB-1365 <https://issues.apache.org/jira/browse/OWB-1365 
> <https://issues.apache.org/jira/browse/OWB-1365>>] - 
> org.apache.webbeans.spi.deployer.skipValidations not usable in standard mode
> [OWB-1366 <https://issues.apache.org/jira/browse/OWB-1366 
> <https://issues.apache.org/jira/browse/OWB-1366>>] - WebBeansLoggerFacade 
> must not create any logger in its static init block if not needed
> [OWB-1380 <https://issues.apache.org/jira/browse/OWB-1380 
> <https://issues.apache.org/jira/browse/OWB-1380>>] - Annotated mode not 
> supported for prescanned scanner service
> 
> 
> The staging repo can be found here:
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1070/
>  
> <https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1070/>
> 
> The sources zip is at 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1070/org/apache/openwebbeans/openwebbeans/2.0.22/
>  
> <https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1070/org/apache/openwebbeans/openwebbeans/2.0.22/>
> sha1 is fac3e5ebe645a0c3cedd001419aa864ed3d5e11e
> 
> Please VOTE
> 
> [+1] still yippee ki yay, let's ship it, but really!
> [+0] meh, don't care at all
> [-1] whoops, stop, there is a ${showstopper}
> 
> The VOTE is open for 72h.
> 
> txs and LieGrue



smime.p7s
Description: S/MIME cryptographic signature

Re: Ready for the next release?

[David Blevins]

> On Mar 17, 2021, at 1:05 AM, Romain Manni-Bucau  wrote:
> 
> Le mer. 17 mars 2021 à 08:50, Romain Manni-Bucau  a
> écrit :
> 
>> @David OWB is still on 3.0.0-M3:
>> https://github.com/apache/openwebbeans/blob/master/webbeans-tck-jakarta/pom.xml#L167
>> 
> 
> Ok just upgraded to 3.0.1 and we are still green ;)

That's awesome!  I still need to do the same on the TomEE side so I'll 
definitely be using that for reference!

That'll definitely save some time.

We can also submit a certification request to get OpenWebBeans listed as a 
certified implementation.  We just need to create a public test results page.  
I'll start another thread on that.


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: Ready for the next release?

[David Blevins]

> On Mar 16, 2021, at 9:49 AM, Mark Struberg  wrote:
> 
> oki, it is now configurable. So the worst thing you could do is to overwrite 
> the default in an openwebbeans.properties file inside TomEE.

Everything looks good for a release from the TomEE side.  Fire at will.

> Btw, TomEE builds perfectly fine with the latest owb version and all 
> pre-activated TCKs enabled.

I don't believe either of us are running the CDI 3.0 TCK in our main builds, 
which is where the issue occurred.


-David




smime.p7s
Description: S/MIME cryptographic signature

Re: Why is jakarta forbidden?

[David Blevins]

> On Mar 16, 2021, at 4:56 PM, David Blevins  wrote:
> 
> The results after the OWB upgrade and prior to this weekend's changes were 
> less than 10k passing.

For clarity, the reason things worked before the OWB upgrade is we had 
AbstractProxyFactory patched.  I deleted that after Mark upgraded us to the 
main branch:

 - 
https://github.com/apache/tomee-jakarta/commit/8883f220104c45be102f4dc339956a09a3ff6e72

Now it appears we don't need a patch or a flag which is very very awesome!


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: Why is jakarta forbidden?

[David Blevins]

> On Mar 15, 2021, at 2:16 PM, David Blevins  wrote:
> 
>> On Mar 15, 2021, at 9:27 AM, Romain Manni-Bucau  
>> wrote:
>> 
>> Hi,
>> 
>> Added a configuration for the packages - since we can hit that with some
>> "specific" jars and some signed ones:
>> https://issues.apache.org/jira/browse/OWB-1377
>> Didn't get a change to run TCK setup but proxied the jakarta package
>> several times so if anyone has enough resources to work on a reproducer I
>> would be happy to refine this particular case if needed.
>> In the mean time I guess tomee can set up the configuration in
>> conf/system.properties and maybe fix its shade.
> 
> I tried this flag out locally and it appears to work, so I've uploaded new 
> snapshots and have kicked off a full run and will report back.
> 
> Interestingly, it worked locally now without the flag so it appears something 
> related might have been fixed in one of the changes over the weekend.  After 
> the above run is done, I'll do another with the flag off.  If it works 
> equally well, I'll also report as if it's fine it's probably better to delete 
> the flag.
> 
> Definitely, it's most ideal if no flag is needed as we are producing 
> *-jakarta.jars and best case scenario is they work without any needed flags.

It does appear that after this weekend's changes things now work with or 
without this new flag.  Jakarta EE 9 test results are 32142 passing with the 
flag and 32140 without the flag.  The results after the OWB upgrade and prior 
to this weekend's changes were less than 10k passing.

I'd recommend doing the release as things are now and then maybe we should 
remove the flag just so we have less to maintain.  Once flags like this are out 
there for a year, it's impossible to ever delete them as you never know who is 
using them or how they'll be impacted.


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: Ready for the next release?

[David Blevins]

On the Jakarta namespace support, I should just need another day or so to 
verify.


-David


> On Mar 15, 2021, at 8:08 AM, Romain Manni-Bucau  wrote:
> 
> Hi Mark,
> 
> Once we solved/reverted/enhanced the jakarta pending point +1
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le lun. 15 mars 2021 à 16:03, Mark Struberg  a
> écrit :
> 
>> hi folks!
>> 
>> I'm right now adding a cache for ClassLoder#defineClass methods. But after
>> that I'd be rather ready to roll a release. wdyt?
>> 
>> LieGrue,
>> strub
>> 
>> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Why is jakarta forbidden?

[David Blevins]

> On Mar 15, 2021, at 9:27 AM, Romain Manni-Bucau  wrote:
> 
> Hi,
> 
> Added a configuration for the packages - since we can hit that with some
> "specific" jars and some signed ones:
> https://issues.apache.org/jira/browse/OWB-1377
> Didn't get a change to run TCK setup but proxied the jakarta package
> several times so if anyone has enough resources to work on a reproducer I
> would be happy to refine this particular case if needed.
> In the mean time I guess tomee can set up the configuration in
> conf/system.properties and maybe fix its shade.

I tried this flag out locally and it appears to work, so I've uploaded new 
snapshots and have kicked off a full run and will report back.

Interestingly, it worked locally now without the flag so it appears something 
related might have been fixed in one of the changes over the weekend.  After 
the above run is done, I'll do another with the flag off.  If it works equally 
well, I'll also report as if it's fine it's probably better to delete the flag.

Definitely, it's most ideal if no flag is needed as we are producing 
*-jakarta.jars and best case scenario is they work without any needed flags.

Should know more tomorrow.


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: Why is jakarta forbidden?

[David Blevins]

> On Mar 12, 2021, at 11:57 PM, Romain Manni-Bucau  
> wrote:
> 
> Hi,
> 
> Likely more a question for David: why is jakarta considered as a forbidden
> package (
> https://github.com/apache/openwebbeans/commit/6ede81da26a4a65dc0c88fda7e438f29114fea37)
> ?
> 
> To explain why I ask: jakarta is a module as any other, and we shouldn't
> get abused by the presence of javax just before which is there for the java
> *se* part of javax api and not EE one so not sure I get the rational there,
> any test/sample I can run to understand?

A javax-to-jakarta namespace switch in bytecode doesn't appear to work without 
this change.  For TomEE 9 80% of the TCK will fail with due to deployment 
errors.

If you revert this change locally and rebuild these repos

 - https://github.com/apache/tomee
 - https://github.com/apache/tomee-jakarta

here's a tck test that shows it:

  ./runtests --web tomee-plume 
com.sun.ts.tests.ejb30.lite.appexception.singleton.annotated

That script is in this branch.  Here's also the TCK download URL.

 - https://github.com/apache/tomee-tck/tree/jakartaee9-tck
 - 
https://download.eclipse.org/jakartaee/platform/9/jakarta-jakartaeetck-9.0.2.zip

Wherever the TCK is unpacked you add this to your ~/.m2/settings.xml.  Here are 
my settings for reference:


  jakartaee-tck
  
true
  
  

/Users/dblevins/work/tcks/jakartaeetck-9.0.2

/Users/dblevins/work/tcks/glassfish6/glassfish
  


The final thing to get setup is copy an Ant install into this location of the 
TCK.

 -  jakartaeetck-9.0.2/tools/ant/

Here's how mine looks:

$ ls /Users/dblevins/work/tcks/jakartaeetck-9.0.2/tools/ant
CONTRIBUTORSLICENSE WHATSNEW
etc lib
INSTALL NOTICE  bin 
fetch.xml   manual
KEYSREADME  contributors.xml
get-m2.xml  patch.xml

Use Java 8 as the TCK itself doesn't run with Java 11 yet.


-David



smime.p7s
Description: S/MIME cryptographic signature

Beans added via Extensions and Interceptors and Decorators

[David Blevins]

Looks as though we don't support Interceptors or Decorators for beans added via 
extension that are not subclasses of AbstractOwbBean.

ThirdpartyBeanImpl returns an inner class impl of Producer from getProducer.  
Since it doesn't extend AbstractProducer it doesn't have the 
defineInterceptorStack method and we skip it at the time where we would resolve 
those.

Is there a reason we don't have the inner class in ThirdpartyBeanImpl extend 
AbstractProducer?


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

Re: Custom Scope mystery

[David Blevins]

Issue is, we need to write a better test case :)

We install the context, but since it is NormalScope and not dependent scoped, 
the instance resolution does not take place until the proxy is invoked (not 
when injected).

The test doesn’t invoke the instance, it only looks it up from the bean 
manager, therefore the custom scope is *never* used.

Don’t have time to improve the testcase, but perfect afternoon of hacking for 
someone else to enjoy :)


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

> On Oct 24, 2015, at 10:49 PM, David Blevins  wrote:
> 
> Intended to implement several custom scopes for JavaOne to show people how.  
> 5 hours later I can’t seem to get much joy.
> 
> We have a test for it, but sadly it appears to not do what we hope:
> 
> - 
> https://github.com/dblevins/openwebbeans/commit/d0b1beda01e4ed3e8924b058b987b9f7ad96391d
> 
> Completely gutted ExternalTestScopeContext but sadly all tests in 
> webbeans-impl still pass.
> 
> 
> Went back several versions 1.2.2, 1.1.8, etc.  Sadly same behavior on all of 
> them.
> 
> What’s the deal?
> 
> (fyi, presentation is Tuesday)
> 
> -- 
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 

Custom Scope mystery

[David Blevins]

Intended to implement several custom scopes for JavaOne to show people how.  5 
hours later I can’t seem to get much joy.

We have a test for it, but sadly it appears to not do what we hope:

 - 
https://github.com/dblevins/openwebbeans/commit/d0b1beda01e4ed3e8924b058b987b9f7ad96391d

Completely gutted ExternalTestScopeContext but sadly all tests in webbeans-impl 
still pass.


Went back several versions 1.2.2, 1.1.8, etc.  Sadly same behavior on all of 
them.

What’s the deal?

(fyi, presentation is Tuesday)

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

Re: [VOTE] for Apache OpenWebBeans 1.6.1

[David Blevins]

+1


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

On Jun 16, 2015, at 7:10 AM, Mark Struberg  wrote:

> 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: [VOTE] Release Apache OpenWebBeans 1.2.5

[David Blevins]

+1


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

On May 23, 2014, at 10:43 AM, Mark Struberg  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=12310844&version=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.4

[David Blevins]

+1 and thank you!!


On May 1, 2014, at 2:14 PM, Mark Struberg  wrote:

> 
> 
> I'd like to call a VOTE on releasing Apache OpenWebBeans-1.2.4 .
> 
> 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=12310844&version=12326813
> 
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1003/
> 
> 
> SVN source tag:
> 
> https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.4/
> 
> 
> Source Release:
> http://repository.apache.org/content/repositories/orgapacheopenwebbeans-1003/org/apache/openwebbeans/openwebbeans/1.2.4/openwebbeans-1.2.4-source-release.zip
> 
> 
> Binary release:
> 
> http://repository.apache.org/content/repositories/orgapacheopenwebbeans-1003/org/apache/openwebbeans/openwebbeans-distribution/1.2.4/openwebbeans-distribution-1.2.4-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] take 1: Release Apache OpenWebBeans-1.2.1

[David Blevins]

+1

-David

On Nov 8, 2013, at 6:12 AM, Jean-Louis MONTEIRO  wrote:

> Hey guys,
> 
> As discuss in another thread, I'd like to call a VOTE on releasing Apache
> OpenWebBeans-1.2.1 .
> 
> This is a maintenance release of the OpenWebBeans-1.2.x branch.
> 
> The ReleaseNotes are available online:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844&version=12324388
> 
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-091/
> 
> SVN source tag:
> *http://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.1/
> *
> 
> Source Release:
> *https://repository.apache.org/content/repositories/orgapacheopenwebbeans-091/org/apache/openwebbeans/openwebbeans/1.2.1/openwebbeans-1.2.1-source-release.zip
> *
> 
> Binary release:
> *https://repository.apache.org/content/repositories/orgapacheopenwebbeans-091/org/apache/openwebbeans/openwebbeans-distribution/1.2.1/openwebbeans-distribution-1.2.1-binary.zip
> *
> 
> 
> The VOTE will be open for 72 hours.
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 veto (and reason why)
> 
> -- 
> Jean-Louis

Re: Time for 1.2.1?

[David Blevins]

+1 :)


On Nov 8, 2013, at 1:34 AM, Jean-Louis MONTEIRO  wrote:

> Ok, if everyone is ok, I gonna try to roll the 1.2.1.
> Even if the vote gets canceled, it's still a good exercise for me :D
> 
> JLouis
> 
> 
> 2013/11/8 Mark Struberg 
> 
>> No problem, let it as is.
>> 
>> It's just easier to keep track of what really was done and part of the
>> release imo.
>> Especially if you have to reroll.
>> 
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>> 
>>> 
>>> From: Romain Manni-Bucau 
>>> To: openwebbeans-dev ; Mark Struberg <
>> strub...@yahoo.de>
>>> Sent: Friday, 8 November 2013, 10:00
>>> Subject: Re: Time for 1.2.1?
>>> 
>>> 
>>> oops sorry :s
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>> 
>>> 
>>> 
>>> 
>>> 2013/11/8 Mark Struberg :
>>>> nope, we first do the RESOLVED and not closed.
>>>> 
>>>> The reason is that we bulk-change them later to closed once we finally
>> shipped the release.
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> From: Jean-Louis MONTEIRO 
>>>>> To: dev@openwebbeans.apache.org
>>>>> Cc: Mark Struberg 
>>>>> Sent: Thursday, 7 November 2013, 21:49
>>>>> Subject: Re: Time for 1.2.1?
>>>>> 
>>>>> 
>>>>> Hey guys,
>>>>> 
>>>>> Trying to prepare the release.
>>>>> Was cleaning up JIRA
>>>>> 
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20OWB%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
>>>>> 
>>>>> 
>>>>> Actually, JIRA are not marked as resolved and the "fix for" attribute is
>>>>> not set.
>>>>> Usually, I'm used to set RESOLVED issues to CLOSED and set the "fix for"
>>>>> field to XXX.
>>>>> Can someone help me to check that list and filter those who are really
>>>>> resolved?
>>>>> 
>>>>> Then, I can finish the README from the release notes.
>>>>> 
>>>>> Then, creating, publishing and doing the legal stuff is not that long
>> nor
>>>>> hard.
>>>>> Thanks for your help.
>>>>> 
>>>>> Jean-Louis
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 2013/11/7 Romain Manni-Bucau 
>>>>> 
>>>>>> *tested
>>>>>> Romain Manni-Bucau
>>>>>> Twitter: @rmannibucau
>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>> Github: https://github.com/rmannibucau
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 2013/11/7 Romain Manni-Bucau :
>>>>>>> testes the shadown part just one minute ago and seems not as bad as
>> I
>>>>>>> thought so repassing tcks and I'll commit it
>>>>>>> Romain Manni-Bucau
>>>>>>> Twitter: @rmannibucau
>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>> Github: https://github.com/rmannibucau
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 2013/11/7 Jean-Louis MONTEIRO :
>>>>>>>> If that is a blocking issue, I agree, but why not committing the
>> fix.
>>>>>>>> You have one, even if not perfect, it works in some cases.
>>>>>>>> 
>>>>>>>> If definitely not a good patch, who can help fixing that, that was
>> my
>>>>>> main
>>>>>>>> purpose.
>>>>>>>> 
>>>>>>>> JLouis
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 2013/11/7 Mark Struberg 
>>>>>>>> 
>>>>>>>>> sure, go on.
>

Re: Time for 1.2.1?

[David Blevins]

On the OPENJPA-2335 note.   Alex, Tim, Judah and all the 3ds guys on the 
users@tomee list are saying they'll have to drop Apache TomEE from their 
product unless they get a release.  They've been asking since July.  Seems 
there cutoff is Friday.

Looks like the most pragmatic way to make everyone happy is to do two releases. 
 One now and one again when OPENJPA-2335 is fixed and OpenJPA 2.3.0 is 
released.  Then there's no need to rush.


-David

On Nov 5, 2013, at 10:59 PM, Mark Struberg  wrote:

> 
> 
> Well, TomEE is mostly blocked by OPENJPA-2335. This is a regression which is 
> in there since a few months and blows up many of my old apps which run fine 
> with openjpa-2.2.2 and lower. I've committed a test (currently failing of 
> course) to the 2.3.x branch in openjpa. 
> 
> 
> I'm mostly offline this week due to holding talks on W-JAX.
> 
> LieGrue,
> strub
> 
> 
> 
> 
> 
>> 
>> From: Jean-Louis MONTEIRO 
>> To: dev@openwebbeans.apache.org 
>> Sent: Wednesday, 6 November 2013, 6:49
>> Subject: Re: Time for 1.2.1?
>> 
>> 
>> Hey,
>> 
>> Still there at least for the moment lol
>> Did not get news from Mark on the issue above. We discuss with Romain but
>> we wanted another feedback. If someone else could have a look we could
>> start the release today and have binaries for vote today.
>> 
>> Thanks a lot
>> Jean Louis
>> 
>> Le 6 nov. 2013 06:29, "Romain Manni-Bucau"  a écrit :
>> 
>>> We have a regression (found on tomee list). I proposed a patch but it needs
>>> some review (Mark wanted to have a deeper look if I didnt misunderstand).
>>> This is clearly blocking ATM :(.
>>> Le 6 nov. 2013 04:39, "David Blevins"  a écrit :
>>> 
>>>> Jean-Louis fixed the issue and mentioned he would release today.  But I
>>>> also know the "release" of his first baby boy is a few days overdue :)  I
>>>> suspect he's suddenly got quite busy. :)
>>>> 
>>>> If we don't hear from him tomorrow, I'll plan on jumping in for him to
>>> get
>>>> the release started.
>>>> 
>>>> 
>>>> -David
>>>> 
>>>> On Nov 4, 2013, at 12:36 AM, Jean-Louis MONTEIRO 
>>>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Ok lemme at least try this morning.
>>>>> 
>>>>> Jean-Louis
>>>>> 
>>>>> 
>>>>> 2013/11/4 Mark Struberg 
>>>>> 
>>>>>> We should fix the session destroy issue first.
>>>>>> Should be really easy.
>>>>>> Anyone likes to take over?
>>>>>> I have 3 conf talks to deliver this week, thus my time is a bit short
>>>> this
>>>>>> week...
>>>>>> 
>>>>>> LieGrue,
>>>>>> strub
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> - Original Message -
>>>>>>> From: Jean-Louis MONTEIRO 
>>>>>>> To: dev@openwebbeans.apache.org
>>>>>>> Cc:
>>>>>>> Sent: Monday, 4 November 2013, 8:24
>>>>>>> Subject: Re: Time for 1.2.1?
>>>>>>> 
>>>>>>> Lol
>>>>>>> I've been discussing with Mark for a while. We were waiting some
>>> fixes
>>>>>> but
>>>>>>> I should start the release early this week, maybe today or so.
>>>>>>> 
>>>>>>> Le 4 nov. 2013 03:09, "David Blevins" 
>>>>>>> a écrit :
>>>>>>> 
>>>>>>>> Anyone have any objections if I roll a 1.2.1 release?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -David
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Jean-Louis
>>>> 
>>>> 
>>> 
>> 
>> 

Re: Time for 1.2.1?

[David Blevins]

Jean-Louis fixed the issue and mentioned he would release today.  But I also 
know the "release" of his first baby boy is a few days overdue :)  I suspect 
he's suddenly got quite busy. :)

If we don't hear from him tomorrow, I'll plan on jumping in for him to get the 
release started.


-David

On Nov 4, 2013, at 12:36 AM, Jean-Louis MONTEIRO  wrote:

> Hi,
> 
> Ok lemme at least try this morning.
> 
> Jean-Louis
> 
> 
> 2013/11/4 Mark Struberg 
> 
>> We should fix the session destroy issue first.
>> Should be really easy.
>> Anyone likes to take over?
>> I have 3 conf talks to deliver this week, thus my time is a bit short this
>> week...
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>> 
>> - Original Message -
>>> From: Jean-Louis MONTEIRO 
>>> To: dev@openwebbeans.apache.org
>>> Cc:
>>> Sent: Monday, 4 November 2013, 8:24
>>> Subject: Re: Time for 1.2.1?
>>> 
>>> Lol
>>> I've been discussing with Mark for a while. We were waiting some fixes
>> but
>>> I should start the release early this week, maybe today or so.
>>> 
>>> Le 4 nov. 2013 03:09, "David Blevins" 
>>> a écrit :
>>> 
>>>> Anyone have any objections if I roll a 1.2.1 release?
>>>> 
>>>> 
>>>> -David
>>>> 
>>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Jean-Louis

Time for 1.2.1?

[David Blevins]

Anyone have any objections if I roll a 1.2.1 release?


-David

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

[David Blevins]

+1


David

On May 13, 2013, at 11:45 PM, Mark Struberg  wrote:

> 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: AnnotatedTypeImpl and thread safety

[David Blevins]

We should be good.  UnmodifiableSet + iterator are just a wrappers and HashSet 
is thread-safe for read-only usage.  They're now populated in the constructor 
as local variables, so outside the constructor no one has a reference to them.

If we revert back to the code where the hashsets are exposed, then we should 
probably use a CopyOnWriteArraySet as you suggest.


-David

On May 12, 2013, at 11:36 AM, Romain Manni-Bucau  wrote:

> If you guarantee me unmodifiableSet itertors are thread safe i'm happy
> otherwise please use a copyonwriteset then it'll not say anything more
> Le 12 mai 2013 20:15, "David Blevins"  a écrit :
> 
>> Looked into that this morning.
>> 
>> It occurred to me that would definitely make it thread-safe, but alone
>> doesn't give us the right logic for AnnotatedType.getMethods(), etc. which
>> are supposed to return a complete list not a list being updated.  So we'd
>> still need to block getMethods() calls until initialization is complete.
>> 
>> Updated the code again.  Have a look and let me know if you see any more
>> holes :)  The lists not being thread safe was definitely accurate.
>> 
>> 
>> -David
>> 
>> On May 11, 2013, at 11:49 PM, Romain Manni-Bucau 
>> wrote:
>> 
>>> I keep my comment/explanation on it, if you want it thread safe at
>> runtime
>>> convert it to sthg thread safe...copyonwriteXXX structures will be
>> enough.
>>> We dont need what you did IMO
>>> Le 12 mai 2013 00:04, "David Blevins"  a écrit
>> :
>>> 
>>>> 
>>>> On May 11, 2013, at 1:59 PM, David Blevins 
>>>> wrote:
>>>> 
>>>>> That being said, I'll see if I can reduce the memory requirement of the
>>>> fix.
>>>> 
>>>> Done.  Managed to reduce the memory requirement of the original code for
>>>> the lazy case as well.  Basically two object references lighter (128
>> bits).
>>>> 
>>>> Thread-safe, lighter and slightly more immutable.
>>>> 
>>>> 
>>>> -David
>>>> 
>>>> 
>> 
>> 

Re: AnnotatedTypeImpl and thread safety

[David Blevins]

Looked into that this morning.

It occurred to me that would definitely make it thread-safe, but alone doesn't 
give us the right logic for AnnotatedType.getMethods(), etc. which are supposed 
to return a complete list not a list being updated.  So we'd still need to 
block getMethods() calls until initialization is complete.

Updated the code again.  Have a look and let me know if you see any more holes 
:)  The lists not being thread safe was definitely accurate.


-David

On May 11, 2013, at 11:49 PM, Romain Manni-Bucau  wrote:

> I keep my comment/explanation on it, if you want it thread safe at runtime
> convert it to sthg thread safe...copyonwriteXXX structures will be enough.
> We dont need what you did IMO
> Le 12 mai 2013 00:04, "David Blevins"  a écrit :
> 
>> 
>> On May 11, 2013, at 1:59 PM, David Blevins 
>> wrote:
>> 
>>> That being said, I'll see if I can reduce the memory requirement of the
>> fix.
>> 
>> Done.  Managed to reduce the memory requirement of the original code for
>> the lazy case as well.  Basically two object references lighter (128 bits).
>> 
>> Thread-safe, lighter and slightly more immutable.
>> 
>> 
>> -David
>> 
>> 

Re: AnnotatedTypeImpl and thread safety

[David Blevins]

Further updated so that the hashsets are not modified outside the 
AnnotatedTypeImpl.State constructor.

Dug around and the only usage of the AnnotatedTypeImpl.addAnnotatedMethod(..) 
and similar methods was if someone attempted to construct an 
AnnotatedFieldImpl, etc. and not pass in a declaringType.  I looked through all 
the code usages, ran all the tests, ran the TCK in OWB and in TomEE and this 
never happened.

If anyone sees any issues with it, let me know.


-David

On May 11, 2013, at 3:04 PM, David Blevins  wrote:

> 
> On May 11, 2013, at 1:59 PM, David Blevins  wrote:
> 
>> That being said, I'll see if I can reduce the memory requirement of the fix.
> 
> Done.  Managed to reduce the memory requirement of the original code for the 
> lazy case as well.  Basically two object references lighter (128 bits).
> 
> Thread-safe, lighter and slightly more immutable.
> 
> 
> -David
> 

Re: [VOTE] take2 - Release OWB-1.2.0

[David Blevins]

That would be a good change.  I mentioned on IRC yesterday that the new code is 
technically still not thread-safe as the lists themselves are not thread-safe 
(your point).

Mark's first remark was that the lists are not updated after initialization.  
If that's true we could even get by with simply making the final variables 
unmodifiable lists and go immutable.


-David

On May 12, 2013, at 2:56 AM, Romain Manni-Bucau  wrote:

> Sure, the last synchro is fine but using a "copyonwrite" set (array
> iterator) would be more efficient and thread safe...hashset are not and the
> copy done in get"set" method can still fail
> 
> So the bug is still here IMO
> Le 12 mai 2013 10:56, "Mark Struberg"  a écrit :
> 
>> Romain, the previous code had a synchronized block for writes but none for
>> reads. This was broken.
>> The new solution is not perfect but definitely better.
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>> 
>> - Original Message -
>>> From: Romain Manni-Bucau 
>>> To: Mark Struberg ; dev@openwebbeans.apache.org
>>> Cc:
>>> Sent: Sunday, 12 May 2013, 9:40
>>> Subject: Re: [VOTE] take2 - Release OWB-1.2.0
>>> 
>>> I said yesterday which solution id like to see, i have no computer before
>>> tonight so i didnt impl it and wanted some discussion before choosing...
>>> 
>>> It is a reason for a -1 since it is a place id like to see stable code
>> (it
>>> is a place well have a bunch of issue because of old extensions).
>>> Le 12 mai 2013 09:33, "Mark Struberg"  a
>>> écrit :
>>> 
 +1
 
 LieGrue,
 strub
 
 
 
 - Original Message -
> From: Mark Struberg 
> To: openwebbeans-dev ;
>>> openwebbeans-user <
 u...@openwebbeans.apache.org>
> Cc:
> Sent: Sunday, 12 May 2013, 1:39
> Subject: [VOTE] take2 - Release OWB-1.2.0
> 
> I'd like to call a 2nd 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=12310844&version=12315461
> 
> Maven staging repo:
> 
 
>>> 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-004/
> 
> SVN source tag:
> 
>> https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.0/
> 
> Source Release:
> 
 
>>> 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-004/org/apache/openwebbeans/openwebbeans/1.2.0/openwebbeans-1.2.0-source-release.zip
> 
> Binary release:
> 
 
>>> 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-004/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: AnnotatedTypeImpl and thread safety

[David Blevins]

On May 11, 2013, at 1:59 PM, David Blevins  wrote:

> That being said, I'll see if I can reduce the memory requirement of the fix.

Done.  Managed to reduce the memory requirement of the original code for the 
lazy case as well.  Basically two object references lighter (128 bits).

Thread-safe, lighter and slightly more immutable.


-David

[jira] [Created] (OWB-859) Remove checkstyle double-checked locking rule

[David Blevins (JIRA)]

David Blevins created OWB-859:
-

 Summary: Remove checkstyle double-checked locking rule
 Key: OWB-859
 URL: https://issues.apache.org/jira/browse/OWB-859
 Project: OpenWebBeans
  Issue Type: Task
Reporter: David Blevins




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

AnnotatedTypeImpl and thread safety

[David Blevins]

There was some doubt on IRC as to if AnnotatedType should be thread safe as 
well as some comments that eliminating the use of AnnotatedType at runtime 
would be a possible solution.

We certainly can reduce or eliminate our use of AnnotatedType, but noticed the 
BeanManager API gives us no choice as it allows people to create and use 
AnnotatedType at runtime.

final BeanManager beanManager = getBeanManager();
final AnnotatedType annotatedType = 
beanManager.createAnnotatedType(Colors.class);

for (int i = 0; i < threads; i++)
{
new Runner(startingLine, startingPistol, exceptions, finishLine, 
annotatedType)
{
@Override
public void doit()
{
beanManager.createInjectionTarget(annotatedType);
}
}.start();
}

That being said, I'll see if I can reduce the memory requirement of the fix.  
Speed-wise, it's good.  FutureTask is fast.


-David

Re: [VOTE] [CANCELLED] release Apache OpenWebBeans-1.2.0

[David Blevins]

The change in TomEE covered it up, but didn't fix the root issue.  Added a test 
case in OWB that reproduces it using just the BeanManager.

-David

On May 11, 2013, at 1:22 AM, Romain Manni-Bucau  wrote:

> -1 David, it was already fixed and was a tomee issue!
> Le 11 mai 2013 05:29, "David Blevins"  a écrit :
> 
>> Excellent.  Fixed an issue in OWB that was affecting the TomEE build for a
>> few days (OWB-858 - AnnotatedTypeImpl not thread safe).  Was causing
>> java.util.ConcurrentModificationExceptions.
>> 
>> Hopefully we can get that in there.  Out of time tonight, but would like
>> to find the issue with passivation checking.
>> 
>> 
>> -David
>> 
>> On May 10, 2013, at 10:09 AM, Mark Struberg  wrote:
>> 
>>> Yea, but I need to reset the versions to 1.2.0-SNAPSHOT still
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
>>> 
>>> - Original Message -
>>>> From: Arne Limburg 
>>>> To: "dev@openwebbeans.apache.org" ; Mark
>> Struberg 
>>>> Cc:
>>>> Sent: Friday, 10 May 2013, 15:33
>>>> Subject: Re: [VOTE] [CANCELLED] release Apache OpenWebBeans-1.2.0
>>>> 
>>>> Hi Thomas,
>>>> 
>>>> You can build it from trunk
>>>> 
>>>> 
>>>> Regards,
>>>> Arne
>>>> 
>>>> Am 10.05.13 13:36 schrieb "Thomas Andraschko" unter
>>>> :
>>>> 
>>>>> Is there already a new snapshot available somewhere?
>>>>> I would try it with my current app.
>>>>> 
>>>>> 
>>>>> 2013/5/10 Mark Struberg 
>>>>> 
>>>>>> Hi folks!
>>>>>> 
>>>>>> I'll reroll the release this evening.
>>>>>> 
>>>>>> We will _not_ exclude the webbeans-cdi11 module from the source
>> release
>>>>>> but we don't ship any binaries for it.
>>>>>> 
>>>>>> The reason is that we must not ship any CDI-1.1 binaries without
>>>> passing
>>>>>> the TCK. But there is no reason not to ship a mechanism to create a
>>>>>> compat
>>>>>> package.
>>>>>> 
>>>>>> 
>>>>>> The reroll will contain Arnes fixes for the AnnotatedType and a few
>>>>>> other
>>>>>> minor things.
>>>>>> 
>>>>>> LieGrue,
>>>>>> strub
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> - Original Message -
>>>>>>> From: Arne Limburg 
>>>>>>> To: "u...@openwebbeans.apache.org"
>>>> 
>>>>>>> Cc:
>>>>>>> Sent: Thursday, 9 May 2013, 18:32
>>>>>>> Subject: Re: [VOTE] release Apache OpenWebBeans-1.2.0
>>>>>>> 
>>>>>>> T hanks Harald for catching this one.
>>>>>>> 
>>>>>>> That's a serious one. I'll fix it and we re-roll the
>>>> release.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Arne
>>>>>>> 
>>>>>>> Am 09.05.13 18:15 schrieb "Harald Wellmann" unter
>>>>>>> :
>>>>>>> 
>>>>>>>> -1 (non-binding)
>>>>>>>> 
>>>>>>>> Looks like there is a regression regarding
>>>>>>>> BeforeBeanDiscovery.addAnnotatedType(), compared to 1.1.8.
>>>>>>>> 
>>>>>>>> Adding more than one type has no effect.
>>>>>>>> 
>>>>>>>> The following method in BeanManagerImpl looks suspicious:
>>>>>>>> 
>>>>>>>>  public void
>>>> addAdditionalAnnotatedType(AnnotatedType
>>>>>>>> annotatedType)
>>>>>>>>  {
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>> webBeansContext.getAnnotatedElementFactory().setAnnotatedType(annotatedTy
>>>>>> p
>>>>>>>> e);
>>>>>>>>  additionalAnnotatedTypes.put(null, annotatedType);
>>>>>>>>  }
>>>>>>>> 
>>>>>>>> All additional types are added with the same null key.
>>>>>>>> 
>>>>>>>> Best regards,
>>>>>>>> Harald
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>>> 
>> 
>> 

Re: Possibly invalid passivation capability check

[David Blevins]

On May 10, 2013, at 2:03 PM, Arne Limburg  wrote:

> Hi David,
> 
> Do I read the log correctly and SimpleServlet is @Dependent? Is
> SimpleServlet injected into a passivation-capable bean?
> If not, I agree with you that this is a bug.

Right.  Neither the bean (Car) or the injection target (SimpleServlet 
constructor) are passivation capable.


-David

> Am 10.05.13 22:55 schrieb "David Blevins" unter :
> 
>> Since the upgrade to 1.2.0 in we have a test failure.  There's a servlet
>> with constructor injection like so:
>> 
>> 
>>   @Inject
>>   public SimpleServlet(Car car) {
>>   this.car = car;
>>   }
>> 
>> And Car looks like so:
>> 
>>   public class Car {
>>   private final String make = "Lexus", model = "IS 350";
>>   private final int year = 2011;
>> 
>>   public String drive(String name) {
>>   return name + " is on the wheel of a " + year + " " + make +
>> " " + model;
>>   }
>>   }
>> 
>> All deploys fine and everything is injected as expected.  Now the
>> problem.  If you introduce a producer, it fails saying Car is not
>> passivation capable as required by the SimpleServlet injection point.
>> 
>>   public class Car {
>>   private final String make = "Lexus", model = "IS 350";
>>   private final int year = 2011;
>> 
>>   public Car(String ignore) {
>>   }
>> 
>>   public String drive(String name) {
>>   return name + " is on the wheel of a " + year + " " + make +
>> " " + model;
>>   }
>>   }
>> 
>>   public class Foo {
>> 
>>   @Produces @Default
>>   public Car car() {
>>   return new Car("foo");
>>   }
>>   }
>> 
>> 
>> javax.enterprise.inject.IllegalProductException: A producer method or
>> field of scope @Dependent returns an unserializable object for injection
>> into an injection point Constructor Injection Point, constructor name :
>> org.apache.openejb.arquillian.tests.cdi.constructor.SimpleServlet, Bean
>> Owner : [SimpleServlet, Name:null, WebBeans Type:DEPENDENT, API
>> Types:[java.io.Serializable,java.lang.Object,javax.servlet.ServletConfig,o
>> rg.apache.openejb.arquillian.tests.cdi.constructor.SimpleServlet,javax.ser
>> vlet.http.HttpServlet,javax.servlet.Servlet,javax.servlet.GenericServlet],
>> 
>> Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]]
>> that requires a passivation capable dependency
>>  at 
>> org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.ja
>> va:108)
>>  at 
>> org.apache.webbeans.inject.InjectableConstructor.doInjection(InjectableCon
>> structor.java:80)
>>  at 
>> org.apache.webbeans.portable.InjectionTargetImpl.newInstance(InjectionTarg
>> etImpl.java:253)
>>  at 
>> org.apache.webbeans.portable.InjectionTargetImpl.produce(InjectionTargetIm
>> pl.java:180)
>>  at 
>> org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:
>> 119)
>> 
>> There's debate as if the test is bad or if the check is incorrect.  Seems
>> like an OWB bug to me.
>> 
>> Thoughts?
>> 
>> 
>> -David
>> 
> 
> 

Re: [VOTE] [CANCELLED] release Apache OpenWebBeans-1.2.0

[David Blevins]

Excellent.  Fixed an issue in OWB that was affecting the TomEE build for a few 
days (OWB-858 - AnnotatedTypeImpl not thread safe).  Was causing 
java.util.ConcurrentModificationExceptions.

Hopefully we can get that in there.  Out of time tonight, but would like to 
find the issue with passivation checking.


-David

On May 10, 2013, at 10:09 AM, Mark Struberg  wrote:

> Yea, but I need to reset the versions to 1.2.0-SNAPSHOT still
> 
> LieGrue,
> strub
> 
> 
> 
> 
> - Original Message -
>> From: Arne Limburg 
>> To: "dev@openwebbeans.apache.org" ; Mark 
>> Struberg 
>> Cc: 
>> Sent: Friday, 10 May 2013, 15:33
>> Subject: Re: [VOTE] [CANCELLED] release Apache OpenWebBeans-1.2.0
>> 
>> Hi Thomas,
>> 
>> You can build it from trunk
>> 
>> 
>> Regards,
>> Arne
>> 
>> Am 10.05.13 13:36 schrieb "Thomas Andraschko" unter
>> :
>> 
>>> Is there already a new snapshot available somewhere?
>>> I would try it with my current app.
>>> 
>>> 
>>> 2013/5/10 Mark Struberg 
>>> 
 Hi folks!
 
 I'll reroll the release this evening.
 
 We will _not_ exclude the webbeans-cdi11 module from the source release
 but we don't ship any binaries for it.
 
 The reason is that we must not ship any CDI-1.1 binaries without 
>> passing
 the TCK. But there is no reason not to ship a mechanism to create a
 compat
 package.
 
 
 The reroll will contain Arnes fixes for the AnnotatedType and a few
 other
 minor things.
 
 LieGrue,
 strub
 
 
 
 - Original Message -
> From: Arne Limburg 
> To: "u...@openwebbeans.apache.org" 
>> 
> Cc:
> Sent: Thursday, 9 May 2013, 18:32
> Subject: Re: [VOTE] release Apache OpenWebBeans-1.2.0
> 
> T hanks Harald for catching this one.
> 
> That's a serious one. I'll fix it and we re-roll the 
>> release.
> 
> Cheers,
> Arne
> 
> Am 09.05.13 18:15 schrieb "Harald Wellmann" unter
> :
> 
>> -1 (non-binding)
>> 
>> Looks like there is a regression regarding
>> BeforeBeanDiscovery.addAnnotatedType(), compared to 1.1.8.
>> 
>> Adding more than one type has no effect.
>> 
>> The following method in BeanManagerImpl looks suspicious:
>> 
>>   public void 
>> addAdditionalAnnotatedType(AnnotatedType
>> annotatedType)
>>   {
>> 
>> 
 
 webBeansContext.getAnnotatedElementFactory().setAnnotatedType(annotatedTy
 p
>> e);
>>   additionalAnnotatedTypes.put(null, annotatedType);
>>   }
>> 
>> All additional types are added with the same null key.
>> 
>> Best regards,
>> Harald
>> 
>> 
> 
 
>> 
> 

[jira] [Commented] (OWB-858) AnnotatedTypeImpl not thread safe

[David Blevins (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13655131#comment-13655131
 ] 

David Blevins commented on OWB-858:
---

Some sample output from the testcase that reflects the issue we saw in some 
multithreaded tests in TomEE.

java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
at java.util.HashMap$KeyIterator.next(HashMap.java:828)
at 
java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1008)
at 
org.apache.webbeans.portable.AnnotatedTypeImplTest$1.doit(AnnotatedTypeImplTest.java:63)
at 
org.apache.webbeans.portable.AnnotatedTypeImplTest$Runner.run(AnnotatedTypeImplTest.java:176)
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
at java.util.HashMap$KeyIterator.next(HashMap.java:828)
at 
java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1008)
at 
org.apache.webbeans.portable.AnnotatedTypeImplTest$1.doit(AnnotatedTypeImplTest.java:63)
at 
org.apache.webbeans.portable.AnnotatedTypeImplTest$Runner.run(AnnotatedTypeImplTest.java:176)
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
at java.util.HashMap$KeyIterator.next(HashMap.java:828)
at 
java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1008)
at 
org.apache.webbeans.portable.AnnotatedTypeImplTest$1.doit(AnnotatedTypeImplTest.java:63)
at 
org.apache.webbeans.portable.AnnotatedTypeImplTest$Runner.run(AnnotatedTypeImplTest.java:176)
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
at java.util.HashMap$KeyIterator.next(HashMap.java:828)
at 
java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1008)
at 
org.apache.webbeans.portable.AnnotatedTypeImplTest$1.doit(AnnotatedTypeImplTest.java:63)
at 
org.apache.webbeans.portable.AnnotatedTypeImplTest$Runner.run(AnnotatedTypeImplTest.java:176)
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
at java.util.HashMap$KeyIterator.next(HashMap.java:828)
at 
java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1008)
at 
org.apache.webbeans.portable.AnnotatedTypeImplTest$1.doit(AnnotatedTypeImplTest.java:63)
at 
org.apache.webbeans.portable.AnnotatedTypeImplTest$Runner.run(AnnotatedTypeImplTest.java:176)
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
at java.util.HashMap$KeyIterator.next(HashMap.java:828)
at 
java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1008)
at 
org.apache.webbeans.portable.AnnotatedTypeImplTest$1.doit(AnnotatedTypeImplTest.java:63)
at 
org.apache.webbeans.portable.AnnotatedTypeImplTest$Runner.run(AnnotatedTypeImplTest.java:176)


> AnnotatedTypeImpl not thread safe
> -
>
> Key: OWB-858
> URL: https://issues.apache.org/jira/browse/OWB-858
> Project: OpenWebBeans
>  Issue Type: Bug
>    Reporter: David Blevins
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OWB-858) AnnotatedTypeImpl not thread safe

[David Blevins (JIRA)]

David Blevins created OWB-858:
-

 Summary: AnnotatedTypeImpl not thread safe
 Key: OWB-858
 URL: https://issues.apache.org/jira/browse/OWB-858
 Project: OpenWebBeans
  Issue Type: Bug
Reporter: David Blevins




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Possibly invalid passivation capability check

[David Blevins]

Since the upgrade to 1.2.0 in we have a test failure.  There's a servlet with 
constructor injection like so:


@Inject
public SimpleServlet(Car car) {
this.car = car;
}

And Car looks like so:

public class Car {
private final String make = "Lexus", model = "IS 350";
private final int year = 2011;

public String drive(String name) {
return name + " is on the wheel of a " + year + " " + make + " " + 
model;
}
}

All deploys fine and everything is injected as expected.  Now the problem.  If 
you introduce a producer, it fails saying Car is not passivation capable as 
required by the SimpleServlet injection point.

public class Car {
private final String make = "Lexus", model = "IS 350";
private final int year = 2011;

public Car(String ignore) {
}

public String drive(String name) {
return name + " is on the wheel of a " + year + " " + make + " " + 
model;
}
}

public class Foo {

@Produces @Default
public Car car() {
return new Car("foo");
}
}


javax.enterprise.inject.IllegalProductException: A producer method or field of 
scope @Dependent returns an unserializable object for injection into an 
injection point Constructor Injection Point, constructor name :  
org.apache.openejb.arquillian.tests.cdi.constructor.SimpleServlet, Bean Owner : 
[SimpleServlet, Name:null, WebBeans Type:DEPENDENT, API 
Types:[java.io.Serializable,java.lang.Object,javax.servlet.ServletConfig,org.apache.openejb.arquillian.tests.cdi.constructor.SimpleServlet,javax.servlet.http.HttpServlet,javax.servlet.Servlet,javax.servlet.GenericServlet],
 Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]] that 
requires a passivation capable dependency
at 
org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:108)
at 
org.apache.webbeans.inject.InjectableConstructor.doInjection(InjectableConstructor.java:80)
at 
org.apache.webbeans.portable.InjectionTargetImpl.newInstance(InjectionTargetImpl.java:253)
at 
org.apache.webbeans.portable.InjectionTargetImpl.produce(InjectionTargetImpl.java:180)
at 
org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:119)

There's debate as if the test is bad or if the check is incorrect.  Seems like 
an OWB bug to me.

Thoughts?


-David

Compile error in trunk?

[David Blevins]

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) 
on project openwebbeans-ee-common: Compilation failure
[ERROR] 
/Users/dblevins/work/openwebbeans/webbeans-ee-common/src/main/java/org/apache/webbeans/ee/common/beans/PrincipalBean.java:[37,51]
 error: constructor ProviderBasedProxyProducer in class 
ProviderBasedProxyProducer cannot be applied to given types;
[ERROR] -> [Help 1]


Dunno if this is a OSX Java 1.7 thing or what.  Anyone not seeing this?


-David

Re: Go ahead with CDI 1.1

[David Blevins]

+1

On Apr 11, 2013, at 12:46 PM, Gerhard Petracek  
wrote:

> @mark: +1
> 
> regards,
> gerhard
> 
> 
> 
> 2013/4/11 Mark Struberg 
> 
>> I'd say we keep 1.2 as CDI-1.0 and implement CDI-1.1 in 2.0.
>> 
>> Reason is that this will allow TomEE-1.6.x to switch to owb-1.2.x and take
>> a bit more time to implement cdi-1.1 without having to stay on owb-1.1.x
>> This will be much easier to maintain and develop cdi-1.1 that way imo.
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>> 
>> - Original Message -
>>> From: Arne Limburg 
>>> To: "dev@openwebbeans.apache.org" 
>>> Cc:
>>> Sent: Thursday, April 11, 2013 7:12 PM
>>> Subject: Go ahead with CDI 1.1
>>> 
>>> Hi all,
>>> 
>>> I would like to go ahead and implement CDI 1.1 on the OWB 1.2 stream.
>>> I wonder, if some of the java ee container implementors want to use the
>> 1.2
>>> stream in a pre java ee 7 release.
>>> If so, I would like to find a way to do this. Maybe this would be
>> possible with
>>> a maven profile and some maven hacking (has someone used the
>>> maven-replacer-plugin?).
>>> If no one is interested in a CDI 1.0 OWB 1.2 stream, we directly can go
>> ahead
>>> and implement CDI 1.1
>>> 
>>> WDYT?
>>> 
>>> Cheers,
>>> Arne
>>> 
>> 

Re: [VOTE] (take2) Release Apache OpenWebBeans 1.1.8

[David Blevins]

+1


David

On Mar 17, 2013, at 10:01 AM, Mark Struberg  wrote:

> 
> Hi!
> 
> 
> 2nd try ;)
> 
> I'd like to call a VOTE on releasing Apache OpenWebBeans-1.1.8 .
> 
> This is a bugfix release of OpenWebBeans-1.1.x, thus it's maintained in a 
> maintenance branch.
> 
> This
> release mainly contains small bugfixes. The most prominent new feature 
> is the addition of the owb-arquillian-standalone adaptor for the JBoss™ 
> Arquillian testing framework (which is ALv2 licensed).
> 
> The ReleaseNotes are available online: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844&version=12323873
> 
> Maven staging repo:
> 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-008/
> 
> SVN source tag:
> https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.8/
> 
> Source Release:
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-008/org/apache/openwebbeans/openwebbeans/1.1.8/openwebbeans-1.1.8-source-release.zip
> 
> Binary release:
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-008/org/apache/openwebbeans/openwebbeans-distribution/1.1.8/openwebbeans-distribution-1.1.8-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: OWB 1.1.8

[David Blevins]

It's tomorrow evening :)  Will do this first thing in the morning tomorrow if 
not already up when I awake.


-David

On Mar 13, 2013, at 2:40 PM, Mark Struberg  wrote:

> I added all the stuff I am aware off. If noone objects then I gonna start 
> with the release tomorrow evening. 
> Though I'm not sure if we have all the xbean release finished until tomorrow 
> evening. (still 1 +1 missing imo)
> 
> LieGrue,
> strub
> 
> 
> 
> 
> - Original Message -
>> From: David Blevins 
>> To: openwebbeans-dev 
>> Cc: 
>> Sent: Wednesday, March 13, 2013 9:52 PM
>> Subject: OWB 1.1.8
>> 
>> Probably should have sent this note yesterday.  We need a 1.1.8 release for 
>> the 
>> pending TomEE 1.5.2.
>> 
>> Mark had indicated he needed to get OWB-790 fixed which he did.  I might try 
>> rolling some release candidates unless someone beats me to it.  If there's 
>> some reason to hold up, that's cool too.
>> 
>> 
>> -David
>> 
> 

OWB 1.1.8

[David Blevins]

Probably should have sent this note yesterday.  We need a 1.1.8 release for the 
pending TomEE 1.5.2.

Mark had indicated he needed to get OWB-790 fixed which he did.  I might try 
rolling some release candidates unless someone beats me to it.  If there's some 
reason to hold up, that's cool too.


-David

[jira] [Commented] (OWB-743) Overloaded EJB Observer methods fail to deploy

[David Blevins (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13540934#comment-13540934
 ] 

David Blevins commented on OWB-743:
---

That was fast :)  Thanks so much, Arne!

> Overloaded EJB Observer methods fail to deploy
> --
>
> Key: OWB-743
> URL: https://issues.apache.org/jira/browse/OWB-743
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: 1.1.6
>Reporter: David Blevins
>Assignee: Arne Limburg
> Fix For: 1.1.8, 1.2.0
>
> Attachments: OverloadedEjbObserverMethodsTest.java
>
>
> Haven't had a chance to look into this -- hacking on other stuff at the 
> moment.  Clear bug, though.
> Attached test case will pass if one of the observer methods is renamed.  
> Things only fail when the method name is overloaded.
> org.apache.openejb.OpenEJBException: Creating application failed: 
> /private/var/folders/bd/f9ntqy1m8xj_fs006s6crtjhgn/T/0/gbuild: couldn't 
> start owb context
>   at 
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:959)
>   at 
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:537)
>   at 
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:982)
>   at 
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:901)
>   at 
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:118)
>   at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
>   at 
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
>   at 
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5173)
>   at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>   at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
>   at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
>   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
>   at 
> org.apache.tomee.catalina.TomcatWebAppBuilder.deployWar(TomcatWebAppBuilder.java:538)
>   at 
> org.apache.tomee.catalina.TomcatWebAppBuilder.deployWebApps(TomcatWebAppBuilder.java:509)
>   at 
> org.apache.tomee.catalina.deployment.TomcatWebappDeployer.deploy(TomcatWebappDeployer.java:44)
>   at org.apache.tomee.embedded.Container.deploy(Container.java:270)
>   at org.apache.tomee.embedded.Container.deploy(Container.java:258)
>   at 
> org.apache.openejb.arquillian.embedded.EmbeddedTomEEContainer.deploy(EmbeddedTomEEContainer.java:111)
>   at 
> org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
>   at 
> org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
>   at 
> org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
>   at 
> org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
>   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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
>   at 
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>   at 
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>   at 
> org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
>   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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
>   at 
> org.jboss.arquillian.core.impl.EventContextImpl.

[jira] [Updated] (OWB-743) Overloaded EJB Observer methods fail to deploy

[David Blevins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Blevins updated OWB-743:
--

Attachment: OverloadedEjbObserverMethodsTest.java

> Overloaded EJB Observer methods fail to deploy
> --
>
> Key: OWB-743
> URL: https://issues.apache.org/jira/browse/OWB-743
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: 1.1.6
>    Reporter: David Blevins
> Attachments: OverloadedEjbObserverMethodsTest.java
>
>
> Haven't had a chance to look into this -- hacking on other stuff at the 
> moment.  Clear bug, though.
> Attached test case will pass if one of the observer methods is renamed.  
> Things only fail when the method name is overloaded.
> org.apache.openejb.OpenEJBException: Creating application failed: 
> /private/var/folders/bd/f9ntqy1m8xj_fs006s6crtjhgn/T/0/gbuild: couldn't 
> start owb context
>   at 
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:959)
>   at 
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:537)
>   at 
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:982)
>   at 
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:901)
>   at 
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:118)
>   at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
>   at 
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
>   at 
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5173)
>   at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>   at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
>   at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
>   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
>   at 
> org.apache.tomee.catalina.TomcatWebAppBuilder.deployWar(TomcatWebAppBuilder.java:538)
>   at 
> org.apache.tomee.catalina.TomcatWebAppBuilder.deployWebApps(TomcatWebAppBuilder.java:509)
>   at 
> org.apache.tomee.catalina.deployment.TomcatWebappDeployer.deploy(TomcatWebappDeployer.java:44)
>   at org.apache.tomee.embedded.Container.deploy(Container.java:270)
>   at org.apache.tomee.embedded.Container.deploy(Container.java:258)
>   at 
> org.apache.openejb.arquillian.embedded.EmbeddedTomEEContainer.deploy(EmbeddedTomEEContainer.java:111)
>   at 
> org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
>   at 
> org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
>   at 
> org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
>   at 
> org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
>   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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
>   at 
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>   at 
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>   at 
> org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
>   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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
>   at 
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>   at 
> org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(Co

[jira] [Created] (OWB-743) Overloaded EJB Observer methods fail to deploy

[David Blevins (JIRA)]

David Blevins created OWB-743:
-

 Summary: Overloaded EJB Observer methods fail to deploy
 Key: OWB-743
 URL: https://issues.apache.org/jira/browse/OWB-743
 Project: OpenWebBeans
  Issue Type: Bug
Affects Versions: 1.1.6
Reporter: David Blevins


Haven't had a chance to look into this -- hacking on other stuff at the moment. 
 Clear bug, though.

Attached test case will pass if one of the observer methods is renamed.  Things 
only fail when the method name is overloaded.

org.apache.openejb.OpenEJBException: Creating application failed: 
/private/var/folders/bd/f9ntqy1m8xj_fs006s6crtjhgn/T/0/gbuild: couldn't 
start owb context
at 
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:959)
at 
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:537)
at 
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:982)
at 
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:901)
at 
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:118)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at 
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5173)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at 
org.apache.tomee.catalina.TomcatWebAppBuilder.deployWar(TomcatWebAppBuilder.java:538)
at 
org.apache.tomee.catalina.TomcatWebAppBuilder.deployWebApps(TomcatWebAppBuilder.java:509)
at 
org.apache.tomee.catalina.deployment.TomcatWebappDeployer.deploy(TomcatWebappDeployer.java:44)
at org.apache.tomee.embedded.Container.deploy(Container.java:270)
at org.apache.tomee.embedded.Container.deploy(Container.java:258)
at 
org.apache.openejb.arquillian.embedded.EmbeddedTomEEContainer.deploy(EmbeddedTomEEContainer.java:111)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at 
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at 
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at 
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at 
org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at 
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at 
org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at 
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)

Thoughts on OWB 1.1.7 ?

[David Blevins]

What's the approximate timeline on 1.1.7 ?


-David

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

[David Blevins]

+1

Thanks, so much, Mark for all the work on this release!  Pretty outstanding!

-David

On Sep 25, 2012, at 5:22 PM, Mark Struberg 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=12310844&version=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: [VOTE] release Apache OpenWebBeans build tools 1.2

[David Blevins]

+1

On Sep 16, 2012, at 1:58 PM, Mark Struberg wrote:

> 
> 
> Hi!  
> 
> 
> I'd like to call a VOTE on releasing Apache OpenWebBeans build-tools-1.2. 
> This release is needed for shipping OWB.
> 
> 
> We just relaxed the method length rules a bit.Maven staging repo: 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-001/
> 
> 
> SVN source tag:
> https://svn.apache.org/repos/asf/openwebbeans/build-tools/tags/checkstyle-rules-1.2/
> 
> Source release: 
> 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-001/org/apache/openwebbeans/build-tools/checkstyle-rules/1.2/checkstyle-rules-1.2-source-release.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: [DISCUSS] release OWB-1.1.6 end of this week?

[David Blevins]

Don't forget we also need a build-tools release.


On Sep 15, 2012, at 2:32 AM, Mark Struberg wrote:

> Hi David!
> 
> I can roll the release tonight or tomorrow morning. 
> Udo still likes to get a few things done afaik. UnitTests and stuff...
> 
> 
> Thomas, did you commit all your changes which you have Jiras created for?
> 
> LieGrue,
> strub
> 
> 
> 
> - Original Message -
>> From: David Blevins 
>> To: dev@openwebbeans.apache.org; Mark Struberg 
>> Cc: 
>> Sent: Saturday, September 15, 2012 10:56 AM
>> Subject: Re: [DISCUSS] release OWB-1.1.6 end of this week?
>> 
>> G ot the ASM support finished.  OWB-701 officially closed.
>> 
>> We still use Javassist by default, but we have the ability to use ASM.
>> 
>> Mark, do you need help with the release?  (I know you have a *very* busy 
>> week 
>> coming up :)
>> 
>> 
>> -David
>> 
>> On Sep 12, 2012, at 11:03 AM, Mark Struberg wrote:
>> 
>>> 2nd try as my previous got eaten by the spam filter :/
>>> 
>>> 
>>> 
>>> 
>>> 
>>> - Forwarded Message -
>>>> From: Mark Struberg 
>>>> To: openwebbeans-dev  
>>>> 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: [DISCUSS] release OWB-1.1.6 end of this week?

[David Blevins]

Got the ASM support finished.  OWB-701 officially closed.

We still use Javassist by default, but we have the ability to use ASM.

Mark, do you need help with the release?  (I know you have a *very* busy week 
coming up :)


-David

On Sep 12, 2012, at 11:03 AM, Mark Struberg wrote:

> 2nd try as my previous got eaten by the spam filter :/
> 
> 
> 
> 
> 
> - Forwarded Message -
>> From: Mark Struberg 
>> To: openwebbeans-dev  
>> 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
>> 
>> 
>> 
>> 
>> 
> 

[jira] [Resolved] (OWB-701) Support ASM for Bean Proxies

[David Blevins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Blevins resolved OWB-701.
---

Resolution: Fixed

> Support ASM for Bean Proxies
> 
>
> Key: OWB-701
> URL: https://issues.apache.org/jira/browse/OWB-701
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core
>    Reporter: David Blevins
>    Assignee: David Blevins
> Fix For: 1.1.6
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OWB-701) Support ASM for Bean Proxies

[David Blevins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Blevins updated OWB-701:
--

Component/s: Core
Summary: Support ASM for Bean Proxies  (was: Remove Javassist)

> Support ASM for Bean Proxies
> 
>
> Key: OWB-701
> URL: https://issues.apache.org/jira/browse/OWB-701
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core
>    Reporter: David Blevins
>    Assignee: David Blevins
> Fix For: 1.1.6
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OWB-701) Remove Javassist

[David Blevins (JIRA)]

David Blevins created OWB-701:
-

 Summary: Remove Javassist
 Key: OWB-701
 URL: https://issues.apache.org/jira/browse/OWB-701
 Project: OpenWebBeans
  Issue Type: Improvement
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 1.1.6




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] release Apache OpenWebBeans 1.1.5

[David Blevins]

+1


-David

On Aug 8, 2012, at 4:01 PM, Mark Struberg 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=12310844&version=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: javassist removal

[David Blevins]

On Aug 9, 2012, at 1:25 AM, Sven Linstaedt wrote:

> Hi, sounds like you have something similar to commons-proxy [1] in
> mind, when creating an abstraction of the proxy class generation
> library. Have you already considered using it?

Just became aware of it yesterday.

ASM does the real work, and then it's about one class to do the actual 
generation and proxy creation.  So it's not a lot of code.  We use a version of 
it in OpenEJB to do @LocalBean proxy generation.  On that side of the fence we 
do tons of ASM bytecode generation and manipulation.  So we just banged this 
out maybe 4 years ago without giving it much though.

I love commons and am happy for the code to live anywhere.


-David

> 2012/8/9 David Blevins :
>> Hey All,
>> 
>> Heads up that I'd like to investigate removing javassist and replacing it 
>> with some simple ASM code to create subclass based proxies.  The proxy code 
>> is the small part, the bigger part is refactoring out the MethodHandler 
>> classes and replacing them with java.lang.reflect.InvocationHandler 
>> implementations.
>> 
>> As usual I'll probably look for an intermediary step in refactoring it out, 
>> maybe some way to keep the MethodHandlers and get all the code working with 
>> a different proxy impl, then refactor the handlers.
>> 
>> Any thoughts or comments welcome.
>> 
>> 
>> -David
>> 
> 

Re: javassist removal

[David Blevins]

On Aug 8, 2012, at 11:36 PM, Charles Moulliard wrote:

> Hi David,
> 
> Is it for performance reasons that you prefer to switch from Javassist to
> ASM (http://swapnil84.wordpress.com/2009/09/01/asm-vs-javassist/) ?

Pretty much.  Slower, consumes more memory and generally overkill.  The code to 
create a subclass with ASM is basically one class -- two or three if you want 
to get fancy.

> What
> could be the impact for existing projects (or side effect) when they will
> upgrade to a "refactored" version of OpenWebbeans using ASM and not longer
> javassist ?

Certainly no impact to user code.  If someone has some very deep OWB 
integration code that digs right down into the proxy layer, they're welcome to 
speak up.  We can easily hold the show and discuss.


-David

> On Thu, Aug 9, 2012 at 6:27 AM, David Blevins wrote:
> 
>> Hey All,
>> 
>> Heads up that I'd like to investigate removing javassist and replacing it
>> with some simple ASM code to create subclass based proxies.  The proxy code
>> is the small part, the bigger part is refactoring out the MethodHandler
>> classes and replacing them with java.lang.reflect.InvocationHandler
>> implementations.
>> 
>> As usual I'll probably look for an intermediary step in refactoring it
>> out, maybe some way to keep the MethodHandlers and get all the code working
>> with a different proxy impl, then refactor the handlers.
>> 
>> Any thoughts or comments welcome.
>> 
>> 
>> -David
>> 
>> 
> 
> 
> -- 
> Charles Moulliard
> Apache Committer / Sr. Pr. Consultant at FuseSource.com
> Twitter : @cmoulliard
> Blog : http://cmoulliard.blogspot.com

javassist removal

[David Blevins]

Hey All,

Heads up that I'd like to investigate removing javassist and replacing it with 
some simple ASM code to create subclass based proxies.  The proxy code is the 
small part, the bigger part is refactoring out the MethodHandler classes and 
replacing them with java.lang.reflect.InvocationHandler implementations.

As usual I'll probably look for an intermediary step in refactoring it out, 
maybe some way to keep the MethodHandlers and get all the code working with a 
different proxy impl, then refactor the handlers.

Any thoughts or comments welcome.


-David

Re: [VOTE] take2 Release Apache OpenWebBeans-1.1.4

[David Blevins]

+1


David

On Apr 5, 2012, at 3:23 AM, Mark Struberg wrote:

> Hi! 
> 
> I'd like to call a second VOTE on releasing Apache OpenWebBeans-1.1.4 .
> 
> 
> I've now fixed the picking up of the atinject-tck and docs.
> 
> 
> 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=12310844&version=12319171
> 
> Maven staging repo:
> 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-007/
> 
> SVN source tag (1309727):
> 
> https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.4/
> 
> Source release:
> 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-007/org/apache/openwebbeans/openwebbeans/1.1.4/openwebbeans-1.1.4-source-release.zip
> 
> Binary release:
> 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-007/org/apache/openwebbeans/openwebbeans-distribution/1.1.4/openwebbeans-distribution-1.1.4-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: [ANNOUNCE] Welcome Romain Manni-Bucau as new Committer!

[David Blevins]

Welcome to this side of the fence, Romain! :)


-David

On Mar 12, 2012, at 2:23 AM, Mark Struberg wrote:

> All, 
> 
> The OpenWebBeans PMC is pleased to announce that Romain Manni-Bucau has 
> accepted our invitation to join the OpenWebBeans project as a 
> committer. 
> 
> Congratulations and welcome Romain!
> 
> the OpenWebBeans PMC
> 
> 

Fwd: Apache TomEE 1.0.0-beta-2

[David Blevins]

Don't forget to tell your friends! :)

Begin forwarded message:

> From: David Blevins 
> Date: January 24, 2012 12:28:37 PM PST
> To: d...@openejb.apache.org
> 
> Retweets encouraged!
> 
> https://twitter.com/#!/ApacheTomEE/statuses/161903294216806400

1.1.4 release?

[David Blevins]

Anyone mind if I take a shot at a 1.1.4 release?  If someone else would rather 
do it, that's fine.

Any showstoppers that we'd want for a 1.1.4 release?


-David

[jira] [Resolved] (OWB-592) EJB Specialization utility method

[David Blevins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Blevins resolved OWB-592.
---

   Resolution: Fixed
Fix Version/s: (was: 1.2.0)
   1.1.1

> EJB Specialization utility method
> -
>
> Key: OWB-592
> URL: https://issues.apache.org/jira/browse/OWB-592
> Project: OpenWebBeans
>  Issue Type: Task
>  Components: Inheritance, Specialization, Java EE Integration
>    Reporter: David Blevins
>    Assignee: David Blevins
> Fix For: 1.1.1
>
>
> Makes the specialization code for EJBs in OpenEJB a little easier

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

[jira] [Closed] (OWB-591) EJB @Specializes inheritance

[David Blevins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Blevins closed OWB-591.
-

   Resolution: Fixed
Fix Version/s: (was: 1.2.0)
   1.1.1
 Assignee: David Blevins  (was: Gurkan Erdogdu)

> EJB @Specializes inheritance
> 
>
> Key: OWB-591
> URL: https://issues.apache.org/jira/browse/OWB-591
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Inheritance, Specialization
>    Reporter: David Blevins
>    Assignee: David Blevins
> Fix For: 1.1.1
>
>


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

ImplementationLoaderService rename

[David Blevins]

Renamed ImplementationLoaderService to simply LoaderService.  Let me know if I 
stepped on anyone's toes :)  Will be happy to revert.

Seeing "implements Implementation..." in the code had me lost in an existential 
"chicken and egg" and "the meaning of meaning" tailspin.  Too deep for me too 
think about :)

Anyway happy to change it back if someone really liked it.


-David

Release?

[David Blevins]

We'll probably be doing releases of Geronimo in the next couple weeks.  
Wondering what we thought about the timing for our 1.1.1 code.

Anything in particular we want to get in it or are we pretty much good to go?

-David

[jira] [Created] (OWB-592) EJB Specialization utility method

[David Blevins (JIRA)]

EJB Specialization utility method
-

 Key: OWB-592
 URL: https://issues.apache.org/jira/browse/OWB-592
 Project: OpenWebBeans
  Issue Type: Task
  Components: Inheritance, Specialization, Java EE Integration
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 1.1.1


Makes the specialization code for EJBs in OpenEJB a little easier

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

[jira] [Commented] (OWB-573) Invalid checking of Interceptor serialization capabilities for non-Passivation capable EJBs

[David Blevins (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065708#comment-13065708
 ] 

David Blevins commented on OWB-573:
---

If you can post the code that does the performance checking, I can take a look 
with yourkit.


> Invalid checking of Interceptor serialization capabilities for 
> non-Passivation capable EJBs
> ---
>
> Key: OWB-573
> URL: https://issues.apache.org/jira/browse/OWB-573
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Interceptor and Decorators
>    Reporter: David Blevins
>Assignee: David Blevins
> Fix For: 1.2.0
>
>
> DefinitionUtil invalidly checks the fields of Interceptor classes to see if 
> they are serializable.  This isn't a requirement of the Interceptor 
> specification.  As well in pure Java serialization terms, there is no 
> requirement that the class types of fields implement Serializable, so a field 
> of say java.lang.Object is OK.  The requirement is that at serialization time 
> that field must point to a serializable instance or be null.  This obviously 
> can only be checked by inspecting instances of a class and cannot be checked 
> statically against the class itself.

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

Thought: Lazily create @New bean defs

[David Blevins]

Kind of a random thought.  Not sure if it's even possible, but

There's nothing particularly fancy about @New beans.  Perhaps we don't need to 
be eagerly creating these things.  Resolving references involves a lot of list 
iteration for us and the eager creation of @New bean definitions bloats our 
lists by more or less double.  Meanwhile I'm not sure how popular they really 
are.

Couldn't we create these NewManagedBean defs on demand when someone actually 
asks for an @New bean reference?  So we don't have to always iterate over them 
and add them to the list of potentially matching beans only to then filter them 
out and return the non-@New bean.

I know that with some recent changes in EJB-type things the EJB implementation 
itself is typically creating @New bean definitions.  Seems a little factory 
method somewhere in the EJB plugin API could do the trick.  Something like:

   NewBean getNewBean(BaseEjbBean bean);
or 
   NewBean getNewBean(Bean bean);

We could cache them after first call, but I can't imagine that creating a 
NewBean copy of a bean is very expensive.

Don't have time to work on it :)  But I thought I'd throw it out there for 
feedback in case someone thinks it's a good idea and wants to take a swing at 
it.


-David

[jira] [Commented] (OWB-573) Invalid checking of Interceptor serialization capabilities for non-Passivation capable EJBs

[David Blevins (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064717#comment-13064717
 ] 

David Blevins commented on OWB-573:
---

Sure, happy to look into it.  Not sure how with the info provided.  Would 
probably need either some info on the benchmark (which part is slow or maybe 
performance data that shows where the biggest tim change is) or the benchmark 
itself.  Or even a test case that can show the slowdown.


> Invalid checking of Interceptor serialization capabilities for 
> non-Passivation capable EJBs
> ---
>
> Key: OWB-573
> URL: https://issues.apache.org/jira/browse/OWB-573
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Interceptor and Decorators
>    Reporter: David Blevins
>Assignee: David Blevins
> Fix For: 1.2.0
>
>
> DefinitionUtil invalidly checks the fields of Interceptor classes to see if 
> they are serializable.  This isn't a requirement of the Interceptor 
> specification.  As well in pure Java serialization terms, there is no 
> requirement that the class types of fields implement Serializable, so a field 
> of say java.lang.Object is OK.  The requirement is that at serialization time 
> that field must point to a serializable instance or be null.  This obviously 
> can only be checked by inspecting instances of a class and cannot be checked 
> statically against the class itself.

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

[jira] [Created] (OWB-591) EJB @Specializes inheritance

[David Blevins (JIRA)]

EJB @Specializes inheritance


 Key: OWB-591
 URL: https://issues.apache.org/jira/browse/OWB-591
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Inheritance, Specialization
Reporter: David Blevins
Assignee: Gurkan Erdogdu




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

Re: Snapshots

[David Blevins]

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.

That sounds promising.  That or 'mvn clean install deploy' as the build command.

I haven't spent even two seconds looking at Hudson config so not sure how to 
advise.  The snapshot repo is here:

  http://repository.apache.org/snapshots


-David


> 
> On Wed, Jun 22, 2011 at 6:02 PM, David Blevins 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  wrote:
>>> 
>>>> From: David Blevins 
>>>> 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

[David Blevins]

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  wrote:
> 
>> From: David Blevins 
>> 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
>> 
>> 
>> 
>> 
> 
> 
> 

[jira] [Resolved] (OWB-573) Invalid checking of Interceptor serialization capabilities for non-Passivation capable EJBs

[David Blevins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Blevins resolved OWB-573.
---

Resolution: Fixed

> Invalid checking of Interceptor serialization capabilities for 
> non-Passivation capable EJBs
> ---
>
> Key: OWB-573
> URL: https://issues.apache.org/jira/browse/OWB-573
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Interceptor and Decorators
>    Reporter: David Blevins
>    Assignee: David Blevins
> Fix For: 1.2.0
>
>
> DefinitionUtil invalidly checks the fields of Interceptor classes to see if 
> they are serializable.  This isn't a requirement of the Interceptor 
> specification.  As well in pure Java serialization terms, there is no 
> requirement that the class types of fields implement Serializable, so a field 
> of say java.lang.Object is OK.  The requirement is that at serialization time 
> that field must point to a serializable instance or be null.  This obviously 
> can only be checked by inspecting instances of a class and cannot be checked 
> statically against the class itself.

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

[jira] [Resolved] (OWB-587) Use business interface for producer and disposer methods of Session beans

[David Blevins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Blevins resolved OWB-587.
---

Resolution: Fixed

> Use business interface for producer and disposer methods of Session beans
> -
>
> Key: OWB-587
> URL: https://issues.apache.org/jira/browse/OWB-587
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Enterprise Web Beans
>    Reporter: David Blevins
>    Assignee: David Blevins
> Fix For: 1.1.1
>
>
> Use the Ejb Plugin to convert bean methods into the respective business 
> methods of the interface.  The method invocations themselves will always take 
> place on the ejb proxy.

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

[jira] [Created] (OWB-587) Use business interface for producer and disposer methods of Session beans

[David Blevins (JIRA)]

Use business interface for producer and disposer methods of Session beans
-

 Key: OWB-587
 URL: https://issues.apache.org/jira/browse/OWB-587
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Enterprise Web Beans
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 1.1.1


Use the Ejb Plugin to convert bean methods into the respective business methods 
of the interface.  The method invocations themselves will always take place on 
the ejb proxy.

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

[jira] [Updated] (OWB-573) Invalid checking of Interceptor serialization capabilities for non-Passivation capable EJBs

[David Blevins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Blevins updated OWB-573:
--

Summary: Invalid checking of Interceptor serialization capabilities for 
non-Passivation capable EJBs  (was: Invalid checking of Interceptor 
serialization capabilities)

Per current spec only @Stateful session beans should be serializable.

> Invalid checking of Interceptor serialization capabilities for 
> non-Passivation capable EJBs
> ---
>
> Key: OWB-573
> URL: https://issues.apache.org/jira/browse/OWB-573
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Interceptor and Decorators
>    Reporter: David Blevins
>    Assignee: David Blevins
> Fix For: 1.2.0
>
>
> DefinitionUtil invalidly checks the fields of Interceptor classes to see if 
> they are serializable.  This isn't a requirement of the Interceptor 
> specification.  As well in pure Java serialization terms, there is no 
> requirement that the class types of fields implement Serializable, so a field 
> of say java.lang.Object is OK.  The requirement is that at serialization time 
> that field must point to a serializable instance or be null.  This obviously 
> can only be checked by inspecting instances of a class and cannot be checked 
> statically against the class itself.

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

Re: Observer method resolution

[David Blevins]

Looks like this is something we have to fix.  See the little example I posted 
here:

  
https://issues.jboss.org/browse/CDITCK-215?focusedCommentId=12607939&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12607939

Anyone want to take a look at fixing this one?  (already overloaded)


-David

On Jun 8, 2011, at 12:27 PM, David Blevins wrote:

> 
> On Jun 8, 2011, at 7:56 AM, Gurkan Erdogdu wrote:
> 
>> Hello David
>> 
>> There are some cases that are explicitly defined in the specification. You 
>> can 
>> open TCK issue from CDI-TCK : https://issues.jboss.org/browse/CDITCK
>> 
>> Seems that our solution to find observer methods is correct!
> 
> That was my thought as well.  I can sort of see how it might be useful when 
> looking at it from an overloaded method perspective:
> 
>   public void doit(Object o)
>   public void doit(File f)
> 
> But I don't see any language like that in the spec anywhere.
> 
> I like our way better :)  Filed a JIRA
> 
>  https://issues.jboss.org/browse/CDITCK-215
> 
> 
> -David
> 
>> 
>> From: David Blevins 
>> To: dev@openwebbeans.apache.org
>> Sent: Wed, June 8, 2011 1:01:54 PM
>> Subject: Observer method resolution
>> 
>> Digging into a test that essentially has two observer methods and is 
>> asserting 
>> that only one of them are called.
>> 
>>  public void observeElephantSessionBean(@Observes 
>> ProcessSessionBean 
>> event)
>>  {
>>  ProcessBeanObserver.elephantProcessSessionBean = event;
>>  }
>> 
>>  public void observeElephantBean(@Observes ProcessBean event)
>>  {
>>  ProcessBeanObserver.elephantProcessBeanCount++;
>>  }
>> 
>> The test is asserting that observeElephantSessionBean is called and that 
>> observeElephantBean is not called.
>> 
>> Currently we call both because ProcessSessionBean is assignable to 
>> ProcessBean.
>> 
>> Anyone know what part of the spec might lead to this kind of requirement?  
>> The 
>> spec seems to say in 10.4 pretty clearly:
>> 
>>  There may be arbitrarily many observer methods with the same event 
>> parameter 
>> type and qualifiers.
>>  A bean (or extension) may declare multiple observer methods.
>> 
>> 
>> For the interested, the test is 
>> org.jboss.jsr299.tck.tests.extensions.processBean.ProcessSessionBeanTest.testProcessSessionBeanEvent
>> 
>> 
>> 
>> -David
> 

Re: Observer method resolution

[David Blevins]

On Jun 8, 2011, at 7:56 AM, Gurkan Erdogdu wrote:

> Hello David
> 
> There are some cases that are explicitly defined in the specification. You 
> can 
> open TCK issue from CDI-TCK : https://issues.jboss.org/browse/CDITCK
> 
> Seems that our solution to find observer methods is correct!

That was my thought as well.  I can sort of see how it might be useful when 
looking at it from an overloaded method perspective:

   public void doit(Object o)
   public void doit(File f)

But I don't see any language like that in the spec anywhere.

I like our way better :)  Filed a JIRA

  https://issues.jboss.org/browse/CDITCK-215


-David

> ________
> From: David Blevins 
> To: dev@openwebbeans.apache.org
> Sent: Wed, June 8, 2011 1:01:54 PM
> Subject: Observer method resolution
> 
> Digging into a test that essentially has two observer methods and is 
> asserting 
> that only one of them are called.
> 
>   public void observeElephantSessionBean(@Observes 
> ProcessSessionBean 
> event)
>   {
>   ProcessBeanObserver.elephantProcessSessionBean = event;
>   }
>   
>   public void observeElephantBean(@Observes ProcessBean event)
>   {
>   ProcessBeanObserver.elephantProcessBeanCount++;
>   }
>   
> The test is asserting that observeElephantSessionBean is called and that 
> observeElephantBean is not called.
> 
> Currently we call both because ProcessSessionBean is assignable to 
> ProcessBean.
> 
> Anyone know what part of the spec might lead to this kind of requirement?  
> The 
> spec seems to say in 10.4 pretty clearly:
> 
>   There may be arbitrarily many observer methods with the same event 
> parameter 
> type and qualifiers.
>   A bean (or extension) may declare multiple observer methods.
> 
> 
> For the interested, the test is 
> org.jboss.jsr299.tck.tests.extensions.processBean.ProcessSessionBeanTest.testProcessSessionBeanEvent
> 
> 
> 
> -David

Observer method resolution

[David Blevins]

Digging into a test that essentially has two observer methods and is asserting 
that only one of them are called.

   public void observeElephantSessionBean(@Observes 
ProcessSessionBean event)
   {
  ProcessBeanObserver.elephantProcessSessionBean = event;
   }
   
   public void observeElephantBean(@Observes ProcessBean event)
   {
  ProcessBeanObserver.elephantProcessBeanCount++;
   }
   
The test is asserting that observeElephantSessionBean is called and that 
observeElephantBean is not called.

Currently we call both because ProcessSessionBean is assignable to ProcessBean.

Anyone know what part of the spec might lead to this kind of requirement?  The 
spec seems to say in 10.4 pretty clearly:

  There may be arbitrarily many observer methods with the same event parameter 
type and qualifiers.
  A bean (or extension) may declare multiple observer methods.


For the interested, the test is 
org.jboss.jsr299.tck.tests.extensions.processBean.ProcessSessionBeanTest.testProcessSessionBeanEvent


-David

Re: Exception handling idea

[David Blevins]

On May 24, 2011, at 11:58 PM, Mark Struberg wrote:

> +1 how to start?

We should try to get a list of the @SpecAssertions from the various 'broken' 
tests.  A little 'find|grep|sort|uniq' action, perhaps.  Then see if we can't 
squeeze out some exception classes from them.  Then start plumbing them into 
the code.

It's getting late here so if someone wants to compile that list and post it, 
cool :)  Otherwise I'll get to it tomorrow.

> We have lots of internal tests, but I think the passivation example is really 
> overly strict in the spec (as you said on the CDI list). I'm not really 
> convinced by petes mail. Need to re-read his mail ot fully understand what he 
> meant.

I had a reply, but it hit moderation as I wasn't subscribed.  I though it was a 
tad negative so I just deleted it and sent a subscription request.  Do you know 
if that list is open?

-David

> --- On Wed, 5/25/11, David Blevins  wrote:
> 
>> From: David Blevins 
>> Subject: Exception handling idea
>> To: dev@openwebbeans.apache.org
>> Date: Wednesday, May 25, 2011, 6:43 AM
>> Grinding through some of the "broken"
>> packages of the CDI TCK and many of them are passing... some
>> of them for the wrong reason.  Any deployment issue
>> counts as a win with those tests, so it's incredibly
>> difficult to verify if the test is passing for the right
>> reason.
>> 
>> One thing that is obvious is that if we had some more
>> specific types to line up with some of the more tested
>> sections of the TCK, we could probably incorporate that into
>> our test runners to check if the tests pass for the right
>> reason.  So say a PassivationCapableException subclass
>> of WebBeansConfigurationException for the various tests that
>> check for passivation capability (section 6.6.4).
>> 
>> A slightly more interesting spin would be to annotate those
>> exceptions with the related section of the spec. 
>> Basically something like the @SpecAssertion(section =
>> "6.6.4", id = "bde") that the TCK uses.  Seems like we
>> could use this to line the exception up with the test
>> assertion and give it the thumbs up or thumbs down in our
>> harness.  Users could also use it to figure out what
>> part of the spec they need to read up on.
>> 
>> 
>> -David
>> 
>> 
> 

Exception handling idea

[David Blevins]

Grinding through some of the "broken" packages of the CDI TCK and many of them 
are passing... some of them for the wrong reason.  Any deployment issue counts 
as a win with those tests, so it's incredibly difficult to verify if the test 
is passing for the right reason.

One thing that is obvious is that if we had some more specific types to line up 
with some of the more tested sections of the TCK, we could probably incorporate 
that into our test runners to check if the tests pass for the right reason.  So 
say a PassivationCapableException subclass of WebBeansConfigurationException 
for the various tests that check for passivation capability (section 6.6.4).

A slightly more interesting spin would be to annotate those exceptions with the 
related section of the spec.  Basically something like the 
@SpecAssertion(section = "6.6.4", id = "bde") that the TCK uses.  Seems like we 
could use this to line the exception up with the test assertion and give it the 
thumbs up or thumbs down in our harness.  Users could also use it to figure out 
what part of the spec they need to read up on.


-David

[jira] [Commented] (OWB-573) Invalid checking of Interceptor serialization capabilities

[David Blevins (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038407#comment-13038407
 ] 

David Blevins commented on OWB-573:
---

That might be better.  Will try that out tomorrow.

> Invalid checking of Interceptor serialization capabilities
> --
>
> Key: OWB-573
> URL: https://issues.apache.org/jira/browse/OWB-573
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Interceptor and Decorators
>Reporter: David Blevins
>    Assignee: David Blevins
> Fix For: 1.2.0
>
>
> DefinitionUtil invalidly checks the fields of Interceptor classes to see if 
> they are serializable.  This isn't a requirement of the Interceptor 
> specification.  As well in pure Java serialization terms, there is no 
> requirement that the class types of fields implement Serializable, so a field 
> of say java.lang.Object is OK.  The requirement is that at serialization time 
> that field must point to a serializable instance or be null.  This obviously 
> can only be checked by inspecting instances of a class and cannot be checked 
> statically against the class itself.

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

[jira] [Created] (OWB-573) Invalid checking of Interceptor serialization capabilities

[David Blevins (JIRA)]

Invalid checking of Interceptor serialization capabilities
--

 Key: OWB-573
 URL: https://issues.apache.org/jira/browse/OWB-573
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Interceptor and Decorators
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 1.2.0


DefinitionUtil invalidly checks the fields of Interceptor classes to see if 
they are serializable.  This isn't a requirement of the Interceptor 
specification.  As well in pure Java serialization terms, there is no 
requirement that the class types of fields implement Serializable, so a field 
of say java.lang.Object is OK.  The requirement is that at serialization time 
that field must point to a serializable instance or be null.  This obviously 
can only be checked by inspecting instances of a class and cannot be checked 
statically against the class itself.

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

Re: Classpath Scanner proposal

[David Blevins]

On Mar 25, 2011, at 12:27 AM, Gurkan Erdogdu wrote:

> Why using the static methods are bad thing? I think, one problem maybe using 
> static fields in static methods can be problem  in hierarchical class 
> loaders. 
> Also if using static fields in class, not so much testable. But from the 
> perspective of Utility Classi I see no problem.

Right.  I actually prefer static methods when 100% of the required data can be 
passed in as params.

A limited amount of static "storage" can be ok too.  But heavy use of volatile 
data stored statically will get you leaks and synchronizing it will get you 
bottlenecks.  That's the part I try and stay away from.


-David


> ________
> From: David Blevins 
> To: dev@openwebbeans.apache.org
> Sent: Fri, March 25, 2011 7:54:28 AM
> Subject: Re: Classpath Scanner proposal
> 
> 
> On Mar 24, 2011, at 12:22 PM, Mark Struberg wrote:
> 
>> I'd like to cook up something for a JSR, but need some more time. 
>> David wrote xbean-finder and we could easily move this to commons or extract 
>> it 
>> into a single jar in geronimo.
> 
> It's already a single jar with just the org.apache.xbean.finder code.  But 
> I'm 
> open to whatever.
> 
>> But first things first: will start with the owb-1.1.0 release now ;)
> 
> Thanks for that btw!  I really like all the recent work.  And I meant to say 
> "thanks" for cloning that static related jira.  Perfect use of that feature.
> 
> On that static note, I was amazed at how much static code we still had after 
> eliminating 95% of what showed up in the tests in the build and then in the 
> standalone part of the TCK.  I didn't get around to the Web Profile part of 
> the 
> TCK.  But it seems either we need to write some more tests or delete some 
> more 
> code :)  I'm sure it will be some of both.
> 
> 
> -David
> 
> 
>> --- On Thu, 3/24/11, Sven Linstaedt  wrote:
>> 
>>> From: Sven Linstaedt 
>>> Subject: Re: Classpath Scanner proposal
>>> To: "dev@openwebbeans.apache.org" 
>>> Date: Thursday, March 24, 2011, 7:09 PM
>>> Hi Mark,
>>> 
>>> that sounds absolutely reasonable. I am just interested in
>>> the state of progress. Afaik xbean-finder is not a project,
>>> but rather a single class of some Apache project, is not it?
>>> So there are no plans any more to introduce this kind of
>>> service via JSR?
>>> 
>>> Regards out of the train
>>> 
>>> Sven
>>> 
>>> -- sent by phone
>>> 
>>> Am 21.03.2011 um 18:42 schrieb Mark Struberg :
>>> 
>>>> Hi Sven!
>>>> 
>>>> Yea, I'm aiming for something like that. The major
>>> benefit would be that we do not trash our ClassLoader with
>>> all the reflection stuff only needed for the initial class
>>> scanning. This is currently eating up lots of PermGenSpace.
>>> 
>>>> 
>>>> Btw, the reflections project is based on the original
>>> scannotation code from Bill Burke, so we aint that far away
>>> ;)
>>>> We are also looking for probably moving it over to
>>> xbean-finder which David wrote for OpenEJB and is now also
>>> being used in geronimo and a few other apache projects. But
>>> we'll do that after 1.1.0 ;)
>>>> 
>>>> txs and LieGrue,
>>>> strub
>>>> 
>>>> --- On Mon, 3/21/11, Sven Linstaedt 
>>> wrote:
>>>> 
>>>>> From: Sven Linstaedt 
>>>>> Subject: Re: Classpath Scanner proposal
>>>>> To: dev@openwebbeans.apache.org
>>>>> Date: Monday, March 21, 2011, 5:35 PM
>>>>> Another interesting use case would
>>>>> look like using some kind of
>>>>> pre-generated scanning information created during
>>>>> build-time.
>>>>> 
>>>>> Artifacts are in general considered final after
>>> creation,
>>>>> so scans done at
>>>>> runtime will return the same result. This result
>>> could be
>>>>> generated during
>>>>> build-time and inlined into the artifact in a
>>> serialized
>>>>> form, which in turn
>>>>> in used during runtime to further speed up scan
>>> jobs. [1]
>>>>> is doing something
>>>>> similar by providing a maven plugin.
>>>>> 
>>>>> br, Sven
>>>>> 
>>>>> 
>>>>> [1] http:/

Re: [VOTE] release Apache OpenWebBeans 1.1.0

[David Blevins]

+1

On Mar 24, 2011, at 5:09 PM, Mark Struberg 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: Classpath Scanner proposal

[David Blevins]

On Mar 24, 2011, at 12:22 PM, Mark Struberg wrote:

> I'd like to cook up something for a JSR, but need some more time. 
> David wrote xbean-finder and we could easily move this to commons or extract 
> it into a single jar in geronimo.

It's already a single jar with just the org.apache.xbean.finder code.  But I'm 
open to whatever.

> But first things first: will start with the owb-1.1.0 release now ;)

Thanks for that btw!  I really like all the recent work.  And I meant to say 
"thanks" for cloning that static related jira.  Perfect use of that feature.

On that static note, I was amazed at how much static code we still had after 
eliminating 95% of what showed up in the tests in the build and then in the 
standalone part of the TCK.  I didn't get around to the Web Profile part of the 
TCK.  But it seems either we need to write some more tests or delete some more 
code :)  I'm sure it will be some of both.


-David


> --- On Thu, 3/24/11, Sven Linstaedt  wrote:
> 
>> From: Sven Linstaedt 
>> Subject: Re: Classpath Scanner proposal
>> To: "dev@openwebbeans.apache.org" 
>> Date: Thursday, March 24, 2011, 7:09 PM
>> Hi Mark,
>> 
>> that sounds absolutely reasonable. I am just interested in
>> the state of progress. Afaik xbean-finder is not a project,
>> but rather a single class of some Apache project, is not it?
>> So there are no plans any more to introduce this kind of
>> service via JSR?
>> 
>> Regards out of the train
>> 
>> Sven
>> 
>> -- sent by phone
>> 
>> Am 21.03.2011 um 18:42 schrieb Mark Struberg :
>> 
>>> Hi Sven!
>>> 
>>> Yea, I'm aiming for something like that. The major
>> benefit would be that we do not trash our ClassLoader with
>> all the reflection stuff only needed for the initial class
>> scanning. This is currently eating up lots of PermGenSpace.
>> 
>>> 
>>> Btw, the reflections project is based on the original
>> scannotation code from Bill Burke, so we aint that far away
>> ;)
>>> We are also looking for probably moving it over to
>> xbean-finder which David wrote for OpenEJB and is now also
>> being used in geronimo and a few other apache projects. But
>> we'll do that after 1.1.0 ;)
>>> 
>>> txs and LieGrue,
>>> strub
>>> 
>>> --- On Mon, 3/21/11, Sven Linstaedt 
>> wrote:
>>> 
 From: Sven Linstaedt 
 Subject: Re: Classpath Scanner proposal
 To: dev@openwebbeans.apache.org
 Date: Monday, March 21, 2011, 5:35 PM
 Another interesting use case would
 look like using some kind of
 pre-generated scanning information created during
 build-time.
 
 Artifacts are in general considered final after
>> creation,
 so scans done at
 runtime will return the same result. This result
>> could be
 generated during
 build-time and inlined into the artifact in a
>> serialized
 form, which in turn
 in used during runtime to further speed up scan
>> jobs. [1]
 is doing something
 similar by providing a maven plugin.
 
 br, Sven
 
 
 [1] http://code.google.com/p/reflections/
 
 
 2011/2/27 Mark Struberg 
 
> I think it should be enough if the
>> classscanner
 implementation itself
> shades any such 3rd party jar into a inner
 dependency.
> My main focus currently is to design the API
>> flexible
 enough to allow all
> necessary use cases to work.
> 
> LieGrue,
> strub
> 
> --- On Sun, 2/27/11, Jan-Kees van Andel 
 wrote:
> 
>> From: Jan-Kees van Andel 
>> Subject: Re: Classpath Scanner proposal
>> To: dev@openwebbeans.apache.org,
 d...@geronimo.apache.org
>> Date: Sunday, February 27, 2011, 1:35 PM
>> +1, although I think Jar hell is a
>> real issue. Think about libraries like
>> cglib, asm or commons-*** and the pain
>> they
 sometimes
>> cause.
>> 
>> But we can easily work around it, for
>> example by
 packaging
>> all
>> using-frameworks as uber-jars and
>> renaming
>> the "org.apache.commons.classscan"
>> packages to
 something
>> like
 "org.apache.myfaces.org.apache.commons.classscan"
>> and
 
>> "org.apache.webbeans.org.apache.commons.classscan".
>> This way we prevent
>> any future versioning issues that
>> libraries like
 cglib and
>> asm currently
>> have.
>> 
>> Regards,
>> Jan-Kees
>> 
>> 
>> 2011/2/27 Mark Struberg 
>> 
>>> Hi Jan-Kees!
>>> 
>>> Txs for this info!
>>> 
>>> Of course, I think the downside of
>> getting
 another
>> dependency to myfaces
>>> would highly be outvalued by the
>> benefit
 we'd gain
>> from it :)
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> --- On Sun, 2/27/11, Jan-Kees van
>> Andel
 
>> wrote:
>>> 
 From: Jan-Kees van Andel 
 Subject: Re: Classpath Scanner
 proposal
 To: dev@openwebbeans.apache.org,
>> d...@geronimo.apache.org,
>> "Mark
>>> Struberg" 
 Da

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

[David Blevins]

In OpenEJB we have OWB integrated 100% of the time.  Primarily so that 
scenarios like this don't occur.  I.e. "my app worked fine and then I turned on 
CDI and all these unrelated things break."

Shawn, I'm hammering on that code now on the OpenEJB end.  I've checked in a 
temporary work around there, which should get us by for a while.

-David

On Mar 20, 2011, at 9:36 PM, Joseph Bergmark wrote:

> 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  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.AbstractInjectionTargetBean,
>>> java.lang.Class, boolean) line: 991
>>> 
>> org.apache.webbeans.config.DefinitionUtil.defineInternalInjectedFieldsRecursively(org.apache.webbeans.component.AbstractInjectionTargetBean,
>>> java.lang.Class) line: 968
>>> 
>> org.apache.webbeans.util.WebBeansAnnotatedTypeUtil.defineInjectedFields(org.apache.webbeans.component.AbstractInjectionTargetBean,
>>> javax.enterprise.inject.spi.AnnotatedType) line: 384
>>> 
>> org.apache.webbeans.component.creation.AnnotatedTypeBeanCreatorImpl(org.apache.webbeans.component.creation.AbstractInjectedTargetBeanCreator).defineInjectedFields()
>>> line: 80
>>> 
>> org.apache.webbeans.util.WebBeansAnnotatedTypeUtil.getJavaEeComponentInstanceInjectionPoints(org.apache.webbeans.config.WebBeansContext,
>>> javax.enterprise.inject.spi.AnnotatedType) 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
>> 

Snapshots

[David Blevins]

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: heavy performance decrease in 1.1.0-SNAPSHOT

[David Blevins]

Spent a few hours poking at performance numbers with Grinder and a simple test 
case based on Marks changes to the interceptor pref test.  Seeing 2-3x increase 
in performance.

Mark, I'm guessing your performance decrease is thread related.  Too many.  Try 
dramatically decreasing the threads allowed to execute at once.  Seems the 
magical number for me was 8 (2-4 per core).  Compiled some stats testing 
behavior against 1.0.x and 1.1.x at 1, 2, 4, 8, 12 ,25 ,50, 100, 500, and 200 
threads: http://people.apache.org/~dblevins/owb-perf/index.html


-David


On Feb 24, 2011, at 3:38 PM, David Blevins wrote:

> Hope attachments work
> 
> 
> 
> On Feb 24, 2011, at 1:53 PM, Mark Struberg wrote:
> 
>> oh that looks really neat. 
>> Will check it out.
>> 
>> LieGrue,
>> strub
>> 
>> --- On Thu, 2/24/11, David Blevins  wrote:
>> 
>>> From: David Blevins 
>>> Subject: Re: heavy performance decrease in 1.1.0-SNAPSHOT
>>> To: dev@openwebbeans.apache.org
>>> Date: Thursday, February 24, 2011, 9:47 PM
>>> 
>>> On Feb 24, 2011, at 1:00 PM, Mark Struberg wrote:
>>> 
>>>> Will do a few parallel unit tests tonight.
>>> 
>>> Side note, I like this tool for parallel execution stats. 
>>> 
>>>  http://grinder.sourceforge.net
>>> 
>>> There docs don't have any screenshots, but basically it
>>> looks like this:
>>> 
>>>  http://people.apache.org/~dblevins/ejbd-client-performance.png
>>> 
>>> You cook up your own test as you normally would, then it
>>> will execute it in parallel however you like and take
>>> samples of each "client" thread and process and spit out
>>> updated stats.
>>> 
>>> 
>>> -David
>>> 
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>> --- On Thu, 2/24/11, David Blevins 
>>> wrote:
>>>> 
>>>>> From: David Blevins 
>>>>> Subject: Re: heavy performance decrease in
>>> 1.1.0-SNAPSHOT
>>>>> To: dev@openwebbeans.apache.org
>>>>> Date: Thursday, February 24, 2011, 6:02 PM
>>>>> 
>>>>> On Feb 24, 2011, at 9:10 AM, Mark Struberg wrote:
>>>>> 
>>>>>> oh yes, and I experience some 'stuttering'.
>>> Means the
>>>>> log scrolls, then it freezes for a second, logs
>>> again,
>>>>> freezes, etc...
>>>>> 
>>>>> You mean log as in log
>>> files?   Definitely
>>>>> disable logging when doing any performance testing
>>> or you're
>>>>> really just measuring your disk.  Improved
>>> logging
>>>>> could easily explain that sharp decrease.
>>>>> 
>>>>> 
>>>>> -David
>>>>> 
>>>>> 
>>>>>> 
>>>>>> --- On Thu, 2/24/11, David Blevins 
>>>>> wrote:
>>>>>> 
>>>>>>> From: David Blevins 
>>>>>>> Subject: Re: heavy performance decrease
>>> in
>>>>> 1.1.0-SNAPSHOT
>>>>>>> To: dev@openwebbeans.apache.org
>>>>>>> Date: Thursday, February 24, 2011, 4:50
>>> PM
>>>>>>> 
>>>>>>> On Feb 24, 2011, at 8:32 AM, Mark Struberg
>>> wrote:
>>>>>>> 
>>>>>>>> hi folks!
>>>>>>>> 
>>>>>>>> Today I did run a few jmeter tests and
>>> it
>>>>> seems that
>>>>>>> we have some serious bottle neck in our
>>> code
>>>>> currently. The
>>>>>>> app just doesn't really scale well anymore
>>> and
>>>>> performance
>>>>>>> is down to 20% compared to 1.0.0 ...
>>>>>>> 
>>>>>>> What aspects were you measuring and how?
>>>>>>> 
>>>>>>> 
>>>>>>> -David
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 
> 

Re: heavy performance decrease in 1.1.0-SNAPSHOT

[David Blevins]

Hope attachments work



On Feb 24, 2011, at 1:53 PM, Mark Struberg wrote:

> oh that looks really neat. 
> Will check it out.
> 
> LieGrue,
> strub
> 
> --- On Thu, 2/24/11, David Blevins  wrote:
> 
>> From: David Blevins 
>> Subject: Re: heavy performance decrease in 1.1.0-SNAPSHOT
>> To: dev@openwebbeans.apache.org
>> Date: Thursday, February 24, 2011, 9:47 PM
>> 
>> On Feb 24, 2011, at 1:00 PM, Mark Struberg wrote:
>> 
>>> Will do a few parallel unit tests tonight.
>> 
>> Side note, I like this tool for parallel execution stats. 
>> 
>>   http://grinder.sourceforge.net
>> 
>> There docs don't have any screenshots, but basically it
>> looks like this:
>> 
>>   http://people.apache.org/~dblevins/ejbd-client-performance.png
>> 
>> You cook up your own test as you normally would, then it
>> will execute it in parallel however you like and take
>> samples of each "client" thread and process and spit out
>> updated stats.
>> 
>> 
>> -David
>> 
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> --- On Thu, 2/24/11, David Blevins 
>> wrote:
>>> 
>>>> From: David Blevins 
>>>> Subject: Re: heavy performance decrease in
>> 1.1.0-SNAPSHOT
>>>> To: dev@openwebbeans.apache.org
>>>> Date: Thursday, February 24, 2011, 6:02 PM
>>>> 
>>>> On Feb 24, 2011, at 9:10 AM, Mark Struberg wrote:
>>>> 
>>>>> oh yes, and I experience some 'stuttering'.
>> Means the
>>>> log scrolls, then it freezes for a second, logs
>> again,
>>>> freezes, etc...
>>>> 
>>>> You mean log as in log
>> files?   Definitely
>>>> disable logging when doing any performance testing
>> or you're
>>>> really just measuring your disk.  Improved
>> logging
>>>> could easily explain that sharp decrease.
>>>> 
>>>> 
>>>> -David
>>>> 
>>>> 
>>>>> 
>>>>> --- On Thu, 2/24/11, David Blevins 
>>>> wrote:
>>>>> 
>>>>>> From: David Blevins 
>>>>>> Subject: Re: heavy performance decrease
>> in
>>>> 1.1.0-SNAPSHOT
>>>>>> To: dev@openwebbeans.apache.org
>>>>>> Date: Thursday, February 24, 2011, 4:50
>> PM
>>>>>> 
>>>>>> On Feb 24, 2011, at 8:32 AM, Mark Struberg
>> wrote:
>>>>>> 
>>>>>>> hi folks!
>>>>>>> 
>>>>>>> Today I did run a few jmeter tests and
>> it
>>>> seems that
>>>>>> we have some serious bottle neck in our
>> code
>>>> currently. The
>>>>>> app just doesn't really scale well anymore
>> and
>>>> performance
>>>>>> is down to 20% compared to 1.0.0 ...
>>>>>> 
>>>>>> What aspects were you measuring and how?
>>>>>> 
>>>>>> 
>>>>>> -David
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> 

Re: heavy performance decrease in 1.1.0-SNAPSHOT

[David Blevins]

On Feb 24, 2011, at 1:00 PM, Mark Struberg wrote:

> Will do a few parallel unit tests tonight.

Side note, I like this tool for parallel execution stats. 

  http://grinder.sourceforge.net

There docs don't have any screenshots, but basically it looks like this:

  http://people.apache.org/~dblevins/ejbd-client-performance.png

You cook up your own test as you normally would, then it will execute it in 
parallel however you like and take samples of each "client" thread and process 
and spit out updated stats.


-David

> 
> LieGrue,
> strub
> 
> --- On Thu, 2/24/11, David Blevins  wrote:
> 
>> From: David Blevins 
>> Subject: Re: heavy performance decrease in 1.1.0-SNAPSHOT
>> To: dev@openwebbeans.apache.org
>> Date: Thursday, February 24, 2011, 6:02 PM
>> 
>> On Feb 24, 2011, at 9:10 AM, Mark Struberg wrote:
>> 
>>> oh yes, and I experience some 'stuttering'. Means the
>> log scrolls, then it freezes for a second, logs again,
>> freezes, etc...
>> 
>> You mean log as in log files?   Definitely
>> disable logging when doing any performance testing or you're
>> really just measuring your disk.  Improved logging
>> could easily explain that sharp decrease.
>> 
>> 
>> -David
>> 
>> 
>>> 
>>> --- On Thu, 2/24/11, David Blevins 
>> wrote:
>>> 
>>>> From: David Blevins 
>>>> Subject: Re: heavy performance decrease in
>> 1.1.0-SNAPSHOT
>>>> To: dev@openwebbeans.apache.org
>>>> Date: Thursday, February 24, 2011, 4:50 PM
>>>> 
>>>> On Feb 24, 2011, at 8:32 AM, Mark Struberg wrote:
>>>> 
>>>>> hi folks!
>>>>> 
>>>>> Today I did run a few jmeter tests and it
>> seems that
>>>> we have some serious bottle neck in our code
>> currently. The
>>>> app just doesn't really scale well anymore and
>> performance
>>>> is down to 20% compared to 1.0.0 ...
>>>> 
>>>> What aspects were you measuring and how?
>>>> 
>>>> 
>>>> -David
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> 

Re: heavy performance decrease in 1.1.0-SNAPSHOT

[David Blevins]

On Feb 24, 2011, at 1:00 PM, Mark Struberg wrote:

> nah, I also redirected it to a file and the output is not that extreme. I 
> work with INFO level and the log output is the same as in 1.0.0.
> This cannot explain that owb-1.0.0 is five times faster...

Down to 20%?  I had misread it as down *by* 20%.

Grab a 15 day trial of YourKit and do some profiling.  With a gap that big 
there should be easy to spot.


-David


> 
> Will do a few parallel unit tests tonight.
> 
> LieGrue,
> strub
> 
> --- On Thu, 2/24/11, David Blevins  wrote:
> 
>> From: David Blevins 
>> Subject: Re: heavy performance decrease in 1.1.0-SNAPSHOT
>> To: dev@openwebbeans.apache.org
>> Date: Thursday, February 24, 2011, 6:02 PM
>> 
>> On Feb 24, 2011, at 9:10 AM, Mark Struberg wrote:
>> 
>>> oh yes, and I experience some 'stuttering'. Means the
>> log scrolls, then it freezes for a second, logs again,
>> freezes, etc...
>> 
>> You mean log as in log files?   Definitely
>> disable logging when doing any performance testing or you're
>> really just measuring your disk.  Improved logging
>> could easily explain that sharp decrease.
>> 
>> 
>> -David
>> 
>> 
>>> 
>>> --- On Thu, 2/24/11, David Blevins 
>> wrote:
>>> 
>>>> From: David Blevins 
>>>> Subject: Re: heavy performance decrease in
>> 1.1.0-SNAPSHOT
>>>> To: dev@openwebbeans.apache.org
>>>> Date: Thursday, February 24, 2011, 4:50 PM
>>>> 
>>>> On Feb 24, 2011, at 8:32 AM, Mark Struberg wrote:
>>>> 
>>>>> hi folks!
>>>>> 
>>>>> Today I did run a few jmeter tests and it
>> seems that
>>>> we have some serious bottle neck in our code
>> currently. The
>>>> app just doesn't really scale well anymore and
>> performance
>>>> is down to 20% compared to 1.0.0 ...
>>>> 
>>>> What aspects were you measuring and how?
>>>> 
>>>> 
>>>> -David
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> 

Re: heavy performance decrease in 1.1.0-SNAPSHOT

[David Blevins]

On Feb 24, 2011, at 9:10 AM, Mark Struberg wrote:

> oh yes, and I experience some 'stuttering'. Means the log scrolls, then it 
> freezes for a second, logs again, freezes, etc...

You mean log as in log files?   Definitely disable logging when doing any 
performance testing or you're really just measuring your disk.  Improved 
logging could easily explain that sharp decrease.


-David


> 
> --- On Thu, 2/24/11, David Blevins  wrote:
> 
>> From: David Blevins 
>> Subject: Re: heavy performance decrease in 1.1.0-SNAPSHOT
>> To: dev@openwebbeans.apache.org
>> Date: Thursday, February 24, 2011, 4:50 PM
>> 
>> On Feb 24, 2011, at 8:32 AM, Mark Struberg wrote:
>> 
>>> hi folks!
>>> 
>>> Today I did run a few jmeter tests and it seems that
>> we have some serious bottle neck in our code currently. The
>> app just doesn't really scale well anymore and performance
>> is down to 20% compared to 1.0.0 ...
>> 
>> What aspects were you measuring and how?
>> 
>> 
>> -David
>> 
>> 
> 
> 
> 
> 

Re: heavy performance decrease in 1.1.0-SNAPSHOT

[David Blevins]

On Feb 24, 2011, at 8:32 AM, Mark Struberg wrote:

> hi folks!
> 
> Today I did run a few jmeter tests and it seems that we have some serious 
> bottle neck in our code currently. The app just doesn't really scale well 
> anymore and performance is down to 20% compared to 1.0.0 ...

What aspects were you measuring and how?


-David

Running TCK in Tomcat

[David Blevins]

Attempting to run the in-Tomcat version of the tck.  Not having any luck.  
Doesn't seem like the expected files are being copied into Tomcat.  Namely, it 
seems to be missing the CDI API jar.

Before I spend much time digging into this, can someone verify that these are 
the correct steps (taken from this email 
http://markmail.org/message/fjvba7dow55dirt7)

--diff--
Index: 
webbeans-tck/src/test/resources/META-INF/openwebbeans/openwebbeans.properties
===
--- 
webbeans-tck/src/test/resources/META-INF/openwebbeans/openwebbeans.properties   
(revision 1063398)
+++ 
webbeans-tck/src/test/resources/META-INF/openwebbeans/openwebbeans.properties   
(working copy)
@@ -36,7 +36,7 @@
 
org.apache.webbeans.spi.ScannerService=org.apache.webbeans.test.tck.mock.TCKMetaDataDiscoveryImpl
 
 #Used for Standalone
-org.apache.webbeans.spi.deployer.useEjbMetaDataDiscoveryService=true
+org.apache.webbeans.spi.deployer.useEjbMetaDataDiscoveryService=false
 
 #Used for WebProfile TCK
 #org.apache.webbeans.spi.deployer.useEjbMetaDataDiscoveryService=false
\ No newline at end of file
Index: webbeans-tck/src/test/resources/META-INF/jboss-test-harness.properties
===
--- webbeans-tck/src/test/resources/META-INF/jboss-test-harness.properties  
(revision 1063398)
+++ webbeans-tck/src/test/resources/META-INF/jboss-test-harness.properties  
(working copy)
@@ -22,11 +22,11 @@
 
org.jboss.testharness.spi.Containers=org.apache.webbeans.test.tck.ContainersImpl
 org.jboss.jsr299.tck.spi.EL=org.apache.webbeans.test.tck.ELImpl
 
-org.jboss.testharness.standalone=true
+org.jboss.testharness.standalone=false
 #jboss-as.dir=/tmp
 #jboss.force.restart=false
 org.jboss.testharness.libraryDirectory=target/dependency/lib
-org.jboss.testharness.runIntegrationTests=false
+org.jboss.testharness.runIntegrationTests=true
 
 
org.jboss.testharness.api.TestLauncher=org.jboss.testharness.impl.runner.servlet.ServletTestLauncher
 
Index: webbeans-tck/pom.xml
===
--- webbeans-tck/pom.xml(revision 1063398)
+++ webbeans-tck/pom.xml(working copy)
@@ -347,7 +347,7 @@
 maven-surefire-plugin
 
 
-
standalone-suite.xml
+
webprofile-suite.xml
 
 
 
--diff--


Then in webbeans-tck I run maven like so:

 mvn install -Ptck -Dtomcat.home=/Users/dblevins/apache-tomcat-6.0.20/



-David

Re: Possible static elimination

[David Blevins]

On Jan 20, 2011, at 10:40 AM, Mark Struberg wrote:

> Btw,...
> 
> 
> ... a biiig thanks for your work on this topic! Really great stuff!

No problem.  It's been fun.

> And also to djencks for the integration stuff and TCK work!

Thanks to Gurkan as well.  It pretty much started with him, went to me and then 
to David.


Thanks for the help getting the standalone TCK running.  Our regular build was 
down to about 11 static calls per test with a total of about 4000~.  With the 
TCK enabled I have some new targets:

  OWB-503 status: 524 code uses
  Total of 7756 static synchronized accesses and 8941 hashed calls in 898 tests
  Average of 8 static synchronized accesses and 9 hashed calls per test
  
  mingus:~/work/jcdi/openwebbeans 05:17:32 
  $ bash usage.sh 
 1 org.apache.webbeans.event.EventImpl
 2 org.apache.webbeans.conversation.ConversationImpl
 2 org.apache.webbeans.el.ELContextStore
 4 org.apache.webbeans.intercept.InterceptorComparator
15 org.apache.webbeans.test.tck.ContextsImpl
17 org.apache.webbeans.config.WebBeansContext
17 org.apache.webbeans.el.WebBeansELResolver
44 org.apache.webbeans.ejb.component.OpenEjbBean
47 org.apache.webbeans.xml.XMLUtil
79 org.apache.webbeans.util.AnnotationUtil
86 org.apache.webbeans.container.InjectableBeanManager
   271 org.apache.webbeans.lifecycle.AbstractLifeCycle
   381 org.apache.webbeans.test.mock.MockManager
   384 org.apache.webbeans.test.tck.StandaloneContainersImpl$2
   577 org.apache.webbeans.test.tck.StandaloneContainersImpl
  1024 org.apache.webbeans.xml.WebBeansXMLConfigurator
  2214 org.apache.webbeans.config.EJBWebBeansConfigurator

The above is the build with the standalone TCK enabled (mvn clean install 
-Ptck).

-David