first steps for the next release
hi @ all, if there are no objections, i will start with the first steps for the next release (v0.7) by the end of next week. regards, gerhard
[jira] [Updated] (DELTASPIKE-472) Implement portable extensions that install custom beans when not running inside a WAR file.
[ https://issues.apache.org/jira/browse/DELTASPIKE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-472: Fix Version/s: (was: 0.7) Implement portable extensions that install custom beans when not running inside a WAR file. --- Key: DELTASPIKE-472 URL: https://issues.apache.org/jira/browse/DELTASPIKE-472 Project: DeltaSpike Issue Type: Improvement Components: Core Reporter: John D. Ament Assignee: John D. Ament In many cases, when you deploy with CDI you're using a self contained WAR that has everything in it. However, in certain deployment models you can reference external classpath entries that could be available to you, but not scanned based on CDI scanning rules. To work with these more efficiently, we need to implement some extensions that do very basic things, mostly installing custom beans at runtime to the destination applications. I'll go through the application and identify cases where we need to install a bean, ignoring things that obviously don't belong, e.g. @Typed classes which are understood to not be installed. At a minimum we should create extensions that encompass our primary features, where they don't already exist - for example, Partial Bean is already an extension and needs no other work, Bean Validation doesn't need an extension since it can be configured, Servlet simply needs to be registered. Most of this work seems to be in Core. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DELTASPIKE-472) Implement portable extensions that install custom beans when not running inside a WAR file.
[ https://issues.apache.org/jira/browse/DELTASPIKE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek closed DELTASPIKE-472. --- Implement portable extensions that install custom beans when not running inside a WAR file. --- Key: DELTASPIKE-472 URL: https://issues.apache.org/jira/browse/DELTASPIKE-472 Project: DeltaSpike Issue Type: Improvement Components: Core Reporter: John D. Ament Assignee: John D. Ament In many cases, when you deploy with CDI you're using a self contained WAR that has everything in it. However, in certain deployment models you can reference external classpath entries that could be available to you, but not scanned based on CDI scanning rules. To work with these more efficiently, we need to implement some extensions that do very basic things, mostly installing custom beans at runtime to the destination applications. I'll go through the application and identify cases where we need to install a bean, ignoring things that obviously don't belong, e.g. @Typed classes which are understood to not be installed. At a minimum we should create extensions that encompass our primary features, where they don't already exist - for example, Partial Bean is already an extension and needs no other work, Bean Validation doesn't need an extension since it can be configured, Servlet simply needs to be registered. Most of this work seems to be in Core. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-472) Implement portable extensions that install custom beans when not running inside a WAR file.
[ https://issues.apache.org/jira/browse/DELTASPIKE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-472. - Resolution: Later currently there is no agreement about this topic Implement portable extensions that install custom beans when not running inside a WAR file. --- Key: DELTASPIKE-472 URL: https://issues.apache.org/jira/browse/DELTASPIKE-472 Project: DeltaSpike Issue Type: Improvement Components: Core Reporter: John D. Ament Assignee: John D. Ament In many cases, when you deploy with CDI you're using a self contained WAR that has everything in it. However, in certain deployment models you can reference external classpath entries that could be available to you, but not scanned based on CDI scanning rules. To work with these more efficiently, we need to implement some extensions that do very basic things, mostly installing custom beans at runtime to the destination applications. I'll go through the application and identify cases where we need to install a bean, ignoring things that obviously don't belong, e.g. @Typed classes which are understood to not be installed. At a minimum we should create extensions that encompass our primary features, where they don't already exist - for example, Partial Bean is already an extension and needs no other work, Bean Validation doesn't need an extension since it can be configured, Servlet simply needs to be registered. Most of this work seems to be in Core. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-453) Provide @Eager for ApplicationScoped beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-453. - Resolution: Won't Fix currently there is no agreement about this topic Provide @Eager for ApplicationScoped beans -- Key: DELTASPIKE-453 URL: https://issues.apache.org/jira/browse/DELTASPIKE-453 Project: DeltaSpike Issue Type: New Feature Components: Core Reporter: Thomas Andraschko Attachments: 453.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DELTASPIKE-453) Provide @Eager for ApplicationScoped beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek closed DELTASPIKE-453. --- Provide @Eager for ApplicationScoped beans -- Key: DELTASPIKE-453 URL: https://issues.apache.org/jira/browse/DELTASPIKE-453 Project: DeltaSpike Issue Type: New Feature Components: Core Reporter: Thomas Andraschko Attachments: 453.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-449) ExceptionHandler not invoked for AccessDeniedException
[ https://issues.apache.org/jira/browse/DELTASPIKE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-449: Attachment: DELTASPIKE-449.patch 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 Attachments: DELTASPIKE-449.patch 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.2#6252)
[jira] [Closed] (DELTASPIKE-441) provide a default implementation for the interface 'SecurityViolation'
[ https://issues.apache.org/jira/browse/DELTASPIKE-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek closed DELTASPIKE-441. --- provide a default implementation for the interface 'SecurityViolation' -- Key: DELTASPIKE-441 URL: https://issues.apache.org/jira/browse/DELTASPIKE-441 Project: DeltaSpike Issue Type: Improvement Components: Security-Module Affects Versions: 0.5 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.7 I've seen quite some code using DeltaSpike already and everytime there was either tons of anonymous classes which always looked the same, or a simple discrete class for SecurityViolation. We should really just provide a simple implementation class with a String parameter. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-441) provide a default implementation for the interface 'SecurityViolation'
[ https://issues.apache.org/jira/browse/DELTASPIKE-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-441. - Resolution: Fixed provide a default implementation for the interface 'SecurityViolation' -- Key: DELTASPIKE-441 URL: https://issues.apache.org/jira/browse/DELTASPIKE-441 Project: DeltaSpike Issue Type: Improvement Components: Security-Module Affects Versions: 0.5 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.7 I've seen quite some code using DeltaSpike already and everytime there was either tons of anonymous classes which always looked the same, or a simple discrete class for SecurityViolation. We should really just provide a simple implementation class with a String parameter. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-440) discuss helper for adding deployment-problems
[ https://issues.apache.org/jira/browse/DELTASPIKE-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-440: Fix Version/s: 0.8 discuss helper for adding deployment-problems - Key: DELTASPIKE-440 URL: https://issues.apache.org/jira/browse/DELTASPIKE-440 Project: DeltaSpike Issue Type: Task Components: Core Reporter: Gerhard Petracek Fix For: 0.8 in many cases it's possible to detect deployment-problems before AfterDeploymentValidation. it's possible to throw an exception at any time, however, it might be useful to unify it. e.g. collecting problems via a helper which adds all issues via AfterDeploymentValidation#addDeploymentProblem -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-449) ExceptionHandler not invoked for AccessDeniedException
[ https://issues.apache.org/jira/browse/DELTASPIKE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-449: Fix Version/s: 0.8 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 Fix For: 0.8 Attachments: DELTASPIKE-449.patch 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.2#6252)
[jira] [Updated] (DELTASPIKE-570) Provide prototype/example for proposed mix between LAZY and CLIENTWINDOW window handling
[ https://issues.apache.org/jira/browse/DELTASPIKE-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-570: - Fix Version/s: (was: 0.7) 0.8 Provide prototype/example for proposed mix between LAZY and CLIENTWINDOW window handling Key: DELTASPIKE-570 URL: https://issues.apache.org/jira/browse/DELTASPIKE-570 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.8 and do a voting afterwards - provided that it works fine -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-544) api for a fine-grained control of @ViewAccessScoped beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-544: - Fix Version/s: (was: 0.7) 0.8 api for a fine-grained control of @ViewAccessScoped beans - Key: DELTASPIKE-544 URL: https://issues.apache.org/jira/browse/DELTASPIKE-544 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.6 Reporter: Gerhard Petracek Assignee: Thomas Andraschko Fix For: 0.8 in codi there is an unified approach for it (Conversation#close). see e.g.: http://s.apache.org/sF since the scope-implementations are splitted, we need a new api for it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-413) Add the ability to create Seam 2 like Factories
[ https://issues.apache.org/jira/browse/DELTASPIKE-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-413: Assignee: Thomas Hug 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 Assignee: Thomas Hug 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 was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-374) Provide a WindowContext/flow implementation that deal with login or error pages flows/redirections
[ https://issues.apache.org/jira/browse/DELTASPIKE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-374. - Resolution: Not a Problem please reopen it, if there is still an issue with v0.6+ and provide a demo-application which illustrates the issue. Provide a WindowContext/flow implementation that deal with login or error pages flows/redirections -- Key: DELTASPIKE-374 URL: https://issues.apache.org/jira/browse/DELTASPIKE-374 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.4 Environment: WebSphere v8.5.0.2 (includes MyFaces) Reporter: Denis Forveille The current implementation of WindowContext is not compatible OOTB with Apache Shiro and other frameworks that implements the classic redirect-to-login-page when required because the parameters are not propagated on all requests of the process The current implementation generates an infinite redirect loop in the browser if used with apache Shiro. It is currently possible to totally disable the WindowContext feature by providing an implementation of ClientWindowConfig impl which sets theClientWindowRenderMode to NONE, but this is not acceptable as many apps need the windows context active and have login pages redirect flows and it is not always possible to rewrite the login process DS should provide a way to keep the windows context active and handle nicely the login page flow without having to change the security frameworks. The same things may happen when dealing with error pages -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-364) Revisit the use of Project Stage globally
[ https://issues.apache.org/jira/browse/DELTASPIKE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975573#comment-13975573 ] Gerhard Petracek commented on DELTASPIKE-364: - please provide concrete examples Revisit the use of Project Stage globally - Key: DELTASPIKE-364 URL: https://issues.apache.org/jira/browse/DELTASPIKE-364 Project: DeltaSpike Issue Type: Bug Reporter: John D. Ament Assignee: John D. Ament Fix For: 0.7 We need to revisit the use of project stage. Right now it's being used to log what is essentially debug level messages as higher levels; throwing end users off and causing lots of complaints as log files fill up. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DELTASPIKE-334) CDI + Blueprint integration
[
https://issues.apache.org/jira/browse/DELTASPIKE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek resolved DELTASPIKE-334.
-
Resolution: Won't Fix
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 gno...@redhat.com
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)
cdi:container xmlns=…
cdi:beans url=… /
/cdi:container
#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
bean ….
cdiroperty name=service… /
/bean
Not sure what exactly we'd need in the cdiroperty/ 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 bean/ 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 bean/
element or a default attribute on the cdi:container/ element.
Cheers,
Guillaume Nodet
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (DELTASPIKE-304) @PreAuthorize and @PostAuthorize support
[
https://issues.apache.org/jira/browse/DELTASPIKE-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek closed DELTASPIKE-304.
---
@PreAuthorize and @PostAuthorize support
Key: DELTASPIKE-304
URL: https://issues.apache.org/jira/browse/DELTASPIKE-304
Project: DeltaSpike
Issue Type: New Feature
Components: Security-Module
Affects Versions: 0.3-incubating
Reporter: Arne Limburg
Assignee: Arne Limburg
The idea of this feature is to allow users to specifiy security rules via el:
@PreAuthorize(thing.hasMember(principal))
public void myBusinessMethod(Thing thing) {
...
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (DELTASPIKE-304) @PreAuthorize and @PostAuthorize support
[
https://issues.apache.org/jira/browse/DELTASPIKE-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek resolved DELTASPIKE-304.
-
Resolution: Won't Fix
Fix Version/s: (was: 0.7)
@PreAuthorize and @PostAuthorize support
Key: DELTASPIKE-304
URL: https://issues.apache.org/jira/browse/DELTASPIKE-304
Project: DeltaSpike
Issue Type: New Feature
Components: Security-Module
Affects Versions: 0.3-incubating
Reporter: Arne Limburg
Assignee: Arne Limburg
The idea of this feature is to allow users to specifiy security rules via el:
@PreAuthorize(thing.hasMember(principal))
public void myBusinessMethod(Thing thing) {
...
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (DELTASPIKE-259) @Transactional should support binding qualifier members
[ https://issues.apache.org/jira/browse/DELTASPIKE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-259: Fix Version/s: (was: 0.7) 0.8 @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.8 right now qualifiers are stored via Class? extends Annotation - the usage of qualifiers is restricted to @Q1, @Q2,... - @Q(1) and @Q(2) isn't supported currently. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-228) Make @MessageBundle annotated type available via EL
[
https://issues.apache.org/jira/browse/DELTASPIKE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-228:
Fix Version/s: (was: 0.7)
0.8
Make @MessageBundle annotated type available via EL
Key: DELTASPIKE-228
URL: https://issues.apache.org/jira/browse/DELTASPIKE-228
Project: DeltaSpike
Issue Type: New Feature
Components: I18n-Module, JSF-Module
Affects Versions: 0.2-incubating
Reporter: Thomas Herzog
Assignee: Mark Struberg
Fix For: 0.8
After you defined an MessageBundle type, you wanna use it in the views as
well without wrapping the type into a @Named annotated cdi bean to be
available to use it via EL.
It would be fine if the implementation would be created and registrered as an
cdi bean at deployment time and therefore available via EL in the views.
I think the main usage for the messages is in the views, at least in our
usacases.
Therefore it would also nice to define the name of the created cdi bean via
maybe @MessageContextConfig annotation and default should be the name of the
type, but the name of the type could be same, just placed in different
packages.
If this will be done the developer only has to define his MessageBundle type
with the getter for the messages and configuration via annotation if
necessary, and use it in the views right away.
Regarding to issue DELTASPIKE-223 it would be necessary to think about
follwing possible issues.
If there would be multiple choices for the convention of the getter methods
for the messages defined in the MessageBundle type, there could occur
follwing problems.
1. String welcomeTo(); // Key: welcome_to
2. String getWelcomeTo(); // Key: welcome_to with get prefix
3 String getWelcomeTo(); // Key: get_welcome_to
@1
How will EL resolve the method if called via #{type.welcomeTo} ?
As far as i know EL would try to invoke getWelcomeTo() method which could not
be found in this case !!
@2 and 3
How will it be distiguished if get prefix is part of the key or just the
start of the getter method?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (DELTASPIKE-265) ComparableAnnotation
[ https://issues.apache.org/jira/browse/DELTASPIKE-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-265: Fix Version/s: (was: 0.7) 0.8 ComparableAnnotation Key: DELTASPIKE-265 URL: https://issues.apache.org/jira/browse/DELTASPIKE-265 Project: DeltaSpike Issue Type: New Feature Components: Core Affects Versions: 0.3-incubating Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.8 We pretty often faced the problem that we have to compare Qualifiers, InterceptorBindings or other CDI annotations which support the @Nonbinding annotation. By providing a simple wrapper which implements the equals() and hashCode(), we can use this wrapper as key in HashMaps, etc. A method #getAnnotation() gives access to the wrapped underlying annotation. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DELTASPIKE-578) org.apache.deltaspike.data.impl.meta.RepositoryComponent is not thread safe
[ https://issues.apache.org/jira/browse/DELTASPIKE-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-578: Fix Version/s: 0.7 org.apache.deltaspike.data.impl.meta.RepositoryComponent is not thread safe --- Key: DELTASPIKE-578 URL: https://issues.apache.org/jira/browse/DELTASPIKE-578 Project: DeltaSpike Issue Type: Bug Components: Data-Module Affects Versions: 0.6 Reporter: Stuart Douglas Assignee: Thomas Hug Fix For: 0.7 Attachments: DELTASPIKE-578.patch The lazy init process is not thread safe. In particular the code checks if entityManagerResolverIsNormalScope is null to determine if the entity is initialised, however this is set before the initialisation is actually completed, meaning a thread can get an uninitialized component, which then causes problems. The initialize() call should be moved up to before entityManagerResolverIsNormalScope is set. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-404) BeanManagerProvider leaks in case of undeploy/redeploy
[ https://issues.apache.org/jira/browse/DELTASPIKE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975587#comment-13975587 ] Gerhard Petracek commented on DELTASPIKE-404: - +1 for a spi BeanManagerProvider leaks in case of undeploy/redeploy -- Key: DELTASPIKE-404 URL: https://issues.apache.org/jira/browse/DELTASPIKE-404 Project: DeltaSpike Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Gerhard Petracek Attachments: patch.diff -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: first steps for the next release
it would be also nice to get in DELTASPIKE-547 and DELTASPIKE-543. (and maybe even DELTASPIKE-404 and DELTASPIKE-519) regards, gerhard 2014-04-21 15:47 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com: Hi Great! Note the thread safety issue of data needs to be fixed before (if an issue ill try to help next week) Le 21 avr. 2014 13:55, Gerhard Petracek gpetra...@apache.org a écrit : hi @ all, if there are no objections, i will start with the first steps for the next release (v0.7) by the end of next week. regards, gerhard
CMS diff: Container Control
Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://deltaspike.apache.org/container-control.mdtext Karl Kildén Index: trunk/content/container-control.mdtext === --- trunk/content/container-control.mdtext (revision 1588841) +++ trunk/content/container-control.mdtext (working copy) @@ -28,9 +28,26 @@ - The **ContextControl** interface allows to control the life-cycle of the built-in contexts of the CDI container. ## CdiContainer +You can use the CdiContainerLoader as a simple factory to gain access to the underlying CdiContainer implementation. This is of little interest for Java EE applications since the CDI Container +already gets properly booted and shut down by the Servlet container integration. + -See the Java SE part [above](#start-a-cdi-container-using-java-se). +:::java +// this will give you a CdiContainer for Weld or OWB, depending on the jar you added +CdiContainer cdiContainer = CdiContainerLoader.getCdiContainer(); +// now we gonna boot the CDI container. This will trigger the classpath scan, etc + cdiContainer.boot(); + +// and finally we like to start all built-in contexts +cdiContainer.getContextControl().startContexts(); + +// now we can use CDI in our SE application. +// And there is not a single line of OWB or Weld specific code in your project! + +// finally we gonna stop the container +cdiContainer.shutdown(); + ## ContextControl usage The `ContextControl` interface allows you to start and stop built-in standard Contexts like `@RequestScoped`, `@ConversationScoped`, `@SessionScoped`, etc. It is provided as `@Dependent` bean and can get injected in the classic CDI way. This is not only usable in Java SE projects but also very helpful in Servlets and Java EE containers.
[jira] [Resolved] (DELTASPIKE-156) documentation for ContainerControl API
[ https://issues.apache.org/jira/browse/DELTASPIKE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-156. - Resolution: Fixed documentation for ContainerControl API -- Key: DELTASPIKE-156 URL: https://issues.apache.org/jira/browse/DELTASPIKE-156 Project: DeltaSpike Issue Type: Sub-task Components: CdiControl, Documentation Affects Versions: 0.2-incubating Reporter: Gerhard Petracek Assignee: Mark Struberg Fix For: 0.7 Attachments: cdiContro.patch the wiki is outdated -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-404) BeanManagerProvider leaks in case of undeploy/redeploy
[ https://issues.apache.org/jira/browse/DELTASPIKE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975625#comment-13975625 ] Romain Manni-Bucau commented on DELTASPIKE-404: --- the issue is it is broken by default then excepted if we detect the container automatically BeanManagerProvider leaks in case of undeploy/redeploy -- Key: DELTASPIKE-404 URL: https://issues.apache.org/jira/browse/DELTASPIKE-404 Project: DeltaSpike Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Gerhard Petracek Attachments: patch.diff -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (DELTASPIKE-404) BeanManagerProvider leaks in case of undeploy/redeploy
[ https://issues.apache.org/jira/browse/DELTASPIKE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975625#comment-13975625 ] Romain Manni-Bucau edited comment on DELTASPIKE-404 at 4/21/14 3:19 PM: the issue is it is broken by default then excepted if we detect the container automatically edit: not sure about others but tomee doesn't need a particular spi, it has its own event for that was (Author: romain.manni-bucau): the issue is it is broken by default then excepted if we detect the container automatically BeanManagerProvider leaks in case of undeploy/redeploy -- Key: DELTASPIKE-404 URL: https://issues.apache.org/jira/browse/DELTASPIKE-404 Project: DeltaSpike Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Gerhard Petracek Attachments: patch.diff -- This message was sent by Atlassian JIRA (v6.2#6252)
