[jira] [Resolved] (DELTASPIKE-400) BeanBuilder should set the bean of the InjectionPoints
[ https://issues.apache.org/jira/browse/DELTASPIKE-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Porter resolved DELTASPIKE-400. - Resolution: Fixed Fix Version/s: 1.3.0 1.2.1 Fixed in commit ae145f3 > BeanBuilder should set the bean of the InjectionPoints > -- > > Key: DELTASPIKE-400 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-400 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 0.4 >Reporter: Mark Struberg >Assignee: Jason Porter > Fix For: 1.2.1, 1.3.0 > > > BeanBuilder creates Beans which have InjetionPoints without a bean set. Means > getBean() will return null for them. > This creates issues in some containers. > What we can do is to set this info if it's null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-400) BeanBuilder should set the bean of the InjectionPoints
[
https://issues.apache.org/jira/browse/DELTASPIKE-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14246957#comment-14246957
]
Jason Porter commented on DELTASPIKE-400:
-
Which code path are we talking about here? {{readFromType}} should already have
that data. If you're specifying {{InjectionPoints}} via {{injectionPoints}}
then I can see it. We can either add some checks and error out, or we could try
and create new {{InjectionPoints}} but there's no guarantee you'll have a Bean
already ready. Maybe the exception is best if you send {{InjectionPoints}}
without a {{Bean}}?
> BeanBuilder should set the bean of the InjectionPoints
> --
>
> Key: DELTASPIKE-400
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-400
> Project: DeltaSpike
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.4
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>
> BeanBuilder creates Beans which have InjetionPoints without a bean set. Means
> getBean() will return null for them.
> This creates issues in some containers.
> What we can do is to set this info if it's null.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-739) BeanBuilder#readFromType should respect @Typed
[
https://issues.apache.org/jira/browse/DELTASPIKE-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Porter updated DELTASPIKE-739:
Assignee: Rafael Benevides (was: Jason Porter)
> BeanBuilder#readFromType should respect @Typed
> --
>
> Key: DELTASPIKE-739
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-739
> Project: DeltaSpike
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.3
>Reporter: Ron Smeral
>Assignee: Rafael Benevides
> Attachments: ds-beanbuilder-typed-reproducer.zip
>
>
> {{BeanBuilder#readFromType}} currently includes all superclasses of a type in
> the set of bean types and it does not respect the {{@Typed}} annotation.
> This currently also causes a problem with PartialBeans which use {{@Typed}}.
> Example:
> {code}
> public interface Rules {}
> {code}
> {code}
> public class BaseRules implements Rules {}
> {code}
> {code}
> @SomePartialBeanBinding
> @Typed(AdminRules.class)
> public abstract class AdminRules implements Rules {}
> {code}
> {code}
> public class Controller {
> @Inject private Rules rules;
> }
> {code}
> This causes a deployment exception - ambiguous dependencies. The expected
> behaviour would be, that {{AdminRules}} is not resolvable as {{Rules}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-690) Documentation donation from RedHat
[ https://issues.apache.org/jira/browse/DELTASPIKE-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134970#comment-14134970 ] Jason Porter commented on DELTASPIKE-690: - There was good documentation up on JDF, but it looks like we've lost it in the new JBoss.org, I'll create a ticket for that. In the mean time, feel free to use https://github.com/seam/migration/blob/develop/open18_migration.asciidoc > Documentation donation from RedHat > -- > > Key: DELTASPIKE-690 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-690 > Project: DeltaSpike > Issue Type: Improvement > Components: Documentation >Reporter: John D. Ament >Assignee: Rafael Benevides > > DeltaSpike Doc Reorg Proposal > Summary of task > Develop better structure of docs so users can find required info > https://issues.apache.org/jira/browse/DELTASPIKE-642 > Areas identified for improvement > 1. Presentation > The Documentation page of the DeltaSpike site provides a long linked table of > contents. The links in the table of contents take users to the relevant > section of the document lower down the page but for a number of these > sections the user then needs to click another link to get to the actual > content (e.g., Core). > Examples are listed as the very last item of the Documentation page (and also > listed on the Home page). > Migration information appears to be linked from the menu bar only. > Recommendations > Change the landing Documentation page to solely provide a list of categorized > (and linked) titles, keeping the actual content on separate pages. [For > example, http://aerogear.org/docs/guides/] > Arrange the titles under four categories as follows: > Getting Started > Overview of DeltaSpike > Installing and Configuring DeltaSpike > Migrating to DeltaSpike > Examples and Tutorials > Using Individual Modules > Link for each module page > Reference > Build DeltaSpike from Source > API > SPI > More Resources > Blogs and Articles > Add-ons > External Examples > 2. Organization > Lots of sections contain solely a link to another section or the sole link to > another page. An example of the latter is the Project Configuration without > Maven page, in which the in-text hyperlinked ‘build’ provides the only link > to the Building DeltaSpike from Source page. This kind of organization means > that users can get easily lost navigating the documentation and makes it > harder for users to understand quickly how concepts and components fit > together. > Recommendations > Implement the presentation changes recommended in item 1, which links every > page from the Documentation page and provides a logical structure to the > content. > Within each page, structure the content as outlined in the page tables at the > end of this document. > 3. Examples and Tutorials > The existing Examples page is low on detail. > There is one (internal) DeltaSpike example listed (artifact-id: > deltaspike-jse-owb-example) but no details on how to obtain or build it. A > number of examples are distributed as part of source.zip but their existence > is not advertised on the website. The distributed examples do not have README > files to inform users what the examples are or how to use them. Several > project templates in GitHub are linked from the Documentation page but no > information is provided about them. These project templates do not have > README files to inform users what the templates are or how to use them. > The list of external DeltaSpike examples is minimal and the user has to open > every link to find out more about each. Further, some of the examples linked > here contain no README file to instruct users what the example is or how to > build it. > There are no quickstart tutorials. It difficult for a user to quickly > understand or experience adding DeltaSpike to a sample project or their own > project and assess whether they want to learn more about DeltaSpike. > Recommendations > Expand the information provided on the currently listed internal example, > including information on what the example demonstrates and how to build it. > Add 2-3 sentences about each of the examples distributed in source.zip, > specifying that the examples source is available in source.zip. > Add a README file to the source code for each distributed example in > source.zip. > Add 2-3 sentences about each of the project templates. > Add a README file to the source code for each project template in GitHub. > Provide one sentence about each of the external project links - what the > project is a demonstration of, why/when would the user find the example > helpful. > Put together a simple tutorial either: > a) demonstrating how to add (for example) the DeltaSpike Core module to a > maven project and make use of one of the main m
[jira] [Commented] (DELTASPIKE-681) Handling AccessDeniedException will run the secured method
[
https://issues.apache.org/jira/browse/DELTASPIKE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14086417#comment-14086417
]
Jason Porter commented on DELTASPIKE-681:
-
Do you know when it's called, or do you have a simple war that recreates this?
> Handling AccessDeniedException will run the secured method
> --
>
> Key: DELTASPIKE-681
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-681
> Project: DeltaSpike
> Issue Type: Bug
> Components: Core, Security-Module
>Affects Versions: 1.0.1
>Reporter: Gabor K
>
> I'm using DeltaSpike Security Module together with Picketlink. I created an
> annotation:
> @Retention(value = RetentionPolicy.RUNTIME)
> @Target({ ElementType.TYPE, ElementType.METHOD })
> @Documented
> @SecurityBindingType
> public @interface Admin { }
> Created an authorizer method:
> @Secures
> @Admin
> public boolean doSecuredCheck(InvocationContext invocationContext,
> BeanManager manager) throws Exception {
> return false; //Nobody is an admin!
> }
> An created a secured method:
> @Admin
> public void test() {
> System.out.println("in method");
> }
> So far this works fine, the method will not run when invoked from a
> h:commandButton, because the authorizer method returns false. An
> AccessDeniedException is thrown which will be displayed on the error page. It
> is very ugly.
> I wanted to handle the exception gracefully, so I created an exception
> handler:
> void printExceptions(@Handles ExceptionEvent evt) {
> FacesContext.getCurrentInstance().addMessage(null, new
> FacesMessage("You have no access!"));
> }
> The exception handler is being called, no ugly error page, and I can see the
> "You have no access!" message appearing on the page.
> Hovewer I can also see this in the console:
> "in method"
> So handling the exception caused to secured method to actually run!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DELTASPIKE-638) re-visit inconsistent handling of @BeforeHandles
[ https://issues.apache.org/jira/browse/DELTASPIKE-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14031008#comment-14031008 ] Jason Porter commented on DELTASPIKE-638: - isHandled should be false if you're doing a throwOriginal, that much looks like it should be a bug. It should also short circuit the rest of the handling. Any time you're going to throw things you're essentially saying, "I can't handle this, and I doubt anything else in the chain can either." > re-visit inconsistent handling of @BeforeHandles > > > Key: DELTASPIKE-638 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-638 > Project: DeltaSpike > Issue Type: Task > Components: ExceptionControl-Module >Affects Versions: 1.0.0 >Reporter: Gerhard Petracek >Assignee: Jason Porter > Fix For: 1.0.1 > > > #throwOriginal in a @BeforeHandles method leads to #isHandled true, once > there is a @Handles method for the same exception. however, in the end the > exception gets thrown. > reason: > the 2nd instance of DefaultExceptionEvent (for @Handles methods) in > ExceptionHandlerBroadcaster, uses the information from ExceptionToCatchEvent. > that also leads to the situation that every change done by a @BeforeHandles > method isn't visible in a @Handles method. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-510) PersistenceException not handled by @Handles @FacesRequest ExceptionEvent
[
https://issues.apache.org/jira/browse/DELTASPIKE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13879213#comment-13879213
]
Jason Porter commented on DELTASPIKE-510:
-
No problem, glad you found the issue!
> PersistenceException not handled by @Handles @FacesRequest
> ExceptionEvent
> -
>
> Key: DELTASPIKE-510
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-510
> Project: DeltaSpike
> Issue Type: Bug
> Components: ExceptionControl-Module
>Affects Versions: 0.5
> Environment: JBoss AS 7.1
>Reporter: Esteve
> Labels: exception-handling
>
> Hi,
> I have defined a @ExceptionHandler like this:
> @ExceptionHandler
> public class FacesExceptionHandler {
> @Inject
> private Logger log;
>
> public void handlePersistenceException(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext
> facesContext) {
> log.debug( "JSF Exception handler. Handling
> javax.persistence.PersistenceException: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, "S'ha produït un error al
> emmagatzemar les dades a la base de dades:
> "+evt.getException().getLocalizedMessage() , ""));
> evt.handledAndContinue();
> }
> public void handleOptimisticLockException(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext facesContext) {
> log.debug( "JSF Exception handler. Handling
> OptimisticLockException: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, "El registre ha estat modificat a
> la base de dades per un altre procés. Les dades no s'han guardat.", ""));
> evt.handled();
> }
> public void showFacesMessage(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext facesContext) {
> log.debug( "JSF Exception handler. Handling Throwable: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, evt.getException().getMessage(),
> ""));
> evt.handledAndContinue();
> }
>
>
> }
> But javax.persistence.PersistenceException is not handled:
> (http-localhost-127.0.0.1-8080-4) Error processing Update: :
> javax.persistence.PersistenceException:
> org.hibernate.exception.ConstraintViolationException: Unique index or primary
> key violation: "CONSTRAINT_INDEX_4 ON
> PUBLIC.UNITAT_NEGOCI_CANAL_VENDA(UNITAT_NEGOCI_ID, CANAL_VENDA_ID)"; SQL
> statement:
> update UNITAT_NEGOCI_CANAL_VENDA set CODI_USUARI_ULTIMA_MODIFICACIO=?,
> DATAHORA_CREACIO=?, DATAHORA_ULTIMA_MODIFICACIO=?, DATAHORA_ALTA=?,
> DATAHORA_BAIXA=?, CANAL_VENDA_ID=?, UNITAT_NEGOCI_ID=?, VERSION=? where ID=?
> and VERSION=? [23505-161]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:976)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.jboss.as.jpa.container.AbstractEntityManager.flush(AbstractEntityManager.java:439)
> [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at
> cat.tmb.tdo.ocicommerce.view.UnitatNegociCanalVendaBean.update(UnitatNegociCanalVendaBean.java:157)
> [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.7.0_51]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [rt.jar:1.7.0_51]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at
> org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
> [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:127)
[jira] [Commented] (DELTASPIKE-510) PersistenceException not handled by @Handles @FacesRequest ExceptionEvent
[
https://issues.apache.org/jira/browse/DELTASPIKE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13879186#comment-13879186
]
Jason Porter commented on DELTASPIKE-510:
-
This is working exactly as it should, and exactly as it is documented. Take a
look at http://deltaspike.apache.org/core.html#exception-handler-annotations,
the last example. In both the example and the code in your project the
exception handlers are being qualified, exactly the same way qualifiers in base
CDI.
Without seeing where this exception is coming from (is the exception qualified
when it's sent to exception handling?) the best I can surmise is that the
exception when it is sent for exception handling is not receiving the
{{@FacesRequest}} qualifier, therefore none of the handlers in your code will
pick it up.
> PersistenceException not handled by @Handles @FacesRequest
> ExceptionEvent
> -
>
> Key: DELTASPIKE-510
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-510
> Project: DeltaSpike
> Issue Type: Bug
> Components: ExceptionControl-Module
>Affects Versions: 0.5
> Environment: JBoss AS 7.1
>Reporter: Esteve
> Labels: exception-handling
>
> Hi,
> I have defined a @ExceptionHandler like this:
> @ExceptionHandler
> public class FacesExceptionHandler {
> @Inject
> private Logger log;
>
> public void handlePersistenceException(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext
> facesContext) {
> log.debug( "JSF Exception handler. Handling
> javax.persistence.PersistenceException: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, "S'ha produït un error al
> emmagatzemar les dades a la base de dades:
> "+evt.getException().getLocalizedMessage() , ""));
> evt.handledAndContinue();
> }
> public void handleOptimisticLockException(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext facesContext) {
> log.debug( "JSF Exception handler. Handling
> OptimisticLockException: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, "El registre ha estat modificat a
> la base de dades per un altre procés. Les dades no s'han guardat.", ""));
> evt.handled();
> }
> public void showFacesMessage(@Handles @FacesRequest
> ExceptionEvent evt, FacesContext facesContext) {
> log.debug( "JSF Exception handler. Handling Throwable: ", evt);
> facesContext.addMessage(null, new
> FacesMessage(FacesMessage.SEVERITY_ERROR, evt.getException().getMessage(),
> ""));
> evt.handledAndContinue();
> }
>
>
> }
> But javax.persistence.PersistenceException is not handled:
> (http-localhost-127.0.0.1-8080-4) Error processing Update: :
> javax.persistence.PersistenceException:
> org.hibernate.exception.ConstraintViolationException: Unique index or primary
> key violation: "CONSTRAINT_INDEX_4 ON
> PUBLIC.UNITAT_NEGOCI_CANAL_VENDA(UNITAT_NEGOCI_ID, CANAL_VENDA_ID)"; SQL
> statement:
> update UNITAT_NEGOCI_CANAL_VENDA set CODI_USUARI_ULTIMA_MODIFICACIO=?,
> DATAHORA_CREACIO=?, DATAHORA_ULTIMA_MODIFICACIO=?, DATAHORA_ALTA=?,
> DATAHORA_BAIXA=?, CANAL_VENDA_ID=?, UNITAT_NEGOCI_ID=?, VERSION=? where ID=?
> and VERSION=? [23505-161]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:976)
> [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
> at
> org.jboss.as.jpa.container.AbstractEntityManager.flush(AbstractEntityManager.java:439)
> [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at
> cat.tmb.tdo.ocicommerce.view.UnitatNegociCanalVendaBean.update(UnitatNegociCanalVendaBean.java:157)
> [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.7.0_51]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [rt.jar:1.7.0_51]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at
> org.jboss.as.ee.component.Mana
[jira] [Commented] (DELTASPIKE-449) ExceptionHandler not invoked for AccessDeniedException
[ https://issues.apache.org/jira/browse/DELTASPIKE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13841317#comment-13841317 ] Jason Porter commented on DELTASPIKE-449: - Rainer: This is great! Would you be okay contributing this up to DeltaSpike? Do you have a CLA on file with Apache? > ExceptionHandler not invoked for AccessDeniedException > -- > > Key: DELTASPIKE-449 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-449 > Project: DeltaSpike > Issue Type: New Feature > Components: Security-Module >Affects Versions: 0.5 > Environment: Glassfish 4 / Weld 2.0.4 >Reporter: John Schneider >Assignee: Jason Porter > > When an > org.apache.deltaspike.security.api.authorization.AccessDeniedException is > thrown, a valid ExceptionHandler method is not invoked. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DELTASPIKE-445) read ProjectStage also from a few other places
[ https://issues.apache.org/jira/browse/DELTASPIKE-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13829093#comment-13829093 ] Jason Porter commented on DELTASPIKE-445: - I also prefer option number 2. There are only so many places you can look. We're also setting them via the deltaspike configuration right? That's extensible, so you can create your own extensions for reading / resolving configurations and therefore make it expandable for where to find / set the ProjectStage. > read ProjectStage also from a few other places > -- > > Key: DELTASPIKE-445 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-445 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Affects Versions: 0.5 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 0.6 > > > We currently only read the ProjectStage setting from > "org.apache.deltaspike.ProjectStage". > We should also try to read the info from the other ususal suspects: > - javax.faces.PROJECT_STAGE > - faces.PROJECT_STAGE > We have 2 options to do so: > 1.) introduce a SPI and make it expandable. But I honestly doubt this is > worth the hassle. > 2.) Just add the other locations and iterate through them directly in the > ProjectStageProducer. > I honestly prefer 2. Not as perfectly as clean, but way easier and usually > this i snothing a user will change anyway. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DELTASPIKE-341) Provide Integration between Faces Exceptions and Exception Handling
[ https://issues.apache.org/jira/browse/DELTASPIKE-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806980#comment-13806980 ] Jason Porter commented on DELTASPIKE-341: - Cody, if you have a working example with the Deactivatable code, that would be a great addition to add to some documentation. > Provide Integration between Faces Exceptions and Exception Handling > --- > > Key: DELTASPIKE-341 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-341 > Project: DeltaSpike > Issue Type: Improvement >Reporter: Cody Lerum >Assignee: Jason Porter > Fix For: 0.6 > > > Just an ExceptionHandlerFactory and ExceptionHandlerWrapper which fire and > remove events so that DS core exceptional handling can intercept. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DELTASPIKE-334) CDI + Blueprint integration
[
https://issues.apache.org/jira/browse/DELTASPIKE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806863#comment-13806863
]
Jason Porter commented on DELTASPIKE-334:
-
I believe part (or maybe all of this?) is being done with PAX CDI. Anyone
working on that here?
> CDI + Blueprint integration
> ---
>
> Key: DELTASPIKE-334
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-334
> Project: DeltaSpike
> Issue Type: New Feature
>Reporter: Charles Moulliard
>Assignee: Charles Moulliard
>Priority: Minor
>
> Description should be enriched by authors (Jason, ...)
> {code}
> From:Nodet Guillaume
> Such a xml is in the META-INF/beans.xml, right ? So that you can override the
> behaviour of annotations ?
> I'm not sure how / where we could use it, and that does not seem really
> critical to me anyway.
> I think we'd better come to an understanding of the use case we'd want to
> cover.
> I'm thinking about:
> * #1 create beans using the CDI container
> * #2 inject CDI beans into blueprint beans using the blueprint xml
> * #3 inject blueprint beans into CDI beans using @Inject
> * #4 support CDI annotations on blueprint beans (@PostConstruct,
> @PreDestroy, @Inject)
> #1 is obviously needed, it could be done from the blueprint xml using a
> simple tag, eventually pointing to the beans.xml config file, or inline it
> (though inlining is not really worth the pain now imho)
> >>
> >>
> >>
> #2 means being able to use one of the bean created from the CDI container and
> inject it using the xml blueprint syntax, something like
>
>
>
> Not sure what exactly we'd need in the element, but the idea is
> to use the bean setters to inject a bean created inside the CDI container
> #3 means that we'd need to be able to inject a bean created by the blueprint
> container using into a @Inject annotated property of a CDI bean
> created by the CDI container. In blueprint, beans are referred to by name
> though, so it may require a custom annotation maybe ?
> #4 means mixing CDI annotations with blueprint beans. It's the most
> complicated case I think, as it needs an even closer cooperation of both
> containers.
> This needs to be triggered either globally or an individual bean using a flag
> such an xml attribute such as cdirocess="true" that could be set on a
> element or a default attribute on the element.
> Cheers,
> Guillaume Nodet
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (DELTASPIKE-414) HttpServletRequest (and others) injection not working in servlet filters from web.xml
[ https://issues.apache.org/jira/browse/DELTASPIKE-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13783102#comment-13783102 ] Jason Porter commented on DELTASPIKE-414: - I'll add my +1 to doing this with a Listener instead of a filter, unless for some reason a container doesn't support CDI in Listeners (which it should) > HttpServletRequest (and others) injection not working in servlet filters from > web.xml > - > > Key: DELTASPIKE-414 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-414 > Project: DeltaSpike > Issue Type: Bug > Components: Servlet-Module >Affects Versions: 0.5 >Reporter: Emond Papegaaij > > DeltaSpike uses a filter to record the request and response objects for > injection in that thread. This filter is configured in web-fragment.xml, > which is loaded before other web-fragments, but not before web.xml. Filters > from web.xml will be first in the chain, breaking request and response > injection into these filters with "Attempt to access the request/response > without an active HTTP request" (RequestResponseHolder:85). > We are moving from Solder, where the request and response objects were > recorded in a ServletRequestListener, which is always fired first, regardless > of it's position in the web.xml/web-fragment.xml. I think DeltaSpike should > use the same approach. > For now, a workaround is to copy the configuration of > RequestResponseHolderFilter to your web.xml and put it before all other > filters. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (DELTASPIKE-413) Add the ability to create Seam 2 like Factories
Jason Porter created DELTASPIKE-413: --- Summary: Add the ability to create Seam 2 like Factories Key: DELTASPIKE-413 URL: https://issues.apache.org/jira/browse/DELTASPIKE-413 Project: DeltaSpike Issue Type: Improvement Components: Data-Module Affects Versions: 0.5 Reporter: Jason Porter For more information see http://stackoverflow.com/questions/18774025/how-can-i-update-a-collection-that-is-produces-applicationscoped and http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Data-module-full-replacement-for-Seam-Factories-td4655749.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-391) Memory Leak in Data Module
[ https://issues.apache.org/jira/browse/DELTASPIKE-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13702049#comment-13702049 ] Jason Porter commented on DELTASPIKE-391: - Singleton won't do any good, in weld, and I believe in OWB, singleton behaves the same way as Application. Honestly you're better off to go with dependent or request scoped, possibly session if you want things to last even longer. > Memory Leak in Data Module > -- > > Key: DELTASPIKE-391 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-391 > Project: DeltaSpike > Issue Type: Bug > Components: Data-Module >Affects Versions: 0.5 >Reporter: Thomas Hug >Assignee: Thomas Hug >Priority: Critical > > Might be a side effect from moving QueryHandler to application scope. Several > beans injected over Instance<> are not cleaned up properly (probably handled > as dependent). Will do some further analysis. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-386) PropertyFileUtils.getResourceBundle() fails in EAR
[ https://issues.apache.org/jira/browse/DELTASPIKE-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690494#comment-13690494 ] Jason Porter commented on DELTASPIKE-386: - With such a small change, would you like to attach a patch or send a pull request? > PropertyFileUtils.getResourceBundle() fails in EAR > -- > > Key: DELTASPIKE-386 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-386 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 0.4 > Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1) >Reporter: Richard DiCroce > > The method PropertyFileUtils.getResourceBundle(String bundleName, Locale > locale) doesn't work correctly in an EAR. > I have the DS core JARs in the EAR /lib and I'm trying to use the JsfMessage > feature in one of my WARs. Because getResourceBundle() calls > ResourceBundle.getBundle(String bundleName, Locale locale), Java attempts to > load the resource bundle using the classloader that was used to load > PropertyFileUtils, which is the EAR's classloader. The property files are in > the WAR, so Java can't find them. > Changing > return ResourceBundle.getBundle(bundleName, locale); > to > return ResourceBundle.getBundle(bundleName, locale, > Thread.currentThread().getContextClassLoader()); > fixes the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-386) PropertyFileUtils.getResourceBundle() fails in EAR
[ https://issues.apache.org/jira/browse/DELTASPIKE-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690495#comment-13690495 ] Jason Porter commented on DELTASPIKE-386: - Larger patches require an iCLA to be on file, but with small patches we should be okay w/o one. > PropertyFileUtils.getResourceBundle() fails in EAR > -- > > Key: DELTASPIKE-386 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-386 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 0.4 > Environment: JBoss AS 7.2.0.Final (EAP 6.1.0.Alpha1) >Reporter: Richard DiCroce > > The method PropertyFileUtils.getResourceBundle(String bundleName, Locale > locale) doesn't work correctly in an EAR. > I have the DS core JARs in the EAR /lib and I'm trying to use the JsfMessage > feature in one of my WARs. Because getResourceBundle() calls > ResourceBundle.getBundle(String bundleName, Locale locale), Java attempts to > load the resource bundle using the classloader that was used to load > PropertyFileUtils, which is the EAR's classloader. The property files are in > the WAR, so Java can't find them. > Changing > return ResourceBundle.getBundle(bundleName, locale); > to > return ResourceBundle.getBundle(bundleName, locale, > Thread.currentThread().getContextClassLoader()); > fixes the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-118) custom port for jbossas-build-managed-7
[ https://issues.apache.org/jira/browse/DELTASPIKE-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686264#comment-13686264 ] Jason Porter commented on DELTASPIKE-118: - When we add support for Wildfly we should be okay with jvm options: https://issues.jboss.org/browse/WFLY-330 > custom port for jbossas-build-managed-7 > --- > > Key: DELTASPIKE-118 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-118 > Project: DeltaSpike > Issue Type: Task > Components: Tests >Affects Versions: 0.1-incubating >Reporter: Gerhard Petracek >Assignee: Mark Struberg > Fix For: 0.5 > > > we need a custom port to run in on jenkins. > ( blocked by https://issues.jboss.org/browse/AS7-1036 ) > we could replace standalone.xml after the unpack process (in > process-test-classes) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-259) @Transactional should support binding qualifier members
[ https://issues.apache.org/jira/browse/DELTASPIKE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686262#comment-13686262 ] Jason Porter commented on DELTASPIKE-259: - Since EE7 has come out now, I'm guessing we should align this with the new functionality from the JTA 1.2 revision > @Transactional should support binding qualifier members > --- > > Key: DELTASPIKE-259 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-259 > Project: DeltaSpike > Issue Type: Improvement > Components: JPA-Module >Affects Versions: 0.3-incubating >Reporter: Gerhard Petracek >Assignee: Mark Struberg > Fix For: 0.5 > > > right now qualifiers are stored via Class -> the usage > of qualifiers is restricted to @Q1, @Q2,... -> @Q(1) and @Q(2) isn't > supported currently. -- 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
