[jira] [Reopened] (DELTASPIKE-339) JndiUtils is broken
[ https://issues.apache.org/jira/browse/DELTASPIKE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reopened DELTASPIKE-339: - we don't have an agreement that it should be active JndiUtils is broken --- Key: DELTASPIKE-339 URL: https://issues.apache.org/jira/browse/DELTASPIKE-339 Project: DeltaSpike Issue Type: Bug Components: Core Affects Versions: 0.4-incubating Reporter: Mark Struberg Assignee: Mark Struberg Priority: Blocker Fix For: 0.4-incubating A recent change in JndiUtils caused a bug in a few Containers java.lang.IllegalStateException: Could not get java:comp/ORB from JNDI at org.apache.deltaspike.core.impl.util.JndiUtils.lookup(JndiUtils.java:79) at org.apache.deltaspike.core.impl.util.JndiUtils.list(JndiUtils.java:186) at org.apache.deltaspike.test.core.impl.util.JndiUtilsTest.testList(JndiUtilsTest.java:72) The code currently enlists all registered objects in JNDI java:comp and tries to lookup() them as a specific type. But as per the spec of javax.naming.Context this will always throw a javax.naming.NamingException if the type of the registered object in JNDI does not match the type for the bind() operation. -- 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-339) JndiUtils is broken
[ https://issues.apache.org/jira/browse/DELTASPIKE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667392#comment-13667392 ] Gerhard Petracek commented on DELTASPIKE-339: - we haven't agreed that LocalJndiConfigSource#isScannable should return true. JndiUtils is broken --- Key: DELTASPIKE-339 URL: https://issues.apache.org/jira/browse/DELTASPIKE-339 Project: DeltaSpike Issue Type: Bug Components: Core Affects Versions: 0.4 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Blocker Fix For: 0.4 A recent change in JndiUtils caused a bug in a few Containers java.lang.IllegalStateException: Could not get java:comp/ORB from JNDI at org.apache.deltaspike.core.impl.util.JndiUtils.lookup(JndiUtils.java:79) at org.apache.deltaspike.core.impl.util.JndiUtils.list(JndiUtils.java:186) at org.apache.deltaspike.test.core.impl.util.JndiUtilsTest.testList(JndiUtilsTest.java:72) The code currently enlists all registered objects in JNDI java:comp and tries to lookup() them as a specific type. But as per the spec of javax.naming.Context this will always throw a javax.naming.NamingException if the type of the registered object in JNDI does not match the type for the bind() operation. -- 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] [Reopened] (DELTASPIKE-343) NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0
[
https://issues.apache.org/jira/browse/DELTASPIKE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek reopened DELTASPIKE-343:
-
NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0
-
Key: DELTASPIKE-343
URL: https://issues.apache.org/jira/browse/DELTASPIKE-343
Project: DeltaSpike
Issue Type: Bug
Components: PartialBean
Affects Versions: 0.4-incubating
Environment: JBoss AS 8.0.0.Alpha1-SNAPSHOT, Weld 2.0.0.CR2
Reporter: Ron Smeral
Assignee: Jozef Hartinger
Fix For: 0.5
The {{PartialBeanAsAbstractClassTest}} doesn't deploy due to a NPE in
{{PartialBeanLifecycle}}.
It might be some problem with javassist dependency, as {{org.javassist}} is
no more a dependency of {{weld-core}} module in AS in Weld 2.0.0.CR2.
Tested with current DS master.
org.jboss.weld.exceptions.WeldException: WELD-001524 Unable to load proxy
class for bean null with class class
org.apache.deltaspike.test.core.api.partialbean.uc003.PartialBean using
classloader sun.misc.Launcher$AppClassLoader@3182f0db
at
org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:306)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.createEnhancedSubclass(SubclassedComponentInstantiator.java:83)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.initEnhancedSubclass(SubclassedComponentInstantiator.java:65)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.init(SubclassedComponentInstantiator.java:58)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.init(SubclassedComponentInstantiator.java:54)
at
org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:126)
at
org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
at
org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:58)
at
org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:521)
at
org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.startContainer(TestContainer.java:268)
at
org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:105)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94
[jira] [Resolved] (DELTASPIKE-343) NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0
[
https://issues.apache.org/jira/browse/DELTASPIKE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek resolved DELTASPIKE-343.
-
Resolution: Not A Problem
isn't an issue in deltaspike
NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0
-
Key: DELTASPIKE-343
URL: https://issues.apache.org/jira/browse/DELTASPIKE-343
Project: DeltaSpike
Issue Type: Bug
Components: PartialBean
Affects Versions: 0.4-incubating
Environment: JBoss AS 8.0.0.Alpha1-SNAPSHOT, Weld 2.0.0.CR2
Reporter: Ron Smeral
Assignee: Jozef Hartinger
Fix For: 0.5
The {{PartialBeanAsAbstractClassTest}} doesn't deploy due to a NPE in
{{PartialBeanLifecycle}}.
It might be some problem with javassist dependency, as {{org.javassist}} is
no more a dependency of {{weld-core}} module in AS in Weld 2.0.0.CR2.
Tested with current DS master.
org.jboss.weld.exceptions.WeldException: WELD-001524 Unable to load proxy
class for bean null with class class
org.apache.deltaspike.test.core.api.partialbean.uc003.PartialBean using
classloader sun.misc.Launcher$AppClassLoader@3182f0db
at
org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:306)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.createEnhancedSubclass(SubclassedComponentInstantiator.java:83)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.initEnhancedSubclass(SubclassedComponentInstantiator.java:65)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.init(SubclassedComponentInstantiator.java:58)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.init(SubclassedComponentInstantiator.java:54)
at
org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:126)
at
org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
at
org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:58)
at
org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:521)
at
org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.startContainer(TestContainer.java:268)
at
org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:105)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597
[jira] [Commented] (DELTASPIKE-339) JndiUtils is broken
[ https://issues.apache.org/jira/browse/DELTASPIKE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666481#comment-13666481 ] Gerhard Petracek commented on DELTASPIKE-339: - that won't change the real issue (please see my first comment...) JndiUtils is broken --- Key: DELTASPIKE-339 URL: https://issues.apache.org/jira/browse/DELTASPIKE-339 Project: DeltaSpike Issue Type: Bug Components: Core Affects Versions: 0.4-incubating Reporter: Mark Struberg Assignee: John D. Ament Priority: Blocker Fix For: 0.4-incubating A recent change in JndiUtils caused a bug in a few Containers java.lang.IllegalStateException: Could not get java:comp/ORB from JNDI at org.apache.deltaspike.core.impl.util.JndiUtils.lookup(JndiUtils.java:79) at org.apache.deltaspike.core.impl.util.JndiUtils.list(JndiUtils.java:186) at org.apache.deltaspike.test.core.impl.util.JndiUtilsTest.testList(JndiUtilsTest.java:72) The code currently enlists all registered objects in JNDI java:comp and tries to lookup() them as a specific type. But as per the spec of javax.naming.Context this will always throw a javax.naming.NamingException if the type of the registered object in JNDI does not match the type for the bind() operation. -- 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] [Assigned] (DELTASPIKE-370) ContainerCtrlTckTest - fix testShutdownWithInactiveContexts()
[ https://issues.apache.org/jira/browse/DELTASPIKE-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reassigned DELTASPIKE-370: --- Assignee: Mark Struberg ContainerCtrlTckTest - fix testShutdownWithInactiveContexts() - Key: DELTASPIKE-370 URL: https://issues.apache.org/jira/browse/DELTASPIKE-370 Project: DeltaSpike Issue Type: Bug Components: CdiControl Affects Versions: 0.3-incubating Reporter: Martin Kouba Assignee: Mark Struberg Line 175: cdiContainer.getContextControl().startContexts(); should be: cdiContainer.getContextControl().stopContexts(); Fixing this causes the testShutdownWithInactiveContexts() failure, due to https://issues.jboss.org/browse/WELD-1072 In fact testRestartContexts() should also fail but it doesn't by coincidence, the reasons: - WeldContainerControl.shutdown() does not stop contexts - Weld core does not invalidate other contexts than @ApplicationScoped during shutdown - Weld core uses some request scoped caching optimization WELD-1072 is going to be fixed in 1.1.13.Final and 2.0.1.Final. The test should be fixed. I'm going to address the other problem (WeldContainerControl.shutdown()) in a different issue. -- 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] [Assigned] (DELTASPIKE-371) Weld ContextController.stopApplicationScope() does not destroy application scoped beans properly
[ https://issues.apache.org/jira/browse/DELTASPIKE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reassigned DELTASPIKE-371: --- Assignee: Mark Struberg Weld ContextController.stopApplicationScope() does not destroy application scoped beans properly Key: DELTASPIKE-371 URL: https://issues.apache.org/jira/browse/DELTASPIKE-371 Project: DeltaSpike Issue Type: Bug Components: CdiControl Affects Versions: 0.3-incubating Reporter: Martin Kouba Assignee: Mark Struberg The current impl simply clears the application context's bean store which is not enough, e.g. @PreDestroy callback is not invoked. The impl should call org.jboss.weld.context.ApplicationContext.invalidate() as it originally did. It was probably changed in the context of WELD-1072... -- 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-368) Move KEYS and deltaspike files to root directory
[ https://issues.apache.org/jira/browse/DELTASPIKE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13664231#comment-13664231 ] Gerhard Petracek commented on DELTASPIKE-368: - there is no official rule for it - we can keep it as it is (projects like https://svn.apache.org/repos/asf/myfaces/ have the same) Move KEYS and deltaspike files to root directory Key: DELTASPIKE-368 URL: https://issues.apache.org/jira/browse/DELTASPIKE-368 Project: DeltaSpike Issue Type: Task Components: Build Reporter: Bruno Leonardo Gonçalves Priority: Minor We could move the files of deltaspike directory and KEYS file to the root of the repository tree, avoiding redundancy in names. For example, the openwebbeans repository keeps the files KEYS, LICENSE and NOTICE in the root directory together with all assets and modules, maintaining the directory structure of the project clearer. This change proceeds or there are other points to keep the project structure in its own directory? -- 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] [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.4-incubating)
0.5
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.5
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 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-228) Make @MessageBundle annotated type available via EL
[
https://issues.apache.org/jira/browse/DELTASPIKE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658402#comment-13658402
]
Gerhard Petracek commented on DELTASPIKE-228:
-
we have to discuss how we handle dynamic lookups since the el allows even more
constellations.
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.5
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 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] [Updated] (DELTASPIKE-343) NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0
[
https://issues.apache.org/jira/browse/DELTASPIKE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-343:
Summary: NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0 (was: NPE
in PartialBeanAsAbstractClassTest with Weld 2.0.0.CR2)
NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0
-
Key: DELTASPIKE-343
URL: https://issues.apache.org/jira/browse/DELTASPIKE-343
Project: DeltaSpike
Issue Type: Bug
Components: PartialBean
Affects Versions: 0.4-incubating
Environment: JBoss AS 8.0.0.Alpha1-SNAPSHOT, Weld 2.0.0.CR2
Reporter: Ron Smeral
Assignee: Jozef Hartinger
Fix For: 0.5
The {{PartialBeanAsAbstractClassTest}} doesn't deploy due to a NPE in
{{PartialBeanLifecycle}}.
It might be some problem with javassist dependency, as {{org.javassist}} is
no more a dependency of {{weld-core}} module in AS in Weld 2.0.0.CR2.
Tested with current DS master.
org.jboss.weld.exceptions.WeldException: WELD-001524 Unable to load proxy
class for bean null with class class
org.apache.deltaspike.test.core.api.partialbean.uc003.PartialBean using
classloader sun.misc.Launcher$AppClassLoader@3182f0db
at
org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:306)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.createEnhancedSubclass(SubclassedComponentInstantiator.java:83)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.initEnhancedSubclass(SubclassedComponentInstantiator.java:65)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.init(SubclassedComponentInstantiator.java:58)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.init(SubclassedComponentInstantiator.java:54)
at
org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:126)
at
org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
at
org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:58)
at
org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:521)
at
org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.startContainer(TestContainer.java:268)
at
org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:105)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java
[jira] [Commented] (DELTASPIKE-343) NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0
[
https://issues.apache.org/jira/browse/DELTASPIKE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13655963#comment-13655963
]
Gerhard Petracek commented on DELTASPIKE-343:
-
javassist is available for tests ( see
https://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=blob;f=deltaspike/modules/partial-bean/impl/pom.xml;h=36b05913ec182fc8d7381995a8efbf8ecd07fe76;hb=HEAD
)
NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0
-
Key: DELTASPIKE-343
URL: https://issues.apache.org/jira/browse/DELTASPIKE-343
Project: DeltaSpike
Issue Type: Bug
Components: PartialBean
Affects Versions: 0.4-incubating
Environment: JBoss AS 8.0.0.Alpha1-SNAPSHOT, Weld 2.0.0.CR2
Reporter: Ron Smeral
Assignee: Jozef Hartinger
Fix For: 0.5
The {{PartialBeanAsAbstractClassTest}} doesn't deploy due to a NPE in
{{PartialBeanLifecycle}}.
It might be some problem with javassist dependency, as {{org.javassist}} is
no more a dependency of {{weld-core}} module in AS in Weld 2.0.0.CR2.
Tested with current DS master.
org.jboss.weld.exceptions.WeldException: WELD-001524 Unable to load proxy
class for bean null with class class
org.apache.deltaspike.test.core.api.partialbean.uc003.PartialBean using
classloader sun.misc.Launcher$AppClassLoader@3182f0db
at
org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:306)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.createEnhancedSubclass(SubclassedComponentInstantiator.java:83)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.initEnhancedSubclass(SubclassedComponentInstantiator.java:65)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.init(SubclassedComponentInstantiator.java:58)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.init(SubclassedComponentInstantiator.java:54)
at
org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:126)
at
org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
at
org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:58)
at
org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:521)
at
org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.startContainer(TestContainer.java:268)
at
org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:105)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
[jira] [Commented] (DELTASPIKE-343) NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0
[
https://issues.apache.org/jira/browse/DELTASPIKE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13655977#comment-13655977
]
Gerhard Petracek commented on DELTASPIKE-343:
-
the issue is in:
org.jboss.weld.bean.proxy.InterceptedSubclassFactory#createDelegateToSuper
the first line results in null in case of the abstract method of the partial
bean - NullPointerException
NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0
-
Key: DELTASPIKE-343
URL: https://issues.apache.org/jira/browse/DELTASPIKE-343
Project: DeltaSpike
Issue Type: Bug
Components: PartialBean
Affects Versions: 0.4-incubating
Environment: JBoss AS 8.0.0.Alpha1-SNAPSHOT, Weld 2.0.0.CR2
Reporter: Ron Smeral
Assignee: Jozef Hartinger
Fix For: 0.5
The {{PartialBeanAsAbstractClassTest}} doesn't deploy due to a NPE in
{{PartialBeanLifecycle}}.
It might be some problem with javassist dependency, as {{org.javassist}} is
no more a dependency of {{weld-core}} module in AS in Weld 2.0.0.CR2.
Tested with current DS master.
org.jboss.weld.exceptions.WeldException: WELD-001524 Unable to load proxy
class for bean null with class class
org.apache.deltaspike.test.core.api.partialbean.uc003.PartialBean using
classloader sun.misc.Launcher$AppClassLoader@3182f0db
at
org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:306)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.createEnhancedSubclass(SubclassedComponentInstantiator.java:83)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.initEnhancedSubclass(SubclassedComponentInstantiator.java:65)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.init(SubclassedComponentInstantiator.java:58)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.init(SubclassedComponentInstantiator.java:54)
at
org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:126)
at
org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
at
org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:58)
at
org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:521)
at
org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.startContainer(TestContainer.java:268)
at
org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:105)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
[jira] [Updated] (DELTASPIKE-360) alternative LocaleResolver which is aware of supported locales
[ https://issues.apache.org/jira/browse/DELTASPIKE-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-360: Fix Version/s: (was: 0.4-incubating) 0.5 alternative LocaleResolver which is aware of supported locales -- Key: DELTASPIKE-360 URL: https://issues.apache.org/jira/browse/DELTASPIKE-360 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Christian Beikov Fix For: 0.5 Attachments: DELTASPIKE-360.patch -- 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
Re: So... what's left in 0.4?
hi john, [1] is still open. regards, gerhard [1] https://issues.apache.org/jira/browse/DELTASPIKE-339 2013/5/13 John D. Ament john.d.am...@gmail.com We have about 22 issues left open still in 0.4. Are all these still needed in 0.4? https://issues.apache.org/jira/issues/?filter=12324018 John
[jira] [Resolved] (DELTASPIKE-359) Websphere 8.0.x javaassist proxy does not reflect instance value
[ https://issues.apache.org/jira/browse/DELTASPIKE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-359. - Resolution: Won't Fix Websphere 8.0.x javaassist proxy does not reflect instance value Key: DELTASPIKE-359 URL: https://issues.apache.org/jira/browse/DELTASPIKE-359 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.4-incubating Environment: Websphere 8.0.x, Windows 7 Reporter: Hampus Wingren I have a strange issue in the ViewConfigResolverProducer where the ViewConfigResolver is always null. When I debug what's happening I can see that the underlying ViewConfigExtension creates a ViewConfigResolver and stores it in an instance variable which is later is returned through getViewConfigResolver. However, the returned value is always null. I've tested this in the Liberty profile where it works so it seems to be isolated to Websphere 8.0.x line. Have you seen anything like this before? Regards, Hampus -- 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] [Created] (DELTASPIKE-360) alternative LocaleResolver which is aware of supported locales
Gerhard Petracek created DELTASPIKE-360: --- Summary: alternative LocaleResolver which is aware of supported locales Key: DELTASPIKE-360 URL: https://issues.apache.org/jira/browse/DELTASPIKE-360 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.3-incubating Reporter: Christian Beikov Fix For: 0.4-incubating -- 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] [Updated] (DELTASPIKE-360) alternative LocaleResolver which is aware of supported locales
[ https://issues.apache.org/jira/browse/DELTASPIKE-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-360: Attachment: DELTASPIKE-360.patch first draft alternative LocaleResolver which is aware of supported locales -- Key: DELTASPIKE-360 URL: https://issues.apache.org/jira/browse/DELTASPIKE-360 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.3-incubating Reporter: Christian Beikov Fix For: 0.4-incubating Attachments: DELTASPIKE-360.patch -- 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] [Updated] (DELTASPIKE-360) alternative LocaleResolver which is aware of supported locales
[ https://issues.apache.org/jira/browse/DELTASPIKE-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-360: Affects Version/s: (was: 0.3-incubating) alternative LocaleResolver which is aware of supported locales -- Key: DELTASPIKE-360 URL: https://issues.apache.org/jira/browse/DELTASPIKE-360 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Christian Beikov Fix For: 0.4-incubating Attachments: DELTASPIKE-360.patch -- 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
Re: Any plan to adopt Java EE 7
hi hantsy, see chapter 5.4.1 of jsr-344 (and the vote you mentioned is fine as well). regards, gerhard 2013/5/1 hantsy han...@yahoo.com.cn Hi, I noticed Java EE 7 got approval, is there any plan to support Java EE 7. And for JSF 2.2, the Converter, Validator , UIComponent, all listeners still do not support CDI @Inject. Personally it is a big disappointment. And other two big features introduced in JSF2.2, resource contract and flow, I also have no interest. Especially the flow, the definition is very tedious, I hope Apache Deltaspike can pick up the simple @ConversationScoped and @Begin @End annotations in Seam 2 to implement a simple page flow solution . BTW, in the vote page, I found the status of Redhat is not voted, what this means? Hantsy -- Fulltime Java EE Freelancer from China
Re: Any plan to adopt Java EE 7
yes - for ee7 (the vote for jsf 2.2 is fine). regards, gerhard 2013/5/1 Jason Porter lightguard...@gmail.com That means the rep for Red Hat didn't vote in the specified time of the vote. On Wed, May 1, 2013 at 8:21 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi hantsy, see chapter 5.4.1 of jsr-344 (and the vote you mentioned is fine as well). regards, gerhard 2013/5/1 hantsy han...@yahoo.com.cn Hi, I noticed Java EE 7 got approval, is there any plan to support Java EE 7. And for JSF 2.2, the Converter, Validator , UIComponent, all listeners still do not support CDI @Inject. Personally it is a big disappointment. And other two big features introduced in JSF2.2, resource contract and flow, I also have no interest. Especially the flow, the definition is very tedious, I hope Apache Deltaspike can pick up the simple @ConversationScoped and @Begin @End annotations in Seam 2 to implement a simple page flow solution . BTW, in the vote page, I found the status of Redhat is not voted, what this means? Hantsy -- Fulltime Java EE Freelancer from China -- Jason Porter http://en.gravatar.com/lightguardjp
[jira] [Assigned] (DELTASPIKE-356) MessageContextProducer causes a ton of log output on each request
[
https://issues.apache.org/jira/browse/DELTASPIKE-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek reassigned DELTASPIKE-356:
---
Assignee: Mark Struberg
MessageContextProducer causes a ton of log output on each request
-
Key: DELTASPIKE-356
URL: https://issues.apache.org/jira/browse/DELTASPIKE-356
Project: DeltaSpike
Issue Type: Bug
Components: I18n-Module
Affects Versions: 0.3-incubating
Reporter: Stefan Strobl
Assignee: Mark Struberg
{noformat}
2013-04-19 12:00:17,102 [http-bio-8080-exec-5]: local
4F6067CAAC93376AC5A451C98CAF289D WARN provider.BeanProvider - BeanProvider
shall not be used to create @Dependent scoped beans. Bean: MessageContext,
Name:null, WebBeans Type:PRODUCERMETHOD, API
Types:[org.apache.deltaspike.core.api.message.MessageContext,java.lang.Object],
Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
{noformat}
in our project with a couple of request scoped beans that have messages
injected, this log is produced once per injection point per request (which
equals to quite a bit of spam). The same log is also visible when running the
Deltaspike tests.
After some code reading it seems to me that the entry is caused by the
following method:
{{org.apache.deltaspike.core.impl.message.MessageContextProducer#createDefaultMessageContext}}
and might only appear when ProjectStage is set to Development or UnitTest
see:
{{org.apache.deltaspike.core.api.provider.BeanProvider#logWarningIfDependent}}
--
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-343) NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0.CR2
[
https://issues.apache.org/jira/browse/DELTASPIKE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13644421#comment-13644421
]
Gerhard Petracek commented on DELTASPIKE-343:
-
it might be different because you used jboss-as and the jenkins build is using
mvn clean install -PWeld -Dweld.version=2.0.0.Final -DforkMode=always
NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0.CR2
-
Key: DELTASPIKE-343
URL: https://issues.apache.org/jira/browse/DELTASPIKE-343
Project: DeltaSpike
Issue Type: Bug
Components: PartialBean
Affects Versions: 0.4-incubating
Environment: JBoss AS 8.0.0.Alpha1-SNAPSHOT, Weld 2.0.0.CR2
Reporter: Ron Smeral
Assignee: Jozef Hartinger
Fix For: 0.5
The {{PartialBeanAsAbstractClassTest}} doesn't deploy due to a NPE in
{{PartialBeanLifecycle}}.
It might be some problem with javassist dependency, as {{org.javassist}} is
no more a dependency of {{weld-core}} module in AS in Weld 2.0.0.CR2.
Tested with current DS master.
org.jboss.weld.exceptions.WeldException: WELD-001524 Unable to load proxy
class for bean null with class class
org.apache.deltaspike.test.core.api.partialbean.uc003.PartialBean using
classloader sun.misc.Launcher$AppClassLoader@3182f0db
at
org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:306)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.createEnhancedSubclass(SubclassedComponentInstantiator.java:83)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.initEnhancedSubclass(SubclassedComponentInstantiator.java:65)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.init(SubclassedComponentInstantiator.java:58)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.init(SubclassedComponentInstantiator.java:54)
at
org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:126)
at
org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
at
org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:58)
at
org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:521)
at
org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.startContainer(TestContainer.java:268)
at
org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:105)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
[jira] [Comment Edited] (DELTASPIKE-343) NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0.CR2
[
https://issues.apache.org/jira/browse/DELTASPIKE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632654#comment-13632654
]
Gerhard Petracek edited comment on DELTASPIKE-343 at 4/28/13 9:15 AM:
--
thx for reporting the issue. we know it already (see
https://builds.apache.org/job/DeltaSpike%20Weld%202.0.0/1/ )
javassist is scoped to 'test' - see
https://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=blob;f=deltaspike/modules/partial-bean/impl/pom.xml;h=36b05913ec182fc8d7381995a8efbf8ecd07fe76;hb=HEAD
was (Author: gpetracek):
thx for reporting the issue. we know it already (see
https://builds.apache.org/view/A-D/view/DeltaSpike/)
javassist is scoped to 'test' - see
https://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=blob;f=deltaspike/modules/partial-bean/impl/pom.xml;h=36b05913ec182fc8d7381995a8efbf8ecd07fe76;hb=HEAD
NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0.CR2
-
Key: DELTASPIKE-343
URL: https://issues.apache.org/jira/browse/DELTASPIKE-343
Project: DeltaSpike
Issue Type: Bug
Components: PartialBean
Affects Versions: 0.4-incubating
Environment: JBoss AS 8.0.0.Alpha1-SNAPSHOT, Weld 2.0.0.CR2
Reporter: Ron Smeral
Assignee: Jozef Hartinger
Fix For: 0.5
The {{PartialBeanAsAbstractClassTest}} doesn't deploy due to a NPE in
{{PartialBeanLifecycle}}.
It might be some problem with javassist dependency, as {{org.javassist}} is
no more a dependency of {{weld-core}} module in AS in Weld 2.0.0.CR2.
Tested with current DS master.
org.jboss.weld.exceptions.WeldException: WELD-001524 Unable to load proxy
class for bean null with class class
org.apache.deltaspike.test.core.api.partialbean.uc003.PartialBean using
classloader sun.misc.Launcher$AppClassLoader@3182f0db
at
org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:306)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.createEnhancedSubclass(SubclassedComponentInstantiator.java:83)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.initEnhancedSubclass(SubclassedComponentInstantiator.java:65)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.init(SubclassedComponentInstantiator.java:58)
at
org.jboss.weld.injection.producer.SubclassedComponentInstantiator.init(SubclassedComponentInstantiator.java:54)
at
org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:126)
at
org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
at
org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:58)
at
org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:521)
at
org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.startContainer(TestContainer.java:268)
at
org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:105)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25
[jira] [Created] (DELTASPIKE-352) update dependencies for weld2
Gerhard Petracek created DELTASPIKE-352: --- Summary: update dependencies for weld2 Key: DELTASPIKE-352 URL: https://issues.apache.org/jira/browse/DELTASPIKE-352 Project: DeltaSpike Issue Type: Task Components: Tests Reporter: Gerhard Petracek Fix For: 0.4-incubating -- 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] [Resolved] (DELTASPIKE-352) update dependencies for weld2
[ https://issues.apache.org/jira/browse/DELTASPIKE-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-352. - Resolution: Fixed update dependencies for weld2 - Key: DELTASPIKE-352 URL: https://issues.apache.org/jira/browse/DELTASPIKE-352 Project: DeltaSpike Issue Type: Task Components: Tests Reporter: Gerhard Petracek Fix For: 0.4-incubating -- 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] [Created] (DELTASPIKE-353) restrict global alternatives to weld 1.x
Gerhard Petracek created DELTASPIKE-353: --- Summary: restrict global alternatives to weld 1.x Key: DELTASPIKE-353 URL: https://issues.apache.org/jira/browse/DELTASPIKE-353 Project: DeltaSpike Issue Type: Task Components: Core Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating weld2 fixed the issue with cdi-alternatives -- 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] [Resolved] (DELTASPIKE-353) restrict global alternatives to weld 1.x
[ https://issues.apache.org/jira/browse/DELTASPIKE-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-353. - Resolution: Fixed restrict global alternatives to weld 1.x Key: DELTASPIKE-353 URL: https://issues.apache.org/jira/browse/DELTASPIKE-353 Project: DeltaSpike Issue Type: Task Components: Core Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating weld2 fixed the issue with cdi-alternatives -- 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] [Created] (DELTASPIKE-349) smart feature-deactivation
Gerhard Petracek created DELTASPIKE-349: --- Summary: smart feature-deactivation Key: DELTASPIKE-349 URL: https://issues.apache.org/jira/browse/DELTASPIKE-349 Project: DeltaSpike Issue Type: New Feature Affects Versions: 1.0.0 Reporter: Gerhard Petracek Fix For: 1.0.1 it should be possible to enable a mode for smart/dynamic feature-deactivation. e.g. if there is no @WindowScoped bean, we can deactivate the classes which handle it (which would get active for every request to do checks,...) - we get a better out-of-the-box performance optimized for the features used by an application. -- 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-349) smart feature-deactivation
[ https://issues.apache.org/jira/browse/DELTASPIKE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13643254#comment-13643254 ] Gerhard Petracek commented on DELTASPIKE-349: - DELTASPIKE-30 is useful in combination with this feature smart feature-deactivation -- Key: DELTASPIKE-349 URL: https://issues.apache.org/jira/browse/DELTASPIKE-349 Project: DeltaSpike Issue Type: New Feature Affects Versions: 1.0.0 Reporter: Gerhard Petracek Fix For: 1.0.1 it should be possible to enable a mode for smart/dynamic feature-deactivation. e.g. if there is no @WindowScoped bean, we can deactivate the classes which handle it (which would get active for every request to do checks,...) - we get a better out-of-the-box performance optimized for the features used by an application. -- 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] [Created] (DELTASPIKE-350) re-visit @Matches
Gerhard Petracek created DELTASPIKE-350: --- Summary: re-visit @Matches Key: DELTASPIKE-350 URL: https://issues.apache.org/jira/browse/DELTASPIKE-350 Project: DeltaSpike Issue Type: New Feature Affects Versions: 0.4-incubating Reporter: Gerhard Petracek -- 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] [Created] (DELTASPIKE-351) discuss usage of DeltaSpikeConfig
Gerhard Petracek created DELTASPIKE-351: --- Summary: discuss usage of DeltaSpikeConfig Key: DELTASPIKE-351 URL: https://issues.apache.org/jira/browse/DELTASPIKE-351 Project: DeltaSpike Issue Type: Task Reporter: Gerhard Petracek Assignee: Mark Struberg Fix For: 0.4-incubating -- 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] [Updated] (DELTASPIKE-351) re-visit usage of DeltaSpikeConfig
[ https://issues.apache.org/jira/browse/DELTASPIKE-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-351: Summary: re-visit usage of DeltaSpikeConfig (was: discuss usage of DeltaSpikeConfig) re-visit usage of DeltaSpikeConfig -- Key: DELTASPIKE-351 URL: https://issues.apache.org/jira/browse/DELTASPIKE-351 Project: DeltaSpike Issue Type: Task Reporter: Gerhard Petracek Assignee: Mark Struberg Fix For: 0.4-incubating -- 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-351) re-visit usage of DeltaSpikeConfig
[ https://issues.apache.org/jira/browse/DELTASPIKE-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13643268#comment-13643268 ] Gerhard Petracek commented on DELTASPIKE-351: - imo DeltaSpikeConfig is used for too many artifacts currently. e.g. for LocaleResolver which is misleading imo. using it for too many parts reduces the advantage of it (finding real configs easily - since you get a long list which also includes unrelated parts like MessageContext just because it extends LocaleResolver) re-visit usage of DeltaSpikeConfig -- Key: DELTASPIKE-351 URL: https://issues.apache.org/jira/browse/DELTASPIKE-351 Project: DeltaSpike Issue Type: Task Reporter: Gerhard Petracek Assignee: Mark Struberg Fix For: 0.4-incubating -- 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] [Resolved] (DELTASPIKE-336) support @Stereotype together with @ViewMetaData
[
https://issues.apache.org/jira/browse/DELTASPIKE-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek resolved DELTASPIKE-336.
-
Resolution: Fixed
support @Stereotype together with @ViewMetaData
---
Key: DELTASPIKE-336
URL: https://issues.apache.org/jira/browse/DELTASPIKE-336
Project: DeltaSpike
Issue Type: New Feature
Components: JSF-Module
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
Fix For: 0.4-incubating
example:
@Target({TYPE})
@Retention(RUNTIME)
@Documented
@Stereotype
@View(navigation = REDIRECT)
@interface FacesRedirect
{
}
-
interface Pages
{
@FacesRedirect
interface Public extends ViewConfig
{
class Index implements Public
{
}
}
}
should result in the same as
interface Pages
{
@View(navigation = REDIRECT)
interface Public extends ViewConfig
{
class Index implements Public
{
}
}
}
that also means
interface Pages
{
@FacesRedirect
@View(viewParams = INCLUDE)
class Home implements ViewConfig
{
}
}
need to get merged to one instance of @View
--
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-348) WindowScope stuff breaks ICEfaces
[ https://issues.apache.org/jira/browse/DELTASPIKE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641114#comment-13641114 ] Gerhard Petracek commented on DELTASPIKE-348: - i talked with ted goddard some weeks ago. he agreed that it makes sense to cooperate here once we are done. for existing versions of icefaces we have to provide an adapter. however, for now we have to finish the basic approach. WindowScope stuff breaks ICEfaces - Key: DELTASPIKE-348 URL: https://issues.apache.org/jira/browse/DELTASPIKE-348 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 0.4-incubating Reporter: Nicklas Karlsson Assignee: Mark Struberg Fix For: 0.4-incubating Calling any JSF action gives a 13:54:29,443 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (http-localhost/127.0.0.1:80-1) Error Rendering View[/OSTi.xhtml]: java.lang.RuntimeException: failed to append element[tag: html; attributes: ] into #document at org.icefaces.impl.context.DOMResponseWriter.appendToCursor(DOMResponseWriter.java:411) [icefaces-3.1.0.jar:] at org.icefaces.impl.context.DOMResponseWriter.startElement(DOMResponseWriter.java:262) [icefaces-3.1.0.jar:] at com.sun.faces.facelets.compiler.StartElementInstruction.write(StartElementInstruction.java:75) [jsf-impl-2.1.19.jar:2.1.19] at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82) [jsf-impl-2.1.19.jar:2.1.19] at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:183) [jsf-impl-2.1.19.jar:2.1.19] at org.icefaces.impl.context.DOMPartialViewContext.processPartial(DOMPartialViewContext.java:142) [icefaces-3.1.0.jar:] at javax.faces.component.UIViewRoot.encodeChildren(UIViewRoot.java:973) [jsf-api-2.1.19.jar:2.1] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1779) [jsf-api-2.1.19.jar:2.1] at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:413) [jsf-impl-2.1.19.jar:2.1.19] at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:124) [jsf-impl-2.1.19.jar:2.1.19] at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.19.jar:2.1] at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.19.jar:2.1] at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.1.19.jar:2.1.19] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.19.jar:2.1.19] at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.19.jar:2.1.19] at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.render(DeltaSpikeLifecycleWrapper.java:94) [deltaspike-jsf-module-impl-0.4-incubating-SNAPSHOT.jar:0.4-incubating-SNAPSHOT] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.19.jar:2.1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.2.0.Final.jar:7.2.0.Final] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final.jar:7.2.0.Final] at fi.affecto.marela.framework.logging.MDCFilter.doFilter(MDCFilter.java:33) [framework-1.0.0-SNAPSHOT.jar:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.2.0.Final.jar:7.2.0.Final] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final.jar:7.2.0.Final] at fi.affecto.marela.framework.audit.ForcedLogoutFilter.doFilter(ForcedLogoutFilter.java:40) [framework-1.0.0-SNAPSHOT.jar:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.2.0.Final.jar:7.2.0.Final] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final.jar:7.2.0.Final] at fi.affecto.marela.framework.audit.OfflineFilter.doFilter(OfflineFilter.java:47) [framework-1.0.0-SNAPSHOT.jar:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.2.0.Final.jar:7.2.0.Final] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final.jar:7.2.0.Final] at fi.affecto.marela.framework.exception.DSExceptionIntegration.doFilter
[jira] [Resolved] (DELTASPIKE-347) keep faces-messages per default in case of a redirect
[ https://issues.apache.org/jira/browse/DELTASPIKE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-347. - Resolution: Fixed keep faces-messages per default in case of a redirect - Key: DELTASPIKE-347 URL: https://issues.apache.org/jira/browse/DELTASPIKE-347 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating the window-scope should be used as storage instead of Flash#setKeepMessages, because there are less issues in view of multi-window support esp. before jsf v2.2 and a custom window-handler might have special requirements (which might not be compatible with Flash#setKeepMessages). -- 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] [Resolved] (DELTASPIKE-346) JsfModuleConfig as type-safe config for the jsf-module
[ https://issues.apache.org/jira/browse/DELTASPIKE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-346. - Resolution: Fixed JsfModuleConfig as type-safe config for the jsf-module -- Key: DELTASPIKE-346 URL: https://issues.apache.org/jira/browse/DELTASPIKE-346 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating -- 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] [Updated] (DELTASPIKE-256) allow custom timeout for the UserTransaction
[
https://issues.apache.org/jira/browse/DELTASPIKE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-256:
Fix Version/s: (was: 0.4-incubating)
0.6-incubating
allow custom timeout for the UserTransaction
Key: DELTASPIKE-256
URL: https://issues.apache.org/jira/browse/DELTASPIKE-256
Project: DeltaSpike
Issue Type: New Feature
Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
Fix For: 0.6-incubating
right now it's only possible via:
@Dependent
@Alternative
public class CustomTransactionStrategy extends
EnvironmentAwareTransactionStrategy
{
@Override
protected int getDefaultTransactionTimeoutInSeconds()
{
return 30;
}
}
it should be possible to configure it via a type-safe module-config (for
every outermost transactional 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
[jira] [Updated] (DELTASPIKE-30) review and discuss startup logging of module config
[ https://issues.apache.org/jira/browse/DELTASPIKE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-30: --- Fix Version/s: 0.5-incubating Affects Version/s: 0.4-incubating review and discuss startup logging of module config - Key: DELTASPIKE-30 URL: https://issues.apache.org/jira/browse/DELTASPIKE-30 Project: DeltaSpike Issue Type: Sub-task Affects Versions: 0.4-incubating Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.5-incubating -- 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] [Resolved] (DELTASPIKE-80) review and discuss built in Authorization providers
[ https://issues.apache.org/jira/browse/DELTASPIKE-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-80. Resolution: Won't Fix not needed with the current security module review and discuss built in Authorization providers --- Key: DELTASPIKE-80 URL: https://issues.apache.org/jira/browse/DELTASPIKE-80 Project: DeltaSpike Issue Type: Sub-task Components: Security-Module Reporter: Shane Bryzak Assignee: Shane Bryzak -- 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] [Assigned] (DELTASPIKE-241) Fix integration testing on Weblogic 12c
[ https://issues.apache.org/jira/browse/DELTASPIKE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reassigned DELTASPIKE-241: --- Assignee: Rudy De Busscher Fix integration testing on Weblogic 12c --- Key: DELTASPIKE-241 URL: https://issues.apache.org/jira/browse/DELTASPIKE-241 Project: DeltaSpike Issue Type: Task Components: Tests Affects Versions: 0.3-incubating Reporter: Rudy De Busscher Assignee: Rudy De Busscher Priority: Minor -- 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] [Created] (DELTASPIKE-345) integration of view-controller callbacks with type-safe view-configs
Gerhard Petracek created DELTASPIKE-345: --- Summary: integration of view-controller callbacks with type-safe view-configs Key: DELTASPIKE-345 URL: https://issues.apache.org/jira/browse/DELTASPIKE-345 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating integration of: @InitView @PreViewAction @PreRenderView @PostRenderView -- 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] [Updated] (DELTASPIKE-288) type-safe view-configs
[ https://issues.apache.org/jira/browse/DELTASPIKE-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-288: Summary: type-safe view-configs (was: type-safe navigation via view-configs) type-safe view-configs -- Key: DELTASPIKE-288 URL: https://issues.apache.org/jira/browse/DELTASPIKE-288 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating steps: #1 import https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-TypesafeViewConfig #2 make @Page optional #3 refactor meta-model to allow all requirements we know from codi and seam-faces #4 add configs for folders (e.g. to use @Secured for pages without view-config) #5 re-visit and add seam-faces features like wildcard based configs as well as advanced features requested by codi users -- 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] [Resolved] (DELTASPIKE-345) integration of view-controller callbacks with type-safe view-configs
[ https://issues.apache.org/jira/browse/DELTASPIKE-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-345. - Resolution: Fixed integration of view-controller callbacks with type-safe view-configs Key: DELTASPIKE-345 URL: https://issues.apache.org/jira/browse/DELTASPIKE-345 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating integration of: @InitView @PreViewAction @PreRenderView @PostRenderView -- 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] [Created] (DELTASPIKE-346) JsfModuleConfig as type-safe config for the jsf-module
Gerhard Petracek created DELTASPIKE-346: --- Summary: JsfModuleConfig as type-safe config for the jsf-module Key: DELTASPIKE-346 URL: https://issues.apache.org/jira/browse/DELTASPIKE-346 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating -- 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] [Created] (DELTASPIKE-347) keep faces-messages per default in case of a redirect
Gerhard Petracek created DELTASPIKE-347: --- Summary: keep faces-messages per default in case of a redirect Key: DELTASPIKE-347 URL: https://issues.apache.org/jira/browse/DELTASPIKE-347 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating -- 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] [Updated] (DELTASPIKE-347) keep faces-messages per default in case of a redirect
[ https://issues.apache.org/jira/browse/DELTASPIKE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-347: Description: the window-scope should be used as storage instead of Flash#setKeepMessages, because there are less issues in view of multi-window support esp. before jsf v2.2 and a custom window-handler might have special requirements (which might not be compatible with Flash#setKeepMessages). keep faces-messages per default in case of a redirect - Key: DELTASPIKE-347 URL: https://issues.apache.org/jira/browse/DELTASPIKE-347 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating the window-scope should be used as storage instead of Flash#setKeepMessages, because there are less issues in view of multi-window support esp. before jsf v2.2 and a custom window-handler might have special requirements (which might not be compatible with Flash#setKeepMessages). -- 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] [Assigned] (DELTASPIKE-339) JndiUtils is broken
[ https://issues.apache.org/jira/browse/DELTASPIKE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reassigned DELTASPIKE-339: --- Assignee: John D. Ament (was: Gerhard Petracek) i just committed the intermediate fix, because nothing happened for 1+ week/s. i wanted to get rid of the failed ci-builds, because checking the details of the result every time (if there is a new issue) took longer than the intermediate fix. however, please see my first comment... JndiUtils is broken --- Key: DELTASPIKE-339 URL: https://issues.apache.org/jira/browse/DELTASPIKE-339 Project: DeltaSpike Issue Type: Bug Components: Core Affects Versions: 0.4-incubating Reporter: Mark Struberg Assignee: John D. Ament Priority: Blocker Fix For: 0.4-incubating A recent change in JndiUtils caused a bug in a few Containers java.lang.IllegalStateException: Could not get java:comp/ORB from JNDI at org.apache.deltaspike.core.impl.util.JndiUtils.lookup(JndiUtils.java:79) at org.apache.deltaspike.core.impl.util.JndiUtils.list(JndiUtils.java:186) at org.apache.deltaspike.test.core.impl.util.JndiUtilsTest.testList(JndiUtilsTest.java:72) The code currently enlists all registered objects in JNDI java:comp and tries to lookup() them as a specific type. But as per the spec of javax.naming.Context this will always throw a javax.naming.NamingException if the type of the registered object in JNDI does not match the type for the bind() operation. -- 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] [Assigned] (DELTASPIKE-343) NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0.CR2
[
https://issues.apache.org/jira/browse/DELTASPIKE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek reassigned DELTASPIKE-343:
---
Assignee: Jozef Hartinger
NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0.CR2
-
Key: DELTASPIKE-343
URL: https://issues.apache.org/jira/browse/DELTASPIKE-343
Project: DeltaSpike
Issue Type: Bug
Components: PartialBean
Affects Versions: 0.4-incubating
Environment: JBoss AS 8.0.0.Alpha1-SNAPSHOT, Weld 2.0.0.CR2
Reporter: Ron Smeral
Assignee: Jozef Hartinger
The {{PartialBeanAsAbstractClassTest}} doesn't deploy due to a NPE in
{{PartialBeanLifecycle}}.
It might be some problem with javassist dependency, as {{org.javassist}} is
no more a dependency of {{weld-core}} module in AS in Weld 2.0.0.CR2.
Tested with current DS master.
--
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-343) NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0.CR2
[
https://issues.apache.org/jira/browse/DELTASPIKE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632654#comment-13632654
]
Gerhard Petracek commented on DELTASPIKE-343:
-
thx for reporting the issue. we know it already (see
https://builds.apache.org/view/A-D/view/DeltaSpike/)
javassist is scoped to 'test' - see
https://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=blob;f=deltaspike/modules/partial-bean/impl/pom.xml;h=36b05913ec182fc8d7381995a8efbf8ecd07fe76;hb=HEAD
NPE in PartialBeanAsAbstractClassTest with Weld 2.0.0.CR2
-
Key: DELTASPIKE-343
URL: https://issues.apache.org/jira/browse/DELTASPIKE-343
Project: DeltaSpike
Issue Type: Bug
Components: PartialBean
Affects Versions: 0.4-incubating
Environment: JBoss AS 8.0.0.Alpha1-SNAPSHOT, Weld 2.0.0.CR2
Reporter: Ron Smeral
Assignee: Jozef Hartinger
The {{PartialBeanAsAbstractClassTest}} doesn't deploy due to a NPE in
{{PartialBeanLifecycle}}.
It might be some problem with javassist dependency, as {{org.javassist}} is
no more a dependency of {{weld-core}} module in AS in Weld 2.0.0.CR2.
Tested with current DS master.
--
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] [Updated] (DELTASPIKE-340) Support PreViewConfigNavigateEvent for unknown views as nav-source
[ https://issues.apache.org/jira/browse/DELTASPIKE-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-340: Summary: Support PreViewConfigNavigateEvent for unknown views as nav-source (was: Allow NULL from-view in PreViewConfigNavigateEvent) Support PreViewConfigNavigateEvent for unknown views as nav-source Key: DELTASPIKE-340 URL: https://issues.apache.org/jira/browse/DELTASPIKE-340 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Cody Lerum Assignee: Gerhard Petracek Fix For: 0.4-incubating This is so the event gets fired in the case that the user has not defined a view for each of the possible from pages when doing a ViewConfigAwareNavigation -- 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] [Resolved] (DELTASPIKE-340) Support PreViewConfigNavigateEvent for unknown views as nav-source
[ https://issues.apache.org/jira/browse/DELTASPIKE-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-340. - Resolution: Fixed Support PreViewConfigNavigateEvent for unknown views as nav-source Key: DELTASPIKE-340 URL: https://issues.apache.org/jira/browse/DELTASPIKE-340 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Cody Lerum Assignee: Gerhard Petracek Fix For: 0.4-incubating This is so the event gets fired in the case that the user has not defined a view for each of the possible from pages when doing a ViewConfigAwareNavigation -- 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-339) JndiUtils is broken
[ https://issues.apache.org/jira/browse/DELTASPIKE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13629503#comment-13629503 ] Gerhard Petracek commented on DELTASPIKE-339: - i agree with romain. if it's needed, you can always register a custom ConfigSource for doing it JndiUtils is broken --- Key: DELTASPIKE-339 URL: https://issues.apache.org/jira/browse/DELTASPIKE-339 Project: DeltaSpike Issue Type: Bug Components: Core Affects Versions: 0.4-incubating Reporter: Mark Struberg Assignee: John D. Ament Priority: Blocker Fix For: 0.4-incubating A recent change in JndiUtils caused a bug in a few Containers java.lang.IllegalStateException: Could not get java:comp/ORB from JNDI at org.apache.deltaspike.core.impl.util.JndiUtils.lookup(JndiUtils.java:79) at org.apache.deltaspike.core.impl.util.JndiUtils.list(JndiUtils.java:186) at org.apache.deltaspike.test.core.impl.util.JndiUtilsTest.testList(JndiUtilsTest.java:72) The code currently enlists all registered objects in JNDI java:comp and tries to lookup() them as a specific type. But as per the spec of javax.naming.Context this will always throw a javax.naming.NamingException if the type of the registered object in JNDI does not match the type for the bind() operation. -- 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
Re: When Can I expect DeltaSpike to be production ready?
hi khadka, #1 several projects use deltaspike in production already #2 the graduation vote (at general incubator) passed already [1] #3 it depends on the activity of the whole community (there is no fixed schedule, however, we hope to get v1 soon) regards, gerhard [1] http://s.apache.org/Qun 2013/4/7 Dev Khadka dev.kha...@syntechnepal.com I have been using seam 3 on my CDI based project. Now as Redhat has officially halted development of seam 3, I do not want to continue with seam 3 further and migrate it to DS. Here are few of my questions? * Is it production ready now? ( I know there is not exactly yes/no answer, Please vote in terms of range[1-10], 10 being more stable and production ready) * How much time will it take for incubation process. * When can I expect 1.0.0-Final ? Thank you. Dev Khadka
Re: [DISCUSS] re-visit annotation package/s
imo the only realistic way to reduce the probability that we need changes later on (esp. before v1) is to get involved on a regular basis. e.g. i like what cody lerum does. he migrates a real application (in parallel) and asks a lot of useful question (in the irc channel). that's also a kind of feedback. regards, gerhard 2013/4/2 Romain Manni-Bucau rmannibu...@gmail.com IMO we can begore being tlp change it (notifying tools we know). Then well need to handle @deprecated for at least ine release...would hurt in code for nthg IMHO Le 2 avr. 2013 23:23, John D. Ament john.d.am...@gmail.com a écrit : Mark, In this case it's about the related tooling that broke. Until JBIDE fixes this, users will end up with the wrong annotations in their code. IMHO, I'm not saying no we can't change things like this, but if we do change them and there are known downstream impacts for tools that support DS we should let those tools know what we are doing before we make the change. John On Tue, Apr 2, 2013 at 4:55 PM, Mark Struberg strub...@yahoo.de wrote: nope, TLP only means maturity on the social/community side. For any users it's just a matter of 2 minutes doing a search/replace on the imports and then rebuild their app. That's nothing which we cannot do easily. LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: gudnabr...@gmail.com; deltaspike-dev@incubator.apache.org Cc: Sent: Tuesday, April 2, 2013 10:13 PM Subject: Re: [DISCUSS] re-visit annotation package/s I dont fully agree even if i get you. For a bunch of people tlp = maturity = stability Le 2 avr. 2013 21:47, Matt Benson gudnabr...@gmail.com a écrit : I would agree with Gerhard that TLP and 1.0 are not necessarily linked concepts. I would think most developers would not be surprised by the idea that any release number 1.0 is not guaranteed not to change. Matt On Tue, Apr 2, 2013 at 2:18 PM, Cody Lerum cody.le...@gmail.com wrote: Works for me. I was only using @Excludes and I can just switch to @Typed() On Tue, Apr 2, 2013 at 12:57 PM, John D. Ament john.d.am...@gmail.com wrote: If that's the case, we should target it for 0.4 and forward. On Tue, Apr 2, 2013 at 2:56 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: +1 after first tlp release to be exact Le 2 avr. 2013 20:38, John D. Ament john.d.am...@gmail.com a écrit : Once DS is a TLP, we should try avoiding breaking integrations. On Tue, Apr 2, 2013 at 2:06 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: that can happen until v1 (and not until deltaspike is a tlp). (it was one of our first agreements.) regards, gerhard 2013/4/2 Romain Manni-Bucau rmannibu...@gmail.com Think people know ds is not yet a tlp so some instability is fine IMHO Le 2 avr. 2013 20:00, Cody Lerum cody.le...@gmail.com a écrit : One small problem is the early integration of DS into JBoss Tools - https://issues.jboss.org/browse/JBIDE-13901 I don't know how many people if any are using that integration yet. On Tue, Apr 2, 2013 at 8:47 AM, Pete Muir pm...@redhat.com wrote: +1 to drop, I hate them. On 1 Apr 2013, at 10:06, Christian Kaltepoth christ...@kaltepoth.de wrote: +1 for dropping 2013/3/31 Cody Lerum cody.le...@gmail.com drop em. On Sun, Mar 31, 2013 at 10:35 AM, Mark Struberg strub...@yahoo.de wrote: yes, let's drop them. annotations are like interfaces nowadays. So this is just superfluous. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 31, 2013 5:30 PM Subject: [DISCUSS] re-visit annotation package/s hi @ all, we had an agreement to use a (sub-)package named annotation for all our
[jira] [Resolved] (DELTASPIKE-338) remove hard dependency to javassist
[ https://issues.apache.org/jira/browse/DELTASPIKE-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-338. - Resolution: Fixed remove hard dependency to javassist --- Key: DELTASPIKE-338 URL: https://issues.apache.org/jira/browse/DELTASPIKE-338 Project: DeltaSpike Issue Type: Task Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating some users don't like to have it as a required dependency, but they would like to use interfaces for partial beans (and don't need abstract classes as partial beans). -- 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] [Updated] (DELTASPIKE-338) remove hard dependency to javassist
[ https://issues.apache.org/jira/browse/DELTASPIKE-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-338: Component/s: PartialBean remove hard dependency to javassist --- Key: DELTASPIKE-338 URL: https://issues.apache.org/jira/browse/DELTASPIKE-338 Project: DeltaSpike Issue Type: Task Components: PartialBean Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating some users don't like to have it as a required dependency, but they would like to use interfaces for partial beans (and don't need abstract classes as partial beans). -- 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] [Updated] (DELTASPIKE-113) Review and Discuss ServiceHandlers
[ https://issues.apache.org/jira/browse/DELTASPIKE-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-113: Component/s: (was: Core) PartialBean Review and Discuss ServiceHandlers -- Key: DELTASPIKE-113 URL: https://issues.apache.org/jira/browse/DELTASPIKE-113 Project: DeltaSpike Issue Type: Sub-task Components: PartialBean Affects Versions: 0.1-incubating Reporter: John D. Ament Assignee: Gerhard Petracek Fix For: 0.4-incubating Discuss the Solder feature ServiceHandler -- 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] [Resolved] (DELTASPIKE-113) Review and Discuss ServiceHandlers
[ https://issues.apache.org/jira/browse/DELTASPIKE-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-113. - Resolution: Fixed Review and Discuss ServiceHandlers -- Key: DELTASPIKE-113 URL: https://issues.apache.org/jira/browse/DELTASPIKE-113 Project: DeltaSpike Issue Type: Sub-task Components: PartialBean Affects Versions: 0.1-incubating Reporter: John D. Ament Assignee: Gerhard Petracek Fix For: 0.4-incubating Discuss the Solder feature ServiceHandler -- 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] [Updated] (DELTASPIKE-333) replace javassist with commons-proxy
[ https://issues.apache.org/jira/browse/DELTASPIKE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-333: Component/s: PartialBean replace javassist with commons-proxy Key: DELTASPIKE-333 URL: https://issues.apache.org/jira/browse/DELTASPIKE-333 Project: DeltaSpike Issue Type: Task Components: PartialBean 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 For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DELTASPIKE-327) InvocationHandlerExtension Bean?s are not passivation capable
[ https://issues.apache.org/jira/browse/DELTASPIKE-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-327: Component/s: PartialBean InvocationHandlerExtension Bean?s are not passivation capable --- Key: DELTASPIKE-327 URL: https://issues.apache.org/jira/browse/DELTASPIKE-327 Project: DeltaSpike Issue Type: Bug Components: PartialBean Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 0.4-incubating -- 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
[DISCUSS] re-visit annotation package/s
hi @ all, we had an agreement to use a (sub-)package named annotation for all our annotations within a package. however, it feels a bit clumsy if a package (currently) just contains annotations. e.g. org.apache.deltaspike.core.api.exclude only contains the package annotation. currently we have a mixture (some parts are using the annotation package and some don't) - we have to align it the one way or the other. i'm currently in favour of dropping the annotation-package/s. regards, gerhard
[jira] [Created] (DELTASPIKE-337) unify package for annotations
Gerhard Petracek created DELTASPIKE-337: --- Summary: unify package for annotations Key: DELTASPIKE-337 URL: https://issues.apache.org/jira/browse/DELTASPIKE-337 Project: DeltaSpike Issue Type: Task Affects Versions: 0.3-incubating Reporter: Gerhard Petracek Fix For: 0.4-incubating see http://mail-archives.apache.org/mod_mbox/incubator-deltaspike-dev/201303.mbox/%3CCAGJtJfHiT_ZZJ_UrQOOB13HfOZnMd-P%2BWVYM-qRLyF97f16%3DUQ%40mail.gmail.com%3E -- 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] [Assigned] (DELTASPIKE-337) unify package for annotations
[ https://issues.apache.org/jira/browse/DELTASPIKE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reassigned DELTASPIKE-337: --- Assignee: Gerhard Petracek unify package for annotations - Key: DELTASPIKE-337 URL: https://issues.apache.org/jira/browse/DELTASPIKE-337 Project: DeltaSpike Issue Type: Task Affects Versions: 0.3-incubating Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating see http://mail-archives.apache.org/mod_mbox/incubator-deltaspike-dev/201303.mbox/%3CCAGJtJfHiT_ZZJ_UrQOOB13HfOZnMd-P%2BWVYM-qRLyF97f16%3DUQ%40mail.gmail.com%3E -- 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] [Resolved] (DELTASPIKE-337) unify package for annotations
[ https://issues.apache.org/jira/browse/DELTASPIKE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-337. - Resolution: Fixed unify package for annotations - Key: DELTASPIKE-337 URL: https://issues.apache.org/jira/browse/DELTASPIKE-337 Project: DeltaSpike Issue Type: Task Affects Versions: 0.3-incubating Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating see http://mail-archives.apache.org/mod_mbox/incubator-deltaspike-dev/201303.mbox/%3CCAGJtJfHiT_ZZJ_UrQOOB13HfOZnMd-P%2BWVYM-qRLyF97f16%3DUQ%40mail.gmail.com%3E -- 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] [Assigned] (DELTASPIKE-333) replace javassist with commons-proxy
[ https://issues.apache.org/jira/browse/DELTASPIKE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reassigned DELTASPIKE-333: --- Assignee: Gerhard Petracek replace javassist with commons-proxy Key: DELTASPIKE-333 URL: https://issues.apache.org/jira/browse/DELTASPIKE-333 Project: DeltaSpike Issue Type: Task Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating -- 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] [Resolved] (DELTASPIKE-333) replace javassist with commons-proxy
[ https://issues.apache.org/jira/browse/DELTASPIKE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-333. - Resolution: Won't Fix Fix Version/s: (was: 0.4-incubating) some details of commons-proxy cause issues with our use-cases replace javassist with commons-proxy Key: DELTASPIKE-333 URL: https://issues.apache.org/jira/browse/DELTASPIKE-333 Project: DeltaSpike Issue Type: Task 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 For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DELTASPIKE-338) remove hard dependency to javassist
Gerhard Petracek created DELTASPIKE-338: --- Summary: remove hard dependency to javassist Key: DELTASPIKE-338 URL: https://issues.apache.org/jira/browse/DELTASPIKE-338 Project: DeltaSpike Issue Type: Task Reporter: Gerhard Petracek Fix For: 0.4-incubating some users don't like to have it as a required dependency, but they would like to use interfaces for partial beans (and don't need abstract classes as partial beans). -- 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] [Assigned] (DELTASPIKE-338) remove hard dependency to javassist
[ https://issues.apache.org/jira/browse/DELTASPIKE-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reassigned DELTASPIKE-338: --- Assignee: Gerhard Petracek remove hard dependency to javassist --- Key: DELTASPIKE-338 URL: https://issues.apache.org/jira/browse/DELTASPIKE-338 Project: DeltaSpike Issue Type: Task Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating some users don't like to have it as a required dependency, but they would like to use interfaces for partial beans (and don't need abstract classes as partial beans). -- 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
Re: Heading towards a 0.4 release
@ ...everyone is free to just add a feature branch...: imo we should keep [1] for single features. otherwise we end up with 100+ branches and we can't drop a single one later on (if it would be needed)... however, we also have to think about an approach for v1+ - i would suggest to add new modules via (feature-)branches once we agreed to add them to deltaspike (in a [discuss]-thread on the dev-list). once a module is stable enough to get part of the next release, we can merge its branch into the master. regards, gerhard [1] http://incubator.apache.org/deltaspike/suggested-git-workflows.html#contribution-workflow 2013/3/27 Mark Struberg strub...@yahoo.de yup please later than 0.4. I'd say we call a feature freeze until we ship 0.4 (hopefully next week) and focus on * JSF * JPA * Security After that we can add new features to the master branch. Of course, everyone is free to just add a feature branch for a new feature which is outside those areas. LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Tuesday, March 26, 2013 2:28 PM Subject: Re: Heading towards a 0.4 release T he last time I asked about it the responses seemed lukewarm, so I figured it wasn't something people really cared about. We could certainly add it in post 0.4 if there really is a desire for it. — Sent from Mailbox for iPhone On Tue, Mar 26, 2013 at 7:23 AM, John D. Ament john.d.am...@gmail.com wrote: Jason, Does that mean we are no longer bringing XML config to DeltaSpike, even though it was already voted in? On Tue, Mar 26, 2013 at 9:10 AM, Jason Porter lightguard...@gmail.comwrote: Wrt xml-config, I'll be working on configuring cdi via osgi blueprint, over in the Aries project. If we want to port over the seam config stuff, we can certainly do that too. — Sent from Mailbox for iPhone On Tue, Mar 26, 2013 at 4:42 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: @Gerhard: the point about proxy was i thought it was not straight forward since some people will not want to bring any additional lib for it (because they use only interfaces and proxy libs can conflcts). Wonder if handling it with a dep optional couldn't do the trick too. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/3/26 Gerhard Petracek gerhard.petra...@gmail.com @ romain: imo it doesn't make sense to remove something (and add it later on again), if it's just a matter of few hours (to do it immediately). anybody is welcome to work on DS-333. @ DS-288 it's almost done and as i mentioned earlier i'll finish it once DS-289 is done. (yes we need it for 0.4) @ xml-config afair we had an agreement already, but nobody worked on it. regards, gerhard 2013/3/26 John D. Ament john.d.am...@gmail.com I think leaving proxy support to full interface only for now makes sense, we can enrich this further in another release. How about we close 113 as a reduced scope and open a new issue for remaining items? I see you already did some Gerhard, but we still have abstract classes as a case as well. Gerhard, can you also comment on 288? Do we need this in 0.4 or can it wait? Romain, I didn't quite get you. Are you saying you're on hold on this one (dependent on something?). Does anyone believe we need Seam XML Config in 0.4? (DS-269 to 272). I'd prefer to move it. For DS-105, it looks like consensus is to keep it since it's needed for older Weld versions. If so can we close as will not fix? Jason P - Can you look at DS-132/134? Do we need these? There are other catch like issues out there. Are they needed? Mark S - You have 12 issues assigned to you :/ BTW I created a new filter - only open issues [1] John [1] https://issues.apache.org/jira/issues/?filter=12323789 On Mon, Mar 25, 2013 at 12:49 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi DS-60: we are a bunch o wait after it DS-113: think we can push partial bean to another release and keep interface handling for this iteration (well if you import asm part right now it can work but then the question will be which shade version? a proxy as in cxf?) other are not blocker IMO *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com
Re: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top Level Project
+1 (asap)
regards,
gerhard
2013/3/25 Mark Struberg strub...@yahoo.de
Lords and Ladies.
Please find attached the PROPOSAL for graduating DeltaSpike out of the
Incubator and establishing it as TLP.
[+1] yea, all fine and I like it
[+0] no blocker, but I don't care
[-1] nah there's a blocker in there. Abort and re-roll because of ${reason}
The internal VOTE is open for 72h. After that we gonna tally and forward
the VOTE to the IPMC to VOTE about the recommendation. Once this is done,
the board might consider our wish in the upcoming board meeting.
LieGrue,
strub
---
Proposed Board Resolution Report
X. Establish the Apache DeltaSpike Project
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to creating a set
of portable CDI (JSR-299) Extensions
for distribution at no charge to the public.
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache DeltaSpike Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby is
responsible for the creation and maintenance of open-source
software related to creating a set of portable CDI Extensions;
and be it further
RESOLVED, that the office of Vice President, Apache DeltaSpike be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache DeltaSpike Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache DeltaSpike Project; and be it further
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache DeltaSpike Project:
Gerhard Petracek gpetracek at apache.org
Mark Struberg struberg at apache.org
Pete Muir pmuir at redhat.com
Jason Porter lightguard.jp at gmail.com
Shane Bryzak sbryzak at gmail.com
Rudy de Busscher rdebusscher at apache.org
Christian Kaltepoth christian at kaltepoth.de
Arne Limburg arne.limburg at openknowledge.de
Charles Moulliard cmoulliard at gmail.com
Cody Lerum cody.lerum at gmail.com
Romain Mannu-Buccau rmannibucau at gmail.com
Matthew Jason Benson mbenson at apache.org
Jim Jagielski jim at apache.org
David Blevins dblevins at apache.org
Ken Finnigan ken at kenfinnigan.me
John D. Ament johndament at apache.org
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mark Struberg
be appointed to the office of Vice President, Apache DeltaSpike, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further
RESOLVED, that the initial Apache DeltaSpike PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache DeltaSpike Project; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator DeltaSpike podling; and be it further
RESOLVED, that all responsibilities pertaining to the Apache
Incubator DeltaSpike podling encumbered upon the Apache Incubator
Project are hereafter discharged.
https://cwiki.apache.org/confluence/display/DeltaSpike/Graduation+Proposal
[jira] [Commented] (DELTASPIKE-263) Generate binaries of DeltaSpike project
[ https://issues.apache.org/jira/browse/DELTASPIKE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13613633#comment-13613633 ] Gerhard Petracek commented on DELTASPIKE-263: - @john: we will have both the separated jar-files and some useful bundles (like ds-web-profile) which are needed for some app.servers (esp. due to CDI-18). Generate binaries of DeltaSpike project --- Key: DELTASPIKE-263 URL: https://issues.apache.org/jira/browse/DELTASPIKE-263 Project: DeltaSpike Issue Type: New Feature Affects Versions: 0.3-incubating Reporter: Charles Moulliard Assignee: Charles Moulliard Fix For: 0.4-incubating -- 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
Re: Heading towards a 0.4 release
@ romain: imo it doesn't make sense to remove something (and add it later on again), if it's just a matter of few hours (to do it immediately). anybody is welcome to work on DS-333. @ DS-288 it's almost done and as i mentioned earlier i'll finish it once DS-289 is done. (yes we need it for 0.4) @ xml-config afair we had an agreement already, but nobody worked on it. regards, gerhard 2013/3/26 John D. Ament john.d.am...@gmail.com I think leaving proxy support to full interface only for now makes sense, we can enrich this further in another release. How about we close 113 as a reduced scope and open a new issue for remaining items? I see you already did some Gerhard, but we still have abstract classes as a case as well. Gerhard, can you also comment on 288? Do we need this in 0.4 or can it wait? Romain, I didn't quite get you. Are you saying you're on hold on this one (dependent on something?). Does anyone believe we need Seam XML Config in 0.4? (DS-269 to 272). I'd prefer to move it. For DS-105, it looks like consensus is to keep it since it's needed for older Weld versions. If so can we close as will not fix? Jason P - Can you look at DS-132/134? Do we need these? There are other catch like issues out there. Are they needed? Mark S - You have 12 issues assigned to you :/ BTW I created a new filter - only open issues [1] John [1] https://issues.apache.org/jira/issues/?filter=12323789 On Mon, Mar 25, 2013 at 12:49 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi DS-60: we are a bunch o wait after it DS-113: think we can push partial bean to another release and keep interface handling for this iteration (well if you import asm part right now it can work but then the question will be which shade version? a proxy as in cxf?) other are not blocker IMO *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/3/25 Gerhard Petracek gerhard.petra...@gmail.com hi john, @ examples: we haven't discussed what our goal is here @ DS-60 imo we should do it for 0.5 (and release 0.5 short after 0.4) @ DS-113 we have to change the proxy-lib and move it to an own module (i'll create the module today) @ DS-263 not needed, but nice to have - +1 (you can have a look at the setup we used in codi for it to know what you need) @ DS-278 i re-opened it because we should find a better approach imo. however, it isn't a real blocker regards, gerhard 2013/3/25 John D. Ament john.d.am...@gmail.com All, Based on the flurry of threads, I wanted to help get things started to move towards a 0.4 release. I created the filter at [1] to show our current progress. We currently have 50 issues fixed in 0.4, with 27 unresolved for the release. Some of these issues stick out, with me thinking that we've actually completed them but perhaps need some finalization (note: I'll use the abbreviation DS for the DELTASPIKE key in JIRA which is TL;DR) DS-306 - I see examples. Do we need more? DS-60 - I believe we have started integrating CDI Query. Should this have spawned child tasks? DS-113 - Gerhard took the reigns on this one and apparently it works just like the Seam3 version. Can this be closed? Some low hanging fruit: DS-263 - I was actually looking for something like this as well. I've been playing with JBoss modules a lot and think having a binary release would help add DS as a JBoss Module. If this isn't complete, do we need it in 0.4? DS-278 - If not done, seems easy enough to add. DS-288 - Seems like another needed feature, but wasn't too difficult in either CODI or Seam3. DS-289 - Ironically, this one isn't even scheduled for 0.4 but is a blocker for the release. I'll update it as such. If you have something in the list below that shouldn't be (e.g. it's not needed for 0.4) we should get it rescheduled. Since previously only 289 was declared needed for 0.4 we should be looking at everything else. John [1]: https://issues.apache.org/jira/issues/?filter=12323788
[jira] [Commented] (DELTASPIKE-263) Generate binaries of DeltaSpike project
[ https://issues.apache.org/jira/browse/DELTASPIKE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13613720#comment-13613720 ] Gerhard Petracek commented on DELTASPIKE-263: - @john: yes, but ds supports cdi 1.0+ (and we will see if cdi 1.1 really fixes all issues we had) Generate binaries of DeltaSpike project --- Key: DELTASPIKE-263 URL: https://issues.apache.org/jira/browse/DELTASPIKE-263 Project: DeltaSpike Issue Type: New Feature Affects Versions: 0.3-incubating Reporter: Charles Moulliard Assignee: Charles Moulliard Fix For: 0.4-incubating -- 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] [Comment Edited] (DELTASPIKE-263) Generate binaries of DeltaSpike project
[ https://issues.apache.org/jira/browse/DELTASPIKE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13613720#comment-13613720 ] Gerhard Petracek edited comment on DELTASPIKE-263 at 3/26/13 12:11 PM: --- @john: yes, but ds supports cdi 1.0+ (and we will see if cdi 1.1 really fixes all issues we had) we don't have to resolve/close it until it's really done. if we don't have time for it before 0.4, we just need to re-schedule it to 0.5 was (Author: gpetracek): @john: yes, but ds supports cdi 1.0+ (and we will see if cdi 1.1 really fixes all issues we had) Generate binaries of DeltaSpike project --- Key: DELTASPIKE-263 URL: https://issues.apache.org/jira/browse/DELTASPIKE-263 Project: DeltaSpike Issue Type: New Feature Affects Versions: 0.3-incubating Reporter: Charles Moulliard Assignee: Charles Moulliard Fix For: 0.4-incubating -- 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] [Created] (DELTASPIKE-335) re-visit support of EARs
Gerhard Petracek created DELTASPIKE-335: --- Summary: re-visit support of EARs Key: DELTASPIKE-335 URL: https://issues.apache.org/jira/browse/DELTASPIKE-335 Project: DeltaSpike Issue Type: Task Affects Versions: 0.4-incubating Reporter: Gerhard Petracek Fix For: 0.5-incubating #1 our current approach to get rid of basic classloader issues (esp. with EARs) is to collect information during bootstrapping and inject the extension instance to consume the result later on. that can expose the collected information of one web-app to other web-apps (of the same EAR). in codi we used the classloader as key, however, this approach also has disadvantages. (something like @WebApplicationName would only work in some cases.) #2 there was no real agreement about https://issues.jboss.org/browse/CDI-129. currently we expect that @ApplicationScoped is separated per web-app. however, that's at least not the case with current versions of weld. - (at least for current versions of weld) we have to think about an own @WebApplicationScoped -- 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-263) Generate binaries of DeltaSpike project
[ https://issues.apache.org/jira/browse/DELTASPIKE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13614047#comment-13614047 ] Gerhard Petracek commented on DELTASPIKE-263: - sure (could be an own sub-task) - but #1 once you provide it (official downloads), (more) people will ask for bundles as well (since some really need them) #2 since you have to change the build-config, you can do both (you also have to check if the bundles are included correctly) Generate binaries of DeltaSpike project --- Key: DELTASPIKE-263 URL: https://issues.apache.org/jira/browse/DELTASPIKE-263 Project: DeltaSpike Issue Type: New Feature Affects Versions: 0.3-incubating Reporter: Charles Moulliard Assignee: Charles Moulliard Fix For: 0.4-incubating -- 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
Re: Heading towards a 0.4 release
hi john, @ examples: we haven't discussed what our goal is here @ DS-60 imo we should do it for 0.5 (and release 0.5 short after 0.4) @ DS-113 we have to change the proxy-lib and move it to an own module (i'll create the module today) @ DS-263 not needed, but nice to have - +1 (you can have a look at the setup we used in codi for it to know what you need) @ DS-278 i re-opened it because we should find a better approach imo. however, it isn't a real blocker regards, gerhard 2013/3/25 John D. Ament john.d.am...@gmail.com All, Based on the flurry of threads, I wanted to help get things started to move towards a 0.4 release. I created the filter at [1] to show our current progress. We currently have 50 issues fixed in 0.4, with 27 unresolved for the release. Some of these issues stick out, with me thinking that we've actually completed them but perhaps need some finalization (note: I'll use the abbreviation DS for the DELTASPIKE key in JIRA which is TL;DR) DS-306 - I see examples. Do we need more? DS-60 - I believe we have started integrating CDI Query. Should this have spawned child tasks? DS-113 - Gerhard took the reigns on this one and apparently it works just like the Seam3 version. Can this be closed? Some low hanging fruit: DS-263 - I was actually looking for something like this as well. I've been playing with JBoss modules a lot and think having a binary release would help add DS as a JBoss Module. If this isn't complete, do we need it in 0.4? DS-278 - If not done, seems easy enough to add. DS-288 - Seems like another needed feature, but wasn't too difficult in either CODI or Seam3. DS-289 - Ironically, this one isn't even scheduled for 0.4 but is a blocker for the release. I'll update it as such. If you have something in the list below that shouldn't be (e.g. it's not needed for 0.4) we should get it rescheduled. Since previously only 289 was declared needed for 0.4 we should be looking at everything else. John [1]: https://issues.apache.org/jira/issues/?filter=12323788
[jira] [Created] (DELTASPIKE-331) create partial-bean module
Gerhard Petracek created DELTASPIKE-331: --- Summary: create partial-bean module Key: DELTASPIKE-331 URL: https://issues.apache.org/jira/browse/DELTASPIKE-331 Project: DeltaSpike Issue Type: Task Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating -- 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] [Resolved] (DELTASPIKE-331) create partial-bean module
[ https://issues.apache.org/jira/browse/DELTASPIKE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-331. - Resolution: Fixed create partial-bean module -- Key: DELTASPIKE-331 URL: https://issues.apache.org/jira/browse/DELTASPIKE-331 Project: DeltaSpike Issue Type: Task Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating -- 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
Re: DISCUSS DeltaSpike-324
hi john, we can't keep it currently (i'm also unhappy about it), because if only 2-3 people help on a regular basis [1], you have to wait until they have time. it isn't only about unassigned issues. e.g. not that many help with writing tests and examples, writing/reviewing javadoc and documentation. even the graduation process takes (very) long. that might be a big blocker for some users. at least codi had several users way before v1 (and for sure even more after v1). however, we would lose more users, if we release v1 which isn't ready. imo our goal for v1 should be at least everything (which we know already) we need for improving the java-ee web-profile as well as a stable api and spi. regards, gerhard [1] https://github.com/apache/incubator-deltaspike/contributors 2013/3/24 Romain Manni-Bucau rmannibu...@gmail.com I get you and think we agree behund words. My main issue is our 0.4 is not ready to be released and still doesnt contain what users are waiting for... When i spoke about 1.0 just understand when last release answer basic needs Le 24 mars 2013 16:49, John D. Ament john.d.am...@gmail.com a écrit : Romain, I'm not sure what to tell you. One of our founding statements was release early and often. I'm not sure why we haven't stuck to that. Personally, I think we have failed to do that. We probably have too many features in a single release/ not much release planning/attempt to release everything as one big release rather than more modular in nature. Those are just thoughts. As I already stated, I don't want this in 0.4. But I don't think it's appropriate to stick this in after 1.0, who knows when that will be. I would love to see this in 0.5, already have prototypes working. My biggest issue, as I was trying to raise in the other thread, is that when people look at the issue list out there, generally the candidates to work on are the unassigned issues. If 80% of what we have out there is assigned, then it's assumed someone's work on it. If it's assigned to someone and they're not working on it, that's probably an issue that needs to be addressed. As far as I can tell, of the 10 unassigned issues out there, none of them are comprehensible enough (other than the one I already worked on) to be worked through. So I'm not sure, maybe it's an issue of perception, but I don't think we have a large pile of open work for future releases. John On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Sure but we cant start everything, finishing nothing...our rare releases are already a pain for users. We need jsf + if possible cdi query for 0.4 IMO then i agree rest helpers are a must have (some tools around jaxrs client part can be great) etc... Le 24 mars 2013 16:13, John D. Ament john.d.am...@gmail.com a écrit : Romain, My only issue with this is that I don't think we've mapped out what the common use cases are (at least based on the email I sent out). If we're favoring JSF, we're neglecting the growing population of REST APIs for rich javascript clients (from UI). On Sat, Mar 23, 2013 at 6:04 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: yes but JMS is clearly not the most used can't we push it for the 1.0? users really wait the first 1.0 to use DS and adding JMS now simply looks like forgetting more common use cases *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/3/23 Gerhard Petracek gerhard.petra...@gmail.com hi @ all, imo it's more a basic question. if we do it for jms 2, we also have to (/should) do it for other specifications like bv 1.1 regards, gerhard 2013/3/21 Romain Manni-Bucau rmannibu...@gmail.com Ill rephrase a bit. I m rather -0 about it and -1 since a lot of others stuff are needed before. Le 21 mars 2013 22:50, Arne Limburg arne.limb...@openknowledge.de a écrit : We should find out if one can simply use a JMS 2.0 implementation and put it into an deployment. If that will be possible, we would not need to implement it. Cheers, Arne Am 21.03.13 22:34 schrieb Mark Struberg unter strub...@yahoo.de : I tend to lean towards +1 simply because EE-7 containers will take another year (or 2) to become used in projects. I just think we should first close a few tasks before we open new ones. LieGrue, strub
Re: DISCUSS DeltaSpike-324
hi adrian, yes, i also know several projects which use codi + ds 0.3 (in production) and they are happy with it. (most of them move to ds feature by feature without issues.) regards, gerhard 2013/3/24 Adrian Gonzalez adr_gonza...@yahoo.fr Hello, I'm a DS user (and I'm not the only one I think). Just to let you know how I use it (if this can help someone) : DS 0.3 with a mix of CODI and 2/3 classes from Seam [1]. Quite happy for now (I'm using DS Exception handling - with custom REST and JSF extensions from Seam 3, Config). From CODI, I use WindowScoped, ConversationScoped and ViewAccessScoped. From Seam 3, I use a modified version JSF ExceptionHandling (to integrate to DS Exception Handling), UIInputContainer (completely optional, but I like it), and REST Exception Handling. Only JSF ExceptionHandling is really mandatory IMO. For the rest of my application CMT EJB Stateless (tx) and @PersistenceContext (no extended). I'll remove CODI when CODI scopes are ported to DS which should be DS 0.4 if I'm correct. Best regards, [1] Most notably : https://github.com/seam/faces/tree/develop/impl/src/main/java/org/jboss/seam/faces/exception De : Romain Manni-Bucau rmannibu...@gmail.com À : deltaspike-dev@incubator.apache.org Envoyé le : Dimanche 24 mars 2013 19h33 Objet : Re: DISCUSS DeltaSpike-324 I did a JUG this week with a part on DS and was the main question asked with those words when will it be usable?...kind of sad. Releasing even in alpha/beta is better IMO. Le 24 mars 2013 19:29, Jason Porter lightguard...@gmail.com a écrit : +1 glad I'm not the only one asking for a roadmap now. — Sent from Mailbox for iPhone On Sun, Mar 24, 2013 at 11:54 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Do we already have a roadmap? I think we should define one by iteration (+handle a backlog if we want). I can help on cdi query part if needed (jsf is still a bit too new for me). Le 24 mars 2013 18:49, Gerhard Petracek gerhard.petra...@gmail.com a écrit : hi john, we can't keep it currently (i'm also unhappy about it), because if only 2-3 people help on a regular basis [1], you have to wait until they have time. it isn't only about unassigned issues. e.g. not that many help with writing tests and examples, writing/reviewing javadoc and documentation. even the graduation process takes (very) long. that might be a big blocker for some users. at least codi had several users way before v1 (and for sure even more after v1). however, we would lose more users, if we release v1 which isn't ready. imo our goal for v1 should be at least everything (which we know already) we need for improving the java-ee web-profile as well as a stable api and spi. regards, gerhard [1] https://github.com/apache/incubator-deltaspike/contributors 2013/3/24 Romain Manni-Bucau rmannibu...@gmail.com I get you and think we agree behund words. My main issue is our 0.4 is not ready to be released and still doesnt contain what users are waiting for... When i spoke about 1.0 just understand when last release answer basic needs Le 24 mars 2013 16:49, John D. Ament john.d.am...@gmail.com a écrit : Romain, I'm not sure what to tell you. One of our founding statements was release early and often. I'm not sure why we haven't stuck to that. Personally, I think we have failed to do that. We probably have too many features in a single release/ not much release planning/attempt to release everything as one big release rather than more modular in nature. Those are just thoughts. As I already stated, I don't want this in 0.4. But I don't think it's appropriate to stick this in after 1.0, who knows when that will be. I would love to see this in 0.5, already have prototypes working. My biggest issue, as I was trying to raise in the other thread, is that when people look at the issue list out there, generally the candidates to work on are the unassigned issues. If 80% of what we have out there is assigned, then it's assumed someone's work on it. If it's assigned to someone and they're not working on it, that's probably an issue that needs to be addressed. As far as I can tell, of the 10 unassigned issues out there, none of them are comprehensible enough (other than the one I already worked on) to be worked through. So I'm not sure, maybe it's an issue of perception, but I don't think we have a large pile of open work for future releases. John On Sun, Mar 24, 2013 at 11:19 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Sure but we cant start everything, finishing nothing...our rare releases
[jira] [Created] (DELTASPIKE-325) upgrade to owb-arquillian-standalone
Gerhard Petracek created DELTASPIKE-325: --- Summary: upgrade to owb-arquillian-standalone Key: DELTASPIKE-325 URL: https://issues.apache.org/jira/browse/DELTASPIKE-325 Project: DeltaSpike Issue Type: Task Affects Versions: 0.3-incubating Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating -- 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] [Updated] (DELTASPIKE-325) upgrade to owb-arquillian-standalone and owb 1.1.8
[ https://issues.apache.org/jira/browse/DELTASPIKE-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-325: Summary: upgrade to owb-arquillian-standalone and owb 1.1.8 (was: upgrade to owb-arquillian-standalone) upgrade to owb-arquillian-standalone and owb 1.1.8 -- Key: DELTASPIKE-325 URL: https://issues.apache.org/jira/browse/DELTASPIKE-325 Project: DeltaSpike Issue Type: Task Affects Versions: 0.3-incubating Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating -- 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] [Resolved] (DELTASPIKE-325) upgrade to owb-arquillian-standalone and owb 1.1.8
[ https://issues.apache.org/jira/browse/DELTASPIKE-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-325. - Resolution: Fixed upgrade to owb-arquillian-standalone and owb 1.1.8 -- Key: DELTASPIKE-325 URL: https://issues.apache.org/jira/browse/DELTASPIKE-325 Project: DeltaSpike Issue Type: Task Affects Versions: 0.3-incubating Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.4-incubating -- 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
Re: DISCUSS DeltaSpike-324
hi @ all, imo it's more a basic question. if we do it for jms 2, we also have to (/should) do it for other specifications like bv 1.1 regards, gerhard 2013/3/21 Romain Manni-Bucau rmannibu...@gmail.com Ill rephrase a bit. I m rather -0 about it and -1 since a lot of others stuff are needed before. Le 21 mars 2013 22:50, Arne Limburg arne.limb...@openknowledge.de a écrit : We should find out if one can simply use a JMS 2.0 implementation and put it into an deployment. If that will be possible, we would not need to implement it. Cheers, Arne Am 21.03.13 22:34 schrieb Mark Struberg unter strub...@yahoo.de: I tend to lean towards +1 simply because EE-7 containers will take another year (or 2) to become used in projects. I just think we should first close a few tasks before we open new ones. LieGrue, strub - Original Message - From: John D. Ament john.d.am...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Thursday, March 21, 2013 6:09 PM Subject: Re: DISCUSS DeltaSpike-324 Romain, Generally, I'm mixed about these. However I think there's some pretty good benefits. For an application developer, maybe none of the other JMS 2 features are useful to you (the bulk of the feature went into CDI support, app server integration, and documentation clean up). You don't want to move off of TomEE 1.5.x to TomEE Y (which could support Java EE 7 Web Profile) due to downtime in your application. There's also lead time required to impelement JMS 2/Java EE 7 features in your application server, but perhaps you don't want to or need to wait for the whole thing. This solution would be DS oriented, I believe requires TransactionScoped (which could require the transaction classes be moved away from persistence) to operate properly. There's also the case of using DeltaSpike as your CDI-JMS implementation if you were a JMS implementer. I haven't reached out to communities such as Apache ActiveMQ or HornetQ to see input here; I know the current GlassFish implementation calls their lower level directly (and not by wrapping the JMS APIs). John On Thu, Mar 21, 2013 at 12:30 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi i'm globally -1 for redoing something which will exist somewhere else (basically if somebody wants JavaEE just let him use JavaEE, CDI doesn't need the full stack IMO). Was my point for JPA, more again on JMS. It is great to add feature before the specs not once it is (or almost) done. Maybe i didnt fully get what you want to do so maybe share some pastebin to be sure we speak about the same stuff. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/3/21 John D. Ament john.d.am...@gmail.com All, I'd like to open the floor to discussion for porting JMS 2 features to DeltaSpike, specifically the features that added some CDI capabilities to JMS. Details of my rough proposal are here: https://issues.apache.org/jira/browse/DELTASPIKE-324 Importing these features start to deprecate functionality in Seam JMS (ideal). These features would give access to an API very similar to the JMS2 API around CDI injection. Some limitations: - This would not be a JMS implementation, simply an inspired interface for use in Java EE 6/JMS 1.x that leveraged CDI injection based on the rules for CDI injection of these interfaces. We would bring in very similar annotations that supported the injection of the three target types. - Cannot use the exact interface, since the interface implements AutoCloseable which is a Java SE 7 interface. DeltaSpike uses Java SE 6 for a compiler. - Internally these would have to use the current JMS interfaces of connection, session. - Testing would be feasible but require a full Java EE container (e.g. no testing in Weld/OWB directly) that supported deployment of destinations at runtime. Since this doesn't touch MDBs we can manually read from the destination. John
Re: DISCUSS DeltaSpike-324
@ romain: +1 regards, gerhard 2013/3/23 Romain Manni-Bucau rmannibu...@gmail.com yes but JMS is clearly not the most used can't we push it for the 1.0? users really wait the first 1.0 to use DS and adding JMS now simply looks like forgetting more common use cases *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/3/23 Gerhard Petracek gerhard.petra...@gmail.com hi @ all, imo it's more a basic question. if we do it for jms 2, we also have to (/should) do it for other specifications like bv 1.1 regards, gerhard 2013/3/21 Romain Manni-Bucau rmannibu...@gmail.com Ill rephrase a bit. I m rather -0 about it and -1 since a lot of others stuff are needed before. Le 21 mars 2013 22:50, Arne Limburg arne.limb...@openknowledge.de a écrit : We should find out if one can simply use a JMS 2.0 implementation and put it into an deployment. If that will be possible, we would not need to implement it. Cheers, Arne Am 21.03.13 22:34 schrieb Mark Struberg unter strub...@yahoo.de: I tend to lean towards +1 simply because EE-7 containers will take another year (or 2) to become used in projects. I just think we should first close a few tasks before we open new ones. LieGrue, strub - Original Message - From: John D. Ament john.d.am...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Thursday, March 21, 2013 6:09 PM Subject: Re: DISCUSS DeltaSpike-324 Romain, Generally, I'm mixed about these. However I think there's some pretty good benefits. For an application developer, maybe none of the other JMS 2 features are useful to you (the bulk of the feature went into CDI support, app server integration, and documentation clean up). You don't want to move off of TomEE 1.5.x to TomEE Y (which could support Java EE 7 Web Profile) due to downtime in your application. There's also lead time required to impelement JMS 2/Java EE 7 features in your application server, but perhaps you don't want to or need to wait for the whole thing. This solution would be DS oriented, I believe requires TransactionScoped (which could require the transaction classes be moved away from persistence) to operate properly. There's also the case of using DeltaSpike as your CDI-JMS implementation if you were a JMS implementer. I haven't reached out to communities such as Apache ActiveMQ or HornetQ to see input here; I know the current GlassFish implementation calls their lower level directly (and not by wrapping the JMS APIs). John On Thu, Mar 21, 2013 at 12:30 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi i'm globally -1 for redoing something which will exist somewhere else (basically if somebody wants JavaEE just let him use JavaEE, CDI doesn't need the full stack IMO). Was my point for JPA, more again on JMS. It is great to add feature before the specs not once it is (or almost) done. Maybe i didnt fully get what you want to do so maybe share some pastebin to be sure we speak about the same stuff. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/3/21 John D. Ament john.d.am...@gmail.com All, I'd like to open the floor to discussion for porting JMS 2 features to DeltaSpike, specifically the features that added some CDI capabilities to JMS. Details of my rough proposal are here: https://issues.apache.org/jira/browse/DELTASPIKE-324 Importing these features start to deprecate functionality in Seam JMS (ideal). These features would give access to an API very similar to the JMS2 API around CDI injection. Some limitations: - This would not be a JMS implementation, simply an inspired interface for use in Java EE 6/JMS 1.x that leveraged CDI injection based on the rules for CDI injection of these interfaces. We would bring in very similar annotations that supported the injection of the three target types. - Cannot use the exact interface, since the interface implements AutoCloseable which is a Java SE 7 interface. DeltaSpike
Re: @View basepath /?
hi romain, it works with codi, but the implementation in deltaspike isn't finished. it isn't the only use-case which is missing right now. (as you see the ticket is in progress and not resolved.) regards, gerhard 2013/3/22 Romain Manni-Bucau rmannibu...@gmail.com forgot to say the same for pages ;) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/3/22 Romain Manni-Bucau rmannibu...@gmail.com Hi why (is there any reason) don't we handle: @View(basePath = foo) ? doing like JAXRS we could just convert it do /foo (since / is mandatory) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau*
Re: @View basepath /?
as i said in the other thread, some use-cases are blocked by [1] and we have to finish [2]. regards, gerhard [1] https://issues.apache.org/jira/browse/DELTASPIKE-289 [2] https://issues.apache.org/jira/browse/DELTASPIKE-113 2013/3/22 Romain Manni-Bucau rmannibu...@gmail.com Ok makes sense then So next question: When do we get next release (starts to last)? Cdi query and typed navigation.seems the features to get it Wdyt? Le 22 mars 2013 21:12, Gerhard Petracek gerhard.petra...@gmail.com a écrit : hi romain, it works with codi, but the implementation in deltaspike isn't finished. it isn't the only use-case which is missing right now. (as you see the ticket is in progress and not resolved.) regards, gerhard 2013/3/22 Romain Manni-Bucau rmannibu...@gmail.com forgot to say the same for pages ;) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/3/22 Romain Manni-Bucau rmannibu...@gmail.com Hi why (is there any reason) don't we handle: @View(basePath = foo) ? doing like JAXRS we could just convert it do /foo (since / is mandatory) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau*
Re: @View basepath /?
i haven't said that. you switched the topic and there the answer is ... some use-cases are blocked by (e.g. JsfMessageBundleInvocationHandler in combination with redirects and @InitView are blocked by it) regards, gerhard 2013/3/22 Romain Manni-Bucau rmannibu...@gmail.com Basically string fixes doesnt need it but then the fixes sound doable to get a release in 1-2 months no? Le 22 mars 2013 21:24, Gerhard Petracek gerhard.petra...@gmail.com a écrit : as i said in the other thread, some use-cases are blocked by [1] and we have to finish [2]. regards, gerhard [1] https://issues.apache.org/jira/browse/DELTASPIKE-289 [2] https://issues.apache.org/jira/browse/DELTASPIKE-113 2013/3/22 Romain Manni-Bucau rmannibu...@gmail.com Ok makes sense then So next question: When do we get next release (starts to last)? Cdi query and typed navigation.seems the features to get it Wdyt? Le 22 mars 2013 21:12, Gerhard Petracek gerhard.petra...@gmail.com a écrit : hi romain, it works with codi, but the implementation in deltaspike isn't finished. it isn't the only use-case which is missing right now. (as you see the ticket is in progress and not resolved.) regards, gerhard 2013/3/22 Romain Manni-Bucau rmannibu...@gmail.com forgot to say the same for pages ;) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/3/22 Romain Manni-Bucau rmannibu...@gmail.com Hi why (is there any reason) don't we handle: @View(basePath = foo) ? doing like JAXRS we could just convert it do /foo (since / is mandatory) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau*
[jira] [Commented] (DELTASPIKE-273) Provide a way to obtain all property names or map of properties
[ https://issues.apache.org/jira/browse/DELTASPIKE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609658#comment-13609658 ] Gerhard Petracek commented on DELTASPIKE-273: - i prefer that as well. i just added the answer here for completeness (because you answered here as well). your mail on the list was a ping to the rest of the community (i placed my vote already and i don't plan to change it). Provide a way to obtain all property names or map of properties --- Key: DELTASPIKE-273 URL: https://issues.apache.org/jira/browse/DELTASPIKE-273 Project: DeltaSpike Issue Type: Improvement Components: Configuration Reporter: Łukasz Dywicki Assignee: John D. Ament Fix For: 0.4-incubating Attachments: DELTASPIKE-273.patch ConfigResolver API provides a way to resolve singular property or multivalued property, however there is lack of method which allows to read all properties discovered from all ConfigSources. -- 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
Re: Pending items for release
hi john, [1] is the most blocking one we need for v0.4. regards, gerhard [1] https://issues.apache.org/jira/browse/DELTASPIKE-289 2013/3/22 John D. Ament john.d.am...@gmail.com All, When I look at open issues for DeltaSpike, all I see is under [1] ; looking at this list it's not clear which are ready to be done or which need more info. In addition when I look at [2] we end up with 50 open issues. V 0.3 was released in August 2012. I'd like to help get DS to a 0.4 release. So please help clarify what issues are in need of help. John [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20DELTASPIKE%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20is%20EMPTY%20ORDER%20BY%20priority%20DESC [2] https://issues.apache.org/jira/issues/?jql=project%20%3D%20DELTASPIKE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
Re: Pending items for release
hi john, no - it will be a new implementation aligned with the new ClientWindow api (of jsf 2.2). afterwards i finish my tickets (which need it) and then we are ready for a release. imo the rest is nice to have for v0.4 regards, gerhard 2013/3/22 John D. Ament john.d.am...@gmail.com Gerhard, But currently it's assigned to Mark. So to outsiders, who maybe haven't been playing close court, someone's already handling it. Since CODI has a Window Scope, I'm assuming that it's simply a port from CODI to DS. John On Thu, Mar 21, 2013 at 9:21 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, [1] is the most blocking one we need for v0.4. regards, gerhard [1] https://issues.apache.org/jira/browse/DELTASPIKE-289 2013/3/22 John D. Ament john.d.am...@gmail.com All, When I look at open issues for DeltaSpike, all I see is under [1] ; looking at this list it's not clear which are ready to be done or which need more info. In addition when I look at [2] we end up with 50 open issues. V 0.3 was released in August 2012. I'd like to help get DS to a 0.4 release. So please help clarify what issues are in need of help. John [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20DELTASPIKE%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20is%20EMPTY%20ORDER%20BY%20priority%20DESC [2] https://issues.apache.org/jira/issues/?jql=project%20%3D%20DELTASPIKE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
Re: Pending items for release
short addition: and we have to create a new module for DS-113 (and use a different proxy lib (or commons proxy)). regards, gerhard 2013/3/22 Gerhard Petracek gerhard.petra...@gmail.com hi john, no - it will be a new implementation aligned with the new ClientWindow api (of jsf 2.2). afterwards i finish my tickets (which need it) and then we are ready for a release. imo the rest is nice to have for v0.4 regards, gerhard 2013/3/22 John D. Ament john.d.am...@gmail.com Gerhard, But currently it's assigned to Mark. So to outsiders, who maybe haven't been playing close court, someone's already handling it. Since CODI has a Window Scope, I'm assuming that it's simply a port from CODI to DS. John On Thu, Mar 21, 2013 at 9:21 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, [1] is the most blocking one we need for v0.4. regards, gerhard [1] https://issues.apache.org/jira/browse/DELTASPIKE-289 2013/3/22 John D. Ament john.d.am...@gmail.com All, When I look at open issues for DeltaSpike, all I see is under [1] ; looking at this list it's not clear which are ready to be done or which need more info. In addition when I look at [2] we end up with 50 open issues. V 0.3 was released in August 2012. I'd like to help get DS to a 0.4 release. So please help clarify what issues are in need of help. John [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20DELTASPIKE%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20is%20EMPTY%20ORDER%20BY%20priority%20DESC [2] https://issues.apache.org/jira/issues/?jql=project%20%3D%20DELTASPIKE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
[jira] [Reopened] (DELTASPIKE-273) Provide a way to obtain all property names or map of properties
[ https://issues.apache.org/jira/browse/DELTASPIKE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reopened DELTASPIKE-273: - imo further discussions are needed Provide a way to obtain all property names or map of properties --- Key: DELTASPIKE-273 URL: https://issues.apache.org/jira/browse/DELTASPIKE-273 Project: DeltaSpike Issue Type: Improvement Components: Configuration Reporter: Łukasz Dywicki Assignee: John D. Ament Fix For: 0.4-incubating Attachments: DELTASPIKE-273.patch ConfigResolver API provides a way to resolve singular property or multivalued property, however there is lack of method which allows to read all properties discovered from all ConfigSources. -- 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-273) Provide a way to obtain all property names or map of properties
[ https://issues.apache.org/jira/browse/DELTASPIKE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13608533#comment-13608533 ] Gerhard Petracek commented on DELTASPIKE-273: - -0,5 a custom config-source might be very large or resolve values from a slow source. Provide a way to obtain all property names or map of properties --- Key: DELTASPIKE-273 URL: https://issues.apache.org/jira/browse/DELTASPIKE-273 Project: DeltaSpike Issue Type: Improvement Components: Configuration Reporter: Łukasz Dywicki Assignee: John D. Ament Fix For: 0.4-incubating Attachments: DELTASPIKE-273.patch ConfigResolver API provides a way to resolve singular property or multivalued property, however there is lack of method which allows to read all properties discovered from all ConfigSources. -- 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] [Comment Edited] (DELTASPIKE-273) Provide a way to obtain all property names or map of properties
[ https://issues.apache.org/jira/browse/DELTASPIKE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13608533#comment-13608533 ] Gerhard Petracek edited comment on DELTASPIKE-273 at 3/21/13 2:02 AM: -- -0,5 a custom config-source might be very large and/or resolve values from a slow source. was (Author: gpetracek): -0,5 a custom config-source might be very large or resolve values from a slow source. Provide a way to obtain all property names or map of properties --- Key: DELTASPIKE-273 URL: https://issues.apache.org/jira/browse/DELTASPIKE-273 Project: DeltaSpike Issue Type: Improvement Components: Configuration Reporter: Łukasz Dywicki Assignee: John D. Ament Fix For: 0.4-incubating Attachments: DELTASPIKE-273.patch ConfigResolver API provides a way to resolve singular property or multivalued property, however there is lack of method which allows to read all properties discovered from all ConfigSources. -- 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
Re: cdi-query, no news?
hi thomas,
@ #getEntityManager:
injection works in such (partial-)beans (we have tests for it).
@ #saveAndFlush:
it's clear what it does, but not why it's the only combined operation (e.g.
there is no #removeAndFlush).
regards,
gerhard
2013/3/18 Thomas Hug thomas@ctp-consulting.com
Thnx for the remarks Gerhard!
- @Query: Good point, looks more consistent to me too.
- NonEntity was AFAIR introduced to make it more explicit that the Entity
class comes from somewhere else. I don't think we need it - if nobody
prefers the explicit style then I'd favor removing it.
- Not sure if I get the next point - the EntityManager comes always from a
producer and is looked up in the Impl classes (and I guess injection won't
work in InvocationHandlerBinding beans anyway). The methods from
EntityRepository and AbstractEntityRepository are not meant to be
implemented by a client. There's only a getEntityManager() on the
AbstractEntityRepository to be used by concrete query methods which you
don't have with an interface-based repository.
@Repository
public interface PersonRepository extends EntityRepository Person, Long {
Person findBySsn(String ssn);
}
public abstract class PersonRepository extends
AbstractEntityRepositoryPerson, Long {
public ListPerson findByXY(X x, Y y) {
// some logic
return getEntityManager().createQuery(query).getResultList();
}
}
- saveAndFlush will simply call flush after persist/merge instead of
waiting for it at the transaction commit. Can have impact on following
queries.
Confluence updates to follow. Hope that helps...
On Sun, Mar 17, 2013 at 3:12 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi thomas,
i would prefer e.g.
Query#value + Query#isNative (false as the default)
instead of
Query#value + Query#sql
and it would be great to get additional information about the need of:
- NonEntity (as the default)
- AbstractEntityRepository
(e.g. you can pass in the EntityManager as parameter or inject it.
you would need it e.g. for EntityRepository#save,... - but in
EntityRepository it isn't part of the contract...)
- (EntityRepository#saveAndFlush as the only combined operation)
regards,
gerhard
2013/3/14 Thomas Hug thomas@ctp-consulting.com
Thnx for the pointers. Started to outline the APIs here [1] with
examples
in decreasing priority.
[1]
https://cwiki.apache.org/confluence/display/DeltaSpike/Repository+Drafts
On Thu, Mar 14, 2013 at 10:05 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
+1
regards,
gerhard
2013/3/14 Romain Manni-Bucau rmannibu...@gmail.com
ok great,
wonder if we couldn't start by a first version without such
extensibility +
no scopes for queries?
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*
http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/3/14 Gerhard Petracek gerhard.petra...@gmail.com
hi romain,
no - it's more about the style we introduced e.g. for type-safe
messages.
regards,
gerhard
2013/3/14 Romain Manni-Bucau rmannibu...@gmail.com
@Gerhard: hope you don't think of @RepoBinding at all...would
be
too
much
IMO. Would be great to support aliases/stereotype maybe but not
the
default
Wdyt?
Le 14 mars 2013 00:11, Gerhard Petracek
gerhard.petra...@gmail.com
a
écrit :
hi thomas,
imo it should follow the basic style/s we have in other parts
already
(if
possible).
i guess the simple implementations in the test-module are too
simple
to
see
the real benefit.
- it would be nice if you add some drafts to a sub-page of
[1].
(the usage you would prefer and not as it is right now.)
regards,
gerhard
[1]
https://cwiki.apache.org/confluence/display/DeltaSpike/Drafts
2013/3/13 Romain Manni-Bucau rmannibu...@gmail.com
i'd put it in to start since that's useful for JPA but it
shouldn't
use
it
at all
a question (for next iteration if that's ok for everybody)
is
should
repos
handle transaction or at least define it.
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*
http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau
Re: cdi-query, no news?
hi thomas, i would prefer e.g. Query#value + Query#isNative (false as the default) instead of Query#value + Query#sql and it would be great to get additional information about the need of: - NonEntity (as the default) - AbstractEntityRepository (e.g. you can pass in the EntityManager as parameter or inject it. you would need it e.g. for EntityRepository#save,... - but in EntityRepository it isn't part of the contract...) - (EntityRepository#saveAndFlush as the only combined operation) regards, gerhard 2013/3/14 Thomas Hug thomas@ctp-consulting.com Thnx for the pointers. Started to outline the APIs here [1] with examples in decreasing priority. [1] https://cwiki.apache.org/confluence/display/DeltaSpike/Repository+Drafts On Thu, Mar 14, 2013 at 10:05 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard 2013/3/14 Romain Manni-Bucau rmannibu...@gmail.com ok great, wonder if we couldn't start by a first version without such extensibility + no scopes for queries? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/3/14 Gerhard Petracek gerhard.petra...@gmail.com hi romain, no - it's more about the style we introduced e.g. for type-safe messages. regards, gerhard 2013/3/14 Romain Manni-Bucau rmannibu...@gmail.com @Gerhard: hope you don't think of @RepoBinding at all...would be too much IMO. Would be great to support aliases/stereotype maybe but not the default Wdyt? Le 14 mars 2013 00:11, Gerhard Petracek gerhard.petra...@gmail.com a écrit : hi thomas, imo it should follow the basic style/s we have in other parts already (if possible). i guess the simple implementations in the test-module are too simple to see the real benefit. - it would be nice if you add some drafts to a sub-page of [1]. (the usage you would prefer and not as it is right now.) regards, gerhard [1] https://cwiki.apache.org/confluence/display/DeltaSpike/Drafts 2013/3/13 Romain Manni-Bucau rmannibu...@gmail.com i'd put it in to start since that's useful for JPA but it shouldn't use it at all a question (for next iteration if that's ok for everybody) is should repos handle transaction or at least define it. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/3/13 John D. Ament john.d.am...@gmail.com Does this have any direct/indirect dependencies on JPA module? Should this maybe become a part of the JPA module? On Wed, Mar 13, 2013 at 7:23 AM, Thomas Hug thomas@ctp-consulting.comwrote: Ok, I guess it's going to be Repository :) Updated the proposal branch and also moved things into a data package/module. Some remarks for the parts below: 1) EntityManagerRepository wasn't present in the Solder implementation - there it was possible to simply implement/extend EntityManager. The problem with the invocation handler is that it's not possible to restrict the bean type and exclude EntityManager (or I missed it). Otherwise I'd rather get rid of this interface. 2) WithEntityManager is definitely discussable. Not the full solution and not consistent. Could be solved with e.g. putting qualifiers on a method returning an EntityManager (less intuitive) or something like the InvocationHandlerBinding. 3) AbstractEntityRepository is just a convenience class for providing concrete query implementations. On Tue, Mar 12, 2013 at 9:40 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi, currently we don't have one jira ticket per part/feature. that's what we used to have for everything we imported. the first parts to discuss are imo EntityManagerDao, WithEntityManager and AbstractEntityDao. regards, gerhard 2013/3/12 Arne Limburg arne.limb...@openknowledge.de
