[jira] [Commented] (DELTASPIKE-130) Remove custom ProjectStageProducer logic
[ https://issues.apache.org/jira/browse/DELTASPIKE-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239314#comment-13239314 ] Mark Struberg commented on DELTASPIKE-130: -- I've now took a deep look into our impl again and I think I know where the misunderstanding comes from (as I fell into the same hole). There must be only 1 CDI producer for our ProjectStage. It doesn't make sense to provide a 'custom' CDI producer for the ProjectStage. But it might make sense to provide a way to configure the SOURCE of the ProjectStage, means the mechanism which does the ProjectStage calculation. I'd just split this part out and move it to a separate class. Or we just document this stuff better. I agree that in 98% of all cases we do not need this (but still might be handy). Remove custom ProjectStageProducer logic Key: DELTASPIKE-130 URL: https://issues.apache.org/jira/browse/DELTASPIKE-130 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.1-incubating Reporter: Jason Porter Assignee: Gerhard Petracek Priority: Minor Fix For: 0.2-incubating Right now we have the ability to register a custom ProjectStageProducer which then overrides the default one in DeltaSpike. I don't think this is really necessary and our default ProjectStageProducer should be able to pick up any custom stages and use them accordingly. The extra configuration is cool, but I think at the end of the day it's not necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-128) JNDI lookup for config variables cannot use java:comp as the sole location
[ https://issues.apache.org/jira/browse/DELTASPIKE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236352#comment-13236352 ] Mark Struberg commented on DELTASPIKE-128: -- Well, if we start messing around with JNDI that way, then we need to make it completely flexible. I know of no single EE container where JNDI is _not_ completely fu up... We need a way to configure the JNDI lookup paths in a flexible way. As we are on the 'JNDI is broken' topic: do we also put stuff into JNDI somewhere in DeltaSpike? Because finding a reliably writable JNDI location is another mess... JNDI lookup for config variables cannot use java:comp as the sole location -- Key: DELTASPIKE-128 URL: https://issues.apache.org/jira/browse/DELTASPIKE-128 Project: DeltaSpike Issue Type: Bug Components: Core Affects Versions: 0.1-incubating Environment: JBoss AS 7.1.1 possibly other web profile or full profile servers Reporter: Jason Porter Assignee: Gerhard Petracek java:comp/env is not available to CDI Extensions in JBoss AS 7.1. I propose we also look under java:global/deltaspike if java:comp/env/deltaspike fails. That would be the next place that would really make sense and an administrator could reliably set without changing a deployment descriptor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-124) tests in ContainerCtrlTckTest don't stop contexts at the end
[ https://issues.apache.org/jira/browse/DELTASPIKE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232560#comment-13232560 ] Mark Struberg commented on DELTASPIKE-124: -- that's perfectly fine. CdiContainer#shutdown() of any CdiContainer should stop all still open contexts anyway! This is true for built-in Contexts and should also be the case for custom contexts. They can (and should) observe the BeforeShutdown event to gracefully cleanup any contextual instances left in their context stores. tests in ContainerCtrlTckTest don't stop contexts at the end Key: DELTASPIKE-124 URL: https://issues.apache.org/jira/browse/DELTASPIKE-124 Project: DeltaSpike Issue Type: Bug Components: Tests Reporter: Gerhard Petracek Assignee: Mark Struberg Priority: Minor Fix For: 0.2-incubating Attachments: DELTASPIKE-124.patch no test in ContainerCtrlTckTest calls: CdiContainer#getContextControl#stopContexts before CdiContainer#shutdown imo the current approach is too error prone - see DELTASPIKE-123 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-92) ContainerControl API + impls
[ https://issues.apache.org/jira/browse/DELTASPIKE-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231929#comment-13231929 ] Mark Struberg commented on DELTASPIKE-92: - I'm going to revise the cdise module It will be renamed back to cdictrl because it's not only for Java SE anymore. The CdiContainer interface will get stripped of start() and stop() and now only contain * boot() * shutdown() * getBeanManager() * and an additional getContextControl() The Context related methods will be moved to a new Interface * ContextControl ContainerControl API + impls Key: DELTASPIKE-92 URL: https://issues.apache.org/jira/browse/DELTASPIKE-92 Project: DeltaSpike Issue Type: New Feature Components: CDI-SE Affects Versions: 0.1-incubating Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.2-incubating Java SE applications need a way to control the container. They need to start/stop it and control the lifecycle of the built-in Contexts (see http://s.apache.org/Rej ) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-92) ContainerControl API + impls
[ https://issues.apache.org/jira/browse/DELTASPIKE-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232088#comment-13232088 ] Mark Struberg commented on DELTASPIKE-92: - Btw: as for the boot vs start and shutdown vs stop discussion: I now used boot + shutdown as this also reflects the wording in the CDI specification itself (e.g. @Observes BeforeShutdown). ContainerControl API + impls Key: DELTASPIKE-92 URL: https://issues.apache.org/jira/browse/DELTASPIKE-92 Project: DeltaSpike Issue Type: New Feature Components: CDI-SE Affects Versions: 0.1-incubating Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.2-incubating Java SE applications need a way to control the container. They need to start/stop it and control the lifecycle of the built-in Contexts (see http://s.apache.org/Rej ) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-107) add BackwardCompatibility profile
[ https://issues.apache.org/jira/browse/DELTASPIKE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219399#comment-13219399 ] Mark Struberg commented on DELTASPIKE-107: -- basically +1 but please rename 'BackwardCompatibility' to 'jbossRepo' we will have to deal with a lot backward compat stuff which has nothing to do with the jboss repo. -PjbossRepo otoh makes it pretty clear what's going on... add BackwardCompatibility profile - Key: DELTASPIKE-107 URL: https://issues.apache.org/jira/browse/DELTASPIKE-107 Project: DeltaSpike Issue Type: Task Affects Versions: 0.1-incubating Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.2-incubating old versions of weld are just available in the jboss maven-repo. - we need to add the repo (at least) in a profile to run e.g. mvn clean install -PWeld -PBackwardCompatibility -Dweld.version=1.1.3.SP1 for old versions of weld at https://builds.apache.org/view/A-F/view/DeltaSpike/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-96) Give names to tests and shrinkwrap archives
[ https://issues.apache.org/jira/browse/DELTASPIKE-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212467#comment-13212467 ] Mark Struberg commented on DELTASPIKE-96: - That's definitely a good thing. But please be aware that all our WAR files are just a workaround because ShrinkWrap doesn't provide a multi-BDA 'SE-Archive' yet. We are _only_ using the WEB-INF/lib/*.jar to work around this shortcoming and do _not_ use WEB-INF/classes nor any other web-app feature so far. Give names to tests and shrinkwrap archives --- Key: DELTASPIKE-96 URL: https://issues.apache.org/jira/browse/DELTASPIKE-96 Project: DeltaSpike Issue Type: Improvement Components: Tests Affects Versions: 0.1-incubating Reporter: Jason Porter Assignee: Gerhard Petracek jars and wars need to have names to make tracking down problems easier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-40) add project name as prefix to artifact-ids
[ https://issues.apache.org/jira/browse/DELTASPIKE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13177962#comment-13177962 ] Mark Struberg commented on DELTASPIKE-40: - I don't think we need this. It's purely redundant. The project name is in the groupId already and the artifactId alone is never sufficient add project name as prefix to artifact-ids -- Key: DELTASPIKE-40 URL: https://issues.apache.org/jira/browse/DELTASPIKE-40 Project: DeltaSpike Issue Type: Task Components: Core Reporter: Gerhard Petracek Assignee: Gerhard Petracek -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-20) move util methods to CdiUtils
[ https://issues.apache.org/jira/browse/DELTASPIKE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13176549#comment-13176549 ] Mark Struberg commented on DELTASPIKE-20: - CdiUtils sounds a bit too loose. I'd rather name it ContextualInstanceProvider and let it resolve the BeanManager internally. move util methods to CdiUtils - Key: DELTASPIKE-20 URL: https://issues.apache.org/jira/browse/DELTASPIKE-20 Project: DeltaSpike Issue Type: Sub-task Components: Core Reporter: Gerhard Petracek Assignee: Mark Struberg public T T getContextualReference(ClassT type, boolean optionalBeanAllowed, Annotation... qualifiers) public T T getContextualReference(String name, boolean optionalBeanAllowed, ClassT targetType) public T T getContextualReference(BeanT bean, boolean optionalBeanAllowed, ClassT targetType) public T ListT getContextualReferences(ClassT type, boolean optionalBeanAllowed, Annotation... qualifiers) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira