[jira] [Commented] (DELTASPIKE-1319) labeled alternatives

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16382627#comment-16382627
 ] 

ASF subversion and git services commented on DELTASPIKE-1319:
-

Commit ca6b722bd0cea0975580d74fefd53f25e9330cc5 in deltaspike's branch 
refs/heads/master from [~gpetracek]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=ca6b722 ]

DELTASPIKE-1319 basic support for test-suites and minor improvements


> labeled alternatives
> 
>
> Key: DELTASPIKE-1319
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1319
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core, TestControl
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> target setup: ds-testcontrol as well as containers like meecrowave which 
> support one instance per test-class, but deploy the whole application.
> in several cases it's essential to bind alternative beans only to a subset of 
> all tests.
> currently we just support that partially via the mock-support (which is very 
> limited in several cases).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] require Java8 and move to Deltaspike-1.9.x version?

[Rudy De Busscher]

Strictly speaking, DS1.x is Java EE 6 based (because we are using CDI 1.0,
JSF 2.0)

But probably no harm in just setting compiler to java 8. (and indicate that
DS 1.9 only run on Java EE 7 server with Java 8)

On 1 March 2018 at 16:05, Thomas Andraschko 
wrote:

> IMO
> DS1.x = JavaEE 7
> DS2.x = JavaEE 8
>
> Java8 in 1.x is fine for me, we can try to improve our APIs with Java8
> In 2.x we can even improve further and cleanup then
>
>
> 2018-03-01 15:55 GMT+01:00 Romain Manni-Bucau :
>
> > 2018-03-01 15:50 GMT+01:00 John D. Ament :
> >
> > > IMHO to move to Java 8 we need to drop support for EE6/EE7.  So to me
> > that
> > > says the next version is 2.0 not 1.9.x.
> > >
> >
> > It is way too early for cdi 2, almost no users rely on that yet compared
> to
> > cdi 1.x.
> >
> >
> > >
> > > There are some weld 1.1 versions that support this, but no testable AS7
> > > instance that we can check against.
> > >
> >
> > Isnt wildfly enough now? Maybe JBoss guys can help us here as well.
> >
> >
> > >
> > > John
> > >
> > > On Thu, Mar 1, 2018 at 9:35 AM Cody Lerum 
> wrote:
> > >
> > > > +1 there is no reason for someone running Java 7 to expect new
> features
> > > > from Deltaspike.
> > > >
> > > > On Feb 28, 2018 9:48 PM, "Mark Struberg" 
> > > > wrote:
> > > >
> > > > > Hi folks!
> > > > >
> > > > > Our build, etc in theory still runs with Java6.
> > > > > As typical with ASF projects we make battle prooven projects for
> > > > > production.
> > > > > That means we take backward compatibility really serious.
> > > > >
> > > > > But I think it's finally time to up the game to Java8.
> > > > > To indicate this I suggest to move from currently 1.8.x to 1.9.x.
> > > > >
> > > > > Note that all the rest will still be backward compatible with older
> > > > > versions!
> > > > > We also might still ship 1.8.2, 1.8.3, etc as Java7 compatible
> > version
> > > if
> > > > > there is any necessity.
> > > > >
> > > > > Any objections?
> > > > >
> > > > > LieGrue,
> > > > > strub
> > > >
> > >
> >
>

Re: [DISCUSS] require Java8 and move to Deltaspike-1.9.x version?

[John D. Ament]

I think assuming all EE7 vendors support Java 8 then I think its fine.  But
I definitely believe we can't do EE6 on Java 8.

John

On Thu, Mar 1, 2018 at 10:06 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> IMO
> DS1.x = JavaEE 7
> DS2.x = JavaEE 8
>
> Java8 in 1.x is fine for me, we can try to improve our APIs with Java8
> In 2.x we can even improve further and cleanup then
>
>
> 2018-03-01 15:55 GMT+01:00 Romain Manni-Bucau :
>
> > 2018-03-01 15:50 GMT+01:00 John D. Ament :
> >
> > > IMHO to move to Java 8 we need to drop support for EE6/EE7.  So to me
> > that
> > > says the next version is 2.0 not 1.9.x.
> > >
> >
> > It is way too early for cdi 2, almost no users rely on that yet compared
> to
> > cdi 1.x.
> >
> >
> > >
> > > There are some weld 1.1 versions that support this, but no testable AS7
> > > instance that we can check against.
> > >
> >
> > Isnt wildfly enough now? Maybe JBoss guys can help us here as well.
> >
> >
> > >
> > > John
> > >
> > > On Thu, Mar 1, 2018 at 9:35 AM Cody Lerum 
> wrote:
> > >
> > > > +1 there is no reason for someone running Java 7 to expect new
> features
> > > > from Deltaspike.
> > > >
> > > > On Feb 28, 2018 9:48 PM, "Mark Struberg" 
> > > > wrote:
> > > >
> > > > > Hi folks!
> > > > >
> > > > > Our build, etc in theory still runs with Java6.
> > > > > As typical with ASF projects we make battle prooven projects for
> > > > > production.
> > > > > That means we take backward compatibility really serious.
> > > > >
> > > > > But I think it's finally time to up the game to Java8.
> > > > > To indicate this I suggest to move from currently 1.8.x to 1.9.x.
> > > > >
> > > > > Note that all the rest will still be backward compatible with older
> > > > > versions!
> > > > > We also might still ship 1.8.2, 1.8.3, etc as Java7 compatible
> > version
> > > if
> > > > > there is any necessity.
> > > > >
> > > > > Any objections?
> > > > >
> > > > > LieGrue,
> > > > > strub
> > > >
> > >
> >
>

Re: [DISCUSS] require Java8 and move to Deltaspike-1.9.x version?

[Thomas Andraschko]

IMO
DS1.x = JavaEE 7
DS2.x = JavaEE 8

Java8 in 1.x is fine for me, we can try to improve our APIs with Java8
In 2.x we can even improve further and cleanup then


2018-03-01 15:55 GMT+01:00 Romain Manni-Bucau :

> 2018-03-01 15:50 GMT+01:00 John D. Ament :
>
> > IMHO to move to Java 8 we need to drop support for EE6/EE7.  So to me
> that
> > says the next version is 2.0 not 1.9.x.
> >
>
> It is way too early for cdi 2, almost no users rely on that yet compared to
> cdi 1.x.
>
>
> >
> > There are some weld 1.1 versions that support this, but no testable AS7
> > instance that we can check against.
> >
>
> Isnt wildfly enough now? Maybe JBoss guys can help us here as well.
>
>
> >
> > John
> >
> > On Thu, Mar 1, 2018 at 9:35 AM Cody Lerum  wrote:
> >
> > > +1 there is no reason for someone running Java 7 to expect new features
> > > from Deltaspike.
> > >
> > > On Feb 28, 2018 9:48 PM, "Mark Struberg" 
> > > wrote:
> > >
> > > > Hi folks!
> > > >
> > > > Our build, etc in theory still runs with Java6.
> > > > As typical with ASF projects we make battle prooven projects for
> > > > production.
> > > > That means we take backward compatibility really serious.
> > > >
> > > > But I think it's finally time to up the game to Java8.
> > > > To indicate this I suggest to move from currently 1.8.x to 1.9.x.
> > > >
> > > > Note that all the rest will still be backward compatible with older
> > > > versions!
> > > > We also might still ship 1.8.2, 1.8.3, etc as Java7 compatible
> version
> > if
> > > > there is any necessity.
> > > >
> > > > Any objections?
> > > >
> > > > LieGrue,
> > > > strub
> > >
> >
>

Re: [DISCUSS] require Java8 and move to Deltaspike-1.9.x version?

[Romain Manni-Bucau]

2018-03-01 15:50 GMT+01:00 John D. Ament :

> IMHO to move to Java 8 we need to drop support for EE6/EE7.  So to me that
> says the next version is 2.0 not 1.9.x.
>

It is way too early for cdi 2, almost no users rely on that yet compared to
cdi 1.x.


>
> There are some weld 1.1 versions that support this, but no testable AS7
> instance that we can check against.
>

Isnt wildfly enough now? Maybe JBoss guys can help us here as well.


>
> John
>
> On Thu, Mar 1, 2018 at 9:35 AM Cody Lerum  wrote:
>
> > +1 there is no reason for someone running Java 7 to expect new features
> > from Deltaspike.
> >
> > On Feb 28, 2018 9:48 PM, "Mark Struberg" 
> > wrote:
> >
> > > Hi folks!
> > >
> > > Our build, etc in theory still runs with Java6.
> > > As typical with ASF projects we make battle prooven projects for
> > > production.
> > > That means we take backward compatibility really serious.
> > >
> > > But I think it's finally time to up the game to Java8.
> > > To indicate this I suggest to move from currently 1.8.x to 1.9.x.
> > >
> > > Note that all the rest will still be backward compatible with older
> > > versions!
> > > We also might still ship 1.8.2, 1.8.3, etc as Java7 compatible version
> if
> > > there is any necessity.
> > >
> > > Any objections?
> > >
> > > LieGrue,
> > > strub
> >
>

Re: [DISCUSS] require Java8 and move to Deltaspike-1.9.x version?

[Rudy De Busscher]

Maybe not drop EE7. I think all current app servers supporting Java EE 7
runs on Java 8.

But removing EE6, means for example that we no longer need BeanProvider and
other specific code for EE6.

So changing to Java 8 has quite some impact (but Java 8 is wanted I guess)
and thus requires 2.x numbering.

Rudy

On 1 March 2018 at 15:50, John D. Ament  wrote:

> IMHO to move to Java 8 we need to drop support for EE6/EE7.  So to me that
> says the next version is 2.0 not 1.9.x.
>
> There are some weld 1.1 versions that support this, but no testable AS7
> instance that we can check against.
>
> John
>
> On Thu, Mar 1, 2018 at 9:35 AM Cody Lerum  wrote:
>
> > +1 there is no reason for someone running Java 7 to expect new features
> > from Deltaspike.
> >
> > On Feb 28, 2018 9:48 PM, "Mark Struberg" 
> > wrote:
> >
> > > Hi folks!
> > >
> > > Our build, etc in theory still runs with Java6.
> > > As typical with ASF projects we make battle prooven projects for
> > > production.
> > > That means we take backward compatibility really serious.
> > >
> > > But I think it's finally time to up the game to Java8.
> > > To indicate this I suggest to move from currently 1.8.x to 1.9.x.
> > >
> > > Note that all the rest will still be backward compatible with older
> > > versions!
> > > We also might still ship 1.8.2, 1.8.3, etc as Java7 compatible version
> if
> > > there is any necessity.
> > >
> > > Any objections?
> > >
> > > LieGrue,
> > > strub
> >
>

Re: [DISCUSS] require Java8 and move to Deltaspike-1.9.x version?

[John D. Ament]

IMHO to move to Java 8 we need to drop support for EE6/EE7.  So to me that
says the next version is 2.0 not 1.9.x.

There are some weld 1.1 versions that support this, but no testable AS7
instance that we can check against.

John

On Thu, Mar 1, 2018 at 9:35 AM Cody Lerum  wrote:

> +1 there is no reason for someone running Java 7 to expect new features
> from Deltaspike.
>
> On Feb 28, 2018 9:48 PM, "Mark Struberg" 
> wrote:
>
> > Hi folks!
> >
> > Our build, etc in theory still runs with Java6.
> > As typical with ASF projects we make battle prooven projects for
> > production.
> > That means we take backward compatibility really serious.
> >
> > But I think it's finally time to up the game to Java8.
> > To indicate this I suggest to move from currently 1.8.x to 1.9.x.
> >
> > Note that all the rest will still be backward compatible with older
> > versions!
> > We also might still ship 1.8.2, 1.8.3, etc as Java7 compatible version if
> > there is any necessity.
> >
> > Any objections?
> >
> > LieGrue,
> > strub
>

[jira] [Commented] (DELTASPIKE-1320) global alternative spi to support custom (type-safe) mechanisms

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381663#comment-16381663
 ] 

ASF subversion and git services commented on DELTASPIKE-1320:
-

Commit 5a8369ae9b1130951bc223352c8eb7ad64e3 in deltaspike's branch 
refs/heads/master from [~gpetracek]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=5a8369a ]

DELTASPIKE-1320 labeled alternatives take priority over global alternatives


> global alternative spi to support custom (type-safe) mechanisms
> ---
>
> Key: DELTASPIKE-1320
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1320
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 1.8.1
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
>Priority: Major
> Fix For: 1.8.2
>
>
> in combination with DELTASPIKE-1319 it should be possible to implement e.g. 
> type-safe labels based on binding-annotations



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DELTASPIKE-1318) Unsatisfied dependencies for type ApplicationContext (deltaspike-cdictrl-weld) in payara 4.1.2.174

[Andreas Keefer (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381650#comment-16381650
 ] 

Andreas Keefer commented on DELTASPIKE-1318:


org.jboss.weld.context.ApplicationContext is in the classpath, but seems not to 
be a CDI/container managed bean that can be injected.

Yes, Glassfish/Payara is still OSGi based (Apache Felix)

> Unsatisfied dependencies for type ApplicationContext 
> (deltaspike-cdictrl-weld) in payara 4.1.2.174
> --
>
> Key: DELTASPIKE-1318
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1318
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: CdiControl
>Affects Versions: 1.8.1
> Environment: payara 4.1.2.174
>Reporter: Andreas Keefer
>Priority: Major
>
> ApplicationContext can't be injected in WeldContextControl on payara 4.1.2.174
>  
> Maven dependencies
> {code:java}
> 
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-api
> compile
> 
> 
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-weld
> runtime
> 
> {code}
>  Sample Bean:
> {code:java}
> @Singleton
> @Startup
> public class KafkaVehicleReceiver {
>   @Inject
>   private ContextControl contextControl;
>   ...
> }{code}
>  payara log:
> {code:java}
> [2018-02-27T00:40:54.713+0100] [Payara 4.1] [SCHWERWIEGEND] [NCLS-CORE-00026] 
> [javax.enterprise.system.core] [tid: _ThreadID=47 
> _ThreadName=admin-thread-pool::admin-listener(1)] [timeMillis: 1519688454713] 
> [levelValue: 1000] [[
> Exception during lifecycle processing
> org.glassfish.deployment.common.DeploymentException: CDI deployment 
> failure:WELD-001408: Unsatisfied dependencies for type ApplicationContext 
> with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private 
> org.apache.deltaspike.cdise.weld.WeldContextControl.applicationContext
> at 
> org.apache.deltaspike.cdise.weld.WeldContextControl.applicationContext(WeldContextControl.java:0)
> at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:270)
> at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
> at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:333)
> at 
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
> at 
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:220)
> at 
> org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:508)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:544)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:540)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:539)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:570)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:562)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:561)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1469)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:111)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1851)
> at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1727)
> at 
> org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:407)
> at 
> org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
> at 
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
> at 
>