January 2014 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-413) Update outdated license

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-413?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-413: ------------------------------------------ Should provide a way to generate two different licence at build time. *Fixing Leads* Could be fixed by adding option in the [doc generation script|https://github.com/cdi-spec/cdi/blob/master/spec/generate.sh] or by introducing a generation thru Maven [Asciidoctor plugin|http://asciidoctor.org/news/2013/04/16/introducing-the-asciidoctor...] and profiles. > Update outdated license > ----------------------- > > Key: CDI-413 > URL: https://issues.jboss.org/browse/CDI-413 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 1.1.FD > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated. > As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license...] for the JCP and the ASL2 for the website download. > Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11...] it mention Red Hat Middleware LLC instead of Red Hat, Inc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-413) Update outdated license

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-413?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-413: ------------------------------------- Labels: Ready_to_fix (was: ) > Update outdated license > ----------------------- > > Key: CDI-413 > URL: https://issues.jboss.org/browse/CDI-413 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 1.1.FD > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated. > As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license...] for the JCP and the ASL2 for the website download. > Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11...] it mention Red Hat Middleware LLC instead of Red Hat, Inc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 3 months

1
0
0 / 0

Time to start the MR

by Antoine Sabot-Durand

Hi all, After resolving some misunderstanding with JCP we’re now ready to start the MR. So we can start to fix the issue list for CDI 1.2 [1] To be as efficient as possible in our asynchronous working mode I propose the following rules : 1. I propose that we favorite IRC over Hangout to organize our work (I lost too much time by typing meeting minutes from my hangout notes when we could have them directly from IRC meeting bot). Off course JIRA and the ML are also place to discuss about this MR content. 2. We should have an IRC meeting once a week (at the same time that we use to have the Hangout). Starting the coming monday (jan 27th) at 6:00pm CET. Off course I’ll try to be reachable on IRC as often as possible during my workday. 3. Proposed workflow on issues - To be able to start work on an issue, Jira discussion should be closed. - Spec leads propose a discussion closing on an issue by applying the label « Ready To Fix » and sum up the resolution choice in the comment of the issue - Other EG member have 48 hours (2 working days) or until the next weekly meeting (whichever is shorter) to disagree (should the spec lead missed something or made a mistake in this closing). - After this delay one of the spec leads will replace the label by a « to be assigned label » - Issue picking is based on volunteering, so each EG member can decide to pick an issue to fix it. Assignation discussion will also take place on weekly meetings - When the assignee start work on the issue he puts it in « in progress » state - As usual when the work is finish a PR is sent to the spec repo for review - PR should be added to Jira as well - When the PR is accepted, the assigned put the issue is resolved state. I hope this way of proceeding is ok for you all. If it’s not the case let me know. To be efficient, I’ll start to put some issues in « Ready To Fix » state tomorrow and we will discuss about their adoption and assignation on monday meeting [1] https://issues.jboss.org/browse/CDI-413?jql=fixVersion%20%3D%20"1.2%20Proposed"%20AND%20project%20%3D%20CDI. Antoine

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-102) Support Injection of Servlet Contexts

by yangju (JIRA)

[ https://issues.jboss.org/browse/CDI-102?page=com.atlassian.jira.plugin.sy... ] yangju commented on CDI-102: ---------------------------- Sorry, forgot to mention the jboss version is Wildfly CR1 > Support Injection of Servlet Contexts > ------------------------------------- > > Key: CDI-102 > URL: https://issues.jboss.org/browse/CDI-102 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.EDR > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-102) Support Injection of Servlet Contexts

by yangju (JIRA)

[ https://issues.jboss.org/browse/CDI-102?page=com.atlassian.jira.plugin.sy... ] yangju commented on CDI-102: ---------------------------- Any solution to this issue? I got error when deploy application with Solder-impl.3.2.0.Final: Exception 0 : org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type HttpServletRequest with qualifiers @Default at injection point [BackedAnnotatedField] @Inject private org.jboss.solder.servlet.http.CookieParamProducer.request at org.jboss.solder.servlet.http.CookieParamProducer.request(CookieParamProducer.java:0) Possible dependencies: - WELD|AbstractSyntheticBean|epen-login-1.4.30-SNAPSHOT.war/WEB-INF/lib/solder-impl-3.2.0.Final.jar|HttpServletRequest, - Producer Method [HttpServletRequest] with qualifiers [@Any @Default] declared as [[BackedAnnotatedMethod] @Produces @Typed @RequestScoped protected org.jboss.solder.servlet.http.ImplicitHttpServletObjectsProducer.getHttpServletRequest()] at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:369) at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:282) at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:133) at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164) at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:507) at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68) at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66) at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60) at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) > Support Injection of Servlet Contexts > ------------------------------------- > > Key: CDI-102 > URL: https://issues.jboss.org/browse/CDI-102 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.EDR > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-415) Observer resolution doesn't specify handling of null parameter values

by Michael Kotten (JIRA)

Michael Kotten created CDI-415: ---------------------------------- Summary: Observer resolution doesn't specify handling of null parameter values Key: CDI-415 URL: https://issues.jboss.org/browse/CDI-415 Project: CDI Specification Issues Issue Type: Clarification Components: Events Reporter: Michael Kotten Priority: Minor There is a gap in chapter 10.2 of the current CDI spec about [observer resolution|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#observer_reso...]. It doesn't specify what should happen if an event gets fired using a null value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 3 months

1
0
0 / 0

How to specify priority of interceptor registered as custom bean?

by Gunnar Morling

Hi, Using a CDI portable extension, I'm registering a custom bean which represents an interceptor (by implementing the javax.enterprise.inject.spi.Interceptor interface). My question now is how to specify the priority of that interceptor. Intuitively I had expected a method such as Interceptor#getPriority(), but there isn't such method. In section 9 the spec says extensions could "override the interceptor order defined by the @Priority annotation" and refers to section 11.5.2 which introduces AfterTypeDiscovery#getInterceptors(). So I could use this to add my interceptor, but I don't see how I could specify the priority while doing so. How can this be achieved? Many thanks, --Gunnar

10 years, 3 months

2
4
0 / 0

CDI 1.1 MR official launch on the 13th

by Antoine Sabot-Durand

Hi all, Happy new year guys ! I wish to all of you the best in your personal and professional life in 2014. So I did the JCP « paperwork » and the the MR will be officially launched next monday (the 13th) and should be closed on march 11th. The last point that was to be decided was about CDI-411: CDI conversation activation conflicts with the Servlet spec [1]. After exchanging with Jozef on the subject we decided to definitely include this in the MR. I also included a last ticket : CDI-413 : Update outdated license. To propose different license according the site where spec is downloaded. Antoine [1] : https://issues.jboss.org/browse/CDI-411 [2] : https://issues.jboss.org/browse/CDI-413

10 years, 4 months

2
2
0 / 0

[JBoss JIRA] (CDI-411) CDI conversation activation conflicts with the Servlet spec

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-411?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-411: ------------------------------------- Labels: (was: Investigate) > CDI conversation activation conflicts with the Servlet spec > ----------------------------------------------------------- > > Key: CDI-411 > URL: https://issues.jboss.org/browse/CDI-411 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.FD > Reporter: Jozef Hartinger > Fix For: 1.2 Proposed > > > The Servlet specification says: > {quote} > If the client hasn't set character encoding and the request data is encoded with a > different encoding than the default as described above, breakage can occur. To > remedy this situation, a new method setCharacterEncoding(String enc) has been > added to the ServletRequest interface. Developers can override the character > encoding supplied by the container by calling this method. It must be called prior to > parsing any post data or reading any input from the request. Calling this method > once data has been read will not affect the encoding. > {quote} > The CDI specification says: > {quote} > The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the > user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the > application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any > service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web > application and before the container calls any ServletRequestListener or AsyncListener in the web application. > {quote} > and > {quote} > The long-running conversation associated with a request may be propagated to any Servlet request via use of a request > parameter named cid containing the unique identifier of the conversation. > {quote} > This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding. > This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-414) Support for "self" injection

by Arne Limburg (JIRA)

[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ] Arne Limburg commented on CDI-414: ---------------------------------- This works with normal-scoped beans (@ApplicationScoped, @SessionScoped, ...) Which scope are you using? > Support for "self" injection > ---------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev January 2014