from:"Mark Struberg"


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg reassigned DELTASPIKE-339:


Assignee: Mark Struberg  (was: John D. Ament)

 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] [Resolved] (DELTASPIKE-339) JndiUtils is broken


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-339.
--

Resolution: Fixed

exception now gets ignored. This is a standard operation situation.

 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] [Resolved] (DELTASPIKE-284) Deltaspike CDIControl won't work with Weld EE


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-284.
--

Resolution: Not A Problem
  Assignee: Mark Struberg  (was: Peter Muir)

as outlined by Jason and me: this is not a problem. The boot api targets the 
standalone and embedded use cases whereas the ContextControl is intended for 
use in both SE and EE environments.

 Deltaspike CDIControl won't work with Weld EE
 -

 Key: DELTASPIKE-284
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-284
 Project: DeltaSpike
  Issue Type: Bug
  Components: CdiControl
Affects Versions: 0.3-incubating
 Environment: Weld 1.1.10-Final
 Weld 1.1.8-Final
 Tomcat 7.0.32 
Reporter: Karl Kildén
Assignee: Mark Struberg
Priority: Critical

 Added POM artifacts for CdiControl:
 dependency
 groupIdorg.apache.deltaspike.cdictrl/groupId
 artifactIddeltaspike-cdictrl-api/artifactId
 version${deltaspike.version}/version
 /dependency
 dependency
 groupIdorg.apache.deltaspike.cdictrl/groupId
 artifactIddeltaspike-cdictrl-weld/artifactId
 version${deltaspike.version}/version
 /dependency
 Server would not start. Full stacktrace in first comment
 Caused by: java.lang.ClassNotFoundException: 
 org.jboss.weld.environment.se.Weld
   at 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1714)
   at 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
   ... 34 more 

--
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-293) Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events.

[
https://issues.apache.org/jira/browse/DELTASPIKE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mark Struberg resolved DELTASPIKE-293.
--

Resolution: Won't Fix
Assignee: Mark Struberg

Hi!

I think this is not easily fixable. The ViewMap might as well be stored on the
ClientSide. Thus we just have no idea whether we do have a session boundary at
all, etc. Please note that the destroyal of any Serializable bean is not a 100%
safe bet.
E.g. even @SessionScoped beans could not be reliable. Just think about the
session being serialized away to another node and then shutting down the
server. Or having session-passivation to disk and then deleting the storage,
etc.

We can just rely on the JSF container and hope for the best. In case of MyFaces
we will also get this event if the ViewMap gets destroyed after a
SessionTimeout. I'm not sure about Mojarra though.

Improve the ViewScopedContext by observing ServletContext and HttpSession
lifecycle events.
---

Key: DELTASPIKE-293
URL: https://issues.apache.org/jira/browse/DELTASPIKE-293
Project: DeltaSpike
Issue Type: Improvement
Components: JSF-Module
Affects Versions: 0.4-incubating
Reporter: Radu Creanga
Assignee: Mark Struberg
Fix For: 0.5

The CDI specification states that Context implementations are responsible for
destroying instances it creates. The current ViewScopedContext relies on
PreDestroyViewMapEvents to be notified when a view map is destroyed. But, the
JSF 2.0 and 2.1 spec only fire this event when a view map is replaced. This
means that in most cases, instances created by ViewScopedContext are not
properly destroyed. The ViewScopedContext should be observing ServletContext
and HttpSession lifecycle events instead in order to ensure that all
instances it creates are properly destroyed. Visible improvements resulting
out of this would be that the @PostConstruct method of @ViewScoped beans is
invoked. Additionally, this will probably result in better memory usage,
since instances that are not properly destroyed are not eligible for GC.

--
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-288) type-safe view-configs


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-288.
--

Resolution: Fixed

stable and complete enough to get released imo.

 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-289) implement WindowContext


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-289.
--

Resolution: Fixed

implemented in a first version. Good enough to be useful, will get improvements 
in 0.5

 implement WindowContext
 ---

 Key: DELTASPIKE-289
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-289
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Core, JSF-Module
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 Introduce a way to manage different beans depending on a 'window' or browser 
 tab notion.
 A WindowContext stores all the information for a single 'window' or browser 
 tab. The WindowContextManager keeps all open WindowContexts (for a session) 
 and allows to set or determine the one which got activated for the current 
 Thread.

--
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-315) Provide a producer for EntityManagerFactories


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-315.
--

Resolution: Fixed

 Provide a producer for EntityManagerFactories
 -

 Key: DELTASPIKE-315
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-315
 Project: DeltaSpike
  Issue Type: New Feature
  Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 I found myself using the following pattern quite often in projects in the 
 last time. I have a @Qualifier UnitName(value) and a producer for a 
 @Dependent EntityManagerFactory for it. The configuration is mostly provided 
 via the persistenceProperties Map in 
 EntityManagerFactory#createEntityManagerFactory(unitname, 
 persistenceProperties);
 We can further tweak the config lookup path and define a route which makes 
 the most sense.
 This can be used to create the EntityManager producer very easily.
 @ApplicationScoped
 public class MyEntityManagerProducer {
   private @Inject @UnitName(orderUnit) EntityManagerFactory emf;
   
   @Produces @RequestScoped
   public EntityManager createEm() {
 return emf.createEntityManager();
   }
   .. + disposer 
 }
 Please note that the EMF producer doens't clash with anything else as it only 
 produces EMFs with the Qualifier @UnitName!

--
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-278) add 'category' to Message API


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-278.
--

Resolution: Fixed

works well and no further commit was done - resolved

 add 'category' to Message API
 -

 Key: DELTASPIKE-278
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-278
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Core
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.5


 Sometimes we need different versions of a rendered message. This could be a 
 shortText vs a longText for example. Or in JSF it's the summary vs detail 
 message.

--
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-350) re-visit @Matches


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667381#comment-13667381
 ] 

Mark Struberg commented on DELTASPIKE-350:
--

Gerhard, could you please elaborate? What do you think needs to be done before 
the 0.4 release? Or can it wait until after?

 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

 possible use-cases:
 @CustomStaticQuota(perDay = 1) //gets picked up via meta-data-inheritance
 interface Pages
 {
 interface Public extends ViewConfig, ViewQuota.PDF, ViewQuota.XML, ZIP
 {
 @CustomUrlMapping(/item/#{item}/)
 class Item implements Public
 {
 }
 }
 //folder - because it's of type ViewConfig
 interface Private extends ViewConfig
 {
 }
 interface ViewQuota //technically not(!) needed (see ZIP) - just for 
 better grouping
 {
 @Matches(pattern = *.xml)
 interface XML
 {
 }
 @Matches(pattern = *.pdf)
 @CustomStaticQuota(perDay = 100) //overrule quota
 interface PDF
 {
 }
 }
 @Matches(pattern = *.zip)
 interface ZIP
 {
 }
 }
 @ViewMetaData
 @interface CustomStaticQuota
 {
 int perDay();
 }
 @ViewMetaData
 @interface CustomUrlMapping
 {
 String value();
 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DELTASPIKE-348) WindowScope stuff breaks ICEfaces


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-348.
--

Resolution: Not A Problem

with RenderMode NONE we change exactly _nothing_ in a non spec complient way. 
If there is a problem then I suspect IceFaces doing some dirty stuff.

 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(DSExceptionIntegration.java:29)
  [framework-1.0.0-SNAPSHOT.jar

[jira] [Resolved] (DELTASPIKE-339) JndiUtils is broken


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-339.
--

Resolution: Fixed

we do. As per the general ConfigSource notion that JNDI is part of the 
Configuration which will get scanned automatically. If it is not active it 
would not be possible to use JNDI to e.g. configure globalAlternatives.

 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] [Resolved] (DELTASPIKE-329) Create a WindowContextManager


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-329.
--

Resolution: Fixed

 Create a WindowContextManager
 -

 Key: DELTASPIKE-329
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-329
 Project: DeltaSpike
  Issue Type: Sub-task
  Components: Core, JSF-Module
Reporter: John D. Ament
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 Need to add a WindowContextManager to handle all of the client windows.

--
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-328) Create ClientWindow API


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-328.
--

Resolution: Fixed

 Create ClientWindow API
 ---

 Key: DELTASPIKE-328
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-328
 Project: DeltaSpike
  Issue Type: Sub-task
  Components: Core, JSF-Module
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 0.4-incubating


 To mirror JSF 2.2 feature, need to create a ClientWindow API.

--
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-262) remove useless OWB workaround


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-262.
--

Resolution: Fixed

fixed

 remove useless OWB workaround
 -

 Key: DELTASPIKE-262
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-262
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core, Security-Module
Affects Versions: 0.2-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 We currently have a few OWB 'workarounds' in our code which are indeed not 
 needed.
 They store information in a static MapClassLoader, Info and expose this 
 info via static methods. 
 This is not needed as Extensions can be injected into other beans which can 
 access this info directly then.

--
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-362) BeanManagerProvider floods log file with warnings on AS7


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-362.
--

Resolution: Fixed
  Assignee: Mark Struberg

This got fixed in the MessageBundle proxy handler. 

Please note that the log in BeanManagerProvider itself is really a good thing 
as it indicates possible mem leaks!

 BeanManagerProvider floods log file with warnings on AS7
 

 Key: DELTASPIKE-362
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-362
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Affects Versions: 0.4-incubating
Reporter: Christian Kaltepoth
Assignee: Mark Struberg
Priority: Minor
 Fix For: 0.4-incubating


 Users reported that when deploying DeltaSpike in an EAR archive to AS7, they 
 get flooded by messages like this:
   When using the BeanManager to retrieve Beans before the Container is 
 started, non-portable behaviour results!
 This warning is created by BeanManagerProvider here:
 https://github.com/apache/incubator-deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/provider/BeanManagerProvider.java#L170
 The the following mails on the users list:
 http://mail-archives.apache.org/mod_mbox/incubator-deltaspike-users/201305.mbox/%3C518D5774.60909%40gmail.com%3E
 http://mail-archives.apache.org/mod_mbox/incubator-deltaspike-users/201304.mbox/%3C3125CD8F11FD1440B3E8452DC32521A2ADDBCEE6%40sExchange-01.PSC.local%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-330) Create a new WindowScope to represent beans that are bound to a browser window


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-330.
--

Resolution: Fixed

implemented

 Create a new WindowScope to represent beans that are bound to a browser window
 --

 Key: DELTASPIKE-330
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-330
 Project: DeltaSpike
  Issue Type: Sub-task
  Components: Core, JSF-Module
Reporter: John D. Ament
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 Need to add a WindowScope to bind beans to a window context/browser window.

--
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-369) Disable WindowScope by default


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-369.
--

Resolution: Not A Problem
  Assignee: Mark Struberg

Enabling the windowId handling by default is the option which makes the most 
sense in the long run. Especially once we introduce features like 
@ViewAccessScoped, etc which really need a browser tab separation to work. 

You can disable this behaviour easily yourself in your app by providing an  own 
ClientWindowConfig or @Specializes DefaultClientWindowConfig where you return 
NONE in getClientWindowRenderMode.

 Disable WindowScope by default
 --

 Key: DELTASPIKE-369
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-369
 Project: DeltaSpike
  Issue Type: Improvement
  Components: JSF-Module
Affects Versions: 0.4
Reporter: Florian Hell
Assignee: Mark Struberg
 Fix For: 0.4


 The WindowScope related stuff like the url params for windowId and dsRid (Is 
 it also related to WindowScope?) shouldn't be enabled by default. Also the 
 loading... page should be optional and of course configurable especially by 
 a resource key to define language specific loading screens.

--
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

DeltaSpike release tomorrow?

2013-05-26 Thread Mark Struberg

Hi folks!

We waited way too long to get it out of the door. 
Thus if there is no real show-stopper, then I gonna start the release train 
tomorrow.

We will ship 0.5 pretty fast afterwards anyway.

LieGrue,
strub

[jira] [Resolved] (DELTASPIKE-208) activateGlobalAlternatives is broken

2013-05-24 Thread Mark Struberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-208.
--

Resolution: Fixed

 activateGlobalAlternatives is broken
 

 Key: DELTASPIKE-208
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-208
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Affects Versions: 0.2-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 for OWB:
 a.) We shall not need to do anything special for OWB at all. OWB by default 
 comes without BDA enabled. If people have BDA enabled in their OWB 
 installation, then they can _easily_ switch it off again via a simple 
 property. There is really no need to do something special for OWB.
 b.) replacing the AnnotatedType with a completely different return Type 
 screws up the CDI container. It's really not expected and I'm not sure if 
 this is allowed at all.
 c.) by replacing the target type, you end up not scanning one of this class 
 at all, effectively disabling Extension processing for it.
 for Weld:
 instead of introducing our own properties we shall scan the beans.xml and act 
 accordingly.
 in general: mixing this complicated topic with the @Exclude extension is 
 highly confusing.

--
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: globalAlternatives

2013-05-22 Thread Mark Struberg



Yea, thought about that as well. We can target this with 0.5.
Still there is an open issue for the globalAlternatives since months.
And I like to fix this before the release.



LieGrue,
strub





 From: Romain Manni-Bucau rmannibu...@gmail.com
To: deltaspike-dev@incubator.apache.org; Mark Struberg strub...@yahoo.de 
Sent: Wednesday, 22 May 2013, 15:55
Subject: Re: globalAlternatives
 


Hi Mark,


throw the question of the configuration for me. I think we should use a 
hierarchic config (can be prefixes in properties format but in 
groovy/yml/xml/... it would just be a block).


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau




2013/5/22 Mark Struberg strub...@yahoo.de

Hi!

Currently the globalAlternatives approach is configured by

interface=impl

in some properties. The issue is that this is pretty costly to detect as 
there is no common prefix.

I suggest we add a hardcoded globalAlternatives. in front of the interface.

That way we can improve the handling speed pretty easily.

wdyt?

LieGrue,
strub

Re: CdiContainer API

2013-05-18 Thread Mark Struberg

Hi Romain!

It works now with openejb-4.6.0-SNAPSHOT latest. But we also need to test with 
openejb-4.5.0...4.5.2 etc.

LieGrue,
strub




- Original Message -
 From: Romain Manni-Bucau rmannibu...@gmail.com
 To: deltaspike-dev@incubator.apache.org; Mark Struberg strub...@yahoo.de
 Cc: 
 Sent: Saturday, 18 May 2013, 0:04
 Subject: Re: CdiContainer API
 
 Ok,
 
 hacked xbean about it (in the surefire integration). can you retest taking
 a fresh xbean snapshot? (i didnt redeploy it from windows)
 
 *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/5/17 Romain Manni-Bucau rmannibu...@gmail.com
 
  hmm, maybe a surefire issue in fact - maybe activate the xbean property to
  not use getURLs
 
  we have a hack for surefire which highly sucks because using
  URLClassLoader without having implemented getURLs()
 
  *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/5/17 Romain Manni-Bucau rmannibu...@gmail.com
 
  just tested again with an app fully cdi (no ejb, no web...) and under
  windows 7...all green
 
  no idea which issue you get :(
 
  *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/5/17 Mark Struberg strub...@yahoo.de
 
 
 
  txs Romain!
 
 
  LieGrue,
  strub
 
 
 
  
   From: Romain Manni-Bucau rmannibu...@gmail.com
  To: Mark Struberg strub...@yahoo.de;
  deltaspike-dev@incubator.apache.org
  Sent: Friday, 17 May 2013, 20:32
  Subject: Re: CdiContainer API
  
  
  
  Ejbcontainer cheats too much and can be broken very very 
 easily.
  Ill dig why cdi jars are not listed in appinfo. It should be in 
 ejbjars
  Le 17 mai 2013 20:22, Mark Struberg 
 strub...@yahoo.de a écrit :
  
  
  
  it seems to be a combination of your DeltaSpike changes + 
 the OpenEJB
  changes.
  
  
  DeltaSpike using EJBContainer + an OpenEJB version of prior 
 15.3. does
  work fine.
  
  Either using your code in CdiControl or a newer OpenEJB 
 verision
  breaks the build in the same way.
  
  LieGrue,
  strub
  
  
   From: Romain Manni-Bucau rmannibu...@gmail.com
  To: deltaspike-dev@incubator.apache.org
  Sent: Friday, 17 May 2013, 17:06
  Subject: CdiContainer API
  
  
  Hi guys,
  
  2 question on cdictrl API:
  
  1) why CdiContainer doesn't expose a method 
 createCDIContainer
  (static) and
  a method close() (+ implements Closeable)?
  2) why not CDIContainer?
  
  You probably got the question were referring to the 
 EJBContainer API
  which
  used other conventions.
  
  
  
  *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: CdiContainer API

2013-05-18 Thread Mark Struberg



That was exactly the reason CdiControl for OpenEJB was designed around 
EJBContainer ...

LieGrue,
strub






 From: Romain Manni-Bucau rmannibu...@gmail.com
To: Mark Struberg strub...@yahoo.de; deltaspike-dev@incubator.apache.org 
Sent: Saturday, 18 May 2013, 9:54
Subject: Re: CdiContainer API
 


Will not and will not be backported (change can impact app in very very 
advanced cases)
Le 18 mai 2013 09:19, Mark Struberg strub...@yahoo.de a écrit :

Hi Romain!

It works now with openejb-4.6.0-SNAPSHOT latest. But we also need to test 
with openejb-4.5.0...4.5.2 etc.

LieGrue,
strub




- Original Message -
 From: Romain Manni-Bucau rmannibu...@gmail.com
 To: deltaspike-dev@incubator.apache.org; Mark Struberg strub...@yahoo.de
 Cc:
 Sent: Saturday, 18 May 2013, 0:04
 Subject: Re: CdiContainer API

 Ok,

 hacked xbean about it (in the surefire integration). can you retest taking
 a fresh xbean snapshot? (i didnt redeploy it from windows)

 *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/5/17 Romain Manni-Bucau rmannibu...@gmail.com

  hmm, maybe a surefire issue in fact - maybe activate the xbean property to
  not use getURLs

  we have a hack for surefire which highly sucks because using
  URLClassLoader without having implemented getURLs()

  *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/5/17 Romain Manni-Bucau rmannibu...@gmail.com

  just tested again with an app fully cdi (no ejb, no web...) and under
  windows 7...all green

  no idea which issue you get :(

  *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/5/17 Mark Struberg strub...@yahoo.de



  txs Romain!


  LieGrue,
  strub



  
   From: Romain Manni-Bucau rmannibu...@gmail.com
  To: Mark Struberg strub...@yahoo.de;
  deltaspike-dev@incubator.apache.org
  Sent: Friday, 17 May 2013, 20:32
  Subject: Re: CdiContainer API
  
  
  
  Ejbcontainer cheats too much and can be broken very very
 easily.
  Ill dig why cdi jars are not listed in appinfo. It should be in
 ejbjars
  Le 17 mai 2013 20:22, Mark Struberg
 strub...@yahoo.de a écrit :
  
  
  
  it seems to be a combination of your DeltaSpike changes +
 the OpenEJB
  changes.
  
  
  DeltaSpike using EJBContainer + an OpenEJB version of prior
 15.3. does
  work fine.
  
  Either using your code in CdiControl or a newer OpenEJB
 verision
  breaks the build in the same way.
  
  LieGrue,
  strub
  
  
   From: Romain Manni-Bucau rmannibu...@gmail.com
  To: deltaspike-dev@incubator.apache.org
  Sent: Friday, 17 May 2013, 17:06
  Subject: CdiContainer API
  
  
  Hi guys,
  
  2 question on cdictrl API:
  
  1) why CdiContainer doesn't expose a method
 createCDIContainer
  (static) and
  a method close() (+ implements Closeable)?
  2) why not CDIContainer?
  
  You probably got the question were referring to the
 EJBContainer API
  which
  used other conventions.
  
  
  
  *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-366) basic test of properties usage in cdictrl openejb container

2013-05-17 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13660413#comment-13660413
 ] 

Mark Struberg commented on DELTASPIKE-366:
--

The test is fine, but the rework in the OpenEJBCdiContainer did break our build

java.lang.IllegalStateException: On a thread without an initialized context nor 
a classloader mapping a deployed app
at 
org.apache.openejb.cdi.ThreadSingletonServiceImpl.get(ThreadSingletonServiceImpl.java:285)
at 
org.apache.openejb.cdi.ThreadSingletonServiceImpl.getContext(ThreadSingletonServiceImpl.java:233)
at 
org.apache.openejb.cdi.ThreadSingletonServiceImpl.get(ThreadSingletonServiceImpl.java:314)
at 
org.apache.openejb.cdi.ThreadSingletonServiceImpl.get(ThreadSingletonServiceImpl.java:58)
at 
org.apache.webbeans.config.WebBeansFinder.getSingletonInstance(WebBeansFinder.java:51)
at 
org.apache.webbeans.config.WebBeansContext.getInstance(WebBeansContext.java:164)
at 
org.apache.webbeans.config.WebBeansContext.currentInstance(WebBeansContext.java:182)
at 
org.apache.deltaspike.cdise.openejb.OpenEjbContainerControl.boot(OpenEjbContainerControl.java:106)
at 
at.sozvers.util.test.ContainerTest.beforeMethod(ContainerTest.java:79)
at at.sozvers.util.test.ContainerTest.beforeClass(ContainerTest.java:90)


 basic test of properties usage in cdictrl openejb container
 ---

 Key: DELTASPIKE-366
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-366
 Project: DeltaSpike
  Issue Type: Improvement
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

[jira] [Reopened] (DELTASPIKE-366) basic test of properties usage in cdictrl openejb container

2013-05-17 Thread Mark Struberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg reopened DELTASPIKE-366:
--


 basic test of properties usage in cdictrl openejb container
 ---

 Key: DELTASPIKE-366
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-366
 Project: DeltaSpike
  Issue Type: Improvement
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

[jira] [Commented] (DELTASPIKE-366) basic test of properties usage in cdictrl openejb container

2013-05-17 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13660421#comment-13660421
 ] 

Mark Struberg commented on DELTASPIKE-366:
--

mvn clean install -Dopenejb.version=4.6.0-SNAPSHOT 
-Dopenejb.owb.version=1.2.0-SNAPSHOT 
to break the build.

 basic test of properties usage in cdictrl openejb container
 ---

 Key: DELTASPIKE-366
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-366
 Project: DeltaSpike
  Issue Type: Improvement
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

Re: CdiContainer API

2013-05-17 Thread Mark Struberg



it seems to be a combination of your DeltaSpike changes + the OpenEJB changes.


DeltaSpike using EJBContainer + an OpenEJB version of prior 15.3. does work 
fine. 

Either using your code in CdiControl or a newer OpenEJB verision breaks the 
build in the same way.

LieGrue,
strub


 From: Romain Manni-Bucau rmannibu...@gmail.com
To: deltaspike-dev@incubator.apache.org 
Sent: Friday, 17 May 2013, 17:06
Subject: CdiContainer API
 

Hi guys,

2 question on cdictrl API:

1) why CdiContainer doesn't expose a method createCDIContainer (static) and
a method close() (+ implements Closeable)?
2) why not CDIContainer?

You probably got the question were referring to the EJBContainer API which
used other conventions.



*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: CdiContainer API

2013-05-17 Thread Mark Struberg



txs Romain!


LieGrue,
strub




 From: Romain Manni-Bucau rmannibu...@gmail.com
To: Mark Struberg strub...@yahoo.de; deltaspike-dev@incubator.apache.org 
Sent: Friday, 17 May 2013, 20:32
Subject: Re: CdiContainer API
 


Ejbcontainer cheats too much and can be broken very very easily.
Ill dig why cdi jars are not listed in appinfo. It should be in ejbjars
Le 17 mai 2013 20:22, Mark Struberg strub...@yahoo.de a écrit :



it seems to be a combination of your DeltaSpike changes + the OpenEJB changes.


DeltaSpike using EJBContainer + an OpenEJB version of prior 15.3. does work 
fine.

Either using your code in CdiControl or a newer OpenEJB verision breaks the 
build in the same way.

LieGrue,
strub


 From: Romain Manni-Bucau rmannibu...@gmail.com
To: deltaspike-dev@incubator.apache.org
Sent: Friday, 17 May 2013, 17:06
Subject: CdiContainer API


Hi guys,

2 question on cdictrl API:

1) why CdiContainer doesn't expose a method createCDIContainer (static) and
a method close() (+ implements Closeable)?
2) why not CDIContainer?

You probably got the question were referring to the EJBContainer API which
used other conventions.



*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: CdiContainer API

2013-05-17 Thread Mark Struberg



txs Romain!


LieGrue,
strub




 From: Romain Manni-Bucau rmannibu...@gmail.com
To: Mark Struberg strub...@yahoo.de; deltaspike-dev@incubator.apache.org 
Sent: Friday, 17 May 2013, 20:32
Subject: Re: CdiContainer API
 


Ejbcontainer cheats too much and can be broken very very easily.
Ill dig why cdi jars are not listed in appinfo. It should be in ejbjars
Le 17 mai 2013 20:22, Mark Struberg strub...@yahoo.de a écrit :



it seems to be a combination of your DeltaSpike changes + the OpenEJB changes.


DeltaSpike using EJBContainer + an OpenEJB version of prior 15.3. does work 
fine.

Either using your code in CdiControl or a newer OpenEJB verision breaks the 
build in the same way.

LieGrue,
strub


 From: Romain Manni-Bucau rmannibu...@gmail.com
To: deltaspike-dev@incubator.apache.org
Sent: Friday, 17 May 2013, 17:06
Subject: CdiContainer API


Hi guys,

2 question on cdictrl API:

1) why CdiContainer doesn't expose a method createCDIContainer (static) and
a method close() (+ implements Closeable)?
2) why not CDIContainer?

You probably got the question were referring to the EJBContainer API which
used other conventions.



*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: Servlet module

2013-05-14 Thread Mark Struberg

+1. Could you please start working on it in a branch?
I really like to release 0.4 sonish (maybe end of this week?)
After that we could go for it in master.

LieGrue,
strub

- Original Message -
From: Jason Porter lightguard...@gmail.com
To: deltaspike-dev@incubator.apache.org
deltaspike-dev@incubator.apache.org
Cc:
Sent: Monday, 13 May 2013, 18:35
Subject: Re: Servlet module

I see no reason not to. Just keep rebasing (if you're working in a separate
module there shouldn't be any conflicts) until we're able to start work
on
0.5.

On Mon, May 13, 2013 at 10:16 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

Since the module is light +1
Le 13 mai 2013 18:11, John D. Ament
john.d.am...@gmail.com a écrit :

+1. This is actually one thing I need to finish porting an app from
seam3
to DS. If you want help doing it let me know.

On Mon, May 13, 2013 at 12:03 PM, Christian Kaltepoth
christ...@kaltepoth.de wrote:

Hey all,

as I already discussed with Mark and Arne two weeks ago, I'm
really
interested in working on the servlet module for DeltaSpike. This
topic
was
discussed several times on the list (see [1], [2]) and I think
there
was
an
agreement to target this for 0.5. Although 0.4 hasn't been
released
yet,
I
would love to spend some time hacking on this. :)

In my opinion the most important features for the module would
be:

- Producers for servlet objects like the HttpServletRequest,
ServletContext, etc. As this will be part of CDI 1.1, the
producer
should
use a custom qualifier.
- Bridging of the servlet lifecycle events to the CDI event
bus.

I think these are the most important features which are required
for
many
real world applications.

I'll start working on this on a separate branch on my GitHub
repo. This
way
I can prototype the module and then ask for your feedback before
merging
it
at a later point in time.

WDYT? Any comments or ideas? :)

Christian

[1]

http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/seam-servlet-stuff-to-deltaspike-td4653869.html
[2]

http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Servlet-module-td4654725.html

--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal

--
Jason Porter
http://en.gravatar.com/lightguardjp

[jira] [Resolved] (DELTASPIKE-365) extend ContainerControl boot() to pass in config properties

2013-05-14 Thread Mark Struberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-365.
--

Resolution: Fixed

 extend ContainerControl boot() to pass in config properties 
 

 Key: DELTASPIKE-365
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-365
 Project: DeltaSpike
  Issue Type: Improvement
  Components: CdiControl
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 Sometimes it's needed to pass some arbitrary config to the booted container. 
 We should add a Map or Properties for it. This is the same like the 
 EJBContainer behaviour.

--
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-365) extend ContainerControl boot() to pass in config properties

2013-05-13 Thread Mark Struberg (JIRA)

Mark Struberg created DELTASPIKE-365:


 Summary: extend ContainerControl boot() to pass in config 
properties 
 Key: DELTASPIKE-365
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-365
 Project: DeltaSpike
  Issue Type: Improvement
  Components: CdiControl
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


Sometimes it's needed to pass some arbitrary config to the booted container. We 
should add a Map or Properties for it. This is the same like the EJBContainer 
behaviour.

--
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?

2013-05-13 Thread Mark Struberg

gonna read through them and scan it. 
Feel free to grab some low hanging fruits.
Would like to release next week.

LieGrue,
strub




- Original Message -
 From: John D. Ament john.d.am...@gmail.com
 To: deltaspike deltaspike-dev@incubator.apache.org
 Cc: 
 Sent: Monday, 13 May 2013, 18:41
 Subject: So... what's left in 0.4?
 
 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-354) NPE in MessageBundleInvocationHandler on null Argument


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-354.
--

   Resolution: Fixed
Fix Version/s: 0.4-incubating

fixed. We will now add 'null' as String for this parameter. The MessageContext 
checks also got fixed.

 NPE in MessageBundleInvocationHandler on null Argument
 --

 Key: DELTASPIKE-354
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-354
 Project: DeltaSpike
  Issue Type: Bug
  Components: I18n-Module
Affects Versions: 0.3-incubating
Reporter: Stefan Strobl
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 simply passing a parameter with value null to any message results in:
 {code}
 Caused by: java.lang.NullPointerException
 at 
 org.apache.deltaspike.core.impl.message.MessageBundleInvocationHandler.resolveMessageContextFromArguments(MessageBundleInvocationHandler.java:157)
 at 
 org.apache.deltaspike.core.impl.message.MessageBundleInvocationHandler.invoke(MessageBundleInvocationHandler.java:61)
 {code}

--
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-363) BeanManagerProvider NPE when shutting down after a failure

Mark Struberg created DELTASPIKE-363:


 Summary: BeanManagerProvider NPE when shutting down after a failure
 Key: DELTASPIKE-363
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-363
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
Priority: Minor
 Fix For: 0.4-incubating


We currently cause a NPE in BeanManagerProvider shutdown if the container din't 
manage to start properly. This often happens during unit tests and hides the 
real problem in the logs.

--
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-363) BeanManagerProvider NPE when shutting down after a failure


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-363.
--

Resolution: Fixed

 BeanManagerProvider NPE when shutting down after a failure
 --

 Key: DELTASPIKE-363
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-363
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
Priority: Minor
 Fix For: 0.4-incubating


 We currently cause a NPE in BeanManagerProvider shutdown if the container 
 din't manage to start properly. This often happens during unit tests and 
 hides the real problem in the logs.

--
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-355) Create Alternative to DefaultMessageInterpolator using java.text.MessageFormat


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-355.
--

   Resolution: Fixed
Fix Version/s: 0.4-incubating
 Assignee: Mark Struberg

implemented. Just activate the following Alternative in your beans.xml 

alternative
  
classorg.apache.deltaspike.core.impl.message.MessageFormatMessageInterpolator/class
/alternative

 Create Alternative to DefaultMessageInterpolator using java.text.MessageFormat
 --

 Key: DELTASPIKE-355
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-355
 Project: DeltaSpike
  Issue Type: Improvement
  Components: I18n-Module
Reporter: Stefan Strobl
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 {{String#format()}} has a couple of disadvantages and limitations (e.g. no 
 choice formating) and therefore MessageFormat might for some people (like me) 
 be a preferrable alternative. Will provide patch or pull request...

--
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-356) MessageContextProducer causes a ton of log output on each request

2013-05-08 Thread Mark Struberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-356.
--

   Resolution: Fixed
Fix Version/s: 0.4-incubating

should be fixed now. Can you please retest the changes? txs!

 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
 Fix For: 0.4-incubating


 {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-355) Create Alternative to DefaultMessageInterpolator using java.text.MessageFormat

2013-05-08 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13652748#comment-13652748
 ] 

Mark Struberg commented on DELTASPIKE-355:
--

I agree that String#format has a few pitfalls, like a broken float formatting. 
String.format of 1.5 results in 1.4 that's pretty ugly.
We have 2 options. Either make MessageFormat the default or provide an 
alternative a user could activate himself.

 Create Alternative to DefaultMessageInterpolator using java.text.MessageFormat
 --

 Key: DELTASPIKE-355
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-355
 Project: DeltaSpike
  Issue Type: Improvement
  Components: I18n-Module
Reporter: Stefan Strobl

 {{String#format()}} has a couple of disadvantages and limitations (e.g. no 
 choice formating) and therefore MessageFormat might for some people (like me) 
 be a preferrable alternative. Will provide patch or pull request...

--
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-359) Websphere 8.0.x javaassist proxy does not reflect instance value

2013-05-07 Thread Mark Struberg (JIRA)

[
https://issues.apache.org/jira/browse/DELTASPIKE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13650590#comment-13650590
]

Mark Struberg commented on DELTASPIKE-359:
--

heh I was about to suggest that for now. It really looks like a classloader
issue in WebSphere. Will try to point a few IBM folks on this issue.

You might also have been hit by https://issues.jboss.org/browse/CDI-129

What about putting only deltaspike-jsf-api + impl in the web modules where you
need it?
All the core libs should be shared (also to prevent classloader clashes).

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

[jira] [Commented] (DELTASPIKE-348) WindowScope stuff breaks ICEfaces

2013-05-06 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13650018#comment-13650018
 ] 

Mark Struberg commented on DELTASPIKE-348:
--

Hi!

I've used the following code to set the render mode to NONE. Locally it did 
have no impact on the JSF components I tested (PrimeFaces and RichFaces).

{code}
@Specializes
public class SampleClientWindowConfig extends DefaultClientWindowConfig
{
@Override
public ClientWindowRenderMode getClientWindowRenderMode(FacesContext 
facesContext)
{
return ClientWindowRenderMode.NONE;
}
}
{code}

Could you be a bit more explicit? Which version of ICEfaces do you use and on 
which container?



 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

[jira] [Comment Edited] (DELTASPIKE-348) WindowScope stuff breaks ICEfaces

2013-05-06 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13650018#comment-13650018
 ] 

Mark Struberg edited comment on DELTASPIKE-348 at 5/6/13 7:25 PM:
--

Hi!

I've used the following code to set the render mode to NONE. Locally it did 
have no impact on the JSF components I tested (PrimeFaces and RichFaces).

{code}
@Specializes
public class SampleClientWindowConfig extends DefaultClientWindowConfig
{
@Override
public ClientWindowRenderMode getClientWindowRenderMode(FacesContext 
facesContext)
{
return ClientWindowRenderMode.NONE;
}
}
{code}

--Could you be a bit more explicit? Which version of ICEfaces do you use and on 
which container?--
*edit* sorry too late, seen the versions as above. Can you plz try with the 
disabled ClientWindowConfig? We do not do much in rendered() - just delegating 
through...



  was (Author: struberg):
Hi!

I've used the following code to set the render mode to NONE. Locally it did 
have no impact on the JSF components I tested (PrimeFaces and RichFaces).

{code}
@Specializes
public class SampleClientWindowConfig extends DefaultClientWindowConfig
{
@Override
public ClientWindowRenderMode getClientWindowRenderMode(FacesContext 
facesContext)
{
return ClientWindowRenderMode.NONE;
}
}
{code}

Could you be a bit more explicit? Which version of ICEfaces do you use and on 
which container?


  
 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

[jira] [Commented] (DELTASPIKE-359) Websphere 8.0.x javaassist proxy does not reflect instance value

2013-05-06 Thread Mark Struberg (JIRA)

[
https://issues.apache.org/jira/browse/DELTASPIKE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13650030#comment-13650030
]

Mark Struberg commented on DELTASPIKE-359:
--

Hi hampus!

WebSphere is a bit bitchy ;) It really needs a beans.xml directly in WEB-INF/
This is *not* spec conform and I already reported a PMR. Please try to add it
and ping back if it did help or not.
What version of WAS do you have excactly? 8.0.0.1 was broken, 8.0.0.5 is pretty
ok. Had no time to test 8.0.0.6 and 8.5.x myself yet.

Websphere 8.0.x javaassist proxy does not reflect instance value

[jira] [Assigned] (DELTASPIKE-354) NPE in MessageBundleInvocationHandler on null Argument

2013-04-28 Thread Mark Struberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg reassigned DELTASPIKE-354:


Assignee: Mark Struberg

 NPE in MessageBundleInvocationHandler on null Argument
 --

 Key: DELTASPIKE-354
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-354
 Project: DeltaSpike
  Issue Type: Bug
  Components: I18n-Module
Affects Versions: 0.3-incubating
Reporter: Stefan Strobl
Assignee: Mark Struberg

 simply passing a parameter with value null to any message results in:
 {code}
 Caused by: java.lang.NullPointerException
 at 
 org.apache.deltaspike.core.impl.message.MessageBundleInvocationHandler.resolveMessageContextFromArguments(MessageBundleInvocationHandler.java:157)
 at 
 org.apache.deltaspike.core.impl.message.MessageBundleInvocationHandler.invoke(MessageBundleInvocationHandler.java:61)
 {code}

--
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: windowId postback detection

2013-04-24 Thread Mark Struberg

It's not exactly the same but goes in the same direction.

Currently we have 4 'operation modes' for each request (see ClientWindowConfig. 

* NONE: no @WindowScoped will be available for this request

* LAZY: the windowId will be verified and ensured on the client side via a 
JavaScript comparison of the windowId and window.name and if it doesn't fit 
then we force a page refresh with the correct windowId: CON: the first page hit 
will still have the old windowId and might touch beans from this other window.

* CLIENTWINDOW: each GET request first gets an intermediate page 
(windowhandler.html) which checks if the windowName and windowId fit. If not - 
new windowId will get requested. If they fit, we reload the page with the 
verified windowId. This 2nd request finally hits the xhtml page. The 
intermediate windowhandler page takes around 1ms to get served and is blazingly 
fast on the client. To prevent flickering if the target page takes some time to 
render we kind of take a DOM screenshot from the original page and display it 
on the intermediate page.

* CUSTOM: A user might implement his own ClientWindow. Not sure though how we 
will integrate this. Currently doesn't work :)

The user can choose them via his own ClientWindowConfig (or @Specializes 
DefaultClientWindowConfig) for each request. E.g. a Request from an internal 
address in a company (in our case the university) gets the ClientWndow 
(intermediate html page which ensures the windowId is correct) and external 
addresses get rendered directly. Bots and other crawlers should also get the 
direct page for example.

Now for the 'exclude region' sometimes you don't like to decorate target links 
with the windowId, nor do you like to store the DOM tree in the localstorage. 
E.g. if you show customer generated context which is not secured or if you have 
links to external pages.
This is more or less a security mechanism.

LieGrue,
strub






 From: Christian Kaltepoth christ...@kaltepoth.de
To: deltaspike-dev@incubator.apache.org 
Cc: Mark Struberg strub...@yahoo.de 
Sent: Tuesday, 23 April 2013, 23:15
Subject: Re: windowId postback detection
 

@Mark
With your 'exclude-area' idea you are referring to something like
Orchestra's o:separateConversationContext, right? I think this could be a
really interesting feature for some usecases and we
should definitively support it.

Regarding the auto detection for links that have to be decorated: I'm not
really sure if there is a need to explicitly configure a set of domains for
this. I guess the decorating is somehow similar to what
HttpServletResponse.encodeURL() does and would even be implemented by
wrapping it (or the corresponding stuff in ExternalContext), correct? So
why don't we simply decorate all links that go though encodeURL unless we
are in an exclude area case?

Christian




2013/4/23 Jason Porter lightguard...@gmail.com

 Interesting idea. What does the rest of the community think?


 On Tue, Apr 23, 2013 at 11:01 AM, Mark Struberg strub...@yahoo.de wrote:

  yes, we will certainly need to do lots of testing with this new approach.
  But it seems much more in sync with the JSF-2.2 idea which requires to
  detect the proper windowId even before the restore-view phase. In the old
  CODI implementation we parsed it from a custom Component which we added
 to
  the view tree ourselfs. maybe we can do both.
 
  There was also an idea about having an 'exclude-area'. Means a tag which
  will exclude the containing GET links from using the browser tab
 detection.
  We might also think about a mechanism to detect the links which need to
  get decorated. Something like
 
  ds:windowId domain=this, someurl.com, otherurl.org/
  For other links we will not add the windowId nor store away the dom tree
  for our 'snapshot view' on the intermediate page.
 
  LieGrue,
  strub
 
 
 
 
  - Original Message -
   From: Jason Porter lightguard...@gmail.com
   To: deltaspike-dev@incubator.apache.org 
  deltaspike-dev@incubator.apache.org
   Cc:
   Sent: Tuesday, 23 April 2013, 18:22
   Subject: Re: windowId postback detection
  
   I'm good either way, but the custom component idea seems to be
 consensus,
   also if the user doesn't want it they can always leave out the new
   component.
  
  
   On Mon, Apr 22, 2013 at 12:38 AM, Thomas Andraschko 
   andraschko.tho...@gmail.com wrote:
  
    +1 for the custom component
  
  
    2013/4/22 Christian Kaltepoth christ...@kaltepoth.de
  
     I like the idea of a custom component because it makes it more
   explicit
     what the component is used for and perhaps would even provide more
    control
     over what is happening.
    
     So +1 for a custom component
    
    
     2013/4/21 Mark Struberg strub...@yahoo.de
    
      Gerhard brought up another alternative: simply provide a
   component
    which
      doesn't render any html but adds the windowhandler.js and
   stores the
      component in the ViewRoot

Re: windowId postback detection

2013-04-23 Thread Mark Struberg

yes, we will certainly need to do lots of testing with this new approach. But 
it seems much more in sync with the JSF-2.2 idea which requires to detect the 
proper windowId even before the restore-view phase. In the old CODI 
implementation we parsed it from a custom Component which we added to the view 
tree ourselfs. maybe we can do both.

There was also an idea about having an 'exclude-area'. Means a tag which will 
exclude the containing GET links from using the browser tab detection.
We might also think about a mechanism to detect the links which need to get 
decorated. Something like

ds:windowId domain=this, someurl.com, otherurl.org/
For other links we will not add the windowId nor store away the dom tree for 
our 'snapshot view' on the intermediate page.

LieGrue,
strub




- Original Message -
 From: Jason Porter lightguard...@gmail.com
 To: deltaspike-dev@incubator.apache.org 
 deltaspike-dev@incubator.apache.org
 Cc: 
 Sent: Tuesday, 23 April 2013, 18:22
 Subject: Re: windowId postback detection
 
 I'm good either way, but the custom component idea seems to be consensus,
 also if the user doesn't want it they can always leave out the new
 component.
 
 
 On Mon, Apr 22, 2013 at 12:38 AM, Thomas Andraschko 
 andraschko.tho...@gmail.com wrote:
 
  +1 for the custom component
 
 
  2013/4/22 Christian Kaltepoth christ...@kaltepoth.de
 
   I like the idea of a custom component because it makes it more 
 explicit
   what the component is used for and perhaps would even provide more
  control
   over what is happening.
  
   So +1 for a custom component
  
  
   2013/4/21 Mark Struberg strub...@yahoo.de
  
Gerhard brought up another alternative: simply provide a 
 component
  which
doesn't render any html but adds the windowhandler.js and 
 stores the
component in the ViewRoot.
   
LieGrue,
strub
   
   
   
   
- Original Message -
 From: Romain Manni-Bucau rmannibu...@gmail.com
 To: Mark Struberg strub...@yahoo.de;
deltaspike-dev@incubator.apache.org
 Cc:
 Sent: Sunday, 21 April 2013, 20:56
 Subject: Re: windowId postback detection

 1 sounds easier to track too
 Le 21 avr. 2013 18:09, Mark Struberg 
 strub...@yahoo.de a
 écrit :

  Hi!

  There are technically 2 options for extracting the 
 windowId on
  POSTs:

  1.) setting a hidden UIOutput component in the ViewRoot


  2.) provide a custom renderkit/ResponseStateManager

  I think 1.) is much easier. Any input?

  LIeGrue,
  strub



   
  
  
  
   --
   Christian Kaltepoth
   Blog: http://blog.kaltepoth.de/
   Twitter: http://twitter.com/chkal
   GitHub: https://github.com/chkal
  
 
 
 
 
 -- 
 Jason Porter
 http://en.gravatar.com/lightguardjp

Re: windowId postback detection

2013-04-21 Thread Mark Struberg

Gerhard brought up another alternative: simply provide a component which 
doesn't render any html but adds the windowhandler.js and stores the component 
in the ViewRoot.

LieGrue,
strub




- Original Message -
 From: Romain Manni-Bucau rmannibu...@gmail.com
 To: Mark Struberg strub...@yahoo.de; deltaspike-dev@incubator.apache.org
 Cc: 
 Sent: Sunday, 21 April 2013, 20:56
 Subject: Re: windowId postback detection
 
 1 sounds easier to track too
 Le 21 avr. 2013 18:09, Mark Struberg strub...@yahoo.de a 
 écrit :
 
  Hi!
 
  There are technically 2 options for extracting the windowId on POSTs:
 
  1.) setting a hidden UIOutput component in the ViewRoot
 
 
  2.) provide a custom renderkit/ResponseStateManager
 
  I think 1.) is much easier. Any input?
 
  LIeGrue,
  strub

[ANNOUNCE] DeltaSpike is now an Apache Top Level Project

2013-04-18 Thread Mark Struberg

Dear Lords and Ladies!

From yesterdays ASF board report
 The following resolutions were passed unaminously: 

 D. Establish the Apache DeltaSpike Project (Mark Struberg, VP)
 

Congratulations to all of you and thanks for the input and hard work!


What does this mean for DeltaSpike and the community?


We are now basically mature as community and on our own feet. From a Project 
API point of view there is not yet a substantial change. All versions below 1.0 
are still subject to API changes, but - as usual - we will take care to hold 
those as minimal as possible!
We will need to establish rules for deprecation and maintenance releases once 
we reach 1.0, but that's a standard thingy.


We will now move on with the LP transition and put some more pressure on 
releasing more often.
I hope we get the 0.4 release done this month even!


By becoming a TLP we now also have a PMC (Project Management Council) which 
form the initial committers (see the graduation proposal).
If you're not on this list then you are still more than welcome to provide 
patches and feedback! The standard contribution rules for ASF projects apply 
and maybe you even get invited to become a committer soon!


As for the PMC-Chair (VP, DeltaSpike):
The voice of the PMC-Chair of a project has no more value than any other PMC 
member! This role is just the official speaker and the despot if it comes to 
doing all the paper work ;) 

I'd suggest to establish the same internal rules which already work fine in a 
few other ASF projects I'm serving. Means to annually re-vote the PMC-chair 
inside the PMC.

txs and LieGrue,
strub

[jira] [Created] (DELTASPIKE-344) BeanProvider should get a getBeans() with the BeanManager as parameter

2013-04-18 Thread Mark Struberg (JIRA)

Mark Struberg created DELTASPIKE-344:


 Summary: BeanProvider should get a getBeans() with the BeanManager 
as parameter
 Key: DELTASPIKE-344
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-344
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


This is very useful if you like to resolve Beans inside Extensions (in 
AfterDeploymentValidation).

--
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-329) Create a WindowContextManager

2013-04-18 Thread Mark Struberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg reassigned DELTASPIKE-329:


Assignee: Mark Struberg

 Create a WindowContextManager
 -

 Key: DELTASPIKE-329
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-329
 Project: DeltaSpike
  Issue Type: Sub-task
  Components: Core, JSF-Module
Reporter: John D. Ament
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 Need to add a WindowContextManager to handle all of the client windows.

--
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-329) Create a WindowContextManager

2013-04-18 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13635581#comment-13635581
 ] 

Mark Struberg commented on DELTASPIKE-329:
--

This is basically the same like our WindowContext

 Create a WindowContextManager
 -

 Key: DELTASPIKE-329
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-329
 Project: DeltaSpike
  Issue Type: Sub-task
  Components: Core, JSF-Module
Reporter: John D. Ament
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 Need to add a WindowContextManager to handle all of the client windows.

--
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

2013-04-13 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13630990#comment-13630990
 ] 

Mark Struberg commented on DELTASPIKE-339:
--

[~romain.manni-bucau] Imo the code is broken on our side. We request ALL 
entries but cast them to the requested type without any further checks. 

 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] [Commented] (DELTASPIKE-339) JndiUtils is broken

2013-04-07 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13624962#comment-13624962
 ] 

Mark Struberg commented on DELTASPIKE-339:
--

Hi John, please build with -Ptomee-build-managed to reproduce the issue - txs!

 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 using the BeanManager to retrieve Beans before the Container is started, non-portable behaviour results!

2013-04-05 Thread Mark Struberg

yes, in ADV it's allowed again. 


LieGrue,
strub



- Original Message -
 From: Romain Manni-Bucau rmannibu...@gmail.com
 To: Jozef Hartinger jhart...@redhat.com
 Cc: deltaspike-dev@incubator.apache.org; Mark Struberg strub...@yahoo.de
 Sent: Friday, April 5, 2013 5:55 PM
 Subject: Re: When using the BeanManager to retrieve Beans before the 
 Container is started, non-portable behaviour results!
 
t hat's what i understood so it should be allowed only here
 
 *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/4/5 Jozef Hartinger jhart...@redhat.com
 
  It is going to be forbidden before ADV.
 
 
  On 04/05/2013 05:28 PM, Romain Manni-Bucau wrote:
 
  in AfterDeploymentValidation? so it means you can't get beans when 
 all is
  ok? that's just inconsistent
 
  *Romain Manni-Bucau*
  *Twitter: @rmannibucau 
 https://twitter.com/**rmannibucauhttps://twitter.com/rmannibucau
  *
  *Blog: 
 **http://rmannibucau.**wordpress.com/*http://rmannibucau.wordpress.com/*
  http://**rmannibucau.wordpress.com/ 
 http://rmannibucau.wordpress.com/
  *LinkedIn: 
 **http://fr.linkedin.com/in/**rmannibucau*http://fr.linkedin.com/in/rmannibucau*
  *Github: 
 https://github.com/**rmannibucau*https://github.com/rmannibucau*
 
 
 
  2013/4/5 Mark Struberg strub...@yahoo.de
 
   Romain, in CDI-1.1 this will even be forbidden by the spec!
 
  LieGrue,
  strub
 
 
 
 
  - Original Message -
 
  From: Romain Manni-Bucau rmannibu...@gmail.com
  To: 
 deltaspike-dev@incubator.**apache.orgdeltaspike-dev@incubator.apache.org
  Cc:
  Sent: Friday, April 5, 2013 11:47 AM
  Subject: When using the BeanManager to retrieve Beans before 
 the
 
  Container is started, non-portable behaviour results!
 
  Hi,
 
  this warning message When using the BeanManager to 
 retrieve Beans
  before
  the Container is started, non-portable behaviour results! 
 pops up when
 
  the
 
  Bean[Manager]Provider is used. the point is we can use it in
  AfterDeploymentValidation event but since extensions order is 
 not
  guaranteed a custom extension can use it before the 
 provider
  extension
  set the warning to not be printed anymore.
 
  Can't we do anything?
 
  A working but not very sexy solution is to offer a
  Bean[Manager]Provider.getXXX(**args, warnBoolean);
 
  wdyt?
 
  *Romain Manni-Bucau*
  *Twitter: @rmannibucau 
 https://twitter.com/**rmannibucauhttps://twitter.com/rmannibucau
  *
  *Blog:
 
 **http://rmannibucau.**wordpress.com/*http://rmannibucau.wordpress.com/*
 
 http://**rmannibucau.wordpress.com/http://rmannibucau.wordpress.com/
  
  *LinkedIn: 
 **http://fr.linkedin.com/in/**rmannibucau*http://fr.linkedin.com/in/rmannibucau*
  *Github: 
 https://github.com/**rmannibucau*https://github.com/rmannibucau*

[jira] [Created] (DELTASPIKE-339) JndiUtils is broken

2013-04-03 Thread Mark Struberg (JIRA)

Mark Struberg created DELTASPIKE-339:


 Summary: 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] [Commented] (DELTASPIKE-330) Create a new WindowScope to represent beans that are bound to a browser window

2013-04-03 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620850#comment-13620850
 ] 

Mark Struberg commented on DELTASPIKE-330:
--

This is already partly implemented in DefaultWindowContext. The 'storage' is 
SessionScoped and can be found in WindowBeanHolder.

 Create a new WindowScope to represent beans that are bound to a browser window
 --

 Key: DELTASPIKE-330
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-330
 Project: DeltaSpike
  Issue Type: Sub-task
  Components: Core, JSF-Module
Reporter: John D. Ament
 Fix For: 0.4-incubating


 Need to add a WindowScope to bind beans to a window context/browser window.

--
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-330) Create a new WindowScope to represent beans that are bound to a browser window

2013-04-03 Thread Mark Struberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg reassigned DELTASPIKE-330:


Assignee: Mark Struberg

 Create a new WindowScope to represent beans that are bound to a browser window
 --

 Key: DELTASPIKE-330
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-330
 Project: DeltaSpike
  Issue Type: Sub-task
  Components: Core, JSF-Module
Reporter: John D. Ament
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 Need to add a WindowScope to bind beans to a window context/browser window.

--
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] re-visit annotation package/s

2013-04-02 Thread Mark Struberg

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
   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
  
  
  
  
  
  
   --
   Christian Kaltepoth
   Blog: 
 http://blog.kaltepoth.de/
   Twitter: 
 http://twitter.com/chkal
   GitHub: 
 https://github.com/chkal

Re: [DISCUSS] re-visit annotation package/s

2013-03-31 Thread Mark Struberg

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
 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] [Resolved] (DELTASPIKE-318) OpenejbCdiControl tries to scan starting classes

2013-03-30 Thread Mark Struberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-318.
--

Resolution: Won't Fix

 OpenejbCdiControl tries to scan starting classes
 

 Key: DELTASPIKE-318
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-318
 Project: DeltaSpike
  Issue Type: Bug
  Components: CdiControl
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 We did hit this issue when we starting OpenEJB in a jbehave test. In that 
 case OpenEJB blows up because it tries to scan the inner class of StepCreator.
 We should generally disable this self-scanning by passing in the following 
 property to the EJBContainer
 openejb.additionnal.callers, 

--
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-318) OpenejbCdiControl tries to scan starting classes

2013-03-30 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618015#comment-13618015
 ] 

Mark Struberg commented on DELTASPIKE-318:
--

It turned out to be an OpenEJB issue. please see 
https://issues.apache.org/jira/browse/TOMEE-840

 OpenejbCdiControl tries to scan starting classes
 

 Key: DELTASPIKE-318
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-318
 Project: DeltaSpike
  Issue Type: Bug
  Components: CdiControl
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 We did hit this issue when we starting OpenEJB in a jbehave test. In that 
 case OpenEJB blows up because it tries to scan the inner class of StepCreator.
 We should generally disable this self-scanning by passing in the following 
 property to the EJBContainer
 openejb.additionnal.callers, 

--
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-318) OpenejbCdiControl tries to scan starting classes

2013-03-30 Thread Mark Struberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated DELTASPIKE-318:
-

Fix Version/s: (was: 0.4-incubating)

 OpenejbCdiControl tries to scan starting classes
 

 Key: DELTASPIKE-318
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-318
 Project: DeltaSpike
  Issue Type: Bug
  Components: CdiControl
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg

 We did hit this issue when we starting OpenEJB in a jbehave test. In that 
 case OpenEJB blows up because it tries to scan the inner class of StepCreator.
 We should generally disable this self-scanning by passing in the following 
 property to the EJBContainer
 openejb.additionnal.callers, 

--
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: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top Level Project

2013-03-30 Thread Mark Struberg

+1 


LieGrue,
strub



- Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: deltaspike-us...@incubator.apache.org 
 deltaspike-us...@incubator.apache.org; deltaspike 
 deltaspike-dev@incubator.apache.org
 Cc: 
 Sent: Monday, March 25, 2013 10:35 PM
 Subject: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top Level 
 Project
 
 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

Re: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top Level Project

2013-03-30 Thread Mark Struberg

?

pardon, I don't get it ^^

A VOTE ends earliest after 72h and not until the RESULT got posted (which I 
gonna tally now).

LieGrue,
strub






 From: John D. Ament john.d.am...@gmail.com
To: deltaspike deltaspike-dev@incubator.apache.org; Mark Struberg 
strub...@yahoo.de 
Cc: deltaspike-us...@incubator.apache.org 
deltaspike-us...@incubator.apache.org 
Sent: Saturday, March 30, 2013 12:49 PM
Subject: Re: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top 
Level Project
 

I think this vote ended?



On Sat, Mar 30, 2013 at 7:31 AM, Mark Struberg strub...@yahoo.de wrote:

+1


LieGrue,
strub




- Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: deltaspike-us...@incubator.apache.org 
 deltaspike-us...@incubator.apache.org; deltaspike 
 deltaspike-dev@incubator.apache.org
 Cc:
 Sent: Monday, March 25, 2013 10:35 PM
 Subject: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top 
 Level Project

 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

Re: [VOTE] [RESULT] Recommending DeltaSpike for Graduation to an Apache Top Level Project

2013-03-30 Thread Mark Struberg

Hi folks!

The majority VOTE has passed with the following voices:


+1 Alexis Krier, Cody Lerum, Charles Moulliard, Romain Manni-Bucau, Shane 
Bryzak, Heiko Kopp, Nicklas Karlsson, Antoine Sabot-Durand, Florian Hell, 
Санжар Жалилов, Pete Muir, Ken Finnigan, Rudy De Busscher, Jason Porter, 
Gerhard Petracek, Dev Khadka, Jean-Louis Monteiro, Thorsten, Mark Struberg


-1 John Ament, Harald Wellmann


A few results were mixed +1 and -1 in one mail. I didn't tally those. Basically 
they have been kind of +1 IF but this is not possible in a VOTE.


I'll go on and continue with the process over on gene...@apache.org.
The Incubator PMC has to review and vote on the proposal now.



txs and LieGrue,
strub




- Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: deltaspike-us...@incubator.apache.org 
 deltaspike-us...@incubator.apache.org; deltaspike 
 deltaspike-dev@incubator.apache.org
 Cc: 
 Sent: Monday, March 25, 2013 10:35 PM
 Subject: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top Level 
 Project
 
 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

Re: Heading towards a 0.4 release

2013-03-27 Thread Mark Struberg

+1

LieGrue,
strub




- Original Message -
 From: Jason Porter lightguard...@gmail.com
 To: deltaspike-dev@incubator.apache.org 
 deltaspike-dev@incubator.apache.org
 Cc: 
 Sent: Tuesday, March 26, 2013 4:03 PM
 Subject: Re: Heading towards a 0.4 release
 
 I doubt it. I've responded (I believe) to all of them and the original
 reporters have not given feedback either way. I interpret that as
 
 * Thanks, that works, or
 * I no longer care
 
 People can always open more tickets if they feel it's still an issue and we
 can dig further.
 
 
 On Tue, Mar 26, 2013 at 7:40 AM, John D. Ament 
 john.d.am...@gmail.comwrote:
 
  Ok.  How about the open catch issues? Do you feel any of those are needed
  for 0.4?
 
 
  On Tue, Mar 26, 2013 at 9:28 AM, Jason Porter lightguard...@gmail.com
  wrote:
 
   The 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.com
   wrote:
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/*
   http://rmannibucau.wordpress.com/
   *LinkedIn: 
 **http://fr.linkedin.com/in/rmannibucau*
   *Github: https://github.com/rmannibucau*
  
  
  
   2013/3/25 Gerhard Petracek

Re: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top Level Project

2013-03-27 Thread Mark Struberg

whoopy, why do I always forget sending my own +1 :)

LieGrue,
strub




- Original Message -
 From: John D. Ament john.d.am...@gmail.com
 To: Mark Struberg strub...@yahoo.de; deltaspike 
 deltaspike-dev@incubator.apache.org
 Cc: 
 Sent: Wednesday, March 27, 2013 11:33 AM
 Subject: Re: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top 
 Level Project
 
 BTW, we still don't have a +1 from any of the mentors. :-)
 
 
 On Wed, Mar 27, 2013 at 6:31 AM, John D. Ament 
 john.d.am...@gmail.comwrote:
 
  Mark,
 
  For the name, I think we still need to do a PNS.  I'll go ahead and 
 enter
  it.  I don't think this process existed when we entered incubation.
 
  John
 
 
  On Wed, Mar 27, 2013 at 6:21 AM, Mark Struberg strub...@yahoo.de 
 wrote:
 
  To come back to your fair points:
 
  I've now updated the incubation status page [1] and reflected a few 
 of
  your points:
 
  * DS naming: I've used trademarkia and a few others, and DeltaSpike 
 is
  still free of usage and not yet trademarked. Did this a year ago as 
 well.
  So the name is ok. It might not be the best, but in the last year 
 nobody
  came up with a better one. We can still rename if we some day find a 
 better
  name.
 
  * committers
   16 vs the original 21 proposed (technically does that mean we 
 shrank?)
  This is quite natural. There were quite a few people who have been very
  vocal about contributing but ended up not even registering to the 
 mailing
  list. I'm not blaming anyone because I know how hard it is to get a 
 few
  hours per week spare time. In ASF projects it's all about merit - 
 and
  obviously those people who didn't yet contribute nor even show up 
 cannot
  make it to the initial contributors list. We are of course happy about
  future contributions from each and everyone!
  Otoh we also have people who just came on board later and added
  substantial contributions!
 
  The real question is the number of people who are active on a more or
  less regular basis, and we are doing quite fine in this regard.
 
 
 
   Since this is procedural, I'm assuming we're following 
 majority, per
   http://www.apache.org/foundation/voting.html .  I don't 
 believe we need
   100% consensus in the matter then, correct?
 
  Yes, but I'm also happy you raised those questions in public 
 because
  there is always room for improvement and things we can aim to do 
 better.
 
 
  LieGrue,
  strub
 
 
 
  [1] http://incubator.apache.org/projects/deltaspike.html   (make sure
  you force a page refresh)
 
 
 
  - Original Message -
   From: John D. Ament john.d.am...@gmail.com
   To: deltaspike deltaspike-dev@incubator.apache.org; Mark 
 Struberg 
  strub...@yahoo.de
   Cc: deltaspike-us...@incubator.apache.org 
  deltaspike-us...@incubator.apache.org
   Sent: Tuesday, March 26, 2013 12:34 AM
   Subject: Re: [VOTE] Recommending DeltaSpike for Graduation to an 
 Apache
  Top Level Project
  
   Mark,
  
   My vote isn't a -1 to DeltaSpike, she's just not ready to 
 blossom yet.
   Maybe another month or two :-)
  
   I will point out an issue which I don't think we've 
 resolved yet per the
   documentation on incubator.a.o
  
   http://incubator.apache.org/guides/graduation.html#requirements
  
   - We have not established whether DS is a suitable name; e.g.
  
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20PODLINGNAMESEARCH
   has
   no entry for DeltaSpike.  Also we have not forwarded the vote 
 thread to
   general@i.a.o to let them know we're thinking about it.
  
   However, most of my comments are around this section of 
 graduation:
   http://incubator.apache.org/guides/graduation.html#community - I 
 don't
   believe we've done this too well.  There are only three 
 developers I
  see on
   the  list that were not on
   http://wiki.apache.org/incubator/DeltaSpikeProposal - In fact we 
 now
  have
   16 vs the original 21 proposed (technically does that mean we 
 shrank?)
  
   Three releases is good.  I think I even saw a podling attempt to
  graduate
   that only released their parent POM a couple times :-)
  
   Since this is procedural, I'm assuming we're following 
 majority, per
   http://www.apache.org/foundation/voting.html .  I don't 
 believe we need
   100% consensus in the matter then, correct?
  
   John
  
  
   On Mon, Mar 25, 2013 at 5:57 PM, Mark Struberg 
 strub...@yahoo.de
  wrote:
  
  
  
    Hi John!
  
    I'm not sure I understand what you mean.
  
    The DeltaSpike project now runs for 1 year. The list of 
 initial
  committers
    are all the people who contributed to it in one form or the 
 other.
  Means
    code drops, documentation, etc. There are exactly 2 people 
 from the
  CODI
    Team in DeltaSpike. These are Gerhard and me. The rest is 
 from either
  the
    Seam team or from other teams around the whole CDI area. In 
 my
  opinion the
    community works together pretty well. Of course, I would be 
 happy if
  there
    are more commits and contributions

Re: Servlet module

2013-03-26 Thread Mark Struberg

sounds good. Maybe for 0.5?

But we have GIT now, thus we can maintain feature branches pretty easily.

LieGrue,
strub




- Original Message -
 From: Ove Ranheim oranh...@gmail.com
 To: deltaspike-dev@incubator.apache.org
 Cc: 
 Sent: Tuesday, March 26, 2013 8:29 AM
 Subject: Re: Servlet module
 
 Hi,
 
 Wouldn't it make sense to add a CDI 1.x servlet module to DS and make it 
 optional to CDI 2?
 
 Ove
 
 On Mar 26, 2013, at 8:23 AM, Nicklas Karlsson nicka...@gmail.com wrote:
 
  Is there enough material in Seam/CODI to warrant a Servlet module or should
  we just wait for CDI 2 to provide servlet lifecycle events etc?
 
  -- 
  Nicklas Karlsson, +358 40 5062266
  Vaakunatie 10 as 7, 20780 Kaarina

Re: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top Level Project

2013-03-26 Thread Mark Struberg

Dennis, all fair points. But please consider that we all (well, most of us) do 
this in our spare time. 
You are also welcome to join the effort and help us moving forward, provide 
feedback, documentation, samples, code, etc



LieGrue,
strub



- Original Message -
 From: titou10 titou10 titou10.tito...@gmail.com
 To: deltaspike-dev@incubator.apache.org
 Cc: 
 Sent: Tuesday, March 26, 2013 1:17 PM
 Subject: Re: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top 
 Level Project
 
 At least @Nicklas, @Esteve and I share almost the same point of view.
 In order:
 1. have a clear list of things to do to have a basic JSF (ie scopes)
 +JPA+security modules and make them work for DS v0.4
 2. have a basic documentation for DS v0.4 more from a user/integrator
 point of view than from a DS designer/architect point of view
 3. have sample apps:
 - one sample app that demonstrate all of the JSF/scopes components,
 with a login page and a basic database model (with derby)
 - one that demonstrate the usaege of DS in J2SE for batchs or unit tests
 4. find a name: CDILink?  Caramel?  Glue?  Caddie?
 5. graduate to TLP
 6. define and publicies what v0.5 will contain: updates in
 JSF+JPA+security+fondation, new modules (cdi-queries, servlet) etc.
 
 WDYT?
 
 2013/3/26 Nicklas Karlsson nicka...@gmail.com:
  +1
 
  I guess it's a bit of a chicken and egg-thingie (taking off 
 as a project
  and building community). The current team is talented and I don't doubt 
 it
  will thrive and become the de facto extension framework for 
 CDI, however
  for the project to really take off it would help if
 
  * The documentation covered everything that can be done (even brief is
  better that nothing)
  * A clear roadmap (e.g the focus for 0.5 will be JSF and will cover the
  following JIRAs, the estimate release window is xx.xx)
  * Tutoring/orchestration for the team (some overview on who could do what,
  make sure stuff integrates well)
  * A catchy name ;-) I'm not sure if the name is on the table but 
 I'm not
  overly fond of the current name. Perhaps something more snappy 
 in the
  lines of Snap, Crackle, Pop, Chew, Bite. OK, not those but you get the
  point...
 
  And I do appreciate the fact that this is a volunteer-project and people
  have limited hours.
 
 
  On Tue, Mar 26, 2013 at 1:34 AM, John D. Ament 
 john.d.am...@gmail.comwrote:
 
  Mark,
 
  My vote isn't a -1 to DeltaSpike, she's just not ready to 
 blossom yet.
   Maybe another month or two :-)
 
  I will point out an issue which I don't think we've resolved 
 yet per the
  documentation on incubator.a.o
 
  http://incubator.apache.org/guides/graduation.html#requirements
 
  - We have not established whether DS is a suitable name; e.g.
 
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20PODLINGNAMESEARCH
  has
  no entry for DeltaSpike.  Also we have not forwarded the vote thread to
  general@i.a.o to let them know we're thinking about it.
 
  However, most of my comments are around this section of graduation:
  http://incubator.apache.org/guides/graduation.html#community - I 
 don't
  believe we've done this too well.  There are only three developers 
 I see on
  the  list that were not on
  http://wiki.apache.org/incubator/DeltaSpikeProposal - In fact we now 
 have
  16 vs the original 21 proposed (technically does that mean we shrank?)
 
  Three releases is good.  I think I even saw a podling attempt to 
 graduate
  that only released their parent POM a couple times :-)
 
  Since this is procedural, I'm assuming we're following 
 majority, per
  http://www.apache.org/foundation/voting.html .  I don't believe we 
 need
  100% consensus in the matter then, correct?
 
  John
 
 
  On Mon, Mar 25, 2013 at 5:57 PM, Mark Struberg 
 strub...@yahoo.de wrote:
 
  
  
   Hi John!
  
   I'm not sure I understand what you mean.
  
   The DeltaSpike project now runs for 1 year. The list of initial
  committers
   are all the people who contributed to it in one form or the other. 
 Means
   code drops, documentation, etc. There are exactly 2 people from 
 the CODI
   Team in DeltaSpike. These are Gerhard and me. The rest is from 
 either the
   Seam team or from other teams around the whole CDI area. In my 
 opinion
  the
   community works together pretty well. Of course, I would be happy 
 if
  there
   are more commits and contributions from the other folks. There is 
 a
  pretty
   stable set of 5+ regular committers.
  
  
   We also have had 3 releases so far. We just had a bit of a break 
 because
  I
   was very busy in my dayjob and Gerhard was busy too. And we are 
 short
   before our 4th release. I'd say this is quite ok. (Even if 
 I'd be happier
   if we would improve our release rate).
  
  
   LieGrue,
   strub
  
   
From: John D. Ament john.d.am...@gmail.com
   To: deltaspike-us...@incubator.apache.org; Mark Struberg 
   strub...@yahoo.de
   Cc: deltaspike deltaspike-dev

[VOTE] Recommending DeltaSpike for Graduation to an Apache Top Level Project

2013-03-25 Thread Mark Struberg

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

Re: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top Level Project

2013-03-25 Thread Mark Struberg



Hi John!

I'm not sure I understand what you mean. 

The DeltaSpike project now runs for 1 year. The list of initial committers are 
all the people who contributed to it in one form or the other. Means code 
drops, documentation, etc. There are exactly 2 people from the CODI Team in 
DeltaSpike. These are Gerhard and me. The rest is from either the Seam team or 
from other teams around the whole CDI area. In my opinion the community works 
together pretty well. Of course, I would be happy if there are more commits and 
contributions from the other folks. There is a pretty stable set of 5+ regular 
committers.


We also have had 3 releases so far. We just had a bit of a break because I was 
very busy in my dayjob and Gerhard was busy too. And we are short before our 
4th release. I'd say this is quite ok. (Even if I'd be happier if we would 
improve our release rate).


LieGrue,
strub


 From: John D. Ament john.d.am...@gmail.com
To: deltaspike-us...@incubator.apache.org; Mark Struberg strub...@yahoo.de 
Cc: deltaspike deltaspike-dev@incubator.apache.org 
Sent: Monday, March 25, 2013 10:45 PM
Subject: Re: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top 
Level Project
 

Sorry, but -1


In my opinion, there are clearly disconnects between the former CODI team and 
the former Seam3 team that are showing to be true blockers to being a cohesive 
community.  There has been no real merger of the two communities to form 
DeltaSpike.  DeltaSpike has failed to release early and often.  


I believe for this podling to graduate, we need to become a single team and 
work on becoming that single team.


John



On Mon, Mar 25, 2013 at 5:35 PM, Mark Struberg strub...@yahoo.de wrote:

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

Re: DISCUSS DeltaSpike-324

2013-03-25 Thread Mark Struberg

 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
   
   
   
   
- 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

Re: Pending items for release

2013-03-23 Thread Mark Struberg

yea, +1 for a release pretty soon.

Will try to get my head around the WindowId stuff soon

LieGrue,
strub




- Original Message -
 From: John D. Ament john.d.am...@gmail.com
 To: deltaspike-dev@incubator.apache.org
 Cc: 
 Sent: Saturday, March 23, 2013 9:04 PM
 Subject: Re: Pending items for release
 
G erhard,
 
 Do you agree w/ Cody's synopsis?  I think mimic is what you're trying to
 describe, but threw me off when you said aligned; I assumed you meant be
 dependent on.
 
 
 On Fri, Mar 22, 2013 at 9:16 AM, Gerhard Petracek 
 gerhard.petra...@gmail.com wrote:
 
  hi john,
 
  no - we will just create our own interface like ClientWindow and provide a
  default implementation.
  (for jsf 2.2+ we just provide an own module with an adapter which delegates
  to javax.faces.lifecycle.ClientWindow.)
 
  regards,
  gerhard
 
 
 
  2013/3/22 John D. Ament john.d.am...@gmail.com
 
   I'm not sure I follow.  We're dependent on JEE7 releases to 
 release DS
  0.4?
   I hope we're not really thinking this...
  
  
   On Thu, Mar 21, 2013 at 9:40 PM, Gerhard Petracek 
   gerhard.petra...@gmail.com wrote:
  
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] [Commented] (DELTASPIKE-295) JsfMessageProducer createJsfMessage return type should be parametrized

2013-03-08 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13597056#comment-13597056
 ] 

Mark Struberg commented on DELTASPIKE-295:
--

go on john!

 JsfMessageProducer createJsfMessage return type should be parametrized
 --

 Key: DELTASPIKE-295
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-295
 Project: DeltaSpike
  Issue Type: Bug
  Components: JSF-Module
Affects Versions: 0.4-incubating
 Environment: Current 0.4-incubating snapshot, Weld 2.0.0.Beta1
Reporter: Marek Schmidt
Assignee: John D. Ament
 Fix For: 0.4-incubating


 The 
 {code}
 public JsfMessage createJsfMessage(InjectionPoint injectionPoint)
 {code}
 should probably be
 {code}
 public T JsfMessageT createJsfMessage(InjectionPoint injectionPoint)
 {code}
 instead.
 The problem manifests itself in Weld 2.0.0.Beta1:
 {noformat}
 Tests in error: 
   org.apache.deltaspike.test.jsf.impl.message.JsfMessageTest: Could not 
 deploy to container: {JBAS014671: Failed services = 
 {jboss.deployment.unit.\jsfMessageTest.war\.WeldService = 
 org.jboss.msc.service.StartException in service 
 jboss.deployment.unit.\jsfMessageTest.war\.WeldService: 
 org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied 
 dependencies for type [JsfMessageUserMessage] with qualifiers [@Default] at 
 injection point [[BackedAnnotatedField] @Inject private 
 org.apache.deltaspike.test.jsf.impl.message.beans.JsfMessageBackingBean.msg]}}
 {noformat}

--
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-318) OpenejbCdiControl tries to scan starting classes

2013-02-26 Thread Mark Struberg (JIRA)

Mark Struberg created DELTASPIKE-318:


 Summary: OpenejbCdiControl tries to scan starting classes
 Key: DELTASPIKE-318
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-318
 Project: DeltaSpike
  Issue Type: Bug
  Components: CdiControl
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


We did hit this issue when we starting OpenEJB in a jbehave test. In that case 
OpenEJB blows up because it tries to scan the inner class of StepCreator.

We should generally disable this self-scanning by passing in the following 
property to the EJBContainer
openejb.additionnal.callers, 

--
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-315) Provide a producer for EntityManagerFactories

2013-02-23 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13585083#comment-13585083
 ] 

Mark Struberg commented on DELTASPIKE-315:
--

I've pushed a first version to 
https://github.com/struberg/incubator-deltaspike/tree/DELTASPIKE-315
The configuration is not yet implemented. I've isolated it in an own interface 
PersistenceConfigurationProvider. We need to define a strategy to configure 
this as easy as possible. I remember that we had a question about introducing 
'categories' into our ConfigSource mechanism. Now this might be the perfect 
reason to review this topic and maybe introduce such a mechanism for 
'persistence'

 Provide a producer for EntityManagerFactories
 -

 Key: DELTASPIKE-315
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-315
 Project: DeltaSpike
  Issue Type: Bug
  Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 I found myself using the following pattern quite often in projects in the 
 last time. I have a @Qualifier UnitName(value) and a producer for a 
 @Dependent EntityManagerFactory for it. The configuration is mostly provided 
 via the persistenceProperties Map in 
 EntityManagerFactory#createEntityManagerFactory(unitname, 
 persistenceProperties);
 We can further tweak the config lookup path and define a route which makes 
 the most sense.
 This can be used to create the EntityManager producer very easily.
 @ApplicationScoped
 public class MyEntityManagerProducer {
   private @Inject @UnitName(orderUnit) EntityManagerFactory emf;
   
   @Produces @RequestScoped
   public EntityManager createEm() {
 return emf.createEntityManager();
   }
   .. + disposer 
 }
 Please note that the EMF producer doens't clash with anything else as it only 
 produces EMFs with the Qualifier @UnitName!

--
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-315) Provide a producer for EntityManagerFactories

2013-02-22 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13584096#comment-13584096
 ] 

Mark Struberg commented on DELTASPIKE-315:
--

I fear this all gets much more complicated than a simple 5 line producer for 
the EntityManager.

For now I'll provide the EntityManagerFactoryProducer and we can think about 
other ideas later on.

 Provide a producer for EntityManagerFactories
 -

 Key: DELTASPIKE-315
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-315
 Project: DeltaSpike
  Issue Type: Bug
  Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 I found myself using the following pattern quite often in projects in the 
 last time. I have a @Qualifier UnitName(value) and a producer for a 
 @Dependent EntityManagerFactory for it. The configuration is mostly provided 
 via the persistenceProperties Map in 
 EntityManagerFactory#createEntityManagerFactory(unitname, 
 persistenceProperties);
 We can further tweak the config lookup path and define a route which makes 
 the most sense.
 This can be used to create the EntityManager producer very easily.
 @ApplicationScoped
 public class MyEntityManagerProducer {
   private @Inject @UnitName(orderUnit) EntityManagerFactory emf;
   
   @Produces @RequestScoped
   public EntityManager createEm() {
 return emf.createEntityManager();
   }
   .. + disposer 
 }
 Please note that the EMF producer doens't clash with anything else as it only 
 produces EMFs with the Qualifier @UnitName!

--
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-315) Provide a producer for EntityManagerFactories

2013-02-22 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13584146#comment-13584146
 ] 

Mark Struberg commented on DELTASPIKE-315:
--

Not sure how you like to implement this. We need a BeanEntityManager which 
would somehow manage to lookup the persistence unit it is supposed for. But 
since we need to produce NormalScoped (@RequestScoped, @TransactionScoped) 
EntityManagers we do not have any InjectionPoint we can lookup. And 
BeanT#create() doesn't take any additional qualifier info ..

We would need to parse all Qualifiers which are @PersistenceUnitName 
meta-annotated and register beans for those. But ProcessAnnotatedType doesn't 
get fired for annotations. The only way would be to @Observes 
ProcessInjectionPoint to collect this info. But I'm really not sure if this is 
worth it to avoid this 5 lines of code a user needs to write...

 Provide a producer for EntityManagerFactories
 -

 Key: DELTASPIKE-315
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-315
 Project: DeltaSpike
  Issue Type: Bug
  Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 I found myself using the following pattern quite often in projects in the 
 last time. I have a @Qualifier UnitName(value) and a producer for a 
 @Dependent EntityManagerFactory for it. The configuration is mostly provided 
 via the persistenceProperties Map in 
 EntityManagerFactory#createEntityManagerFactory(unitname, 
 persistenceProperties);
 We can further tweak the config lookup path and define a route which makes 
 the most sense.
 This can be used to create the EntityManager producer very easily.
 @ApplicationScoped
 public class MyEntityManagerProducer {
   private @Inject @UnitName(orderUnit) EntityManagerFactory emf;
   
   @Produces @RequestScoped
   public EntityManager createEm() {
 return emf.createEntityManager();
   }
   .. + disposer 
 }
 Please note that the EMF producer doens't clash with anything else as it only 
 produces EMFs with the Qualifier @UnitName!

--
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-315) Provide a producer for EntityManagerFactories

2013-02-22 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13584177#comment-13584177
 ] 

Mark Struberg commented on DELTASPIKE-315:
--

The problem is that ProcessAnnotatedType does not get fired for annotations.

 Provide a producer for EntityManagerFactories
 -

 Key: DELTASPIKE-315
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-315
 Project: DeltaSpike
  Issue Type: Bug
  Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 I found myself using the following pattern quite often in projects in the 
 last time. I have a @Qualifier UnitName(value) and a producer for a 
 @Dependent EntityManagerFactory for it. The configuration is mostly provided 
 via the persistenceProperties Map in 
 EntityManagerFactory#createEntityManagerFactory(unitname, 
 persistenceProperties);
 We can further tweak the config lookup path and define a route which makes 
 the most sense.
 This can be used to create the EntityManager producer very easily.
 @ApplicationScoped
 public class MyEntityManagerProducer {
   private @Inject @UnitName(orderUnit) EntityManagerFactory emf;
   
   @Produces @RequestScoped
   public EntityManager createEm() {
 return emf.createEntityManager();
   }
   .. + disposer 
 }
 Please note that the EMF producer doens't clash with anything else as it only 
 produces EMFs with the Qualifier @UnitName!

--
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-315) Provide a producer for EntityManagerFactories

2013-02-21 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583152#comment-13583152
 ] 

Mark Struberg commented on DELTASPIKE-315:
--

Had an idea this morning.

@Qualifier
public @interface UnitSomething @  //X better name needed ;)
  Class? extends Annotation scope default RequestScoped.class;
  
  @Nonbinding
  String unitName;
}

The important point is that the 'scope' is NOT Nonbinding!

We will provide 2 producer methods by default. The first which produces the 
RequestScoped EM, the other one which produces a @TransactionScoped EM.




 Provide a producer for EntityManagerFactories
 -

 Key: DELTASPIKE-315
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-315
 Project: DeltaSpike
  Issue Type: Bug
  Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 I found myself using the following pattern quite often in projects in the 
 last time. I have a @Qualifier UnitName(value) and a producer for a 
 @Dependent EntityManagerFactory for it. The configuration is mostly provided 
 via the persistenceProperties Map in 
 EntityManagerFactory#createEntityManagerFactory(unitname, 
 persistenceProperties);
 We can further tweak the config lookup path and define a route which makes 
 the most sense.
 This can be used to create the EntityManager producer very easily.
 @ApplicationScoped
 public class MyEntityManagerProducer {
   private @Inject @UnitName(orderUnit) EntityManagerFactory emf;
   
   @Produces @RequestScoped
   public EntityManager createEm() {
 return emf.createEntityManager();
   }
   .. + disposer 
 }
 Please note that the EMF producer doens't clash with anything else as it only 
 produces EMFs with the Qualifier @UnitName!

--
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-315) Provide a producer for EntityManagerFactories

2013-02-19 Thread Mark Struberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581474#comment-13581474
 ] 

Mark Struberg commented on DELTASPIKE-315:
--

Romain, we should gather the info about EntityManagers on the DeltaSpike CMS 
page. This clearly only addresses resource-local aka 'native' EntityManagers. 
Some people prefer this over container managed EMs because there is sadly no 
single container working the same way. All of them use a different JNDI 
location, etc. 

I'm -1 to use the javax.* namespace in a way which is not intended by the specs 
as well. That might confuse users.

The benefit of my approach is that the producer does nothing until someone uses 
the @UnitName qualifier. 

Regarding 'making it easier'. Imo that's all a question of how we handle the 
configuration of the Map we pass to the EntityManagerFactory.

We at least need the following coordinates/overloadability:

* default values (useful for some default configuration of the JPA provider)
* ProjectStage (useful for having different settings depending on Development 
vs Production, etc)
* Database Vendor (useful to switch between different database vendors via 
config or maven property)



 Provide a producer for EntityManagerFactories
 -

 Key: DELTASPIKE-315
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-315
 Project: DeltaSpike
  Issue Type: Bug
  Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 I found myself using the following pattern quite often in projects in the 
 last time. I have a @Qualifier UnitName(value) and a producer for a 
 @Dependent EntityManagerFactory for it. The configuration is mostly provided 
 via the persistenceProperties Map in 
 EntityManagerFactory#createEntityManagerFactory(unitname, 
 persistenceProperties);
 We can further tweak the config lookup path and define a route which makes 
 the most sense.
 This can be used to create the EntityManager producer very easily.
 @ApplicationScoped
 public class MyEntityManagerProducer {
   private @Inject @UnitName(orderUnit) EntityManagerFactory emf;
   
   @Produces @RequestScoped
   public EntityManager createEm() {
 return emf.createEntityManager();
   }
   .. + disposer 
 }
 Please note that the EMF producer doens't clash with anything else as it only 
 produces EMFs with the Qualifier @UnitName!

--
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-315) Provide a producer for EntityManagerFactories

2013-02-16 Thread Mark Struberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated DELTASPIKE-315:
-

Description: 
I found myself using the following pattern quite often in projects in the last 
time. I have a @Qualifier UnitName(value) and a producer for a @Dependent 
EntityManagerFactory for it. The configuration is mostly provided via the 
persistenceProperties Map in 
EntityManagerFactory#createEntityManagerFactory(unitname, 
persistenceProperties);
We can further tweak the config lookup path and define a route which makes the 
most sense.

This can be used to create the EntityManager producer very easily.

@ApplicationScoped
public class MyEntityManagerProducer {
  private @Inject @UnitName(orderUnit) EntityManagerFactory emf;
  
  @Produces @RequestScoped
  public EntityManager createEm() {
return emf.createEntityManager();
  }
  .. + disposer 
}


Please note that the EMF producer doens't clash with anything else as it only 
produces EMFs with the Qualifier @UnitName!

  was:
I found myself using the following pattern quite often in projects in the last 
time. I have a @Qualifier UnitName(value) and a producer for a @Dependent 
EntityManagerFactory for it. The configuration is mostly provided via the 
persistenceProperties Map in 
EntityManagerFactory#createEntityManagerFactory(unitname, 
persistenceProperties);
We can further tweak the config lookup path and define a route which makes the 
most sense.

This can be used to create the EntityManager producer very easily.

@ApplicationScoped
public class MyEntityManagerProducer {
  private @Inject @UnitName(orderUnit) EntityManagerFactory emf;
  
  @Produces @RequestScoped
  public EntityManager createEm() {
return emf.createEntityManager();
  }
  .. + disposer 
}




 Provide a producer for EntityManagerFactories
 -

 Key: DELTASPIKE-315
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-315
 Project: DeltaSpike
  Issue Type: Bug
  Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 I found myself using the following pattern quite often in projects in the 
 last time. I have a @Qualifier UnitName(value) and a producer for a 
 @Dependent EntityManagerFactory for it. The configuration is mostly provided 
 via the persistenceProperties Map in 
 EntityManagerFactory#createEntityManagerFactory(unitname, 
 persistenceProperties);
 We can further tweak the config lookup path and define a route which makes 
 the most sense.
 This can be used to create the EntityManager producer very easily.
 @ApplicationScoped
 public class MyEntityManagerProducer {
   private @Inject @UnitName(orderUnit) EntityManagerFactory emf;
   
   @Produces @RequestScoped
   public EntityManager createEm() {
 return emf.createEntityManager();
   }
   .. + disposer 
 }
 Please note that the EMF producer doens't clash with anything else as it only 
 produces EMFs with the Qualifier @UnitName!

--
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-315) Provide a producer for EntityManagerFactories

2013-02-16 Thread Mark Struberg (JIRA)

Mark Struberg created DELTASPIKE-315:


 Summary: Provide a producer for EntityManagerFactories
 Key: DELTASPIKE-315
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-315
 Project: DeltaSpike
  Issue Type: Bug
  Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


I found myself using the following pattern quite often in projects in the last 
time. I have a @Qualifier UnitName(value) and a producer for a @Dependent 
EntityManagerFactory for it. The configuration is mostly provided via the 
persistenceProperties Map in 
EntityManagerFactory#createEntityManagerFactory(unitname, 
persistenceProperties);
We can further tweak the config lookup path and define a route which makes the 
most sense.

This can be used to create the EntityManager producer very easily.

@ApplicationScoped
public class MyEntityManagerProducer {
  private @Inject @UnitName(orderUnit) EntityManagerFactory emf;
  
  @Produces @RequestScoped
  public EntityManager createEm() {
return emf.createEntityManager();
  }
  .. + disposer 
}



--
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: git commit: DELTASPIKE-113 added profile

2013-02-16 Thread Mark Struberg

hmm why is this only needed in the jpa module?
Javassist is an implicit part of all the Weld profile. It should be in the 
parent poms Weld profile, isn't?

LieGrue,
strub




- Original Message -
 From: gpetra...@apache.org gpetra...@apache.org
 To: deltaspike-comm...@incubator.apache.org
 Cc: 
 Sent: Sunday, February 17, 2013 7:37 AM
 Subject: git commit: DELTASPIKE-113 added profile
 
 Updated Branches:
   refs/heads/master 357a6d35a - fa8ed3c6d
 
 
 DELTASPIKE-113 added profile
 
 
 Project: http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/repo
 Commit: 
 http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/commit/fa8ed3c6
 Tree: 
 http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/tree/fa8ed3c6
 Diff: 
 http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/diff/fa8ed3c6
 
 Branch: refs/heads/master
 Commit: fa8ed3c6d1bf6e7a3e53103b1b439d463db0072b
 Parents: 357a6d3
 Author: gpetracek gpetra...@apache.org
 Authored: Sun Feb 17 07:32:37 2013 +0100
 Committer: gpetracek gpetra...@apache.org
 Committed: Sun Feb 17 07:32:37 2013 +0100
 
 --
 deltaspike/modules/jpa/impl/pom.xml      |   19 +--
 deltaspike/modules/security/impl/pom.xml |   18 --
 2 files changed, 25 insertions(+), 12 deletions(-)
 --
 
 
 http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/blob/fa8ed3c6/deltaspike/modules/jpa/impl/pom.xml
 --
 diff --git a/deltaspike/modules/jpa/impl/pom.xml 
 b/deltaspike/modules/jpa/impl/pom.xml
 index 5a22dd9..e482e82 100644
 --- a/deltaspike/modules/jpa/impl/pom.xml
 +++ b/deltaspike/modules/jpa/impl/pom.xml
 @@ -64,14 +64,21 @@
              groupIdorg.apache.geronimo.specs/groupId
              artifactIdgeronimo-jta_1.1_spec/artifactId
          /dependency
 -
 -        dependency
 -            groupIdjavassist/groupId
 -            artifactIdjavassist/artifactId
 -            scopetest/scope
 -        /dependency
      /dependencies
 
 +    profiles
 +        profile
 +            idWeld/id
 +            dependencies
 +                dependency
 +                    groupIdjavassist/groupId
 +                    artifactIdjavassist/artifactId
 +                    scopetest/scope
 +                /dependency
 +            /dependencies
 +        /profile
 +    /profiles
 +
      build
          plugins
              plugin
 
 http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/blob/fa8ed3c6/deltaspike/modules/security/impl/pom.xml
 --
 diff --git a/deltaspike/modules/security/impl/pom.xml 
 b/deltaspike/modules/security/impl/pom.xml
 index 86a21b7..cb275e0 100644
 --- a/deltaspike/modules/security/impl/pom.xml
 +++ b/deltaspike/modules/security/impl/pom.xml
 @@ -51,12 +51,18 @@
            groupIdorg.apache.geronimo.specs/groupId
            artifactIdgeronimo-jpa_2.0_spec/artifactId
          /dependency
 -
 -        dependency
 -            groupIdjavassist/groupId
 -            artifactIdjavassist/artifactId
 -            scopetest/scope
 -        /dependency
      /dependencies
 
 +    profiles
 +        profile
 +            idWeld/id
 +            dependencies
 +                dependency
 +                    groupIdjavassist/groupId
 +                    artifactIdjavassist/artifactId
 +                    scopetest/scope
 +                /dependency
 +            /dependencies
 +        /profile
 +    /profiles
 /project

Re: cdi-query, no news?

2013-02-12 Thread Mark Struberg



Thanks Thomas, great news!

LieGrue,
strub






 From: Thomas Hug thomas@ctp-consulting.com
To: deltaspike-dev@incubator.apache.org 
deltaspike-dev@incubator.apache.org 
Sent: Tuesday, February 12, 2013 4:10 PM
Subject: Re: cdi-query, no news?
 
FYI, I've started to de-solderize CDI Query and move things to depend on
DS Core [1]:
https://github.com/ctpconsulting/query/tree/deltaspike

Todos:
[x] Replace ServiceHandler
[_] Include Property utils
[_] Replace JBoss Logging

Any feedback welcome.

[1] including this modification
https://issues.apache.org/jira/browse/DELTASPIKE-113?focusedCommentId=13576531page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13576531

On Mon, Feb 11, 2013 at 6:01 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 a review of the API i guess

 what is missing today is probably the pagination helpers (PageRequest for
 instance)

 but technically all is fine 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/2/11 Jason Porter lightguard...@gmail.com

  I know I'm playing the necromancer, but please forgive me. We have
  InvocationHandler, which looks like it would work as a ServiceHandler
  substitute. What else is needed to get CDI Query into DeltaSpike?
 
 
  On Sun, Nov 18, 2012 at 12:35 PM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
   +1, it is a must have for cdi world
   Le 18 nov. 2012 20:04, john.d.ament john.d.am...@gmail.com a
 écrit :
  
RE ServiceHandler - I was one of those who previously suggested
  bringing
   it
over to DeltaSpike, you can see DELTASPIKE-113 and find the thread
  about
   it
from April of this year.  At the time, I was in a position where I
   couldn't
spend much time on open source contribution.  I've recently changed
  jobs,
to
something that's going to help me spend some more time with the open
   source
community, and believe I can pick it back up if we're ready.
   
If everyone's ok with it I can start a new thread for 113 or revive
 the
   old
thread (though it may come through with a large pile of dust).
   
Regards,
   
John
   
   
   
--
View this message in context:
   
  
 
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/cdi-query-no-news-tp4654029p4654036.html
Sent from the Apache DeltaSpike Incubator Discussions mailing list
   archive
at Nabble.com.
   
  
 
 
 
  --
  Jason Porter
  http://en.gravatar.com/lightguardjp

[jira] [Created] (DELTASPIKE-312) GlobalAlternatives must not get handled for OpenWebBeans

Mark Struberg created DELTASPIKE-312:


 Summary: GlobalAlternatives must not get handled for OpenWebBeans
 Key: DELTASPIKE-312
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-312
 Project: DeltaSpike
  Issue Type: Bug
  Components: Core
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


We currently also rewrite the AnnotatedType for OWB. But this is not needed for 
OWB because we handle the BDA flat anyway. Thus standard alternatives in 
beans.xml is plenty enough for OWB. OWB users of containers which come with BDA 
enabled (e.g. IBM WebSphere) should instead just disable this feature via 
openwebbeans.properties

--
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-313) allow cdictrl-openejb to use a different owb version in the build

Mark Struberg created DELTASPIKE-313:


 Summary: allow cdictrl-openejb to use a different owb version in 
the build
 Key: DELTASPIKE-313
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-313
 Project: DeltaSpike
  Issue Type: Bug
  Components: build_infra
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


Currently the CdiCtrl-OpenEJB module always uses the OpenWebBeans version 
declared in the main parent pom. By manually overriding this property to test 
new OWB versions we most times break the build because OWB must fit the version 
used in the OpenEJB build.

We should optionally separate those versions

--
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-313) allow cdictrl-openejb to use a different owb version in the build


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved DELTASPIKE-313.
--

Resolution: Fixed

 allow cdictrl-openejb to use a different owb version in the build
 -

 Key: DELTASPIKE-313
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-313
 Project: DeltaSpike
  Issue Type: Bug
  Components: build_infra
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 0.4-incubating


 Currently the CdiCtrl-OpenEJB module always uses the OpenWebBeans version 
 declared in the main parent pom. By manually overriding this property to test 
 new OWB versions we most times break the build because OWB must fit the 
 version used in the OpenEJB build.
 We should optionally separate those versions

--
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-313) allow cdictrl-openejb to use a different owb version in the build