Re: Site migration setup
I think I asked the wrong question. I’d like to understand:
- where the human-edited website source is,
- where the generated source is and what it’s generated from and how
- the process by which this eventually gets to the asf-site branch of the
openwebbeans-site repo.
> On Aug 5, 2021, at 1:26 PM, Romain Manni-Bucau wrote:
>
> Le jeu. 5 août 2021 à 20:54, David Jencks a
> écrit :
>
>> What process updates the content?
>>
>
> We have an asf.yaml but didnt see it used fast enough so pushed directly in
> main branch the html files.
>
>
>
>> Personally I think it’s weird to have a site repo that combines html and
>> markdown with some process that builds the markdown to html.
>>
>
> We dont need the md to html part i think.
>
>
>> Would cloning at depth 1 alleviate your concerns?
>>
>
> Can i push after? Got trouble with that years ago.
This Jenkinsfile script seems to be working great for Aries and Felix with an
Antora build:
stages {
stage('build') {
steps {
sh 'rm -rf build'
// clone the felix-site-pub repo
sh 'git clone --depth 1 --branch asf-staging
https://gitbox.apache.org/repos/asf/felix-site-pub.git build/site'
dir('build/site') {
sh 'git rm -r .'
}
sh 'npm run clean-install'
sh 'npm run build-noclean'
dir('build/site') {
sh 'git add .'
sh 'echo `git commit -m "site build"`'
sh 'git push
https://gitbox.apache.org/repos/asf/felix-site-pub.git asf-staging'
}
}
}
}
What I like about this approach is that the website is built complete each time
from some kind of source and the initial ‘git rm -r’ makes sure there is no
leftover outdated content that is no longer being generated.
>
> If publishing is done by CI what’s the problem with cloning the whole repo?
>>
>
> Does not scale and blocks/slows down too much publishing after some time,
> must stay straight forward IMHO since we dont do it often and should be
> locally reproducable.
I don’t understand. If you clone with depth 1 then you are only fetching the
last version of the site, which is likely to be approximately the same size as
the new version of the site.
AFAICT the only way to get a predictable result is to have a process to build
the entire website from sources, in which case there’s no need to locally clone
the site repo since only CI should be actually updating it.
I might be biased from my Antora experiences.
David Jencks
>
>
>
>> David Jencks
>>
>>> On Aug 5, 2021, at 6:31 AM, Romain Manni-Bucau
>> wrote:
>>>
>>> Hi all,
>>>
>>> AFAIK we migrated our site to
>> https://github.com/apache/openwebbeans-site
>>>
>>> It is ok until we want to publish the content. Until now we were
>> publishing
>>> it to subfolders directly (like meecrowave one) but now it is on git i'm
>>> not sure how to setup the publish-scm or other plugin.
>>> What i'd like to avoid is to clone the full git repo to modify meecrowave
>>> folder and then commit/push it.
>>>
>>> Any idea?
>>>
>>> Side note: worse case we can go back on svn if there is no clean
>> solution,
>>> it does not impact the dev process so the simplest is the best here IMHO.
>>>
>>> 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
>>>
>>
>>
Re: Site migration setup
What process updates the content? Personally I think it’s weird to have a site repo that combines html and markdown with some process that builds the markdown to html. Would cloning at depth 1 alleviate your concerns? If publishing is done by CI what’s the problem with cloning the whole repo? David Jencks > On Aug 5, 2021, at 6:31 AM, Romain Manni-Bucau wrote: > > Hi all, > > AFAIK we migrated our site to https://github.com/apache/openwebbeans-site > > It is ok until we want to publish the content. Until now we were publishing > it to subfolders directly (like meecrowave one) but now it is on git i'm > not sure how to setup the publish-scm or other plugin. > What i'd like to avoid is to clone the full git repo to modify meecrowave > folder and then commit/push it. > > Any idea? > > Side note: worse case we can go back on svn if there is no clean solution, > it does not impact the dev process so the simplest is the best here IMHO. > > 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>
Re: Jakarta EE 9 Support
I’m not sure exactly how it impacts this decision, but IIUC the geronimo cdi spec jar is rather essential for some uses as it has OSGI support whereas IIUC the eclipse/jakarta one doesn’t. Personally I’m afraid I’m totally on Romain’s side so far, AFAICT Gurkan’s proposal will only add difficulty for developers and probably users. Although I haven’t been active here for years I might even vote. thanks David Jencks > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu wrote: > >> >> Tomcat works with branches since years without any issue. >> All projects we tried to use branches we abandoned branches just after >> having done them. >> It is fine if the old branch is no more used but here we know we will >> maintain javax branch more than jakarta one for some time so I think we >> should avoid it while it is not justified or one of the 2 branches (javax) >> is "almost dead". > > Working with branches always happens in all open source projects. And > there are times when it is logical to create the branch. Jakarta EE 9 API > migration is the best time to create such a branch. Eventually, we will > create such a branch in Jakarta EE 10. > > Fact there will be no more javax is useless IMHO, only question we should >> care about is "do we have javax users?" and should we work on javax branch >> enough to care about having 2 duplicate branches. Answer is obviously yes >> and more than jakarta users today, therefore I think for some months (maybe >> a few years) we should stick to javax as our primary branch and ensure the >> alignments and bugfixes can trivially - == without any action from dev - be >> ported. It is what we have today. >> > What could be more natural than maintaining branches (with backporting from > master only if necessary). With Jakarta EE 10, we will eventually create > the branch for supporting the EE 8. Also, for the release versioning, it is > nice to have a 3.x release. The community will notice that 3.x is the > starting point of Jakarta EE support. Will you release 2.x with the > intention of supporting Jakarta EE 9? I am personally not positive on this. > I think, 3.x release will also get more interest even if the functionality > and API stay the same. We can prepare the press release for it. > > Note we shouldn't depend on jakarta/javax api anyway (neither as groupId >> nor as transitive dep so this change must stay a noop for consumers). >> > What is the problem of depending on the official Jakarta EE CDI API? It is > an Apache friendly license. Instead of maintaining the Geronimo CDI API > internally, it is more logical to use Jakarta EE official CDI API and > maintain this API with EE4J community. > > would also appreciate if you do a vote if you can point out the breaking >> changes - except the package renaming - justifying to fork ourself and what >> does not work with current solution, can ease the decision/vote. >> Today using jakarta/EE9 API is quite easy ( >> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt >> ). >> We should absolutely enhance the pom experience though but it is trivial to >> do at maven level - I was envisionning to do it in shade plugin to be more >> precise. >> > I know that there will be no functional change. But, I am also against > shading for jakarta.*. If there will be no change on Jakarta EE 10, will we > continue to shade? What happens when there will be a change in EJB, JMS > etc specifications but no change in CDI in Jakarta EE 10? Also, VOTING is > the natural thing to do for the community decision. If the community would > like to keep it as it is via shading, it is fine. > >> >> To try to rephrase/clarify my questionning today: you ask for jakarta >> support, we already have it in a dev and project efficient way so why >> should we change since I don't hink there is anything new - once again if >> API starts to fully break discussion is different but github doesnt reflect >> that? >> > This is not just for Jakarta EE 9 support. As we know, there will be no API > (functional) change, only package renaming. But, I want to emphasize that > with such turning points, it is so logical to integrate official Jakarta > CDI API into our master (removing the geronimo-cdi), and release our new > 3.x version and let the public know that OWB supports official CDI API > beginning with 3.x release. Yeah, shading is an option for package renaming > but think long term. Also, I am really against the shading. It really > disturbs the users which depend on OWB implementation. For example, > currently Glassfish supports Weld integration but one can also implement > OWB t
Re: svn commit: r1622766 - /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/config/BeansDeployer.java
I didn't look at the context, but your commit comment suggests that perhaps the
previous throw should also be changed to DeploymentException? If not a comment
why the DefinitionException is correct might be appropriate.
sorry I'm too lazy to look into this further myself….
thanks
david jencks
On Sep 5, 2014, at 12:25 PM, strub...@apache.org wrote:
> Author: struberg
> Date: Fri Sep 5 19:25:33 2014
> New Revision: 1622766
>
> URL: http://svn.apache.org/r1622766
> Log:
> DefinitionExceptions during startup need to be treated as DeploymentException
> it seems
>
> at least according to the TCK.
>
> Modified:
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/config/BeansDeployer.java
>
> Modified:
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/config/BeansDeployer.java
> URL:
> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/config/BeansDeployer.java?rev=1622766&r1=1622765&r2=1622766&view=diff
> ==
> ---
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/config/BeansDeployer.java
> (original)
> +++
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/config/BeansDeployer.java
> Fri Sep 5 19:25:33 2014
> @@ -278,6 +278,10 @@ public class BeansDeployer
> {
> throw new DefinitionException(e);
> }
> +catch (DefinitionException de)
> +{
> +throw new DeploymentException(de);
> +}
> catch (Exception e)
> {
> throw ExceptionUtil.throwAsRuntimeException(e);
>
>
Re: heavy cleanup
Quite a while back I set up a project at geronimo specs for the 1.1 spec classes, are there changes in any of the classes? thanks david jencks On Nov 25, 2012, at 11:36 AM, Mark Struberg wrote: > I again found a heavy bug which is caused by things like > > > //X TODO this MUST NOT be public! > public static ThreadLocal>> > dependentInstanceOfProducerMethods = > new ThreadLocal>>(); > > > Such code is pure PITA! > > > I'm really tempted to do a heavy cleanup in 1.2.0 (trunk) and go for CDI-1.1 > directly. The spec is good enough to give a rough direction atm and we really > need to cleanup tons of things! > > LieGrue, > strub
Re: Eclipse/Checkstyle errors
My opinion as a pretty much completely inactive contributor to OWB is that it
would be better to have the test classes follow the same style rules as the
main code, but I'm not prepared to help fix it.
thanks
david jencks
On Sep 15, 2012, at 11:09 AM, Thomas Andraschko wrote:
> I use the same rules as the maven plugin, you must just import the settings.
> The problem is that maven-checkstyle-plugin does not check the test-src but
> eclipse does (per default).
>
> So what do you think? should we fix this errors or should the developers
> exclude test classes?
>
> 2012/9/15 Joseph Bergmark
>
>> I haven't used the checkstyle plugin for Eclipse, so afraid I can't
>> provide much advice here. Its too bad it doesn't appear to follow the
>> same rules as the maven plugin.
>>
>> Sincerely,
>>
>> Joe
>>
>> On Sat, Sep 15, 2012 at 1:15 PM, Thomas Andraschko
>> wrote:
>>> It's only in test-classes because the won't be checked by maven.
>>> For example -> AbstractUnitTest#addExtension
>>>
>>> 2012/9/15 Joseph Bergmark
>>>
>>>> Which test classes are you getting check style errors in? When I
>>>> build on the command line I don't see any check style errors:
>>>>
>>>> [INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
>>>> openwebbeans-web ---
>>>> [INFO]
>>>> [INFO]
>>>>
>>>>
>>>> [INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
>>>> openwebbeans-impl ---
>>>> [INFO]
>>>> [INFO]
>>>>
>>>> etc..
>>>>
>>>> Sincerely,
>>>>
>>>> Joe
>>>>
>>>> On Sat, Sep 15, 2012 at 12:26 PM, Thomas Andraschko
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> we have many checkstyle errors (not warnings) in the test classes.
>>>>> Can i fix them or should i exclude (don't know if possible in Eclipse)
>>>> the
>>>>> test classes from checkstyle?
>>>>> The most errors are "{ should be on a new line" and naming errors of
>>>>> constants and variables.
>>>>>
>>>>> Also i have many eclipse errors that @PostConstruct, @PreDestory,
>>>>> @WebServiceRef etc are not accessible.
>>>>> Can we add this APIs with provided scope or is there any better
>> solution?
>>>>>
>>>>> Regards,
>>>>> Thomas
>>>>
>>
Re: [DISCUSS] implement a hierarchic BeanManager?
This seems like a good idea. I'd only note that geronimo has a single classloader per ear so obviously we don't key per-app-module stuff off the classloader. However, OWB supports plugging in a different "keying" system. You implement a SingletonService and install it with WebBeansFinder.setSingletonService(INSTANCE);. Then you need in the app server infrastructure to notify the singleton service when you enter and leave a context such as web app or ejb module. thanks david jencks On Feb 14, 2012, at 6:16 AM, Joseph Bergmark wrote: > I agree, at the very minimum some way to associate bean managers as > having visibility into each other would allow us to build more complex > relationships. > > In your example below, all 3 wars would have visibility into shared > jars in ear/lib, but have their own unique web-inf/lib jars. This > mostly works now, given that we key things off of the Classloader. If > we share the contexts (which are also looked by up class loader, so > you have to change that) then it pretty much works. > > Where things start to fall apart a bit are ejb-jars in the ear. In > some servers those jars share a single class loader, but they can be > started/stopped individually, which makes it difficult to key things > like BeanManagers & Lifecycles to the class loader that they all > share. We need to be able to start/stop them individually, but still > somehow expose the fact that they have visibility into each others > classes. > > Sincerely, > > Joe > > > On Mon, Feb 13, 2012 at 4:45 PM, Mark Struberg wrote: >> Hi folks! >> >> We discussed abut the implications of EAR deployments for Geronimo and other >> EE containers quite often already. The problematic area is also described in >> CDI-18 and CDI-129 in the EG spec issue tracker. In other words: those are >> not OWB specific issues but rather a lack in the specification itself. >> >> Consider having an EAR with 3 WARs (warA, warB, warC). Each of the >> WebApplications have per JSR-316 recommendation an own WebApp-ClassLoader >> whereas the shared EAR libs haven an own ClassLoader forming the parent of >> the WebApps. >> Beans in the shared EAR libs are visible in the whole application. But beans >> from a WEB-INF/lib/*.jar or WEB-INF/classes of warA are obviously not >> visible to warB and warC. And neither to any shared EAR libs. >> >> Other problems arise if e.g a bean in warB @Specialices a bean of a shared >> EAR lib. In this case the specialiced bean must only get used for warB. The >> same is true for @Alternatives, Interceptors, etc. >> >> Currently most EE containers (Geronimo, JBossAS, Glassfish, ...) only have >> one single BeanManager which manages the whole EAR. But this is obviously >> not enough! >> >> What we need is a BeanManager tree which is in balance with the ClassLoader >> hierarchy. That way all the shared EARs would get scanned with a BeanManager >> which responsibility is only to manage those shared classes. Each >> WebApplication would get an own BeanManager which has the shared BeanManager >> as 'parent'. >> >> Our MetaDataService SPI might be perfectly fine for this stuff already, we >> only need to make sure that we don't scan too much classes. >> For the lookup aspect we'd need to introduce a 'parent-first' lookup with an >> additional 'DisabledBeans' list. This trick is needed to not pickup Beans >> which are not enabled anymore in the webapps (they might have been >> @Specialized by another bean in the WebApp already). >> >> wdyt? >> >> LieGrue, >> strub
Re: [VOTE] drop outdated (and unused) openwebbeans-openejb plugin
+1 drop it david jencks On Dec 27, 2011, at 11:08 AM, Mark Struberg wrote: > Hi! > > I was made aware by David that our openwebbeans-openejb plugin is > > > a.) not needed anymore because the OpenEJB project maintains a much deeper > integration already > b.) It doesn't even compile against the latest trunk anymore, because > DeploymentInfo got removed. > > Thus I hereby ask to drop the openwebbeans-openejb plugin form our SVN repo. > > Anyone using it? > > > > [+1] get rid of it, it is just broken and not used anymore > > [+0] I don't care > > [-1] nope I'm using it and it must remain maintained > > > The VOTE is open for 72h with lazy consensus. > > > here is my > > > +1 for dropping it > > > LieGrue, > strub >
Re: [DISCUSS] CDI-1.1 roadmap
BTW, would it be possible to encourage the cdi expert group to specify the
correct osgi package versions for the spec packages? I think the 1.0 spec
getting 1.0 package versions is pretty easy to agree on, I'd like it if the 1.1
package versions were both semantically correct and specified in the spec
itself.
thanks
david jencks
On Oct 5, 2011, at 1:39 PM, David Jencks wrote:
> I created GERONIMO-6182 and set up a geronimo specs project for the cdi 1.1
> spec by copying the 1.0 spec project.
>
> https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jcdi_1.1_spec
>
> I'll do my best to apply patches attached to the jira promptly.
>
> thanks
> david jencks
>
> On Oct 5, 2011, at 12:46 AM, Mark Struberg wrote:
>
>> Hi folks!
>>
>> While working on OWB-589 yesterday, I realized that we cannot use our old
>> 1.0 TCK for new CDI-1.1 features anymore.
>> While OWB always was more like a CDI-1.1 container than 1.0 ('global'
>> interceptors, no BDA), there are still some changes which are notable.
>>
>> *) CDI-1.1 adds a few annotations, so firstly we need to add those to a new
>> geronimo-specs-jcdi-1.1. Dblevins, Djencks, how do we do this best? Should I
>> just ship patches?
>> *) The CDI-1.1 TCK is now based on arquillian -> we have to change our tck
>> integration
>> *) we can finally remove all the BDA handling stuff with the public static
>> ThreadLocals (at least a few of them). This got removed from the spec
>>
>>
>> From a users perspective CDI-1.1 is pretty much backward compatible. From
>> the TCK perspective, CDI-1.1 removed some unnecessary restrictions, e.g in
>> the Serialization check area.
>>
>> How do we continue with our release planing?
>>
>> There are a few possible options:
>>
>> a.) 1.1.2-SNAPSHOT (as all versions since 1.0.0-alpha1) already contains a
>> few CDI-1.1 parts, so should we just continue?
>>
>> b.) Since Geronimo, TomEE and WebSphere use OWB as CDI-1.0 container, should
>> we now release a 1.1.2 version and create a maintenance branch for it? This
>> would mean that the 1.1.x branch would not get much love from us anymore,
>> and we will focus on 1.2.0-SNAPSHOT
>>
>> c.) Should we just branch 1.1.x now (without a release) and move our trunk
>> to version 1.2.0-SNAPSHOT, then actively maintain both? (That would mean
>> that someone else than I must handle the maintenance branch).
>>
>> LieGrue,
>> strub
>
Re: [DISCUSS] CDI-1.1 roadmap
I created GERONIMO-6182 and set up a geronimo specs project for the cdi 1.1
spec by copying the 1.0 spec project.
https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jcdi_1.1_spec
I'll do my best to apply patches attached to the jira promptly.
thanks
david jencks
On Oct 5, 2011, at 12:46 AM, Mark Struberg wrote:
> Hi folks!
>
> While working on OWB-589 yesterday, I realized that we cannot use our old 1.0
> TCK for new CDI-1.1 features anymore.
> While OWB always was more like a CDI-1.1 container than 1.0 ('global'
> interceptors, no BDA), there are still some changes which are notable.
>
> *) CDI-1.1 adds a few annotations, so firstly we need to add those to a new
> geronimo-specs-jcdi-1.1. Dblevins, Djencks, how do we do this best? Should I
> just ship patches?
> *) The CDI-1.1 TCK is now based on arquillian -> we have to change our tck
> integration
> *) we can finally remove all the BDA handling stuff with the public static
> ThreadLocals (at least a few of them). This got removed from the spec
>
>
> From a users perspective CDI-1.1 is pretty much backward compatible. From the
> TCK perspective, CDI-1.1 removed some unnecessary restrictions, e.g in the
> Serialization check area.
>
> How do we continue with our release planing?
>
> There are a few possible options:
>
> a.) 1.1.2-SNAPSHOT (as all versions since 1.0.0-alpha1) already contains a
> few CDI-1.1 parts, so should we just continue?
>
> b.) Since Geronimo, TomEE and WebSphere use OWB as CDI-1.0 container, should
> we now release a 1.1.2 version and create a maintenance branch for it? This
> would mean that the 1.1.x branch would not get much love from us anymore, and
> we will focus on 1.2.0-SNAPSHOT
>
> c.) Should we just branch 1.1.x now (without a release) and move our trunk to
> version 1.2.0-SNAPSHOT, then actively maintain both? (That would mean that
> someone else than I must handle the maintenance branch).
>
> LieGrue,
> strub
[jira] [Commented] (OWB-582) Support for Java 1.5 (needed for WebSphere 6.1)
[ https://issues.apache.org/jira/browse/OWB-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079218#comment-13079218 ] David Jencks commented on OWB-582: -- This breaks the geronimo integration and requires users to configure the ImplementationLoaderService. In rev 1153739 I changed this to use the default service if none is configured. In rev 1153741 I changed this to only try to create one if there is none in the initial services. > Support for Java 1.5 (needed for WebSphere 6.1) > --- > > Key: OWB-582 > URL: https://issues.apache.org/jira/browse/OWB-582 > Project: OpenWebBeans > Issue Type: Improvement > Components: Core >Affects Versions: 1.1.0 >Reporter: Udo Schnurpfeil >Assignee: Gerhard Petracek > Fix For: 1.1.1 > > Attachments: OWB-582.patch, OWB-582_maven_config.patch, > OWB-582_pluggable_service_loader_and_java5_support.patch > > > I would be nice, if OWB supports Java 1.5, e. g. to run with WebSphere 6.1. > It can be implemented with low effort. > There is one basic dependency to Java 1.6: java.util.ServiceLoader > To solve this problem, I've added a utility class in my local copy and > delegate calls to ServiceLoader to this utility. > The utility class itself calls ServiceLoader, if the class is available (Java > 1.6) or uses com.googlecode.bspi.ServiceLoader (Java 1.5). > So the application needs one new dependency (only in the case of Java 1.5). > I've also changed the maven-compiler-plugin to generate Java 1.5 compatible > byte code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Snapshots
Unless something has changed in the (rather long) time since I looked at this, you don't want to use that option because it doesn't use mvn deploy and doesn't end up with the right metadata. Can you adjust hudson to run mvn clean deploy instead of mvn clean install? This can result in only the first few modules of a broken build getting deployed, but I'm OK with that happening occasionally. thanks david jencks On Jun 22, 2011, at 4:26 PM, Joseph Bergmark wrote: > I set up the Hudson builds for both OpenWebBeans-trunk > and OpenWebBeans_1.0.x. I suspect I could configure it to also configure it > to publish them. I see there is a "Deploy artifacts to Maven repository" > option that takes a repository URL. > > Sincerely, > > Joe > > On Wed, Jun 22, 2011 at 6:02 PM, David Blevins 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 >>>> >>>> >>>> >>>> >>> >>> >>> >> >>
[jira] [Resolved] (OWB-588) PrincipalBean is misspelled
[ https://issues.apache.org/jira/browse/OWB-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks resolved OWB-588. -- Resolution: Fixed rev 1138270 > PrincipalBean is misspelled > --- > > Key: OWB-588 > URL: https://issues.apache.org/jira/browse/OWB-588 > Project: OpenWebBeans > Issue Type: Bug > Components: Enterprise Web Beans >Affects Versions: 1.1.1 >Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.1.1 > > > PrinicipalBean??? > Opening a jira since someone might be using the badly spelled version -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OWB-588) PrincipalBean is misspelled
PrincipalBean is misspelled --- Key: OWB-588 URL: https://issues.apache.org/jira/browse/OWB-588 Project: OpenWebBeans Issue Type: Bug Components: Enterprise Web Beans Affects Versions: 1.1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1.1 PrinicipalBean??? Opening a jira since someone might be using the badly spelled version -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OWB-579) check for non-proxyiable methods should exclude synthetic methods
[ https://issues.apache.org/jira/browse/OWB-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052279#comment-13052279 ] David Jencks commented on OWB-579: -- rev 1137824 fixes two interceptor method checks and a decorator method check. I think this brings the "with aries proxies" code to the same tck conformance as the "without aries proxies" version. > check for non-proxyiable methods should exclude synthetic methods > - > > Key: OWB-579 > URL: https://issues.apache.org/jira/browse/OWB-579 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.1 > Reporter: David Jencks >Assignee: David Jencks > Fix For: 1.1.1 > > > Aries trunk has some weaving code that adds some final synthetic methods to > just about every class. AFAICT javassist can still proxy these classes but > OWB check for proxiablility fails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OWB-585) ProcessSessionBean doesn't deal with generic type quite right (CDITCK-215)
[
https://issues.apache.org/jira/browse/OWB-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048262#comment-13048262
]
David Jencks commented on OWB-585:
--
This has to do with
org.jboss.jsr299.tck.tests.extensions.processBean.ProcessSessionBeanTest
> ProcessSessionBean doesn't deal with generic type quite right (CDITCK-215)
> --
>
> Key: OWB-585
> URL: https://issues.apache.org/jira/browse/OWB-585
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Events
>Affects Versions: 1.1.1
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 1.1.1
>
>
> As discussed in CDITCK-215, there's something odd in ProcessSessionBean:
> ProcessSessionBean extends ProcessManagedBean
> So, a ProcessSessionBean is not a ProcessManagedBean but
> a ProcessManagedBean. So the generic type parameter depends on which
> event type you are considering the event as.
> To solve this I've modified GenericBeanEvent.getBeanClass() to
> public Class getBeanClassFor(Class eventClass);
> where you can pass in the type of the event you are thinking about. The
> implementations are unchanged except for GProcessSessionBean where it's now:
> public Class getBeanClassFor(Class eventClass)
> {
> if (ProcessSessionBean.class.isAssignableFrom(eventClass))
> {
> return getBean().getBeanClass();
> }
> else
> {
> return Object.class;
> }
> }
> I also corrected the type parameter in
> public class ProcessSessionBeanImpl extends ProcessBeanImpl
> implements ProcessSessionBean
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OWB-585) ProcessSessionBean doesn't deal with generic type quite right (CDITCK-215)
[
https://issues.apache.org/jira/browse/OWB-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks resolved OWB-585.
--
Resolution: Fixed
rev 1134736
> ProcessSessionBean doesn't deal with generic type quite right (CDITCK-215)
> --
>
> Key: OWB-585
> URL: https://issues.apache.org/jira/browse/OWB-585
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Events
>Affects Versions: 1.1.1
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 1.1.1
>
>
> As discussed in CDITCK-215, there's something odd in ProcessSessionBean:
> ProcessSessionBean extends ProcessManagedBean
> So, a ProcessSessionBean is not a ProcessManagedBean but
> a ProcessManagedBean. So the generic type parameter depends on which
> event type you are considering the event as.
> To solve this I've modified GenericBeanEvent.getBeanClass() to
> public Class getBeanClassFor(Class eventClass);
> where you can pass in the type of the event you are thinking about. The
> implementations are unchanged except for GProcessSessionBean where it's now:
> public Class getBeanClassFor(Class eventClass)
> {
> if (ProcessSessionBean.class.isAssignableFrom(eventClass))
> {
> return getBean().getBeanClass();
> }
> else
> {
> return Object.class;
> }
> }
> I also corrected the type parameter in
> public class ProcessSessionBeanImpl extends ProcessBeanImpl
> implements ProcessSessionBean
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OWB-585) ProcessSessionBean doesn't deal with generic type quite right (CDITCK-215)
ProcessSessionBean doesn't deal with generic type quite right (CDITCK-215)
--
Key: OWB-585
URL: https://issues.apache.org/jira/browse/OWB-585
Project: OpenWebBeans
Issue Type: Bug
Components: Events
Affects Versions: 1.1.1
Reporter: David Jencks
Assignee: David Jencks
Fix For: 1.1.1
As discussed in CDITCK-215, there's something odd in ProcessSessionBean:
ProcessSessionBean extends ProcessManagedBean
So, a ProcessSessionBean is not a ProcessManagedBean but a
ProcessManagedBean. So the generic type parameter depends on which
event type you are considering the event as.
To solve this I've modified GenericBeanEvent.getBeanClass() to
public Class getBeanClassFor(Class eventClass);
where you can pass in the type of the event you are thinking about. The
implementations are unchanged except for GProcessSessionBean where it's now:
public Class getBeanClassFor(Class eventClass)
{
if (ProcessSessionBean.class.isAssignableFrom(eventClass))
{
return getBean().getBeanClass();
}
else
{
return Object.class;
}
}
I also corrected the type parameter in
public class ProcessSessionBeanImpl extends ProcessBeanImpl
implements ProcessSessionBean
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Observer method resolution
My fix is in rev 1134736. Jira is down at the moment, I'll open an issue for
it when it comes back.
Review/comments very welcome :-)
thanks
david jencks
On Jun 11, 2011, at 9:54 AM, David Jencks wrote:
> I think I have a solution for this... more soon.
>
> david jencks
>
> On Jun 10, 2011, at 2:27 PM, David Blevins wrote:
>
>> 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
I think I have a solution for this... more soon.
david jencks
On Jun 10, 2011, at 2:27 PM, David Blevins wrote:
> 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
>>
>
[jira] [Resolved] (OWB-584) check for declared name consistency for specializes beans is wrong
[
https://issues.apache.org/jira/browse/OWB-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks resolved OWB-584.
--
Resolution: Invalid
Both problems are caused by an error in openejb.
> check for declared name consistency for specializes beans is wrong
> --
>
> Key: OWB-584
> URL: https://issues.apache.org/jira/browse/OWB-584
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Inheritance, Specialization
>Affects Versions: 1.1.1
>Reporter: David Jencks
> Assignee: David Jencks
>
> tck tests org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise
> have 3 out of 7 failures caused by this code from
> WebBeansUtil.configureSpecializations:
> if(comp.getName() != null)
> {
> throw new DefinitionException("@Specialized Class : "
> + specializedClass.getName()
> + " may not explicitly declare a bean name");
> }
> First of all, in the debugger, getName is returning the unqualified class
> name rather than the decapitalized unqualified class name as the spec says.
> (3.1.5, 3.2.5)
> Second, in these tests there is no @Named annotation so we're comparing
> default names, which isn't correct. We should be testing for a @Named
> annotation name. (4.3.1:
> If Y has a name and X declares a name explicitly, using @Named, the container
> automatically detects the problem and treats it as a definition error. )
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OWB-584) check for declared name consistency for specializes beans is wrong
check for declared name consistency for specializes beans is wrong
--
Key: OWB-584
URL: https://issues.apache.org/jira/browse/OWB-584
Project: OpenWebBeans
Issue Type: Bug
Components: Inheritance, Specialization
Affects Versions: 1.1.1
Reporter: David Jencks
Assignee: David Jencks
tck tests org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise have
3 out of 7 failures caused by this code from
WebBeansUtil.configureSpecializations:
if(comp.getName() != null)
{
throw new DefinitionException("@Specialized Class : " +
specializedClass.getName()
+ " may not explicitly declare a bean name");
}
First of all, in the debugger, getName is returning the unqualified class name
rather than the decapitalized unqualified class name as the spec says. (3.1.5,
3.2.5)
Second, in these tests there is no @Named annotation so we're comparing default
names, which isn't correct. We should be testing for a @Named annotation name.
(4.3.1:
If Y has a name and X declares a name explicitly, using @Named, the container
automatically detects the problem and treats it as a definition error. )
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OWB-581) Decorator interface check needs configurable exclusions
[ https://issues.apache.org/jira/browse/OWB-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044628#comment-13044628 ] David Jencks commented on OWB-581: -- The added interface causes tons more problems. I've excluded it whereever I've detected a problem in rev 1132498. I've asked the aries folks if it would be possible to mark this interface synthetic (or, better, remove it entirely) in which case we could just exclude synthetic interfaces here in OWB. No response yet. Not sure what this would do to or for cobertura. > Decorator interface check needs configurable exclusions > --- > > Key: OWB-581 > URL: https://issues.apache.org/jira/browse/OWB-581 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.1 > Reporter: David Jencks >Assignee: David Jencks > Fix For: 1.1.1 > > > Aries proxy weaving code adds an interface to every class and so does > Cobertura for code coverage. This breaks the implemented interface checks > for decorators.Gurkan suggested using the spi package but I don't see a > reasonable way to do that. I've implemented a solution using a configuration > property. If not present, it just excludes Serializable as done now. > There are a couple places where only one method is expected in a OWB object > but weaving may add more. I've fixed these places too to find the desired > method by name. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OWB-579) check for non-proxyiable methods should exclude synthetic methods
[ https://issues.apache.org/jira/browse/OWB-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044626#comment-13044626 ] David Jencks commented on OWB-579: -- I found a lot more instances where synthetic fields and methods were breaking the tck. I've excluded them from consideration in rev 1132497. > check for non-proxyiable methods should exclude synthetic methods > - > > Key: OWB-579 > URL: https://issues.apache.org/jira/browse/OWB-579 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.1 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 1.1.1 > > > Aries trunk has some weaving code that adds some final synthetic methods to > just about every class. AFAICT javassist can still proxy these classes but > OWB check for proxiablility fails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Yet another proxy/weaving problem
I've now found another place where the added WovenProxy interface breaks OpenWebBeans. The lack of response on the aries list to my first post makes me think that perhaps this interface can't be removed. I notice that there's an isSynthetic() method on Class. I'm not sure what this means but I'm wondering if it would be possible to mark this interface synthetic and have the relevant parts of OWB ignore synthetic interfaces rather than explicitly configuring it to ignore this particular interface? thanks david jencks On Jun 2, 2011, at 11:53 PM, David Jencks wrote: > another day another problem > > org.apache.webbeans.exception.WebBeansConfigurationException: Decorator : > Name:null, WebBeans Type:DECORATOR, API > Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object], > Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] > delegate attribute must implement all of the decorator decorated types, but > decorator type interface org.apache.aries.proxy.weaving.WovenProxy is not > assignable from delegate type of interface > org.jboss.jsr299.tck.tests.context.dependent.Interior > > > I believe the story here is that decorator classes must not implement > interfaces that the delegate doesn't implement, but aries is adding the > org.apache.aries.proxy.weaving.WovenProxy to the decorator class. > > OWB is already excluding Serializable and I can modify the code to also > exclude org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests pass but > this is going to involve making the list of ignored interfaces configurable > and may not be acceptable to OWB. > > Is there any way to make the weaving/proxying code not add this interface? I > don't think the jdk proxying code needs to add interfaces > > thanks > david jencks
[jira] [Resolved] (OWB-581) Decorator interface check needs configurable exclusions
[ https://issues.apache.org/jira/browse/OWB-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks resolved OWB-581. -- Resolution: Fixed Fix Version/s: 1.1.1 rev 1131302. This works, if you have a better idea comment or reopen or implement. > Decorator interface check needs configurable exclusions > --- > > Key: OWB-581 > URL: https://issues.apache.org/jira/browse/OWB-581 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.1 >Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.1.1 > > > Aries proxy weaving code adds an interface to every class and so does > Cobertura for code coverage. This breaks the implemented interface checks > for decorators.Gurkan suggested using the spi package but I don't see a > reasonable way to do that. I've implemented a solution using a configuration > property. If not present, it just excludes Serializable as done now. > There are a couple places where only one method is expected in a OWB object > but weaving may add more. I've fixed these places too to find the desired > method by name. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OWB-581) Decorator interface check needs configurable exclusions
Decorator interface check needs configurable exclusions --- Key: OWB-581 URL: https://issues.apache.org/jira/browse/OWB-581 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.1.1 Reporter: David Jencks Assignee: David Jencks Aries proxy weaving code adds an interface to every class and so does Cobertura for code coverage. This breaks the implemented interface checks for decorators.Gurkan suggested using the spi package but I don't see a reasonable way to do that. I've implemented a solution using a configuration property. If not present, it just excludes Serializable as done now. There are a couple places where only one method is expected in a OWB object but weaving may add more. I've fixed these places too to find the desired method by name. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OWB-579) check for non-proxyiable methods should exclude synthetic methods
[ https://issues.apache.org/jira/browse/OWB-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044159#comment-13044159 ] David Jencks commented on OWB-579: -- After some more input from the aries folks I've reimplemented excluding synthetic and bridge methods from the proxyable evaluation, rev 1131301, using the method.isSynthetic() and method.isBridge() methods. > check for non-proxyiable methods should exclude synthetic methods > - > > Key: OWB-579 > URL: https://issues.apache.org/jira/browse/OWB-579 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.1 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 1.1.1 > > > Aries trunk has some weaving code that adds some final synthetic methods to > just about every class. AFAICT javassist can still proxy these classes but > OWB check for proxiablility fails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Yet another proxy/weaving problem
another day another problem org.apache.webbeans.exception.WebBeansConfigurationException: Decorator : Name:null, WebBeans Type:DECORATOR, API Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object], Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] delegate attribute must implement all of the decorator decorated types, but decorator type interface org.apache.aries.proxy.weaving.WovenProxy is not assignable from delegate type of interface org.jboss.jsr299.tck.tests.context.dependent.Interior I believe the story here is that decorator classes must not implement interfaces that the delegate doesn't implement, but aries is adding the org.apache.aries.proxy.weaving.WovenProxy to the decorator class. OWB is already excluding Serializable and I can modify the code to also exclude org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests pass but this is going to involve making the list of ignored interfaces configurable and may not be acceptable to OWB. Is there any way to make the weaving/proxying code not add this interface? I don't think the jdk proxying code needs to add interfaces.... thanks david jencks
[jira] [Commented] (OWB-579) check for non-proxyiable methods should exclude synthetic methods
[ https://issues.apache.org/jira/browse/OWB-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043233#comment-13043233 ] David Jencks commented on OWB-579: -- revert the change in rev 1130915, cf ARIES-668 where I change aries to not mark the methods as final > check for non-proxyiable methods should exclude synthetic methods > - > > Key: OWB-579 > URL: https://issues.apache.org/jira/browse/OWB-579 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.1 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 1.1.1 > > > Aries trunk has some weaving code that adds some final synthetic methods to > just about every class. AFAICT javassist can still proxy these classes but > OWB check for proxiablility fails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OWB-579) check for non-proxyiable methods should exclude synthetic methods
[ https://issues.apache.org/jira/browse/OWB-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043009#comment-13043009 ] David Jencks commented on OWB-579: -- The original user supplied class doesn't have final methods, and AFAICT nether the jdk proxies nor javassist nor openjpa enhancement have any problems with these added synthetic methods. I would like to see a scenario where this (modified) check causes a problem before changing it. > check for non-proxyiable methods should exclude synthetic methods > - > > Key: OWB-579 > URL: https://issues.apache.org/jira/browse/OWB-579 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.1 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 1.1.1 > > > Aries trunk has some weaving code that adds some final synthetic methods to > just about every class. AFAICT javassist can still proxy these classes but > OWB check for proxiablility fails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OWB-579) check for non-proxyiable methods should exclude synthetic methods
[ https://issues.apache.org/jira/browse/OWB-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks resolved OWB-579. -- Resolution: Fixed Fix Version/s: 1.1.1 rev 1130394 also mentions the final methods that can't be proxied. > check for non-proxyiable methods should exclude synthetic methods > - > > Key: OWB-579 > URL: https://issues.apache.org/jira/browse/OWB-579 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.1 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 1.1.1 > > > Aries trunk has some weaving code that adds some final synthetic methods to > just about every class. AFAICT javassist can still proxy these classes but > OWB check for proxiablility fails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OWB-579) check for non-proxyiable methods should exclude synthetic methods
check for non-proxyiable methods should exclude synthetic methods - Key: OWB-579 URL: https://issues.apache.org/jira/browse/OWB-579 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.1.1 Reporter: David Jencks Assignee: David Jencks Aries trunk has some weaving code that adds some final synthetic methods to just about every class. AFAICT javassist can still proxy these classes but OWB check for proxiablility fails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OWB-578) Allow DI for OpenWebBeansConfiguration properties
[ https://issues.apache.org/jira/browse/OWB-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks resolved OWB-578. -- Resolution: Fixed Fix Version/s: 1.1.1 fixed in rev 1129986 > Allow DI for OpenWebBeansConfiguration properties > - > > Key: OWB-578 > URL: https://issues.apache.org/jira/browse/OWB-578 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.1 >Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.1.1 > > > I've again run into an osgi situation where no properties files for OWB > configuration are visible. I think this is going to be a normal situation in > OSGI environments. I'm going to add another constructor to > OpenWebBeansConfiguration and slightly rearrange WebBeansContext so that you > can supply the properties for OpenWebBeansConfiguration along with a map of > pre-constructed services. This won't be used by normal OWB but can be used > by alternate SingletonService implementations. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OWB-578) Allow DI for OpenWebBeansConfiguration properties
Allow DI for OpenWebBeansConfiguration properties - Key: OWB-578 URL: https://issues.apache.org/jira/browse/OWB-578 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.1.1 Reporter: David Jencks Assignee: David Jencks I've again run into an osgi situation where no properties files for OWB configuration are visible. I think this is going to be a normal situation in OSGI environments. I'm going to add another constructor to OpenWebBeansConfiguration and slightly rearrange WebBeansContext so that you can supply the properties for OpenWebBeansConfiguration along with a map of pre-constructed services. This won't be used by normal OWB but can be used by alternate SingletonService implementations. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r1081681 - in /openwebbeans/trunk: webbeans-impl/src/main/java/org/apache/webbeans/corespi/ webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/ webbeans-impl/src/main/res
On Mar 15, 2011, at 12:09 PM, Mark Struberg wrote: > Yes, we should hide this impl from the public somehow. In an EE server I > guess this could be done via OSGi. I think we should investigate checking for sufficient caller permissions in the constructor. > > Anyway, it's actually not more bad than having a public SecurityUtil class > with public static methods of the same signature... > Both are kind of broken, but the Service might at least theoretically get > shielded way better. I agree, I didn't look at what you changed away from. > > Btw imo the whole SecurityManager stuff is broken by design, ever was... dunno about SecurityManager, but I think there's some sense in the Permission based security model and doPrivileged. On the other hand I haven't really tried to do much in an environment where codebase-related security was turned on. thanks david jencks > > LieGrue, > strub > > --- On Tue, 3/15/11, David Jencks wrote: > >> From: David Jencks >> Subject: Re: svn commit: r1081681 - in /openwebbeans/trunk: >> webbeans-impl/src/main/java/org/apache/webbeans/corespi/ >> webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/ >> webbeans-impl/src/main/resources/META-INF/openwebbeans/ >> webbeans-openejb/src/main/... >> To: dev@openwebbeans.apache.org >> Date: Tuesday, March 15, 2011, 6:25 PM >> I'm wondering how this is supposed to >> work. I haven't looked at the code in detail but it >> looks to me like you've introduced a public class with a >> default constructor that anyone with malicious intent can >> instantiate and call all these methods on to do unrestricted >> reflection that the security manager setup was supposed to >> prevent. >> >> Have I misunderstood how this works? >> >> I wonder if having a default constructor that checked for >> reflection privileges would suffice to restrict access to >> this class, and calling it from within a protected >> action. I think we'd still have to be very careful not >> to pass the instance around in such a way as to make it >> accessible from outside owb. >> >> hopefully I've misunderstood... >> >> thanks >> david jencks >> >> On Mar 15, 2011, at 1:27 AM, strub...@apache.org >> wrote: >> >>> Author: struberg >>> Date: Tue Mar 15 08:27:37 2011 >>> New Revision: 1081681 >>> >>> URL: http://svn.apache.org/viewvc?rev=1081681&view=rev >>> Log: >>> OWB-545 introduce ManagedSecurityService >>> >>> Added: >>> >> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/ >>> >> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/ManagedSecurityService.java >>> >> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/SimpleSecurityService.java >>> - copied, changed from r1081676, >> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/SimpleSecurityService.java >>> Removed: >>> >> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/SimpleSecurityService.java >>> Modified: >>> >> openwebbeans/trunk/webbeans-impl/src/main/resources/META-INF/openwebbeans/openwebbeans.properties >>> >> openwebbeans/trunk/webbeans-openejb/src/main/java/org/apache/webbeans/ejb/service/OpenEJBSecurityService.java >>> >> openwebbeans/trunk/webbeans-spi/src/main/java/org/apache/webbeans/spi/SecurityService.java >>> >> openwebbeans/trunk/webbeans-tomcat6/src/main/java/org/apache/webbeans/web/tomcat/TomcatSecurityService.java >>> >> openwebbeans/trunk/webbeans-tomcat7/src/main/java/org/apache/webbeans/web/tomcat/TomcatSecurityService.java >>> >>> Added: >> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/ManagedSecurityService.java >>> URL: >>> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/ManagedSecurityService.java?rev=1081681&view=auto >>> >> == >>> --- >> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/ManagedSecurityService.java >> (added) >>> +++ >> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/ManagedSecurityService.java >> Tue Mar 15 08:27:37 2011 >>> @@ -0,0 +1,329 @@ &g
Re: svn commit: r1081681 - in /openwebbeans/trunk: webbeans-impl/src/main/java/org/apache/webbeans/corespi/ webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/ webbeans-impl/src/main/res
I'm wondering how this is supposed to work. I haven't looked at the code in
detail but it looks to me like you've introduced a public class with a default
constructor that anyone with malicious intent can instantiate and call all
these methods on to do unrestricted reflection that the security manager setup
was supposed to prevent.
Have I misunderstood how this works?
I wonder if having a default constructor that checked for reflection privileges
would suffice to restrict access to this class, and calling it from within a
protected action. I think we'd still have to be very careful not to pass the
instance around in such a way as to make it accessible from outside owb.
hopefully I've misunderstood...
thanks
david jencks
On Mar 15, 2011, at 1:27 AM, strub...@apache.org wrote:
> Author: struberg
> Date: Tue Mar 15 08:27:37 2011
> New Revision: 1081681
>
> URL: http://svn.apache.org/viewvc?rev=1081681&view=rev
> Log:
> OWB-545 introduce ManagedSecurityService
>
> Added:
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/ManagedSecurityService.java
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/SimpleSecurityService.java
> - copied, changed from r1081676,
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/SimpleSecurityService.java
> Removed:
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/SimpleSecurityService.java
> Modified:
>
> openwebbeans/trunk/webbeans-impl/src/main/resources/META-INF/openwebbeans/openwebbeans.properties
>
> openwebbeans/trunk/webbeans-openejb/src/main/java/org/apache/webbeans/ejb/service/OpenEJBSecurityService.java
>
> openwebbeans/trunk/webbeans-spi/src/main/java/org/apache/webbeans/spi/SecurityService.java
>
> openwebbeans/trunk/webbeans-tomcat6/src/main/java/org/apache/webbeans/web/tomcat/TomcatSecurityService.java
>
> openwebbeans/trunk/webbeans-tomcat7/src/main/java/org/apache/webbeans/web/tomcat/TomcatSecurityService.java
>
> Added:
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/ManagedSecurityService.java
> URL:
> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/ManagedSecurityService.java?rev=1081681&view=auto
> ==
> ---
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/ManagedSecurityService.java
> (added)
> +++
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/corespi/security/ManagedSecurityService.java
> Tue Mar 15 08:27:37 2011
> @@ -0,0 +1,329 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements. See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership. The ASF licenses this file
> + * to you under the Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance
> + * with the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> + * software distributed under the License is distributed on an
> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + * KIND, either express or implied. See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
> +package org.apache.webbeans.corespi.security;
> +
> +import org.apache.webbeans.exception.WebBeansException;
> +import org.apache.webbeans.spi.SecurityService;
> +
> +import java.lang.reflect.AccessibleObject;
> +import java.lang.reflect.Constructor;
> +import java.lang.reflect.Field;
> +import java.lang.reflect.Method;
> +import java.security.AccessController;
> +import java.security.Principal;
> +import java.security.PrivilegedAction;
> +import java.security.PrivilegedActionException;
> +import java.security.PrivilegedExceptionAction;
> +import java.util.Properties;
> +
> +/**
> + * This version of the {@link SecurityService} uses the
> java.lang.SecurityManager
> + * to check low level access to the underlying functions via a doPriviliged
> block.
> + */
> +public class ManagedSecurityService implements SecurityService
> +{
> +private static final int METHOD_CLASS_GETDECLAREDCONSTRUCTOR = 0x01;
> +
> +private static final int METHOD_CLASS_GET
Re: TCK working again
Hi Mark,
My thinking on this is that you can use asm to find classes of interest, but to
actually get to the annotations or details about the class you need to load the
class and use normal reflection. I don't think our goal here is really to
rewrite java.lang.reflect but to only look at classes that we need to.
I would like to stay focussed on the goal of determining which classes can be
CDI beans based on annotations, loading those eagerly, and loading the rest of
them lazily. My impression is that a large proportion of the reflection
objects used to examine the class will actually be used by OWB when using the
class, so there isn't much extra overhead for classes that are actually CDI
beans. If we can avoid looking at classes that aren't CDI beans I think we
will have done well enough.
thanks
david jencks
On Mar 5, 2011, at 2:43 AM, Mark Struberg wrote:
> Another question:
>
> we not only need something like
>
> ScannerService#getDeclaredFields(String className);
>
> And of course also a method to get all the annotations from this field.
>
> basically all the reflect stuff in a class would be needed. But without
> filling the classloader with crap which we cannot get rid of later ;)
>
>
> LieGrue,
> strub
>
> --- On Fri, 3/4/11, David Jencks wrote:
>
>> From: David Jencks
>> Subject: Re: TCK working again
>> To: dev@openwebbeans.apache.org
>> Date: Friday, March 4, 2011, 5:41 PM
>> xbean can tell you about the
>> subclasses of classes you found from an annotation.
>> The annotation tells you about Farmer, then since @Observes
>> is inherited you look for subclasses of Farmer and find
>> LazyFarmer.
>>
>> I still don't see any problems as long as completely
>> non-annotation-related pojo beans can be defined lazily on
>> first (dynamic) use.
>>
>> david jencks
>>
>> On Mar 4, 2011, at 4:57 AM, Mark Struberg wrote:
>>
>>> hi!
>>>
>>> I've now fixed the DefinitionUtil#isPurePojoBean and a
>> few other things which means the TCK is now working again.
>>>
>>>
>>> @djencks: I fear we really have to scan all beans. In
>> the official TCK there is a class
>>>
>>> public class LazyFarmer extends Farmer
>>> {
>>> }
>>>
>>> but since Farmer is
>>>
>>> public class Farmer
>>> {
>>>
>>>public void
>> observeEggLaying(@Observes Egg egg)
>>>{
>>> egg.recordVisit(this);
>>>}
>>>
>>> }
>>>
>>> it is also a JSR-299 managed bean and MUST get picked
>> up eagerly :(
>>>
>>> So without the definition in the spec that any CDI
>> bean have to define a proper scope, we just need to suck all
>> the classes :(
>>>
>>> Currently all this class loading consumes a huge
>> amount of PermGenSpace, and here is where xbean could help.
>> If we dont use
>>>
>>> Class#getDeclaredConstructors() / Annotations
>>> Class#getDeclaredMethods() / Annotations
>>> ...
>>>
>>> but instead get this info from XBean, then we do not
>> pollute the ClassLoader and after the scanning, we can just
>> clear the XBean cache again to reduce memory consumption.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>
>>
>
>
>
Re: TCK working again
xbean can tell you about the subclasses of classes you found from an
annotation. The annotation tells you about Farmer, then since @Observes is
inherited you look for subclasses of Farmer and find LazyFarmer.
I still don't see any problems as long as completely non-annotation-related
pojo beans can be defined lazily on first (dynamic) use.
david jencks
On Mar 4, 2011, at 4:57 AM, Mark Struberg wrote:
> hi!
>
> I've now fixed the DefinitionUtil#isPurePojoBean and a few other things which
> means the TCK is now working again.
>
>
> @djencks: I fear we really have to scan all beans. In the official TCK there
> is a class
>
> public class LazyFarmer extends Farmer
> {
> }
>
> but since Farmer is
>
> public class Farmer
> {
>
> public void observeEggLaying(@Observes Egg egg)
> {
> egg.recordVisit(this);
> }
>
> }
>
> it is also a JSR-299 managed bean and MUST get picked up eagerly :(
>
> So without the definition in the spec that any CDI bean have to define a
> proper scope, we just need to suck all the classes :(
>
> Currently all this class loading consumes a huge amount of PermGenSpace, and
> here is where xbean could help. If we dont use
>
> Class#getDeclaredConstructors() / Annotations
> Class#getDeclaredMethods() / Annotations
> ...
>
> but instead get this info from XBean, then we do not pollute the ClassLoader
> and after the scanning, we can just clear the XBean cache again to reduce
> memory consumption.
>
> LieGrue,
> strub
>
>
>
[jira] Updated: (OWB-526) remove usage of java.net.URLs from ScannerService and drop scannotation
[ https://issues.apache.org/jira/browse/OWB-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated OWB-526: - Attachment: OsgiMetaDataScannerService.java.mine This is an xbean-based scanner that only finds classes that have cdi-relevant annotations in them. I'm not sure I got all the relevant cdi annotations, and it doesn't handle meta-annotations, but does show how to use xbean effectively. There's a non-osgi xbean finder class that has the same methods, just a different constructor. > remove usage of java.net.URLs from ScannerService and drop scannotation > --- > > Key: OWB-526 > URL: https://issues.apache.org/jira/browse/OWB-526 > Project: OpenWebBeans > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.0 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.1.0 > > Attachments: OsgiMetaDataScannerService.java.mine > > Original Estimate: 6h > Remaining Estimate: 6h > > Our ScannerService currently returns Set sometimes caused by the > underlying use of scannotation. > Since scannotation is broken anyway (see OWB-524) we should drop scannotation > and switch to url - Strings in the ScannerService SPI interface. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OWB-538) introduce proprietary configuration option to ignore not explicitly marked (via annotation or registered by extension) Dependent beans
[ https://issues.apache.org/jira/browse/OWB-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000586#comment-13000586 ] David Jencks commented on OWB-538: -- Maybe I've forgotten too much jcdi the last few weeks while working on other stuff, but I don't understand your usecases. 1. IIUC right now if we can't create metadata for a class, we don't, and ignore the failure. If you then try to load such a web bean dynamically at runtime, won't you get the same exception? 2. Such a bean has a @ProducerMethod annotation, right? So we'd find it and register the ProducerMethodBean at deploy time. To perhaps try to be clearer I was thinking of looking for all annotations at deploy time and dealing with all of them (producer methods, fields, @Inject, etc etc etc) and only dealing with completely unannotated beans lazily. (IIRC there's some @Alternative (???) annotation that can also pull in other unannotated sub- or super- classes these can be dealt with at deploy time also). > introduce proprietary configuration option to ignore not explicitly marked > (via annotation or registered by extension) Dependent beans > -- > > Key: OWB-538 > URL: https://issues.apache.org/jira/browse/OWB-538 > Project: OpenWebBeans > Issue Type: New Feature > Components: Injection and Lookup >Affects Versions: 1.0.0 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.1.0 > > > The JSR-299 spec defines that not annotated beans must get picked up as being > @Dependent by default. > But this > a) introduces many errors in projects > b) unnecessarily fills up our managed beans list > c) causes lots of unnecessary work while scanning the classes. > Thus I'd like to propose the introduction of a non spec compliant flag > 'useExplicitDependentScoped' which is false by default -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OWB-538) introduce proprietary configuration option to ignore not explicitly marked (via annotation or registered by extension) Dependent beans
[ https://issues.apache.org/jira/browse/OWB-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000493#comment-13000493 ] David Jencks commented on OWB-538: -- I think the real problem here is that owb currently loads every application class and creates metadata for almost all of them. I think there may be a way to avoid this while not introducing any proprietary limitations or configuration. We can easily find all the classes that are explicitly annotated or explicitly injected. I think there's little doubt we should find these classes, load them, and create metadata for them on app startup. However there are some dynamic ways of asking for web beans that cannot be detected through annotation scanning. Can we arrange to create the metadata for these beans lazily when one of the dynamic methods is called? BTW I don't recall any errors from the current "load everything" strategy what kinds of errors are you thinking of? > introduce proprietary configuration option to ignore not explicitly marked > (via annotation or registered by extension) Dependent beans > -- > > Key: OWB-538 > URL: https://issues.apache.org/jira/browse/OWB-538 > Project: OpenWebBeans > Issue Type: New Feature > Components: Injection and Lookup >Affects Versions: 1.0.0 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.1.0 > > > The JSR-299 spec defines that not annotated beans must get picked up as being > @Dependent by default. > But this > a) introduces many errors in projects > b) unnecessarily fills up our managed beans list > c) causes lots of unnecessary work while scanning the classes. > Thus I'd like to propose the introduction of a non spec compliant flag > 'useExplicitDependentScoped' which is false by default -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OWB-527) JspFactory.getDefaultFactory() is synchronized, We can cache the return value to improve performance
[ https://issues.apache.org/jira/browse/OWB-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999064#comment-12999064 ] David Jencks commented on OWB-527: -- I'm looking at trunk code where the JspFactory.getDefaultFactory() is called at most once per web app in afterStartApplication line 117. Since the result may be different for every web app I don't understand how anything can be cached or speeded up. > JspFactory.getDefaultFactory() is synchronized, We can cache the return value > to improve performance > > > Key: OWB-527 > URL: https://issues.apache.org/jira/browse/OWB-527 > Project: OpenWebBeans > Issue Type: Bug > Components: Lifecycle >Affects Versions: 1.0.0 >Reporter: Xiaoming Shi >Assignee: Mark Struberg > > In the file: > ./openwebbeans-1.0.0/webbeans-web/src/main/java/org/apache/webbeans/web/lifecycle/WebContainerLifecycle.java >line:86 > The value returned by JspFactory.getDefaultFactory() can be cached to reduce > race and improve performance > (Similar to the Apache Bug, > https://issues.apache.org/bugzilla/show_bug.cgi?id=44408) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OWB-496) Don't replace the ProxyFactory classloaderProvider without the intention to do so
[ https://issues.apache.org/jira/browse/OWB-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997613#comment-12997613 ] David Jencks commented on OWB-496: -- I don't think anyone has tried to explain why its a good idea to flail around with unexpected exceptions rather than installing a classloader provider that is suitable for the environment OWB is running in. I hope you don't synchronize a static or singleton method that is called very frequently from multiple threads. I think that would be required to make this exception handling code work. > Don't replace the ProxyFactory classloaderProvider without the intention to > do so > - > > Key: OWB-496 > URL: https://issues.apache.org/jira/browse/OWB-496 > Project: OpenWebBeans > Issue Type: Bug > Components: Context and Scopes > Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > > Currently JavassistProxyFactory.getProxyClass() replaces the > ProxyFactory.classloaderProvider on any exception with a classloaderProvider > that is very unlikely to work better than the default. Setting the > classLoaderProvider should be a matter of intentional configuration, not > flailing around after an unexpected exception. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Problem with serializing ResourceProxyHandler
Hi Gerhard,
My suggestion is that if there is an abstract class here, it be
public abstract class AbstraceResourceInjectionService implements
ResourceInjectionService
{
/**
* delegation of serialization behavior
*/
public void writeExternal(Bean bean, T actualResource, ObjectOutput
out) throws IOException
{
//do nothing
}
}
public T readExternal(Bean bean, ObjectInput in) throws IOException,
ClassNotFoundException
{
return (T) ((ResourceBean)bean).getActualInstance();
}
This is much simpler and likely faster (at most one deserialization from jndi
in readExternal rather than serialization on write and deserialization on read)
than the implementations in StandaloneResourceInjectionService and
OpenEjbResourceInjectionService. I think it is likely to work in many more
scenarios than the current OWB code. I don't think the
OpenEjbResourceInjectionService is used anywhere, certainly not in the openejb
integration in openejb. The code above works in geronimo and the existing OWB
code does not.
My original idea at the start of this thread was to just use this method always
without delegating to ResourceinjectionService, but Mark didn't like that idea.
I still do not understand any circumstance in which the existing code would be
useful compared with the above.
thanks
david jencks
On Jan 11, 2011, at 2:42 PM, Gerhard wrote:
> hi david,
>
> please provide more details btw. a more concrete suggestion.
> currently StandaloneResourceInjectionService
> and OpenEjbResourceInjectionService are the only classes which have an
> implementation of the new methods (the same implementation).
> -> we have c&p + new methods which break backward compatibility (we should
> avoid both - if it is possible).
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
> 2011/1/10 David Jencks
>
>> He Gerhard,
>>
>> I'm not entirely sure what you have in mind. is it to introduce an
>>
>> public abstract class AbstraceResourceInjectionService implements
>> ResourceInjectionService
>> {
>> public void writeExternal(Bean bean, T actualResource,
>> ObjectOutput out) throws IOException
>> {
>> ...
>> }
>>
>> }
>>
>> /**
>>* delegation of serialization behavior
>>*/
>> public T readExternal(Bean bean, ObjectInput in) throws
>> IOException,
>> ClassNotFoundException
>> {
>> ...
>> }
>>
>> ?
>>
>> I'm OK with this if the implementations here are the ones in geronimo, not
>> the ones in StandaloneResourceInjectionService which I think are unlikely to
>> be useful in most environments and are a lot more complicated.
>>
>> public void writeExternal(Bean bean, T actualResource,
>> ObjectOutput out) throws IOException {
>> //do nothing
>> }
>>
>> /**
>>* delegation of serialization behavior
>>*/
>> public T readExternal(Bean bean, ObjectInput out) throws
>> IOException,
>> ClassNotFoundException {
>> return (T) ((ResourceBean)bean).getActualInstance();
>> }
>>
>>
>> I would need to understand why the implementations in the
>> StandaloneResourceInjectionService are ever useful to support their use as a
>> default implementation.
>>
>> thanks
>> david jencks
>>
>>
>> On Jan 10, 2011, at 4:43 AM, Gerhard wrote:
>>
>>> hi,
>>>
>>> @ResourceInjectionService:
>>> the current trunk breaks backward compatibility with existing owb
>> plugins.
>>> instead of c&p the default implementation of the new methods we should
>>> introduce an abstract class.
>>>
>>> regards,
>>> gerhard
>>>
>>> http://www.irian.at
>>>
>>> Your JSF powerhouse -
>>> JSF Consulting, Development and
>>> Courses in English and German
>>>
>>> Professional Support for Apache MyFaces
>>>
>>>
>>>
>>> 2010/12/31 David Jencks
>>>
>>>> I put an implementation of the delegation idea in
>>>> https://issues.apache.org/jira/browse/OWB-511 along with a proposal for
>>>> making WebBeansContext more useful (IMO).
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Dec 29, 2010, at 4:12 PM, David Jencks wrote:
>>>>
>>>>>
>
Re: svn commit: r1057407 - in /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans: component/BuildInOwbBean.java proxy/JavassistProxyFactory.java
This didn't compile, which I fixed in rev 1057448. However there's a design
problem in that the proxy choices are per-application since they are configured
from OWBConfiguration. Therefore the choices cannot be stored in a static map.
My change put the entire map of configuration info in every BuildinOwbBean
which is also wasteful.
I would suggest either putting the configuration map into a service in
WebBeansContext or simply parsing it in a static method each time a built in
bean is created and passing in the type from the subclass constructor.
thanks
david jencks
On Jan 10, 2011, at 2:44 PM, yingw...@apache.org wrote:
> Author: yingwang
> Date: Mon Jan 10 22:44:57 2011
> New Revision: 1057407
>
> URL: http://svn.apache.org/viewvc?rev=1057407&view=rev
> Log:
> [OWB-508] add abstract build in owb bean class
>
> Added:
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/component/BuildInOwbBean.java
> Modified:
>
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy/JavassistProxyFactory.java
>
> Added:
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/component/BuildInOwbBean.java
> URL:
> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/component/BuildInOwbBean.java?rev=1057407&view=auto
> ==
> ---
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/component/BuildInOwbBean.java
> (added)
> +++
> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/component/BuildInOwbBean.java
> Mon Jan 10 22:44:57 2011
> @@ -0,0 +1,315 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements. See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership. The ASF licenses this file
> + * to you under the Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance
> + * with the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> + * software distributed under the License is distributed on an
> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + * KIND, either express or implied. See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
> +package org.apache.webbeans.component;
> +
> +import java.io.IOException;
> +import java.io.ObjectInputStream;
> +import java.io.ObjectOutputStream;
> +import java.io.Serializable;
> +import java.lang.reflect.Constructor;
> +import java.lang.reflect.Method;
> +import java.security.AccessController;
> +import java.security.PrivilegedAction;
> +import java.util.HashMap;
> +
> +import javax.enterprise.context.spi.CreationalContext;
> +import javassist.util.proxy.MethodHandler;
> +import javassist.util.proxy.ProxyObject;
> +
> +import org.apache.webbeans.config.BeansDeployer;
> +import org.apache.webbeans.config.OpenWebBeansConfiguration;
> +import org.apache.webbeans.container.BeanManagerImpl;
> +import org.apache.webbeans.logger.WebBeansLogger;
> +import org.apache.webbeans.proxy.JavassistProxyFactory;
> +
> +/**
> + * Following 3 options are provided for vendor's build-in beans
> implementation:
> + *
> + * 1. "none", means the build-in bean does not need a proxy wrapper.
> + * 2. "default", means the build-in bean needs OWB-provided default proxy
> wrapper.
> + * 3. A class name, which implements MethodHandler. This will allow vendor
> to
> + *customize the serialization behavior.
> + *
> + * The default values for 4 build-in beans are "default". Following property
> could
> + * be used to change the default behavior:
> + *
> + * Property Name: org.apache.webbeans.component.BuildInOwbBean.property
> + * Sample values:
> UserTransation:none;Principal:default;Validation:com.mycompany.ValidationProxyHandler;ValidationFactory:default
> + *
> + * @author yingwang
> + *
> + * @param
> + */
> +public abstract class BuildInOwbBean extends AbstractOwbBean
> +{
> +
> +//Logger instance
> +private final WebBeansLogger logger =
> WebBeansLogger.getLogger(BeansDeployer.class);
> +
> +
> +private static HashMap proxyHandlerMap = new
> HashMap();
> +
> +
> +public static final String BUILD_IN_BEAN_PROPERTY =
> "org.apache.webbeans.component.BuildInOwbBean.property";
> +
&g
Re: Problem with serializing ResourceProxyHandler
He Gerhard,
I'm not entirely sure what you have in mind. is it to introduce an
public abstract class AbstraceResourceInjectionService implements
ResourceInjectionService
{
public void writeExternal(Bean bean, T actualResource, ObjectOutput
out) throws IOException
{
...
}
}
/**
* delegation of serialization behavior
*/
public T readExternal(Bean bean, ObjectInput in) throws IOException,
ClassNotFoundException
{
...
}
?
I'm OK with this if the implementations here are the ones in geronimo, not the
ones in StandaloneResourceInjectionService which I think are unlikely to be
useful in most environments and are a lot more complicated.
public void writeExternal(Bean bean, T actualResource, ObjectOutput
out) throws IOException {
//do nothing
}
/**
* delegation of serialization behavior
*/
public T readExternal(Bean bean, ObjectInput out) throws IOException,
ClassNotFoundException {
return (T) ((ResourceBean)bean).getActualInstance();
}
I would need to understand why the implementations in the
StandaloneResourceInjectionService are ever useful to support their use as a
default implementation.
thanks
david jencks
On Jan 10, 2011, at 4:43 AM, Gerhard wrote:
> hi,
>
> @ResourceInjectionService:
> the current trunk breaks backward compatibility with existing owb plugins.
> instead of c&p the default implementation of the new methods we should
> introduce an abstract class.
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2010/12/31 David Jencks
>
>> I put an implementation of the delegation idea in
>> https://issues.apache.org/jira/browse/OWB-511 along with a proposal for
>> making WebBeansContext more useful (IMO).
>>
>> thanks
>> david jencks
>>
>> On Dec 29, 2010, at 4:12 PM, David Jencks wrote:
>>
>>>
>>> On Dec 29, 2010, at 12:24 AM, Mark Struberg wrote:
>>>
>>>>> My current idea is that we should assume that _all_
>>>>> resource objects are stateless and _always_ deserialize
>>>>> these ResourceProxyHandlers by obtaining the actual resource
>>>>> from the ResourceInjectionService.
>>>>
>>>> Now I am confused ;) This means to _not_ deserialize those Resources at
>> all, but instead always re-attach by getting it fro JNDI again?
>>>
>>> s/jndi/ResourceInjectionService
>>> yes, that's what I'd like.
>>>
>>>>
>>>> What I meant in my long flame: JNDI objects were supposed to be stored
>> in serialised form, but that in the mean time JNDI got used as a big fat
>> toilette where lots of objects got flushed down in the various EE specs
>> without thinking about it. Take the QueueConnectionFactory [1] for JMS. The
>> spec says that the impls _should_ be Serializable, but quite a few impls are
>> not.
>>>
>>> I won't argue against the claim that JNDI is a garbage pit of
>> underspecified bad ideas and bizarre implementations. However, it's also an
>> ee requirement at the moment.
>>>
>>>>
>>>> In fact: a few resources we get from JNDI are Serializable, others are
>> not.
>>>>
>>>> My opinion: The ones which implement Serializable should manage
>> themself, the others should be re-attached from JNDI via a 'proxy'
>>>>
>>>> But maybe I still miss the 'one' important point ;)
>>>
>>> My experience is that EE stuff bound to jndi that implements serializable
>> usually doesn't actually serialize/deserialize properly. So I'm very
>> reluctant to delegate to implementations that are likely to be broken. In
>> particular I'm having problems serializing/deserializing an openjpa EMF.
>>>
>>> AFAIK none of the ee objects you can specify as a @Resource and get from
>> jndi are supposed to have user modifiable state. Therefore getting a new
>> one from jndi on deserialization should work fine.
>>>
>>> If you find this argument less than compelling, could we simply delegate
>> _all_ of the serialization/deserialization of the actual resource to the
>> ResourceInjectionService? Then I can do the "always lookup in jndi"
>> approach in geronimo and you can avoid it in OWB.
>>>
>>> thanks
>>> david jencks
>>>
>>>>
>>>> LieGrue,
>>>>
Can we avoid loading all the classes during startup?
David Blevins and I have been hoping that it would be possible to avoid loading all the classes in an application when "deploying" it into OWB. Mark has been telling me that this won't work. It's pretty easy to scan the application and find all the classes with relevant annotations and all the classes that are injected into something using ASM so all the other classes aren't loaded. However I now see that there's a BeanManager method public Set> getBeans(Type beanType, Annotation... bindings) where you can pass in an arbitrary class and get the possible beans back. This certainly means that just finding all the beans referenced in ways such as the injection targets or having a name is not sufficient. I can think of a couple ways to proceed that might help: 1. eagerly create and register Bean for classes that are easy to identify as above and lazily create Bean for otherwise unidentifiable beans on demand. I haven't found anything in the spec that says tis can't be done but haven't looked very hard. 2. We can identify some classes during scanning that can't be beans, (e.g. having only non-default constructors not annotated with @Inject) and exclude only these from consideration. This would be pretty easy but is apt to load many more classes than we'd like. 3. Modify the AbstractOWBBean and AnnotatedTypeImpl so they lazily load the bean class. I haven't investigated, so maybe the bean class is needed immediately. I wonder if it might not be needed immediately for beans with no annotations. Thoughts or advice? thanks david jencks
Re: Next steps with WebBeansContext?
On Jan 9, 2011, at 1:44 PM, Gurkan Erdogdu wrote: >>>> I think we only have the ProcessProducerMethod/Field tests to worry about >>>> as >>>> far as tck compliance. > > I have corrected those errors in OWB side. > > For me, tomcat integration has passed TCK 1.0.4 CR2 with WebProfile. This appears to work in geronimo also many thanks david jencks > > Thanks; > > --Gurkan > > > > - Original Message > From: David Jencks > To: dev@openwebbeans.apache.org > Sent: Sat, January 8, 2011 10:13:02 PM > Subject: Re: Next steps with WebBeansContext? > > with rev 1056785 all the standalone tck tests are passing for me so I think > we > only have the ProcessProducerMethod/Field tests to worry about as far as tck > compliance. > > thanks > david jencks > > On Jan 8, 2011, at 10:43 AM, David Jencks wrote: > >> I guess as a side effect of these changes in the last day when I run >> >> mvn clean install -Ptck >> >> locally I've gone from 23 to 1 failing test. I suspect something in the >> app >> environment wasn't getting cleaned up appropriately. >> >> thanks >> david jencks >> >> On Jan 8, 2011, at 3:25 AM, Mark Struberg wrote: >> >>> great news! >>> >>> LieGrue, >>> strub >>> >>> --- On Sat, 1/8/11, David Blevins wrote: >>> >>>> From: David Blevins >>>> Subject: Re: Next steps with WebBeansContext? >>>> To: dev@openwebbeans.apache.org >>>> Date: Saturday, January 8, 2011, 1:24 AM >>>> On Thu, Jan 6, 2011 at 2:35 PM, David >>>> Blevins >>>> wrote: >>>>> On Dec 31, 2010, at 1:31 PM, David Jencks wrote: >>>>> >>>>>> Some of these ideas are implemented in the patch >>>> attached to https://issues.apache.org/jira/browse/OWB-511 >>>>>> >>>>>> thanks >>>>>> david jencks >>>>>> >>>>>> On Dec 31, 2010, at 12:02 PM, David Jencks wrote: >>>>>> >>>>>>> I looked at the WebBeansContext recently and >>>> was a little surprised at what it does and doesn't do. I >>>> wonder if what I want it to do is what David Blevins was >>>> thinking of as "next steps". >>>>> >>>>> You pretty much got it. The changes are a good next >>>> step. We still have a ways to go as in OpenWebBeans proper >>>> (using the DefaultSingletonService) we still get most our >>>> hits through the static access to ServiceLoader. >>>>> >>>>> 68639 org.apache.webbeans.corespi.ServiceLoader >>>>> 34129 org.apache.webbeans.util.AnnotationUtil >>>>> 6063 org.apache.webbeans.util.WebBeansUtil >>>>> 2170 org.apache.webbeans.test.TestContext >>>>> 1832 org.apache.webbeans.component.AbstractOwbBean >>>>> 1464 >>>> org.apache.webbeans.intercept.WebBeansInterceptorConfig >>>>> 1402 >>>> org.apache.webbeans.inject.impl.InjectionPointFactory >>>>> 1170 >>>> org.apache.webbeans.decorator.WebBeansDecoratorConfig >>>> >>>> Nice, your last change got us down another 200 or so static >>>> sync calls: >>>> >>>> OWB-503 status: 565 code uses >>>> Total of 94975 static synchronized accesses and >>>> 95398 hashed calls >>>> in 340 tests >>>> Average of 279 static synchronized accesses and 280 >>>> hashed calls per test >>>> >>>> The hashed calls count is no longer accurate as I haven't >>>> updated my >>>> tracking hooks to count the new services map, but the >>>> static >>>> synchronized is still good. >>>> >>>> Here are the next top 10: >>>> >>>> 65558 org.apache.webbeans.context.ContextFactory >>>> 7976 org.apache.webbeans.util.WebBeansUtil >>>> 2420 >>>> org.apache.webbeans.intercept.WebBeansInterceptorConfig >>>> 2288 org.apache.webbeans.config.DefinitionUtil >>>> 2178 org.apache.webbeans.test.TestContext >>>> 1833 org.apache.webbeans.component.AbstractOwbBean >>>> 1622 org.apache.webbeans.inject.impl.InjectionPointFactory >>>> 1254 org.apache.webbeans.event.EventUtil >>>> 1168 org.apache.webbeans.decorator.WebBeansDecoratorConfig >>>> 940 org.apache.webbeans.deployment.StereoTypeModel >>>> >>>> Just de-static'd the ContextFactory, and now we're down >>>> another 200~ per test >>>> >>>> OWB-503 status: 615 code uses >>>> Total of 28894 static synchronized accesses and >>>> 29317 hashed calls >>>> in 340 tests >>>> Average of 84 static synchronized accesses and 86 >>>> hashed calls per test >>>> >>>> -David >>>> >>> >>> >>> >> > >
Re: Next steps with WebBeansContext?
with rev 1056785 all the standalone tck tests are passing for me so I think we only have the ProcessProducerMethod/Field tests to worry about as far as tck compliance. thanks david jencks On Jan 8, 2011, at 10:43 AM, David Jencks wrote: > I guess as a side effect of these changes in the last day when I run > > mvn clean install -Ptck > > locally I've gone from 23 to 1 failing test. I suspect something in the app > environment wasn't getting cleaned up appropriately. > > thanks > david jencks > > On Jan 8, 2011, at 3:25 AM, Mark Struberg wrote: > >> great news! >> >> LieGrue, >> strub >> >> --- On Sat, 1/8/11, David Blevins wrote: >> >>> From: David Blevins >>> Subject: Re: Next steps with WebBeansContext? >>> To: dev@openwebbeans.apache.org >>> Date: Saturday, January 8, 2011, 1:24 AM >>> On Thu, Jan 6, 2011 at 2:35 PM, David >>> Blevins >>> wrote: >>>> On Dec 31, 2010, at 1:31 PM, David Jencks wrote: >>>> >>>>> Some of these ideas are implemented in the patch >>> attached to https://issues.apache.org/jira/browse/OWB-511 >>>>> >>>>> thanks >>>>> david jencks >>>>> >>>>> On Dec 31, 2010, at 12:02 PM, David Jencks wrote: >>>>> >>>>>> I looked at the WebBeansContext recently and >>> was a little surprised at what it does and doesn't do. I >>> wonder if what I want it to do is what David Blevins was >>> thinking of as "next steps". >>>> >>>> You pretty much got it. The changes are a good next >>> step. We still have a ways to go as in OpenWebBeans proper >>> (using the DefaultSingletonService) we still get most our >>> hits through the static access to ServiceLoader. >>>> >>>> 68639 org.apache.webbeans.corespi.ServiceLoader >>>> 34129 org.apache.webbeans.util.AnnotationUtil >>>> 6063 org.apache.webbeans.util.WebBeansUtil >>>> 2170 org.apache.webbeans.test.TestContext >>>> 1832 org.apache.webbeans.component.AbstractOwbBean >>>> 1464 >>> org.apache.webbeans.intercept.WebBeansInterceptorConfig >>>> 1402 >>> org.apache.webbeans.inject.impl.InjectionPointFactory >>>> 1170 >>> org.apache.webbeans.decorator.WebBeansDecoratorConfig >>> >>> Nice, your last change got us down another 200 or so static >>> sync calls: >>> >>> OWB-503 status: 565 code uses >>> Total of 94975 static synchronized accesses and >>> 95398 hashed calls >>> in 340 tests >>> Average of 279 static synchronized accesses and 280 >>> hashed calls per test >>> >>> The hashed calls count is no longer accurate as I haven't >>> updated my >>> tracking hooks to count the new services map, but the >>> static >>> synchronized is still good. >>> >>> Here are the next top 10: >>> >>> 65558 org.apache.webbeans.context.ContextFactory >>> 7976 org.apache.webbeans.util.WebBeansUtil >>> 2420 >>> org.apache.webbeans.intercept.WebBeansInterceptorConfig >>> 2288 org.apache.webbeans.config.DefinitionUtil >>> 2178 org.apache.webbeans.test.TestContext >>> 1833 org.apache.webbeans.component.AbstractOwbBean >>> 1622 org.apache.webbeans.inject.impl.InjectionPointFactory >>> 1254 org.apache.webbeans.event.EventUtil >>> 1168 org.apache.webbeans.decorator.WebBeansDecoratorConfig >>> 940 org.apache.webbeans.deployment.StereoTypeModel >>> >>> Just de-static'd the ContextFactory, and now we're down >>> another 200~ per test >>> >>> OWB-503 status: 615 code uses >>> Total of 28894 static synchronized accesses and >>> 29317 hashed calls >>> in 340 tests >>> Average of 84 static synchronized accesses and 86 >>> hashed calls per test >>> >>> -David >>> >> >> >> >
Re: Next steps with WebBeansContext?
I guess as a side effect of these changes in the last day when I run mvn clean install -Ptck locally I've gone from 23 to 1 failing test. I suspect something in the app environment wasn't getting cleaned up appropriately. thanks david jencks On Jan 8, 2011, at 3:25 AM, Mark Struberg wrote: > great news! > > LieGrue, > strub > > --- On Sat, 1/8/11, David Blevins wrote: > >> From: David Blevins >> Subject: Re: Next steps with WebBeansContext? >> To: dev@openwebbeans.apache.org >> Date: Saturday, January 8, 2011, 1:24 AM >> On Thu, Jan 6, 2011 at 2:35 PM, David >> Blevins >> wrote: >>> On Dec 31, 2010, at 1:31 PM, David Jencks wrote: >>> >>>> Some of these ideas are implemented in the patch >> attached to https://issues.apache.org/jira/browse/OWB-511 >>>> >>>> thanks >>>> david jencks >>>> >>>> On Dec 31, 2010, at 12:02 PM, David Jencks wrote: >>>> >>>>> I looked at the WebBeansContext recently and >> was a little surprised at what it does and doesn't do. I >> wonder if what I want it to do is what David Blevins was >> thinking of as "next steps". >>> >>> You pretty much got it. The changes are a good next >> step. We still have a ways to go as in OpenWebBeans proper >> (using the DefaultSingletonService) we still get most our >> hits through the static access to ServiceLoader. >>> >>> 68639 org.apache.webbeans.corespi.ServiceLoader >>> 34129 org.apache.webbeans.util.AnnotationUtil >>> 6063 org.apache.webbeans.util.WebBeansUtil >>> 2170 org.apache.webbeans.test.TestContext >>> 1832 org.apache.webbeans.component.AbstractOwbBean >>> 1464 >> org.apache.webbeans.intercept.WebBeansInterceptorConfig >>> 1402 >> org.apache.webbeans.inject.impl.InjectionPointFactory >>> 1170 >> org.apache.webbeans.decorator.WebBeansDecoratorConfig >> >> Nice, your last change got us down another 200 or so static >> sync calls: >> >> OWB-503 status: 565 code uses >> Total of 94975 static synchronized accesses and >> 95398 hashed calls >> in 340 tests >> Average of 279 static synchronized accesses and 280 >> hashed calls per test >> >> The hashed calls count is no longer accurate as I haven't >> updated my >> tracking hooks to count the new services map, but the >> static >> synchronized is still good. >> >> Here are the next top 10: >> >> 65558 org.apache.webbeans.context.ContextFactory >> 7976 org.apache.webbeans.util.WebBeansUtil >> 2420 >> org.apache.webbeans.intercept.WebBeansInterceptorConfig >> 2288 org.apache.webbeans.config.DefinitionUtil >> 2178 org.apache.webbeans.test.TestContext >> 1833 org.apache.webbeans.component.AbstractOwbBean >> 1622 org.apache.webbeans.inject.impl.InjectionPointFactory >> 1254 org.apache.webbeans.event.EventUtil >> 1168 org.apache.webbeans.decorator.WebBeansDecoratorConfig >> 940 org.apache.webbeans.deployment.StereoTypeModel >> >> Just de-static'd the ContextFactory, and now we're down >> another 200~ per test >> >> OWB-503 status: 615 code uses >> Total of 28894 static synchronized accesses and >> 29317 hashed calls >> in 340 tests >> Average of 84 static synchronized accesses and 86 >> hashed calls per test >> >> -David >> > > >
Re: svn commit: r1056287 - in /openwebbeans/trunk: webbeans-el10/src/main/java/org/apache/webbeans/el10/ webbeans-impl/src/main/java/org/apache/webbeans/el/ webbeans-impl/src/main/java/org/apache/webb
Before concealing the use of WebBeansContext.getInstance() with this annotation
I'd like to see a comment explaining why this is the only way to get the
WebBeansContext.
thanks
david jencks
On Jan 7, 2011, at 4:38 AM, gerdo...@apache.org wrote:
> @Override
> -@SuppressWarnings("unchecked")
> +@SuppressWarnings({"unchecked","deprecation"})
> public Object getValue(ELContext context, Object obj, Object property)
> throws NullPointerException, PropertyNotFoundException, ELException
> {
Re: Can somebody deploy a new snapshot version?
oops, meant to do this yesterday after my commit. Uploading now after locally reverting Gurkan's rev 1056287 which broke the build (seems to be missing a new class) thanks david jencks On Jan 7, 2011, at 4:26 AM, Rick McGuire wrote: > The Geronimo build currently depends on recent changes to the openwebbeans > trunk. The currently deployed snapshot is back level, which requires people > to build it locally or the server build is broken. Can one of the committers > deploy and updated snapshot? > > Rick
Re: Does it needed to deploy single annotated Type if there's no annotation in the impl Class ?
Hi Shawn,
I think there are several situations where a class with no annotations can
still be a web bean. I'm not very familiar with these but I think one case is
when there's an annotated Producer method that returns an instance of the class.
David Blevins improved the xbean-finder so that it can figure out all the
classes OWB needs to look at in the (geronimo, osgi) scanner service. I think
that once we integrate this improvement the CNF problem will be solved.
I don't recall seeing this problem in the parts of the tck I ran, could you
ping the g. tck list with some details?
thanks
david jencks
On Jan 6, 2011, at 10:08 PM, Shawn Jiang wrote:
> I met some CNF problem when running full profile Geronimo TCK. I traced
> the problem and found even there's no annoation at all in implClass.
> deploySingleAnnoatedType() will still get executed and scan all the field of
> the implClass. See following code in method:
>
> org.apache.webbeans.config.BeansDeployer.deployFromClassPath(ScannerService)
>
> ...
>
> AnnotatedType annotatedType =
> webBeansContext.getAnnotatedElementFactory().newAnnotatedType(implClass);
>
> if (null != annotatedType)
> {
> deploySingleAnnotatedType(implClass, annotatedType);
> }
>
> ...
>
>
>
> I'm wondering if the condition should be something like this:
>
>
> if (null != annotatedType*&&annotatedType.getAnnotations().size()>0*)
>{
>deploySingleAnnotatedType(implClass, annotatedType);
>}
>
>
>
> Any comments ?
> --
> Shawn
[jira] Commented: (OWB-496) Don't replace the ProxyFactory classloaderProvider without the intention to do so
[ https://issues.apache.org/jira/browse/OWB-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978444#action_12978444 ] David Jencks commented on OWB-496: -- I don't understand why you are pursuing this solution. In geronimo we simply install the classloader provider we want to use. Why can't you do this in the tomcat integration? > Don't replace the ProxyFactory classloaderProvider without the intention to > do so > - > > Key: OWB-496 > URL: https://issues.apache.org/jira/browse/OWB-496 > Project: OpenWebBeans > Issue Type: Bug > Components: Context and Scopes > Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > > Currently JavassistProxyFactory.getProxyClass() replaces the > ProxyFactory.classloaderProvider on any exception with a classloaderProvider > that is very unlikely to work better than the default. Setting the > classLoaderProvider should be a matter of intentional configuration, not > flailing around after an unexpected exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Yan:: Re: Release 1.1.0
The tck version is up to 1.0.4-SNAPSHOT, but this is the remaining problem in geronimo. I think you'll need to get the http://anonsvn.jboss.org/repos/weld/cdi-tck/branches/1.0 and build it yourself to see the most recent test revisions. I'm not convinced the changes Pete has made to the meaning of the events and the tests are appropriate for a 1.0.x tck. I'm curious what you think. thanks david jencks On Jan 5, 2011, at 11:16 AM, Gurkan Erdogdu wrote: > Hello David > i will look at owb-493 you mentioned. i assume that this is the single failed > test for 1.0.2-final tck in geronimo, isnt it? > > Thanks > > Çar, 05 Oca 2011 19:52 EET tarihinde David Jencks şöyle yazdı: > >> >> On Jan 5, 2011, at 6:55 AM, Gurkan Erdogdu wrote: >> >>> Hello folks, >>> >>> - WDYT about 1.1.0 release? >> >> Since you applied my patch that adds significant capabilities to >> WebBeansContext, I'd like to spend a little time modifying OWB to use it >> wherever it's easy to do so. If we don't completely eliminate the service >> loader we need to be sure it doesn't conflict with the new code. >> >> Also, OWB-493 needs to be fixed or we need to talk Pete into excluding the >> relevant tests. I don't think I have the knowledge of OWB internals needed >> to fix it. >> >>> - Please look at your JIRA tasks and close them if no need to stay as open. >> >> I don't seem to be able to close issues, just resolve them. >> >> thanks >> david jencks >> >> >>> - Please look at Unscheduled tasks and put them in 1.0.1 or 1.1.0 >>> >>> Thanks; >>> >>> --Gurkan >>> >>> >>> >> > > >
Re: Release 1.1.0
On Jan 5, 2011, at 6:55 AM, Gurkan Erdogdu wrote: > Hello folks, > > - WDYT about 1.1.0 release? Since you applied my patch that adds significant capabilities to WebBeansContext, I'd like to spend a little time modifying OWB to use it wherever it's easy to do so. If we don't completely eliminate the service loader we need to be sure it doesn't conflict with the new code. Also, OWB-493 needs to be fixed or we need to talk Pete into excluding the relevant tests. I don't think I have the knowledge of OWB internals needed to fix it. > - Please look at your JIRA tasks and close them if no need to stay as open. I don't seem to be able to close issues, just resolve them. thanks david jencks > - Please look at Unscheduled tasks and put them in 1.0.1 or 1.1.0 > > Thanks; > > --Gurkan > > >
[jira] Commented: (OWB-493) ProcessProducerMethod and ProcessProducerField type parameters are reversed in filtering (?) CDITCK-168
[ https://issues.apache.org/jira/browse/OWB-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976635#action_12976635 ] David Jencks commented on OWB-493: -- More info: T - The class of the return type of the producer method (Cow in the test) X - The class of the bean representing the producer method (CowShed in the test, having the producer method) ProcessProducerMethod extends ProcessBean methods: AnnotatedParameter getAnnotatedDisposedParameter() AnnotatedMethod getAnnotatedProducerMethod() Note that these are on T, the return type of the producer method (Cow in the test) Looking at AnnotatedMethod, Type Parameters: X - the declaring type Represents a method of a Java type. java.lang.reflect.MethodgetJavaMember() Get the underlying Method. This is supposed to represent the producer method on X (CowShed), but it's specified to be on T (Cow). So I think it has to return null and/or the test should be disabled. Similarly for the AnnotatedParameter. thoughts? > ProcessProducerMethod and ProcessProducerField type parameters are reversed > in filtering (?) CDITCK-168 > > > Key: OWB-493 > URL: https://issues.apache.org/jira/browse/OWB-493 > Project: OpenWebBeans > Issue Type: Bug > Components: Events >Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > > See https://jira.jboss.org/browse/CDITCK-168 > The tck extensions.processBean.ProcessBeanTest test had a couple errors where > ProcessProducerMethod was treated as a ProcessMethod > whereas it is a ProcessMethod, and similarly for ProcessProducerField. > OWB seems to be subject to the same error. >public void observeCowProcessProducerMethod(@Observes > ProcessProducerMethod event) > is getting called correctly for the ProcessProducerMethod, but >public void observeCowShedProccesBean(@Observes ProcessBean event) > is getting called with the same event. > I haven't been able to figure out where the problem is. > The corrected test is in 1.0.2.CR3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Next steps with WebBeansContext?
Some of these ideas are implemented in the patch attached to https://issues.apache.org/jira/browse/OWB-511 thanks david jencks On Dec 31, 2010, at 12:02 PM, David Jencks wrote: > I looked at the WebBeansContext recently and was a little surprised at what > it does and doesn't do. I wonder if what I want it to do is what David > Blevins was thinking of as "next steps". > > I think of an OWB "instance" set up for a particular application (or web > module) as a bunch of instances of implementations of interfaces all wired > together. The implementation classes for each interface are (currently) > specified in WebBeansConfiguration and in web beans plugins. When a > component needs the instance of a particular interface it will get it from > the wiring system. > > My impression is that the information in WebBeansConfiguration and the set of > available plugins is intended to be immutable once the OWB "instance" is > "started". > > I believe that before WebBeansContext the lookup to obtain an instance of an > interface proceeded through > - lookup to obtain WebBeansConfiguration to obtain implementation class > - lookup to create or obtain the cached instance of the implementation class. > > I don't really understand how WebBeansContext changes this significantly. > What I would like is for WebBeansContext to supply the complete solution for > this behavior so a component can directly get the implementation of an > interface from WebBeansContext. > > I also think we should look into eagerly creating all the components > specified in WebBeansConfiguration immediately. I think this will greatly > reduce the likelihood of concurrency problems. > > So I'd like to add these to WebBeansContext: > > private final Map, Object> serviceMap // service interface class to > implementation map > > public WebBeansContext(WebBeansConfiguration conf) // new constructor to > eagerly create all listed services > > public T getService serviceInterface> // implementation taken > from ServiceLoader > > public void registerService(Class clazz, T t) // in case someone wants > to use a non-WebBeansConfiguration configuration scheme. > > > > > As a more minor point I'm a little confused by the choice of some of the > hardcoded services now in WebBeansContext. Some make sense like > ConversationManager where there is no interface and no subclasses, but some > are specific implementations of service interfaces such as JndiService and > ScannerService where IMO the Default* implementations are unlikely to be used > in most integration contexts. > > thoughts? > > thanks > david jencks >
Re: Problem with serializing ResourceProxyHandler
I put an implementation of the delegation idea in https://issues.apache.org/jira/browse/OWB-511 along with a proposal for making WebBeansContext more useful (IMO). thanks david jencks On Dec 29, 2010, at 4:12 PM, David Jencks wrote: > > On Dec 29, 2010, at 12:24 AM, Mark Struberg wrote: > >>> My current idea is that we should assume that _all_ >>> resource objects are stateless and _always_ deserialize >>> these ResourceProxyHandlers by obtaining the actual resource >>> from the ResourceInjectionService. >> >> Now I am confused ;) This means to _not_ deserialize those Resources at all, >> but instead always re-attach by getting it fro JNDI again? > > s/jndi/ResourceInjectionService > yes, that's what I'd like. > >> >> What I meant in my long flame: JNDI objects were supposed to be stored in >> serialised form, but that in the mean time JNDI got used as a big fat >> toilette where lots of objects got flushed down in the various EE specs >> without thinking about it. Take the QueueConnectionFactory [1] for JMS. The >> spec says that the impls _should_ be Serializable, but quite a few impls are >> not. > > I won't argue against the claim that JNDI is a garbage pit of underspecified > bad ideas and bizarre implementations. However, it's also an ee requirement > at the moment. > >> >> In fact: a few resources we get from JNDI are Serializable, others are not. >> >> My opinion: The ones which implement Serializable should manage themself, >> the others should be re-attached from JNDI via a 'proxy' >> >> But maybe I still miss the 'one' important point ;) > > My experience is that EE stuff bound to jndi that implements serializable > usually doesn't actually serialize/deserialize properly. So I'm very > reluctant to delegate to implementations that are likely to be broken. In > particular I'm having problems serializing/deserializing an openjpa EMF. > > AFAIK none of the ee objects you can specify as a @Resource and get from jndi > are supposed to have user modifiable state. Therefore getting a new one from > jndi on deserialization should work fine. > > If you find this argument less than compelling, could we simply delegate > _all_ of the serialization/deserialization of the actual resource to the > ResourceInjectionService? Then I can do the "always lookup in jndi" approach > in geronimo and you can avoid it in OWB. > > thanks > david jencks > >> >> LieGrue, >> strub >> >> >> >> [1] >> >> --- On Tue, 12/28/10, David Jencks wrote: >> >>> From: David Jencks >>> Subject: Re: Problem with serializing ResourceProxyHandler >>> To: dev@openwebbeans.apache.org >>> Date: Tuesday, December 28, 2010, 11:31 PM >>> I'm afraid I don't understand your >>> response very well. >>> >>> On Dec 27, 2010, at 3:13 AM, Mark Struberg wrote: >>> >>>> Hi! >>>> >>>> I think this is really theoretical. Serializing / >>> Deserializing will most probably only happen in a cluster >>> between the same applications. If they have different >>> configurations activated on different cluster nodes, well >>> ... ;) >>>> >>>> Can you think of any other scenario? >>>> >>> >>> such scenarios might be unlikely but since they are easy to >>> guard against I don't really see why not to do so. On >>> the other hand if we decide to delegate all the content >>> serialization (see below) then we can delegate this checking >>> as well. >>> >>>> >>>> For the general serialisation question: >>>> JNDI usage in EE servers is in general (and thus also >>> the EMF handling in this area also) pretty sick. Originally >>> EMFs have been Serializable because they are bound to JNDI. >>> JNDI is typically bound to directory services in serialized >>> form. But in EE they are now used completely different. They >>> should now all be javax.naming.Referencable and not >>> Serializable anymore... >>>> >>>> If we get other things from JNDI which are >>> Serializable, then we must serialize them to get back this >>> exact state because any intermediate JNDI rebind would >>> probably crash our application. >>>> >>>> I personally try to avoid JNDI wherever possible. They >>> are perfectly over-specced and still behave very
[jira] Updated: (OWB-511) Delegate actualInstance serialization behavior in ResourceProxyHandler
[ https://issues.apache.org/jira/browse/OWB-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated OWB-511: - Attachment: OWB-511.diff proposal for delegating resource serialization and making WebBeansContext more useful > Delegate actualInstance serialization behavior in ResourceProxyHandler > -- > > Key: OWB-511 > URL: https://issues.apache.org/jira/browse/OWB-511 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > Attachments: OWB-511.diff > > > I suggested this on the dev list, here's a patch to show what I have in mind > more definitely. This also includes part of the proposal to extend the > usefulness of WebBeansContext. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-511) Delegate actualInstance serialization behavior in ResourceProxyHandler
Delegate actualInstance serialization behavior in ResourceProxyHandler -- Key: OWB-511 URL: https://issues.apache.org/jira/browse/OWB-511 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: David Jencks Assignee: Gurkan Erdogdu Fix For: 1.1.0 I suggested this on the dev list, here's a patch to show what I have in mind more definitely. This also includes part of the proposal to extend the usefulness of WebBeansContext. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Next steps with WebBeansContext?
I looked at the WebBeansContext recently and was a little surprised at what it does and doesn't do. I wonder if what I want it to do is what David Blevins was thinking of as "next steps". I think of an OWB "instance" set up for a particular application (or web module) as a bunch of instances of implementations of interfaces all wired together. The implementation classes for each interface are (currently) specified in WebBeansConfiguration and in web beans plugins. When a component needs the instance of a particular interface it will get it from the wiring system. My impression is that the information in WebBeansConfiguration and the set of available plugins is intended to be immutable once the OWB "instance" is "started". I believe that before WebBeansContext the lookup to obtain an instance of an interface proceeded through - lookup to obtain WebBeansConfiguration to obtain implementation class - lookup to create or obtain the cached instance of the implementation class. I don't really understand how WebBeansContext changes this significantly. What I would like is for WebBeansContext to supply the complete solution for this behavior so a component can directly get the implementation of an interface from WebBeansContext. I also think we should look into eagerly creating all the components specified in WebBeansConfiguration immediately. I think this will greatly reduce the likelihood of concurrency problems. So I'd like to add these to WebBeansContext: private final Map, Object> serviceMap // service interface class to implementation map public WebBeansContext(WebBeansConfiguration conf) // new constructor to eagerly create all listed services public T getService serviceInterface> // implementation taken from ServiceLoader public void registerService(Class clazz, T t) // in case someone wants to use a non-WebBeansConfiguration configuration scheme. As a more minor point I'm a little confused by the choice of some of the hardcoded services now in WebBeansContext. Some make sense like ConversationManager where there is no interface and no subclasses, but some are specific implementations of service interfaces such as JndiService and ScannerService where IMO the Default* implementations are unlikely to be used in most integration contexts. thoughts? thanks david jencks
Re: Problem with serializing ResourceProxyHandler
On Dec 29, 2010, at 12:24 AM, Mark Struberg wrote: >> My current idea is that we should assume that _all_ >> resource objects are stateless and _always_ deserialize >> these ResourceProxyHandlers by obtaining the actual resource >> from the ResourceInjectionService. > > Now I am confused ;) This means to _not_ deserialize those Resources at all, > but instead always re-attach by getting it fro JNDI again? s/jndi/ResourceInjectionService yes, that's what I'd like. > > What I meant in my long flame: JNDI objects were supposed to be stored in > serialised form, but that in the mean time JNDI got used as a big fat > toilette where lots of objects got flushed down in the various EE specs > without thinking about it. Take the QueueConnectionFactory [1] for JMS. The > spec says that the impls _should_ be Serializable, but quite a few impls are > not. I won't argue against the claim that JNDI is a garbage pit of underspecified bad ideas and bizarre implementations. However, it's also an ee requirement at the moment. > > In fact: a few resources we get from JNDI are Serializable, others are not. > > My opinion: The ones which implement Serializable should manage themself, the > others should be re-attached from JNDI via a 'proxy' > > But maybe I still miss the 'one' important point ;) My experience is that EE stuff bound to jndi that implements serializable usually doesn't actually serialize/deserialize properly. So I'm very reluctant to delegate to implementations that are likely to be broken. In particular I'm having problems serializing/deserializing an openjpa EMF. AFAIK none of the ee objects you can specify as a @Resource and get from jndi are supposed to have user modifiable state. Therefore getting a new one from jndi on deserialization should work fine. If you find this argument less than compelling, could we simply delegate _all_ of the serialization/deserialization of the actual resource to the ResourceInjectionService? Then I can do the "always lookup in jndi" approach in geronimo and you can avoid it in OWB. thanks david jencks > > LieGrue, > strub > > > > [1] > > --- On Tue, 12/28/10, David Jencks wrote: > >> From: David Jencks >> Subject: Re: Problem with serializing ResourceProxyHandler >> To: dev@openwebbeans.apache.org >> Date: Tuesday, December 28, 2010, 11:31 PM >> I'm afraid I don't understand your >> response very well. >> >> On Dec 27, 2010, at 3:13 AM, Mark Struberg wrote: >> >>> Hi! >>> >>> I think this is really theoretical. Serializing / >> Deserializing will most probably only happen in a cluster >> between the same applications. If they have different >> configurations activated on different cluster nodes, well >> ... ;) >>> >>> Can you think of any other scenario? >>> >> >> such scenarios might be unlikely but since they are easy to >> guard against I don't really see why not to do so. On >> the other hand if we decide to delegate all the content >> serialization (see below) then we can delegate this checking >> as well. >> >>> >>> For the general serialisation question: >>> JNDI usage in EE servers is in general (and thus also >> the EMF handling in this area also) pretty sick. Originally >> EMFs have been Serializable because they are bound to JNDI. >> JNDI is typically bound to directory services in serialized >> form. But in EE they are now used completely different. They >> should now all be javax.naming.Referencable and not >> Serializable anymore... >>> >>> If we get other things from JNDI which are >> Serializable, then we must serialize them to get back this >> exact state because any intermediate JNDI rebind would >> probably crash our application. >>> >>> I personally try to avoid JNDI wherever possible. They >> are perfectly over-specced and still behave very different >> on different EE servers when it comes to gory details ;) >> >> I don't understand any of your argument here, nor what >> conclusion you have reached. You are free to write a >> ResourceInjectionService backed by something other than >> jndi, although I don't see how it would relate to how >> @Resource annotations are supposed to work in cdi. >> >> My current idea is that we should assume that _all_ >> resource objects are stateless and _always_ deserialize >> these ResourceProxyHandlers by obtaining the actual resource >> from the ResourceInjectionService. This means leaving >> out
[jira] Resolved: (OWB-510) return null instead of an unusable proxy if a resource is missing
[ https://issues.apache.org/jira/browse/OWB-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks resolved OWB-510. -- Resolution: Fixed fixed in rev 1053774 > return null instead of an unusable proxy if a resource is missing > - > > Key: OWB-510 > URL: https://issues.apache.org/jira/browse/OWB-510 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > > Currently if the ResourceInjectionService returns null for a resource we > build a proxy that is guaranteed to never work. I think this is really > confusing for users. Instead, as Mark suggested, lets return null if the > resource is null. In addition, the ResourceInjectionService implementation > can throw an exception if it does not want to return null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-510) return null instead of an unusable proxy if a resource is missing
return null instead of an unusable proxy if a resource is missing - Key: OWB-510 URL: https://issues.apache.org/jira/browse/OWB-510 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: David Jencks Assignee: Gurkan Erdogdu Fix For: 1.1.0 Currently if the ResourceInjectionService returns null for a resource we build a proxy that is guaranteed to never work. I think this is really confusing for users. Instead, as Mark suggested, lets return null if the resource is null. In addition, the ResourceInjectionService implementation can throw an exception if it does not want to return null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problem with serializing ResourceProxyHandler
I'm afraid I don't understand your response very well. On Dec 27, 2010, at 3:13 AM, Mark Struberg wrote: > Hi! > > I think this is really theoretical. Serializing / Deserializing will most > probably only happen in a cluster between the same applications. If they have > different configurations activated on different cluster nodes, well ... ;) > > Can you think of any other scenario? > such scenarios might be unlikely but since they are easy to guard against I don't really see why not to do so. On the other hand if we decide to delegate all the content serialization (see below) then we can delegate this checking as well. > > For the general serialisation question: > JNDI usage in EE servers is in general (and thus also the EMF handling in > this area also) pretty sick. Originally EMFs have been Serializable because > they are bound to JNDI. JNDI is typically bound to directory services in > serialized form. But in EE they are now used completely different. They > should now all be javax.naming.Referencable and not Serializable anymore... > > If we get other things from JNDI which are Serializable, then we must > serialize them to get back this exact state because any intermediate JNDI > rebind would probably crash our application. > > I personally try to avoid JNDI wherever possible. They are perfectly > over-specced and still behave very different on different EE servers when it > comes to gory details ;) I don't understand any of your argument here, nor what conclusion you have reached. You are free to write a ResourceInjectionService backed by something other than jndi, although I don't see how it would relate to how @Resource annotations are supposed to work in cdi. My current idea is that we should assume that _all_ resource objects are stateless and _always_ deserialize these ResourceProxyHandlers by obtaining the actual resource from the ResourceInjectionService. This means leaving out the FailoverService here. We could have a ResourceSerializationService which if supplied does the serialization. Or we could delegate all the serialization to a ResourceSerializationService so I can implement something that works for geronimo without disturbing the current special-casing of corba stubs. Hoping you can clarify in a way I can understand :-) thanks david jencks > > LieGrue, > strub > > > > --- On Mon, 12/27/10, David Jencks wrote: > >> From: David Jencks >> Subject: Re: Problem with serializing ResourceProxyHandler >> To: dev@openwebbeans.apache.org >> Date: Monday, December 27, 2010, 7:43 AM >> And another thing... >> >> ResourceProxyHandler will have problems if the serializing >> and deserializing OWB instances differ on whether >> FailoverService is present. We should write a token to >> indicate whether FailoverService was used to serialize and >> use it in deserialization. >> >> thanks >> david jencks >> >> On Dec 26, 2010, at 11:21 PM, David Jencks wrote: >> >>> There's some asymetric logic in >> serializing/deserializing ResourceProxyHandler. >>> >>> Serializing: any serialized actual resource is >> written to the object output stream, whereas >> non-serializable objects have a marker serialized. >>> >>> Deserializing: The object is read from the object >> input stream, but only the marker object and CORBA stubs >> result in the actualResource field being set. >>> >>> Finding the marker object results in getting the >> resource again from the ResourceInjectionService, typically >> by looking something up in jndi. >>> >>> I would prefer to always get the actual resource from >> the ResourceInjectionService. Is there a strong reason >> not to do this? >>> >>> If anyone wants to keep the current approach, I think >> the logic currently in place to reconnect a CORBA stub uses >> the wrong ORB, I think it needs to look up the orb in jndi. >>> >>> I'm going to fix the current hole in the logic (rev >> 1053011) but IMO serializing random objects rather than >> getting them from the bean is a bad idea. Even with >> this I get a tck failure trying to deserialze an >> EntityManagerFactory. >>> >>> thanks >>> david jencks >>> >> >> > > >
Re: Problem with serializing ResourceProxyHandler
And another thing... ResourceProxyHandler will have problems if the serializing and deserializing OWB instances differ on whether FailoverService is present. We should write a token to indicate whether FailoverService was used to serialize and use it in deserialization. thanks david jencks On Dec 26, 2010, at 11:21 PM, David Jencks wrote: > There's some asymetric logic in serializing/deserializing > ResourceProxyHandler. > > Serializing: any serialized actual resource is written to the object output > stream, whereas non-serializable objects have a marker serialized. > > Deserializing: The object is read from the object input stream, but only the > marker object and CORBA stubs result in the actualResource field being set. > > Finding the marker object results in getting the resource again from the > ResourceInjectionService, typically by looking something up in jndi. > > I would prefer to always get the actual resource from the > ResourceInjectionService. Is there a strong reason not to do this? > > If anyone wants to keep the current approach, I think the logic currently in > place to reconnect a CORBA stub uses the wrong ORB, I think it needs to look > up the orb in jndi. > > I'm going to fix the current hole in the logic (rev 1053011) but IMO > serializing random objects rather than getting them from the bean is a bad > idea. Even with this I get a tck failure trying to deserialze an > EntityManagerFactory. > > thanks > david jencks >
Problem with serializing ResourceProxyHandler
There's some asymetric logic in serializing/deserializing ResourceProxyHandler. Serializing: any serialized actual resource is written to the object output stream, whereas non-serializable objects have a marker serialized. Deserializing: The object is read from the object input stream, but only the marker object and CORBA stubs result in the actualResource field being set. Finding the marker object results in getting the resource again from the ResourceInjectionService, typically by looking something up in jndi. I would prefer to always get the actual resource from the ResourceInjectionService. Is there a strong reason not to do this? If anyone wants to keep the current approach, I think the logic currently in place to reconnect a CORBA stub uses the wrong ORB, I think it needs to look up the orb in jndi. I'm going to fix the current hole in the logic (rev 1053011) but IMO serializing random objects rather than getting them from the bean is a bad idea. Even with this I get a tck failure trying to deserialze an EntityManagerFactory. thanks david jencks
[jira] Resolved: (OWB-509) Unwrap InvocationTargetException in ResourceProxyHandler.invokie
[ https://issues.apache.org/jira/browse/OWB-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks resolved OWB-509. -- Resolution: Fixed rev 1053011 also includes minor cleanup. The serialization behavior is still causing tck problems. > Unwrap InvocationTargetException in ResourceProxyHandler.invokie > > > Key: OWB-509 > URL: https://issues.apache.org/jira/browse/OWB-509 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > > ResourceProxyHandler doesn't unwrap InvocationTargetException, and nothing > else knows how either. This messes up some tck tests that test for the > wrapped exception. > There's also a logic hole in ResourceProxyHandler.readExternal where > serializable non-CORBA stub objects are ignored resulting in no > actualResource getting set. There's an easy fix although I think serializing > any resources is a bad idea, see discussion on dev list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-509) Unwrap InvocationTargetException in ResourceProxyHandler.invokie
Unwrap InvocationTargetException in ResourceProxyHandler.invokie Key: OWB-509 URL: https://issues.apache.org/jira/browse/OWB-509 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: David Jencks Assignee: Gurkan Erdogdu Fix For: 1.1.0 ResourceProxyHandler doesn't unwrap InvocationTargetException, and nothing else knows how either. This messes up some tck tests that test for the wrapped exception. There's also a logic hole in ResourceProxyHandler.readExternal where serializable non-CORBA stub objects are ignored resulting in no actualResource getting set. There's an easy fix although I think serializing any resources is a bad idea, see discussion on dev list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Is there a reason to produce non-working proxies from a ResourceBean?
Currently ResourceBean will happily produce proxies that can't possibly work if
the ResourceInjectionService returns null when asked for the resource. I think
this is really confusing for users. It certainly wasted several hours of my
time. I would prefer that the ResourceBean throw an NPE if the resource can't
be found clearly indicating that there's a problem before the unfortunate user
tries to use the proxy.
Is there a reason for the current behavior or would this change be fine?
thanks
david jencks
proposed patch:
Index:
webbeans-impl/src/main/java/org/apache/webbeans/component/ResourceBean.java
===
--- webbeans-impl/src/main/java/org/apache/webbeans/component/ResourceBean.java
(revision 1051320)
+++ webbeans-impl/src/main/java/org/apache/webbeans/component/ResourceBean.java
(working copy)
@@ -53,8 +53,13 @@
ResourceInjectionService resourceService =
ServiceLoader.getService(ResourceInjectionService.class);
X instance =
resourceService.getResourceReference(this.resourceReference);
-if (instance != null &&
Modifier.isFinal(instance.getClass().getModifiers()))
+if (instance == null)
{
+throw new NullPointerException("No instance: " + this);
+}
+
+if (Modifier.isFinal(instance.getClass().getModifiers()))
+{
return instance;
}
[jira] Commented: (OWB-493) ProcessProducerMethod and ProcessProducerField type parameters are reversed in filtering (?) CDITCK-168
[ https://issues.apache.org/jira/browse/OWB-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975071#action_12975071 ] David Jencks commented on OWB-493: -- The javadoc for ProcessProducerMethod (and ProcessProducerField) has changed to keep the erroneous order of generic type parameters but change their meaning. Old: * @param The class of the bean declaring the producer method * @param The return type of the producer method new: * @param The return type of the producer method * @param The class of the bean declaring the producer method public interface ProcessProducerMethod extends ProcessBean The test now relates to this new meaning for the parameters. I think OWB does not follow this new meaning. I don't think OWB was acting correctly according to the original meaning since it was emitting ProcessProducerMethod events (the original test passed) but the return type bean (Cow in this test) had no producer methods so no ProcessProducerMethod event should be emitted when it's processed. > ProcessProducerMethod and ProcessProducerField type parameters are reversed > in filtering (?) CDITCK-168 > > > Key: OWB-493 > URL: https://issues.apache.org/jira/browse/OWB-493 > Project: OpenWebBeans > Issue Type: Bug > Components: Events >Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > > See https://jira.jboss.org/browse/CDITCK-168 > The tck extensions.processBean.ProcessBeanTest test had a couple errors where > ProcessProducerMethod was treated as a ProcessMethod > whereas it is a ProcessMethod, and similarly for ProcessProducerField. > OWB seems to be subject to the same error. >public void observeCowProcessProducerMethod(@Observes > ProcessProducerMethod event) > is getting called correctly for the ProcessProducerMethod, but >public void observeCowShedProccesBean(@Observes ProcessBean event) > is getting called with the same event. > I haven't been able to figure out where the problem is. > The corrected test is in 1.0.2.CR3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-493) ProcessProducerMethod and ProcessProducerField type parameters are reversed in filtering (?) CDITCK-168
[
https://issues.apache.org/jira/browse/OWB-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974991#action_12974991
]
David Jencks commented on OWB-493:
--
I think there is a problem in OWB with the current test. The test has:
Cow...
public class Cowshed
{
@Produces
public Cow getDaisy()
{
return new Cow("Daisy");
}
...
public void observeCowProcessProducerMethod(@Observes
ProcessProducerMethod event)
{
ProcessBeanObserver.cowProcessProducerMethod = event;
}
which the tck expects to be called with the ProcessProducerMethod event. However, although a ProcessProducerMethod is being
constructed, it appears to be a ProcessProducerMethod so isn't
firing this observer method.
I haven't been able to figure out if the test is correct and/or how to switch
the types in the event.
> ProcessProducerMethod and ProcessProducerField type parameters are reversed
> in filtering (?) CDITCK-168
>
>
> Key: OWB-493
> URL: https://issues.apache.org/jira/browse/OWB-493
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Events
> Affects Versions: 1.1.0
>Reporter: David Jencks
>Assignee: Gurkan Erdogdu
> Fix For: 1.1.0
>
>
> See https://jira.jboss.org/browse/CDITCK-168
> The tck extensions.processBean.ProcessBeanTest test had a couple errors where
> ProcessProducerMethod was treated as a ProcessMethod
> whereas it is a ProcessMethod, and similarly for ProcessProducerField.
> OWB seems to be subject to the same error.
>public void observeCowProcessProducerMethod(@Observes
> ProcessProducerMethod event)
> is getting called correctly for the ProcessProducerMethod, but
>public void observeCowShedProccesBean(@Observes ProcessBean event)
> is getting called with the same event.
> I haven't been able to figure out where the problem is.
> The corrected test is in 1.0.2.CR3
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-493) ProcessProducerMethod and ProcessProducerField type parameters are reversed in filtering (?) CDITCK-168
[ https://issues.apache.org/jira/browse/OWB-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973126#action_12973126 ] David Jencks commented on OWB-493: -- the tck 1.0.4-SNAPSHOT has changed the test back and eliminated the counting but the tests are still failing for me in geronimo -- no events are received at all. Could someone who knows how run the standalone tck and see what happens? > ProcessProducerMethod and ProcessProducerField type parameters are reversed > in filtering (?) CDITCK-168 > > > Key: OWB-493 > URL: https://issues.apache.org/jira/browse/OWB-493 > Project: OpenWebBeans > Issue Type: Bug > Components: Events >Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > > See https://jira.jboss.org/browse/CDITCK-168 > The tck extensions.processBean.ProcessBeanTest test had a couple errors where > ProcessProducerMethod was treated as a ProcessMethod > whereas it is a ProcessMethod, and similarly for ProcessProducerField. > OWB seems to be subject to the same error. >public void observeCowProcessProducerMethod(@Observes > ProcessProducerMethod event) > is getting called correctly for the ProcessProducerMethod, but >public void observeCowShedProccesBean(@Observes ProcessBean event) > is getting called with the same event. > I haven't been able to figure out where the problem is. > The corrected test is in 1.0.2.CR3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
geronimo/owb cdi tck status
The cdi guys published a new release of the cdi tck on monday, 1.0.2.SP1. Geronimo/owb has 9 or 12 failures testNonexistentConversationExceptionThrown(org.jboss.jsr299.tck.tests.context.conversation.ClientConversationContextTest) This test was possibly inadvertently added from 1.1 (trunk) but with missing pieces. I've asked in CDITCK-191 what is intended. testGetAnnotatedMethod(org.jboss.jsr299.tck.tests.extensions.observer.ProcessObserverMethodEventTest) testProcessObserverMethodEventsSent(org.jboss.jsr299.tck.tests.extensions.observer.ProcessObserverMethodEventTest) testGetObserverMethod(org.jboss.jsr299.tck.tests.extensions.observer.ProcessObserverMethodEventTest) These are fixed currently per OWB-490 but there is a question whether the test is correct, Gurkan has opened CIDTCK-199 to try to find out what is intended. testProcessProducerMethodEvent(org.jboss.jsr299.tck.tests.extensions.processBean.ProcessBeanTest) testProcessProducerFieldEvent(org.jboss.jsr299.tck.tests.extensions.processBean.ProcessBeanTest) See OWB-493. I spent a few hours investigating this but got lost. I could use some help from OWB experts. testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) testInjectionOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) testInjectionOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) testBeanTypesAndBindingTypesOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) The immediate error here is that the persistence.xml uses a proprietary jndi name for jta-datasource. Pete says we should be able to replace the persistence.xml with one that works for us. I haven't tried yet. testInjectionIntoWebServiceEndpoint(org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.InjectionIntoWebServiceEndPointTest) I will raise a CDITCK jira asking why a web service test is run in web profile where web services are not supported. I have a little bit of evidence that there will be a problem when we run against the full server because I think the test harness is generating invalid ears: the war has a manifest class-path entry that is supposed to point to a jar with all the classes in it, but it appears to be wrong. thanks david jencks
Re: Yan:: svn commit: r1049215 - in /openwebbeans/trunk/webbeans-impl/src: main/java/org/apache/webbeans/event/NotificationManager.java test/java/org/apache/webbeans/newtests/portable/events/extension
IMO the changes committed to the tck for CDITCK-174 require the changes I
committed to OWB in order to pass. The changes in the tck for CDITCk-174 are
still present in the 1.0.2.SP1 tck. If you think these contradict the javadoc
can you file a new CDITCK jira or reopen CDITCK-174 or take some other
appropriate action with Pete or other CDI EG representative? I don't
understand what course of action you want to follow. Is it to fail the most
recent tck and ignore the problem?
thanks
david jencks
On Dec 14, 2010, at 1:14 PM, Mark Struberg wrote:
> David, as clarified by the JSP EC, API Javadocs are _always_ correct if there
> is any question or discrepance with the written spec.
>
> I have not looked at the Javadoc, but please also check the corresponding
> CDI-TCK-174
>
> https://issues.jboss.org/browse/CDITCK-174
>
>
> LieGrue,
> strub
>
> --- On Tue, 12/14/10, David Jencks wrote:
>
>> From: David Jencks
>> Subject: Re: Yan:: svn commit: r1049215 - in
>> /openwebbeans/trunk/webbeans-impl/src:
>> main/java/org/apache/webbeans/event/NotificationManager.java
>> test/java/org/apache/webbeans/newtests/portable/events/extensions/AddObserverMethodExtension.java
>> To: dev@openwebbeans.apache.org
>> Date: Tuesday, December 14, 2010, 9:02 PM
>> Since there's a new released tck that
>> doesn't change or exclude the tests in question, I tend to
>> think that current opinion in the cdi EG is that the javadoc
>> is wrong. Can you take this up with pete to find out
>> what's going on? Meanwhile I would think there would
>> be some interest in passing the tck.
>>
>> thanks
>> david jencks
>>
>> On Dec 14, 2010, at 12:50 PM, Gurkan Erdogdu wrote:
>>
>>> As pete mail, javadoc is correct therefore i reverted
>> change before. If javadoc is correct those tck tests must be
>> excluded. our code is correct because it is aligned with
>> published javadoc
>>>
>>> Sal, 14 Ara 2010 20:51 EET tarihinde djen...@apache.org
>> şöyle yazdı:
>>>
>>>> Author: djencks
>>>> Date: Tue Dec 14 18:51:54 2010
>>>> New Revision: 1049215
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1049215&view=rev
>>>> Log:
>>>> OWB-490, CDITCK-174 reapply rev 1034955 to comply
>> with cdi tck 1.0.2.SP1
>>>>
>>>> Modified:
>>>>
>>>> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/event/NotificationManager.java
>>>>
>>>> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/portable/events/extensions/AddObserverMethodExtension.java
>>>>
>>>> Modified:
>> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/event/NotificationManager.java
>>>> URL:
>>>> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/event/NotificationManager.java?rev=1049215&r1=1049214&r2=1049215&view=diff
>>>>
>> ==
>>>> ---
>> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/event/NotificationManager.java
>> (original)
>>>> +++
>> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/event/NotificationManager.java
>> Tue Dec 14 18:51:54 2010
>>>> @@ -354,13 +354,7 @@ public final class
>> NotificationManager
>>>> {
>>>> Type
>> beanClassArg = actualArgs[0];
>>>> Type
>> returnClassArg = actualArgs[1];
>>>> -
>>>> -
>> if(isObserverMethod)
>>>> -{
>>>> -
>> beanClassArg = actualArgs[1];
>>>> -
>> returnClassArg = actualArgs[0];
>>>> -}
>>>> -
>>>> +
>>
>>>>
>> if(checkEventTypeParameterForExtensions(beanClass,
>> beanClassArg) &&
>>>>
>>
>> checkEventTypeParameterForExtensions(producerOrObserverReturnClass,
>> returnClassArg))
>>>> {
>>>>
>>>> Modified:
>> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/portable/events/extensions/AddObserverMethodExtension.java
>>>> URL:
>>>> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/portable/eve
Re: Yan:: svn commit: r1049215 - in /openwebbeans/trunk/webbeans-impl/src: main/java/org/apache/webbeans/event/NotificationManager.java test/java/org/apache/webbeans/newtests/portable/events/extension
Since there's a new released tck that doesn't change or exclude the tests in
question, I tend to think that current opinion in the cdi EG is that the
javadoc is wrong. Can you take this up with pete to find out what's going on?
Meanwhile I would think there would be some interest in passing the tck.
thanks
david jencks
On Dec 14, 2010, at 12:50 PM, Gurkan Erdogdu wrote:
> As pete mail, javadoc is correct therefore i reverted change before. If
> javadoc is correct those tck tests must be excluded. our code is correct
> because it is aligned with published javadoc
>
> Sal, 14 Ara 2010 20:51 EET tarihinde djen...@apache.org şöyle yazdı:
>
>> Author: djencks
>> Date: Tue Dec 14 18:51:54 2010
>> New Revision: 1049215
>>
>> URL: http://svn.apache.org/viewvc?rev=1049215&view=rev
>> Log:
>> OWB-490, CDITCK-174 reapply rev 1034955 to comply with cdi tck 1.0.2.SP1
>>
>> Modified:
>>
>> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/event/NotificationManager.java
>>
>> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/portable/events/extensions/AddObserverMethodExtension.java
>>
>> Modified:
>> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/event/NotificationManager.java
>> URL:
>> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/event/NotificationManager.java?rev=1049215&r1=1049214&r2=1049215&view=diff
>> ==
>> ---
>> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/event/NotificationManager.java
>> (original)
>> +++
>> openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/event/NotificationManager.java
>> Tue Dec 14 18:51:54 2010
>> @@ -354,13 +354,7 @@ public final class NotificationManager
>>{
>>Type beanClassArg = actualArgs[0];
>>Type returnClassArg = actualArgs[1];
>> -
>> -if(isObserverMethod)
>> -{
>> -beanClassArg = actualArgs[1];
>> -returnClassArg = actualArgs[0];
>> -}
>> -
>> +
>>if(checkEventTypeParameterForExtensions(beanClass, beanClassArg)
>> &&
>>
>> checkEventTypeParameterForExtensions(producerOrObserverReturnClass,
>> returnClassArg))
>>{
>>
>> Modified:
>> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/portable/events/extensions/AddObserverMethodExtension.java
>> URL:
>> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/portable/events/extensions/AddObserverMethodExtension.java?rev=1049215&r1=1049214&r2=1049215&view=diff
>> ==
>> ---
>> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/portable/events/extensions/AddObserverMethodExtension.java
>> (original)
>> +++
>> openwebbeans/trunk/webbeans-impl/src/test/java/org/apache/webbeans/newtests/portable/events/extensions/AddObserverMethodExtension.java
>> Tue Dec 14 18:51:54 2010
>> @@ -40,9 +40,9 @@ public class AddObserverMethodExtension
>>
>>public static class MyBeanExtension implements Extension
>>{
>> -public static ObserverMethod observerMethod;
>> +public static ObserverMethod
>> observerMethod;
>>
>> -public void observer(@Observes ProcessObserverMethod> AddObserverMethodExtension> event)
>> +public void observer(@Observes
>> ProcessObserverMethod event)
>>{
>>observerMethod = event.getObserverMethod();
>>
>>
>>
>
>
>
[jira] Commented: (OWB-490) ProcessObserverMethod Type parameters are inverted (CDITCK-174)
[ https://issues.apache.org/jira/browse/OWB-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971371#action_12971371 ] David Jencks commented on OWB-490: -- I reapplied rev 1034955 in rev 1049215 as the 1.0.2.SP1 tck is unchanged in these tests from 1.0.2.CR3. If you disagree please get the exclusion list or tck snapshot updated before reverting this change. > ProcessObserverMethod Type parameters are inverted (CDITCK-174) > --- > > Key: OWB-490 > URL: https://issues.apache.org/jira/browse/OWB-490 > Project: OpenWebBeans > Issue Type: Bug > Components: Events >Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > > cf CDITCK-174. There's some code in NotificationManager that swaps the > arguments if it's an observer. I think this was because the tck was wrong. > Now that its fixed this swapping causes a tck failure. The order is checked > in the PortableAddObserverMethodTest and AddObserverMethodExtension which has > the opposite order as the tck ProcessObserverMethodObserver. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-490) ProcessObserverMethod Type parameters are inverted (CDITCK-174)
[ https://issues.apache.org/jira/browse/OWB-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971357#action_12971357 ] David Jencks commented on OWB-490: -- Gurkan reverted rev 1034955 in rev 1038667 and 1038669 without including the jira number in the commit message. > ProcessObserverMethod Type parameters are inverted (CDITCK-174) > --- > > Key: OWB-490 > URL: https://issues.apache.org/jira/browse/OWB-490 > Project: OpenWebBeans > Issue Type: Bug > Components: Events >Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > > cf CDITCK-174. There's some code in NotificationManager that swaps the > arguments if it's an observer. I think this was because the tck was wrong. > Now that its fixed this swapping causes a tck failure. The order is checked > in the PortableAddObserverMethodTest and AddObserverMethodExtension which has > the opposite order as the tck ProcessObserverMethodObserver. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-493) ProcessProducerMethod and ProcessProducerField type parameters are reversed in filtering (?) CDITCK-168
[ https://issues.apache.org/jira/browse/OWB-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971351#action_12971351 ] David Jencks commented on OWB-493: -- I'm seeing these errors in the recently released 1.0.2.SP1 testProcessProducerMethodEvent(org.jboss.jsr299.tck.tests.extensions.processBean.ProcessBeanTest) testProcessProducerFieldEvent(org.jboss.jsr299.tck.tests.extensions.processBean.ProcessBeanTest) > ProcessProducerMethod and ProcessProducerField type parameters are reversed > in filtering (?) CDITCK-168 > > > Key: OWB-493 > URL: https://issues.apache.org/jira/browse/OWB-493 > Project: OpenWebBeans > Issue Type: Bug > Components: Events >Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > > See https://jira.jboss.org/browse/CDITCK-168 > The tck extensions.processBean.ProcessBeanTest test had a couple errors where > ProcessProducerMethod was treated as a ProcessMethod > whereas it is a ProcessMethod, and similarly for ProcessProducerField. > OWB seems to be subject to the same error. >public void observeCowProcessProducerMethod(@Observes > ProcessProducerMethod event) > is getting called correctly for the ProcessProducerMethod, but >public void observeCowShedProccesBean(@Observes ProcessBean event) > is getting called with the same event. > I haven't been able to figure out where the problem is. > The corrected test is in 1.0.2.CR3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-490) ProcessObserverMethod Type parameters are inverted (CDITCK-174)
[ https://issues.apache.org/jira/browse/OWB-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971346#action_12971346 ] David Jencks commented on OWB-490: -- There's a new 1.0.2.SP1 cdi tck available and these tests are failing for me: testGetAnnotatedMethod(org.jboss.jsr299.tck.tests.extensions.observer.ProcessObserverMethodEventTest) testProcessObserverMethodEventsSent(org.jboss.jsr299.tck.tests.extensions.observer.ProcessObserverMethodEventTest) testGetObserverMethod(org.jboss.jsr299.tck.tests.extensions.observer.ProcessObserverMethodEventTest) Have not yet investigated why. > ProcessObserverMethod Type parameters are inverted (CDITCK-174) > --- > > Key: OWB-490 > URL: https://issues.apache.org/jira/browse/OWB-490 > Project: OpenWebBeans > Issue Type: Bug > Components: Events >Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > > cf CDITCK-174. There's some code in NotificationManager that swaps the > arguments if it's an observer. I think this was because the tck was wrong. > Now that its fixed this swapping causes a tck failure. The order is checked > in the PortableAddObserverMethodTest and AddObserverMethodExtension which has > the opposite order as the tck ProcessObserverMethodObserver. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Is EL in jsp supported at all?
On Dec 13, 2010, at 12:48 AM, Mark Struberg wrote:
> Which jasper do you use btw? The tomcat-7 jasper I looked 6 months ago was
> pretty broken... Does it work now?
AFAICT, it works fine now for normal jsps. I haven't had a chance to dig in
and see what is happening here.
david jencks
>
> LieGrue,
> strub
>
> --- On Fri, 12/10/10, David Jencks wrote:
>
>> From: David Jencks
>> Subject: Re: Is EL in jsp supported at all?
>> To: dev@openwebbeans.apache.org
>> Date: Friday, December 10, 2010, 12:56 AM
>> This property is set for this sample
>> in geronimo, and the code in WebContainerLifecycle that adds
>> an OwbELResolver is getting executed. I guess I'll
>> have to look inside jasper to see what is going on.
>>
>> thanks
>> david jencks
>>
>> On Dec 9, 2010, at 2:16 PM, Joseph Bergmark wrote:
>>
>>> There is a custom property to get the JSP chain
>> ELResolver to register, I
>>> believe to prevent us from being in the EL-Resolver
>> chain twice in the JSF
>>> case where we can't provide an instance of the bean,
>> as eventually the JSF
>>> chain delegates down to the JSP chain.
>>>
>>> The property is:
>>> #application is full jsp or not
>>> org.apache.webbeans.application.jsp=true
>>>
>>> Sincerely,
>>>
>>> Joe
>>>
>>> On Thu, Dec 9, 2010 at 4:41 PM, Mark Struberg
>> wrote:
>>>
>>>> it 'used' to work back then. I think we also have
>> an example for it.
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>> --- On Thu, 12/9/10, David Jencks
>> wrote:
>>>>
>>>>> From: David Jencks
>>>>> Subject: Is EL in jsp supported at all?
>>>>> To: dev@openwebbeans.apache.org
>>>>> Date: Thursday, December 9, 2010, 9:33 PM
>>>>> I've been trying to test 6.4.3 for
>>>>> jsp and am starting to think that OWB does not
>> support web
>>>>> beans in EL in jsp pages at all. I have
>> a jsp like
>>>>> this...
>>>>>
>>>>>
>>>>> <%...@page contentType="text/html"
>> pageEncoding="UTF-8"
>>>>> %>
>>>>> > 1.0
>>>>> Transitional//EN" "
>>>> http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
>>>>> http://www.w3.org/1999/xhtml";>
>>>>>
>>>>>
>>>>> > http-equiv="Content-Type"
>>>>> content="text/html; charset=UTF-8"/>
>>>>> > href="./css/default.css"
>>>>> rel="stylesheet"
>>>>>
>> type="text/css"/>
>>>>> Expression
>> test
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ${expressionBean}
>>>>>
>>>>>
>>>>>
>>>>> ${expressionBean.value ==
>>>>> expressionBean.value}
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> with an ExpressionBean...
>>>>>
>>>>> @Named
>>>>> public class ExpressionBean {
>>>>>
>>>>> private Counter counter;
>>>>>
>>>>> @Inject
>>>>> public void initialize(Counter
>> counter) {
>>>>> counter.create();
>>>>> this.counter =
>> counter;
>>>>> }
>>>>>
>>>>> public String getValue() {
>>>>> return "foo";
>>>>> }
>>>>>
>>>>> @PreDestroy
>>>>> public void destroy() {
>>>>> counter.destroy();
>>>>> }
>>>>>
>>>>> public Counter getCounter() {
>>>>> return counter;
>>>>> }
>>>>>
>>>>> public String getStatus() {
>>>>> return
>> counter.getStatus();
>>>>> }
>>>>>
>>>>> public String toString() {
>>>>> return
>> "ExpressionBean:
>>>>> status:" + getStatus();
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>> and an app-scoped counter. The output
>> from my jsp
>>>>> seem to indicate that EL is not finding or
>> creating an
>>>>> ExpressionBean.
>>>>>
>>>>> Am I doing something obviously stupid?
>> Is there an
>>>>> example of EL + OWB + jsp working?
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>
>
>
Re: Is EL in jsp supported at all?
This property is set for this sample in geronimo, and the code in
WebContainerLifecycle that adds an OwbELResolver is getting executed. I guess
I'll have to look inside jasper to see what is going on.
thanks
david jencks
On Dec 9, 2010, at 2:16 PM, Joseph Bergmark wrote:
> There is a custom property to get the JSP chain ELResolver to register, I
> believe to prevent us from being in the EL-Resolver chain twice in the JSF
> case where we can't provide an instance of the bean, as eventually the JSF
> chain delegates down to the JSP chain.
>
> The property is:
> #application is full jsp or not
> org.apache.webbeans.application.jsp=true
>
> Sincerely,
>
> Joe
>
> On Thu, Dec 9, 2010 at 4:41 PM, Mark Struberg wrote:
>
>> it 'used' to work back then. I think we also have an example for it.
>>
>> LieGrue,
>> strub
>>
>> --- On Thu, 12/9/10, David Jencks wrote:
>>
>>> From: David Jencks
>>> Subject: Is EL in jsp supported at all?
>>> To: dev@openwebbeans.apache.org
>>> Date: Thursday, December 9, 2010, 9:33 PM
>>> I've been trying to test 6.4.3 for
>>> jsp and am starting to think that OWB does not support web
>>> beans in EL in jsp pages at all. I have a jsp like
>>> this...
>>>
>>>
>>> <%...@page contentType="text/html" pageEncoding="UTF-8"
>>> %>
>>> >> Transitional//EN" "
>> http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
>>> http://www.w3.org/1999/xhtml";>
>>>
>>>
>>>>> content="text/html; charset=UTF-8"/>
>>>>> rel="stylesheet"
>>> type="text/css"/>
>>>Expression test
>>>
>>>
>>>
>>>
>>>
>>>
>>> ${expressionBean}
>>>
>>>
>>>
>>> ${expressionBean.value ==
>>> expressionBean.value}
>>>
>>>
>>>
>>>
>>>
>>>
>>> with an ExpressionBean...
>>>
>>> @Named
>>> public class ExpressionBean {
>>>
>>>private Counter counter;
>>>
>>>@Inject
>>>public void initialize(Counter counter) {
>>>counter.create();
>>>this.counter = counter;
>>>}
>>>
>>>public String getValue() {
>>>return "foo";
>>>}
>>>
>>>@PreDestroy
>>>public void destroy() {
>>>counter.destroy();
>>>}
>>>
>>>public Counter getCounter() {
>>>return counter;
>>>}
>>>
>>>public String getStatus() {
>>>return counter.getStatus();
>>>}
>>>
>>>public String toString() {
>>>return "ExpressionBean:
>>> status:" + getStatus();
>>>}
>>> }
>>>
>>>
>>> and an app-scoped counter. The output from my jsp
>>> seem to indicate that EL is not finding or creating an
>>> ExpressionBean.
>>>
>>> Am I doing something obviously stupid? Is there an
>>> example of EL + OWB + jsp working?
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>>
>>
>>
>>
Is EL in jsp supported at all?
I've been trying to test 6.4.3 for jsp and am starting to think that OWB does
not support web beans in EL in jsp pages at all. I have a jsp like this...
<%...@page contentType="text/html" pageEncoding="UTF-8" %>
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml";>
Expression test
${expressionBean}
${expressionBean.value == expressionBean.value}
with an ExpressionBean...
@Named
public class ExpressionBean {
private Counter counter;
@Inject
public void initialize(Counter counter) {
counter.create();
this.counter = counter;
}
public String getValue() {
return "foo";
}
@PreDestroy
public void destroy() {
counter.destroy();
}
public Counter getCounter() {
return counter;
}
public String getStatus() {
return counter.getStatus();
}
public String toString() {
return "ExpressionBean: status:" + getStatus();
}
}
and an app-scoped counter. The output from my jsp seem to indicate that EL is
not finding or creating an ExpressionBean.
Am I doing something obviously stupid? Is there an example of EL + OWB + jsp
working?
thanks
david jencks
Re: Yan:: svn commit: r1042754 - /openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml
6.4.3 starts out...
Suppose a Unified EL expression in a JSF or JSP page...
I wasn't going to say anything until I had a test I believed, but I don't see
how the ApplicationFactory solution works for jsps, and I don't see how
something that works for jsps can fail to also work for jsf pages. So far I
still think the OwbApplicationFactory doesn't do anything useful, but I'm
keeping an open mind until I have more evidence.
thanks
david jencks
On Dec 8, 2010, at 11:37 AM, Gurkan Erdogdu wrote:
> David,
>
> This is for JSF pages not an ordinary JSP pages. This is the reason why we
> registered application factory.
>
> --Gurkan
>
>
>
> - Original Message
> From: David Jencks
> To: dev@openwebbeans.apache.org
> Sent: Wed, December 8, 2010 8:25:29 PM
> Subject: Re: Yan:: svn commit: r1042754 -
> /openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml
>
> Investigating this is taking longer than I hoped. There's a tck test for
> 6.4.3,
> but it doesn't test most of the requirements in 6.4.3 and it's not clear to
> me
> that it has any relevance to how EL would work in a jsp or jsf page since the
> test doesn't involve a jsp or jsf. I enhanced the test to check the "destroy
> at
> end of evaluation" and "new expression results in new bean" requirements and
> now
> it fails in geronimo with or without the modification in faces-config.xml
> because the beans aren't getting destroyed after expression evaluation. I'm
> going to try writing an actual jsp page to check if it works.
>
> The tck test is
>
> org.jboss.jsr299.tck.tests.lookup.el.ResolutionByNameTest
>
> and my altered method is
>
> @Test
> @SpecAssertion(section="6.4.3", id="a")
> public void testQualifiedNameLookup()
> {
> assert
> getCurrentConfiguration().getEl().evaluateValueExpression("#{(game.value ==
> 'foo' and game.value == 'foo') ? game.value == 'foo' : false}",
> Boolean.class);
> assert getInstanceByType(Counter.class).getCount() == 1;
> //original test stops here
> assert getInstanceByType(Counter.class).getDestroy() == 1;
> assert
> getCurrentConfiguration().getEl().evaluateValueExpression("#{(game.value ==
> 'foo' and game.value == 'foo') ? game.value == 'foo' : false}",
> Boolean.class);
> assert getInstanceByType(Counter.class).getCount() == 2;
> assert getInstanceByType(Counter.class).getDestroy() == 2;
> }
>
>
> with the obvious corresponding changes in Counter and Game.
>
> thanks
> david jencks
>
>
> On Dec 7, 2010, at 9:49 AM, David Jencks wrote:
>
>> I'm investigating this further. I don't see any jcdi tck failures in
>> geronimo
>> with my patch so I'd like to determine if the requirements in 6.4.3 are
>> actually
>> tested.
>>
>> thanks
>> david jencks
>>
>> On Dec 7, 2010, at 5:27 AM, Gurkan Erdogdu wrote:
>>
>>> David,
>>>
>>> Does it make sense?
>>>
>>>
>>>
>>> - Original Message
>>> From: Gurkan Erdogdu
>>> To: dev@openwebbeans.apache.org
>>> Sent: Tue, December 7, 2010 8:55:45 AM
>>> Subject: Re: Yan:: svn commit: r1042754 -
>>> /openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml
>>>
>>> Hello David,
>>>
>>> Reason of installing OwbApplication is that after evaulating EL expression,
>>> you
>>>
>>> must destroy all dependent instances using in EL expression. (See
>>> specification
>>>
>>> section 6.4.3, Dependent Pseudo-scope and Unified EL).
>>>
>>> Therefore we have to implement our own ValueExpression class. Our custom
>>> ValueExpression is returned from
>>> WrappedExpressionFactory#createValueExpression
>>>
>>> (in webbeans-impl). OwbApplication#getExpressionFactory is responsible for
>>> getting WrappedExpressionFactory for getting WrappedExpressionFactory.
>>>
>>>
>>> As I said in my previons email, if developer wants to use OWB in JSF
>>> applications, it must drop webbeans-jsf.jar into its classpath. Otherwise,
>>> he
>>> is
>>>
>>>
>>> not able to use spec. compliant OWB implementation.
>>>
>>> Regards;
>>>
>>> --Gurkan
>>>
>>>
>>>
>>> - Original Message
>>>
Re: Yan:: svn commit: r1042754 - /openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml
Investigating this is taking longer than I hoped. There's a tck test for
6.4.3, but it doesn't test most of the requirements in 6.4.3 and it's not clear
to me that it has any relevance to how EL would work in a jsp or jsf page since
the test doesn't involve a jsp or jsf. I enhanced the test to check the
"destroy at end of evaluation" and "new expression results in new bean"
requirements and now it fails in geronimo with or without the modification in
faces-config.xml because the beans aren't getting destroyed after expression
evaluation. I'm going to try writing an actual jsp page to check if it works.
The tck test is
org.jboss.jsr299.tck.tests.lookup.el.ResolutionByNameTest
and my altered method is
@Test
@SpecAssertion(section="6.4.3", id="a")
public void testQualifiedNameLookup()
{
assert
getCurrentConfiguration().getEl().evaluateValueExpression("#{(game.value ==
'foo' and game.value == 'foo') ? game.value == 'foo' : false}", Boolean.class);
assert getInstanceByType(Counter.class).getCount() == 1;
//original test stops here
assert getInstanceByType(Counter.class).getDestroy() == 1;
assert
getCurrentConfiguration().getEl().evaluateValueExpression("#{(game.value ==
'foo' and game.value == 'foo') ? game.value == 'foo' : false}", Boolean.class);
assert getInstanceByType(Counter.class).getCount() == 2;
assert getInstanceByType(Counter.class).getDestroy() == 2;
}
with the obvious corresponding changes in Counter and Game.
thanks
david jencks
On Dec 7, 2010, at 9:49 AM, David Jencks wrote:
> I'm investigating this further. I don't see any jcdi tck failures in
> geronimo with my patch so I'd like to determine if the requirements in 6.4.3
> are actually tested.
>
> thanks
> david jencks
>
> On Dec 7, 2010, at 5:27 AM, Gurkan Erdogdu wrote:
>
>> David,
>>
>> Does it make sense?
>>
>>
>>
>> - Original Message
>> From: Gurkan Erdogdu
>> To: dev@openwebbeans.apache.org
>> Sent: Tue, December 7, 2010 8:55:45 AM
>> Subject: Re: Yan:: svn commit: r1042754 -
>> /openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml
>>
>> Hello David,
>>
>> Reason of installing OwbApplication is that after evaulating EL expression,
>> you
>> must destroy all dependent instances using in EL expression. (See
>> specification
>> section 6.4.3, Dependent Pseudo-scope and Unified EL).
>>
>> Therefore we have to implement our own ValueExpression class. Our custom
>> ValueExpression is returned from
>> WrappedExpressionFactory#createValueExpression
>> (in webbeans-impl). OwbApplication#getExpressionFactory is responsible for
>> getting WrappedExpressionFactory for getting WrappedExpressionFactory.
>>
>>
>> As I said in my previons email, if developer wants to use OWB in JSF
>> applications, it must drop webbeans-jsf.jar into its classpath. Otherwise,
>> he is
>>
>> not able to use spec. compliant OWB implementation.
>>
>> Regards;
>>
>> --Gurkan
>>
>>
>>
>> - Original Message
>> From: David Jencks
>> To: dev@openwebbeans.apache.org
>> Sent: Mon, December 6, 2010 11:55:59 PM
>> Subject: Re: Yan:: svn commit: r1042754 -
>> /openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml
>>
>> Irrespective of what happens to this commit, do you see any spec support for
>> installing OwbApplicationFactory for every jsf-aware web beans app? AFAICT
>> there is none and installing it is a convenience for users that they may or
>> may
>> not want. If you see something in the spec contrary to this I would like to
>> know about it. Since I don't see any spec support for this I wonder if
>> installing it automatically results in portable apps.
>>
>> thanks
>> david jencks
>>
>> On Dec 6, 2010, at 12:24 PM, Gurkan Erdogdu wrote:
>>
>>> Hi David
>>> we designed owb as a plugin way. When he wants to add jsf support, he
>>> simply
>>> drops webeansjsf.jar into classpath. Removing factory from faces config
>>> prohibits it. Therefore this issue must be resolved on geronimo side
>>> instead of
>>
>>> owb site. moreover, not every jsf application must be assumed as cdi
>>> application. for being cdi, there exist beans.xml under web-inf.therefore
>>> i
>>> will revert this change.
>>>
>>>
Re: Yan:: svn commit: r1042754 - /openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml
I'm investigating this further. I don't see any jcdi tck failures in geronimo with my patch so I'd like to determine if the requirements in 6.4.3 are actually tested. thanks david jencks On Dec 7, 2010, at 5:27 AM, Gurkan Erdogdu wrote: > David, > > Does it make sense? > > > > - Original Message > From: Gurkan Erdogdu > To: dev@openwebbeans.apache.org > Sent: Tue, December 7, 2010 8:55:45 AM > Subject: Re: Yan:: svn commit: r1042754 - > /openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml > > Hello David, > > Reason of installing OwbApplication is that after evaulating EL expression, > you > must destroy all dependent instances using in EL expression. (See > specification > section 6.4.3, Dependent Pseudo-scope and Unified EL). > > Therefore we have to implement our own ValueExpression class. Our custom > ValueExpression is returned from > WrappedExpressionFactory#createValueExpression > (in webbeans-impl). OwbApplication#getExpressionFactory is responsible for > getting WrappedExpressionFactory for getting WrappedExpressionFactory. > > > As I said in my previons email, if developer wants to use OWB in JSF > applications, it must drop webbeans-jsf.jar into its classpath. Otherwise, he > is > > not able to use spec. compliant OWB implementation. > > Regards; > > --Gurkan > > > > - Original Message > From: David Jencks > To: dev@openwebbeans.apache.org > Sent: Mon, December 6, 2010 11:55:59 PM > Subject: Re: Yan:: svn commit: r1042754 - > /openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml > > Irrespective of what happens to this commit, do you see any spec support for > installing OwbApplicationFactory for every jsf-aware web beans app? AFAICT > there is none and installing it is a convenience for users that they may or > may > not want. If you see something in the spec contrary to this I would like to > know about it. Since I don't see any spec support for this I wonder if > installing it automatically results in portable apps. > > thanks > david jencks > > On Dec 6, 2010, at 12:24 PM, Gurkan Erdogdu wrote: > >> Hi David >> we designed owb as a plugin way. When he wants to add jsf support, he simply >> drops webeansjsf.jar into classpath. Removing factory from faces config >> prohibits it. Therefore this issue must be resolved on geronimo side instead >> of > >> owb site. moreover, not every jsf application must be assumed as cdi >> application. for being cdi, there exist beans.xml under web-inf.therefore i >> will revert this change. >> >> Pzt, 06 Ara 2010 20:19 EET tarihinde djen...@apache.org şöyle yazdı: >> >>> Author: djencks >>> Date: Mon Dec 6 18:19:24 2010 >>> New Revision: 1042754 >>> >>> URL: http://svn.apache.org/viewvc?rev=1042754&view=rev >>> Log: >>> OWB-505 don't install OwbApplicationFactory by default >>> >>> Modified: >>> > openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml >>> >>> Modified: >>> openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml >>> URL: >>> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml?rev=1042754&r1=1042753&r2=1042754&view=diff >>> >>> >>> > == >>> --- >>> openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml >>> >>> (original) >>> +++ >>> openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml >>> Mon >>> >>> Dec 6 18:19:24 2010 >>> @@ -24,10 +24,6 @@ under the License. >>> >>> org_apache_openwebbeans >>> >>> - >>> - >>> org.apache.webbeans.jsf.OwbApplicationFactory >>> >>> >>> - >>> - >>> >>> >>> org.apache.webbeans.jsf.ConversationAwareViewHandler >>> >>> >>> org.apache.webbeans.el.WebBeansELResolver >>> >>> >> >> >> > >
Re: Proxy problems
On Dec 6, 2010, at 11:02 PM, Gurkan Erdogdu wrote: > Hello David, > > I understand that some classloader problems have been occured on an OSGI > based > application/server. As I tried to indicate in my post, these problems will occur in any environment that tries to isolate application and server classes. While I ran into them in an osgi context, the particular classloader feature that causes the problem has nothing to do with osgi. > > Using javassist was decided at the start of the project. All OWB modules have > been implemented/updated with respect to javassist usage. Therefore it may > not > possible to remove javassist completely and use other bytecode library in a > near > time. > > > But we can add some SPI interfaces for generating proxy classes and defaults > to > "javassist". If you wish to use another bytecode library, you could easily > implement those SPI interfaces that we did for other things. It may be > contained > in 1.2.0 (not 1.1.0) I'm not understanding what you are saying. Surely it is less work to replace javassist than put an spi layer between OWB and javasisst. Are you saying that if I say tomorrow removed javassist in favor of proxy creation that did not require exposing server classes to applications that would not be acceptable for the next OWB release? If so, why? Hoping you can clarify what you mean, david jencks > > Regards; > > --Gurkan > > > > - Original Message > From: David Jencks > To: dev@openwebbeans.apache.org > Sent: Tue, December 7, 2010 2:50:23 AM > Subject: Proxy problems > > I think there might be a problem with using javassist to build proxies. > > jsr299 allows proxying default or package access classes. > > A very definite although hard-to-find-the-documentation-for requirement of > classloaders is that all the default access classes and subclasses of default > access classes in a package have to be loaded from the same classloader (not > just be in the same package). (this has nothing to do with osgi and split > packages). > > javassist proxies require access to some javassist classes. > > Therefore any default access classes that need to be proxied need to be > loaded > in a classloader that can also load javassist classes. This certainly > prevents > isolating application classes from server libraries and may be difficult to > arrange in some circumstances. > > I think there are a couple of solutions available that use asm to construct > class proxies that only use normal jdk classes. Is there any good reason to > use > javassist rather than something else? > > thanks > david jencks > >
Proxy problems
I think there might be a problem with using javassist to build proxies. jsr299 allows proxying default or package access classes. A very definite although hard-to-find-the-documentation-for requirement of classloaders is that all the default access classes and subclasses of default access classes in a package have to be loaded from the same classloader (not just be in the same package). (this has nothing to do with osgi and split packages). javassist proxies require access to some javassist classes. Therefore any default access classes that need to be proxied need to be loaded in a classloader that can also load javassist classes. This certainly prevents isolating application classes from server libraries and may be difficult to arrange in some circumstances. I think there are a couple of solutions available that use asm to construct class proxies that only use normal jdk classes. Is there any good reason to use javassist rather than something else? thanks david jencks
Re: Yan:: svn commit: r1042754 - /openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml
Irrespective of what happens to this commit, do you see any spec support for installing OwbApplicationFactory for every jsf-aware web beans app? AFAICT there is none and installing it is a convenience for users that they may or may not want. If you see something in the spec contrary to this I would like to know about it. Since I don't see any spec support for this I wonder if installing it automatically results in portable apps. thanks david jencks On Dec 6, 2010, at 12:24 PM, Gurkan Erdogdu wrote: > Hi David > we designed owb as a plugin way. When he wants to add jsf support, he simply > drops webeansjsf.jar into classpath. Removing factory from faces config > prohibits it. Therefore this issue must be resolved on geronimo side instead > of owb site. moreover, not every jsf application must be assumed as cdi > application. for being cdi, there exist beans.xml under web-inf.therefore i > will revert this change. > > Pzt, 06 Ara 2010 20:19 EET tarihinde djen...@apache.org şöyle yazdı: > >> Author: djencks >> Date: Mon Dec 6 18:19:24 2010 >> New Revision: 1042754 >> >> URL: http://svn.apache.org/viewvc?rev=1042754&view=rev >> Log: >> OWB-505 don't install OwbApplicationFactory by default >> >> Modified: >> >> openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml >> >> Modified: >> openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml >> URL: >> http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml?rev=1042754&r1=1042753&r2=1042754&view=diff >> == >> --- >> openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml >> (original) >> +++ >> openwebbeans/trunk/webbeans-jsf/src/main/resources/META-INF/faces-config.xml >> Mon Dec 6 18:19:24 2010 >> @@ -24,10 +24,6 @@ under the License. >> >>org_apache_openwebbeans >> >> - >> - >> org.apache.webbeans.jsf.OwbApplicationFactory >> - >> - >> >> >> org.apache.webbeans.jsf.ConversationAwareViewHandler >>org.apache.webbeans.el.WebBeansELResolver >> >> > > >
[jira] Commented: (OWB-505) OwbApplicationFactory should not be installed by default
[ https://issues.apache.org/jira/browse/OWB-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12967465#action_12967465 ] David Jencks commented on OWB-505: -- rev 1042754. Not resolving for easier review. > OwbApplicationFactory should not be installed by default > > > Key: OWB-505 > URL: https://issues.apache.org/jira/browse/OWB-505 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > > Although OwbApplicationFactory is convenient, there's nothing in the spec > that indicates that something like it should be installed by default. > Currently geronimo is treating all jsf apps as web beans apps and automatic > installation of OwbApplicationFactory is interfering with some jsf tck tests > that check that getApplication returns the same as setApplication and all > ways of getting an EL ExpressionFactory return the same object. I think that > if users want the functionality of the OwbApplicationFactory they can install > it themselves. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-505) OwbApplicationFactory should not be installed by default
OwbApplicationFactory should not be installed by default Key: OWB-505 URL: https://issues.apache.org/jira/browse/OWB-505 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: David Jencks Assignee: Gurkan Erdogdu Fix For: 1.1.0 Although OwbApplicationFactory is convenient, there's nothing in the spec that indicates that something like it should be installed by default. Currently geronimo is treating all jsf apps as web beans apps and automatic installation of OwbApplicationFactory is interfering with some jsf tck tests that check that getApplication returns the same as setApplication and all ways of getting an EL ExpressionFactory return the same object. I think that if users want the functionality of the OwbApplicationFactory they can install it themselves. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-504) OwbApplicationFactory getWrapped should return wrapped application factory
[ https://issues.apache.org/jira/browse/OWB-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks resolved OWB-504. -- Resolution: Fixed rev 1042752 > OwbApplicationFactory getWrapped should return wrapped application factory > -- > > Key: OWB-504 > URL: https://issues.apache.org/jira/browse/OWB-504 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > > getWrapped currently delegates to the wrapped ApplicationFactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-504) OwbApplicationFactory getWrapped should return wrapped application factory
OwbApplicationFactory getWrapped should return wrapped application factory -- Key: OWB-504 URL: https://issues.apache.org/jira/browse/OWB-504 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: David Jencks Assignee: Gurkan Erdogdu Fix For: 1.1.0 getWrapped currently delegates to the wrapped ApplicationFactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (OWB-502) Only cache the ContextService once, in the SingletonService
Thanks and my apologies for breaking stuff I thought I had checked this but evidently not :-( BTW I don't think the slowdown from using the singleton service is something to worry about since Mark, David Blevins and I all want to rewrite the OWB wiring to avoid the static lookups which should be even faster than the TCCL cache I removed. thanks again david jencks On Nov 30, 2010, at 12:23 AM, Gurkan Erdogdu (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/OWB-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965148#action_12965148 > ] > > Gurkan Erdogdu commented on OWB-502: > > > Compiler errors fix in r1040432. > >> Only cache the ContextService once, in the SingletonService >> --- >> >> Key: OWB-502 >> URL: https://issues.apache.org/jira/browse/OWB-502 >> Project: OpenWebBeans >>Issue Type: Bug >>Components: Core >> Affects Versions: 1.0.1 >> Reporter: David Jencks >> Assignee: Gurkan Erdogdu >> Fix For: 1.0.1 >> >> >> Currently the ContextService is cached once in the SingletonService, which >> can be replaced in environments that don't use enough classloaders to >> distinguish different web apps in an ear, and also cached by classloader in >> ContextFactory, which can't as easily be replaced. Caching twice is too >> compilcated. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. >
[jira] Commented: (OWB-502) Only cache the ContextService once, in the SingletonService
[ https://issues.apache.org/jira/browse/OWB-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965037#action_12965037 ] David Jencks commented on OWB-502: -- Fixed in rev 1040364. > Only cache the ContextService once, in the SingletonService > --- > > Key: OWB-502 > URL: https://issues.apache.org/jira/browse/OWB-502 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.0.1 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.0.1 > > > Currently the ContextService is cached once in the SingletonService, which > can be replaced in environments that don't use enough classloaders to > distinguish different web apps in an ear, and also cached by classloader in > ContextFactory, which can't as easily be replaced. Caching twice is too > compilcated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-502) Only cache the ContextService once, in the SingletonService
Only cache the ContextService once, in the SingletonService --- Key: OWB-502 URL: https://issues.apache.org/jira/browse/OWB-502 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.0.1 Reporter: David Jencks Assignee: Gurkan Erdogdu Fix For: 1.0.1 Currently the ContextService is cached once in the SingletonService, which can be replaced in environments that don't use enough classloaders to distinguish different web apps in an ear, and also cached by classloader in ContextFactory, which can't as easily be replaced. Caching twice is too compilcated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-498) Java EE Resource Injections for CDI Interceptors & Decorators
[ https://issues.apache.org/jira/browse/OWB-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935477#action_12935477 ] David Jencks commented on OWB-498: -- I think there is at least a strong possibility that this should be left partly or entirely to the integration code between OWB and the EE container. There has to be some such code so that the web beans injections can be integrated into the EE containers component creation process. In geronimo this code is sufficient to also do the EE injections into web beans. > Java EE Resource Injections for CDI Interceptors & Decorators > - > > Key: OWB-498 > URL: https://issues.apache.org/jira/browse/OWB-498 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0 >Reporter: Gurkan Erdogdu >Assignee: Gurkan Erdogdu > Fix For: 1.1.0, 1.0.1 > > > Currently OWB does not inject Java EE resources to CDI interceptors and > decorators. For example > @Resource UserTransaction transaction does not work! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-497) Don't break deployment if java can't read all the annotations
[ https://issues.apache.org/jira/browse/OWB-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934669#action_12934669 ] David Jencks commented on OWB-497: -- rev 1037951 fixes the two places I've had problems from. > Don't break deployment if java can't read all the annotations > - > > Key: OWB-497 > URL: https://issues.apache.org/jira/browse/OWB-497 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: David Jencks >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > > Running the jsr303 tck with OWB installed in geronimo we run into a bunch of > exceptions that I think must be a jdk bug: calling a method that causes the > annotations on a class to be initialized (clazz.getAnnotations() for > instance) throws and exception > Caused by: java.lang.ArrayStoreException: > sun.reflect.annotation.TypeNotPresentExceptionProxy > at > sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:653) > at > sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:460) > at > sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:286) > at > sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222) > at > sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69) > at > sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52) > at java.lang.Class.initAnnotationsIfNecessary(Class.java:3070) > at java.lang.Class.getAnnotation(Class.java:3029) > at > org.apache.webbeans.util.AnnotationUtil.hasClassAnnotation(AnnotationUtil.java:865) > at > org.apache.webbeans.config.BeansDeployer.checkSpecializations(BeansDeployer.java:620) > Googling this is supposedly caused by an annotation (whose class is loadable) > having a value whose class is missing. In my particular case I can't verify > this as the cause. > In any case, OWB seems to have a policy that if a class can't have its > annotations read (e.g. ClassNotFoundException or NoClassDefFoundError) we > ignore it. I think this policy should be extended to when this exception > occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
