Re: [VOTE] Release Apache DeltaSpike-2.0.0

[John D. Ament]

+1 LGTM

Though I always question when release notes mention things that are Won't
Do as being included in them, not a problem for the release.

On Fri, Mar 29, 2024 at 10:45 AM Mark Struberg 
wrote:

> Good afternoon!
>
> I'd like to call a VOTE on releasing Apache DeltaSpike-2.0.0
>
> The list of fixed tickets can be found in the release notes
>
> https://github.com/apache/deltaspike/blob/master/deltaspike/readme/ReleaseNotes-2.0.0.txt
>
> This is the first version to natively target JakartaEE-9 and the jakarta.*
> namespace.
>
> The staging repo is available under:
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1060/
>
> The source release zip can be found here
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1060/org/apache/deltaspike/deltaspike/2.0.0/
>
> the sha512 is
>
> 06a462cd3e66457cc35bc88e8ec0f63f4560fa4bdf4d91cb0983e07001c05fbf4fa7d50d73310a9e52fb420824256e69bf373a1d03750858645f5e83120f5d1e
>
> Please VOTE
>
> [+1] let's ship it
> [+0] don't care
> [-1] stop, there is a ${showstopper}
>
> The VOTE is open for 72h
>
>
>
> txs and LieGrue,
> strub
>

Re: [VOTE] Release Apache DeltaSpike-1.9.6

[John D. Ament]

+1

On Fri, Apr 8, 2022 at 12:27 Mark Struberg 
wrote:

> Hi lords and ladies!
>
> I'd like to call a VOTE on releasing Apache DeltaSpike-1.9.6
>
> The following tickets got resolved:
>
>
> Bug
> [DELTASPIKE-1133] - Don't override the log level
> [DELTASPIKE-1427] - JUL Logging with {} as param leeds to
> NumberFormatException
> [DELTASPIKE-1433] - EntityManagerFactoryProducer should also provide a
> @Disposes method
> [DELTASPIKE-1453] - injecting config of Class got broken
>
> New Feature
> [DELTASPIKE-1431] - add easy way to disable InvocationResultLogger
> [DELTASPIKE-1444] - Create POJO and Record based Config
> [DELTASPIKE-1445] - Dynamic Config injection via a Supplier
>
> Improvement
> [DELTASPIKE-1426] - DeltaSpikeProxyFactory is slow on start
> [DELTASPIKE-1432] - Proxy class definition does not work
> [DELTASPIKE-1454] - Upgrade ASM to 9.3
>
> Task
> [DELTASPIKE-1452] - upgrade to apache-parent 25
>
>
>
> The staging repository can be found here:
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1058/
> <
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1058/
> >
>
> The source repo is located at:
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1058/org/apache/deltaspike/deltaspike/1.9.6/
> <
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1058/org/apache/deltaspike/deltaspike/1.9.6/
> >
> sha512 is
> ae2b2b183a54b9dff00d78a8f3a60fc87bde701599390a437970b218c208cb636d058fa596d0ab0ac3dfa9dd022c383c59f9ac6f5bab4e3bfe47db0a063af490
>
> Please VOTE
>
> [+1] yeah, ship it!
> [+0] meh, don't care
> [-1]  stop there is a ${showstopper}
>
> The VOTE is open for 72h.
>
> txs and LieGrue,
> strub
>
>
>

Re: your project website

[John D. Ament]

On Tue, Feb 2, 2021 at 8:18 AM Gavin McDonald  wrote:

> Hi Mark,
>
> Thanks for confirming and apologies for the late reply, I was looking at
> the instructions in your repo here:-
>
> https://github.com/apache/deltaspike/tree/master/site
>
> I assume that README.md is now out of date ?
>

No.  The asciidoc files are committed to that tree, then a manual step is
run to execute the maven build of this module that checks in to SVN the
generated site.


>
> Gav...
>
> On 2020/10/17 13:04:16, Mark Struberg  wrote:
> > Hi Gav!
> >
> > 
> https://svn.apache.org/repos/asf/deltaspike/site/trunk/content/documentation/
> <
> https://svn.apache.org/repos/asf/deltaspike/site/trunk/content/documentation/%3C/svn.scmPubUrl%3E
> >
> >
> > LieGrue,
> > strub
> >
> > > Am 28.09.2020 um 22:18 schrieb Gavin McDonald :
> > >
> > >
> > >
> > > On 2020/08/23 06:25:05, Mark Struberg 
> wrote:
> > >> +1 site is generated via maven and committed to svnpubsub.
> > >
> > > Can you explain more here please - where exactly to you commit to?
> > >
> > > Gav...
> > >
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>> Am 17.08.2020 um 20:57 schrieb Avinash Moram :
> > >>>
> > >>> Hi Andrew,
> > >>>
> > >>> It may have been a mistake, we do not use Apache CMS for our project.
> > >>>
> > >>> On Mon, Aug 17, 2020, 07:30 Andrew Wetmore 
> wrote:
> > >>>
> >  Hi:
> > 
> >  I wrote to you two weeks ago about your project website, but have
> not seen
> >  a response. Whom should I contact directly? I am trying to see
> whether your
> >  project still uses the Apache CMS and, if so, what your plans are to
> >  migrate off it.
> > 
> >  Thanks in advance for your help.
> > 
> >  Andrew
> > 
> >  On Tue, Aug 4, 2020 at 10:47 AM Andrew Wetmore 
> wrote:
> > 
> > > Hi:
> > >
> > > I am part of the Infrastructure team, and am writing to ask
> whether your
> > > project is still using the Apache CMS for your project website. As
> you
> > > know, the CMS is reaching end-of-life, and we need projects to
> move their
> > > websites onto a different option within the next few weeks.
> > >
> > > There are several alternatives available, including those listed
> on this
> > > page [1] on managing project websites. Infra is assembling a Wiki
> page
> >  [2]
> > > on migrating a website from the CMS, and is looking forward to
> helping
> > > projects with this transition.
> > >
> > > Please let me know whether your site is still on the Apache CMS
> and, if
> > > so, who will be the project point-of-contact with Infra for the
> >  migration.
> > >
> > > Thank you!
> > >
> > >
> > >
> > >
> > > [1] https://infra.apache.org/project-site.html
> > >
> > > [2]
> > >
> > 
> https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS
> > >
> > >
> > > --
> > > Andrew Wetmore
> > > Technical Writer-Editor
> > > Infra
> > > *Apache Software Foundation*
> > > andr...@apache.org
> > >
> > >
> > > <
> > 
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> >  Virus-free.
> > > www.avast.com
> > > <
> > 
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> > >
> > > <#m_189353851618530815_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > >
> > 
> > 
> >  --
> >  Andrew Wetmore
> >  Technical Writer-Editor
> >  Infra
> >  *Apache Software Foundation*
> >  andr...@apache.org
> > 
> > >>
> > >>
> >
> >
>

Re: [VOTE] Release Apache DeltaSpike-1.9.3

[John D. Ament]

+1

On Tue, Jan 28, 2020 at 10:17 AM Mark Struberg 
wrote:

> Hi!
>
> We are about to release Apache DeltaSpike-1.9.3.
> This release fixes a security issue for our ClientSideWindowHandler.
>
> The staging repo can be found here:
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1054
>
> The source release can be found here
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1054/org/apache/deltaspike/deltaspike/1.9.3/
> sha1
> 
> is 6c822278d187dee6f9167dbdf630feab633ec4f3
>
> Please VOTE
>
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
>
> The VOTE is open for 72h
>
> txs and LieGrue,
> strub
>
>

Re: [VOTE] Release Apache DeltaSpike 1.9.0

[John D. Ament]

Just looked, for DS-900 a file was added MockUserTransactionResolver.java
which does not have a proper header.  Probably not a big deal, but should
we fix before this release gets cut?

John

On Fri, Sep 7, 2018 at 8:04 AM Mark Struberg 
wrote:

> Good afternoon!
>
> I'd like to call a VOTE on releasing Apache DeltaSpike 1.9.0.
> This is the first version which requires Java8 as minimum Java version!
> Apart from that it introduces a new SPI for our configuration system and
> the ability to better deal with dynamic configuration values.
>
> The staging repo can be found here:
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1048/
>
> The source release zip is here:
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1048/org/apache/deltaspike/deltaspike/1.9.0/
> sha1
> :
> d83b8174b2eaac0071606428dfc9792f8d0c6ff5
>
> The following tickets got resolved since 1.8.2:
>
> Bug
>
> • [DELTASPIKE-900] - ResourceLocalTransactionStrategy not working
> with multiple EntityManagers
> • [DELTASPIKE-1198] - BeanManagerProvider.isActive() returns true
> after container shutdown
> • [DELTASPIKE-1324] - @Transactional annotation at method level
> doesn't override the one at class level any more
> • [DELTASPIKE-1327] - EnvironmentPropertyConfigSource is not
> scannable?
> • [DELTASPIKE-1336] - Regression: deltaspike-cdictrl-weld 1.8.0
> depends on weld-api 1.1.Final
> • [DELTASPIKE-1344] - deltaspike-cdictrl-owb has a transient
> runtime dependency on Shrinkwrap and Arquillian
> • [DELTASPIKE-1349] - isProxyableClass should ignore methods from
> Object.class
> • [DELTASPIKE-1351] - Java 10: IllegalArgumentException in
> ClassReader.
> • [DELTASPIKE-1353] - null values as arguments in messagebundles
> lead to exceptions
> New Feature
>
> • [DELTASPIKE-1280] - Automatic support for count* methods in
> EntityRepository
> • [DELTASPIKE-1315] - EntityRepository should offer an
> findOptionalBy
> • [DELTASPIKE-1321] - Upgrade DeltaSpike to require Java8 as
> minimum version
> • [DELTASPIKE-1335] - allow atomic access to n different
> TypedResolver values
> Improvement
>
> • [DELTASPIKE-1277] - Force refresh of cached config values
> • [DELTASPIKE-1322] - clean up ConfigResolver
> • [DELTASPIKE-1326] - Clean up Java 8 support in data module
> • [DELTASPIKE-1339] - Add support for dynamic interceptor binding,
> added via Extension
> • [DELTASPIKE-1340] - Delegate to JPA 2.2 getResultStream
> • [DELTASPIKE-1341] - [perf] QueryProcessorFactory could reuse
> QueryProcessors
> • [DELTASPIKE-1342] - Upgrade to ASM 6.1 for Java 10 support
> • [DELTASPIKE-1346] - ProjectStageProducer should log changed
> values only if the value changed
> Task
>
> • [DELTASPIKE-1308] - Documentation of user home properties
> mechanism
> • [DELTASPIKE-1325] - actively release ConfigSources and
> ConfigFilters if they implement Autocloseable
>
>
> Please VOTE:
>
> [+1] let's ship it!
> [+0] meh, don't care
> [-1] stop there is a ${showstopper}
>
>
> The VOTE is open for 72h
>
> txs and LieGrue,
> strub
>
>
>

Re: Build failed in Jenkins: DeltaSpike Deploy #2478

[John D. Ament]

Hi Mark

Could you add a valid license header to MockUserTransactionResolver.java or
replace it if it's not Apache licensed?

John

On Sat, Sep 8, 2018 at 9:54 AM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://builds.apache.org/job/DeltaSpike%20Deploy/2478/display/redirect>
>
> --
> [...truncated 555.07 KB...]
> [INFO] --- apache-rat-plugin:0.12:check (default) @
> deltaspike-jpa-module-api ---
> [INFO] Enabled default license matchers.
> [INFO] Will parse SCM ignores for exclusions...
> [INFO] Finished adding exclusions from SCM ignore files.
> [INFO] 61 implicit excludes (use -debug for more details).
> [INFO] Exclude: .idea/**/*
> [INFO] Exclude: readme/**/*
> [INFO] Exclude: **/*.log
> [INFO] Exclude: target/**
> [INFO] Exclude: test-ee7/target/**
> [INFO] Exclude: **/*.iml
> [INFO] Exclude: **/MANIFEST.MF
> [INFO] 25 resources included (use -debug for more details)
> [INFO] Rat check: Summary over all files. Unapproved: 0, unknown: 0,
> generated: 0, approved: 25 licenses.
> [INFO]
> [INFO] --- maven-bundle-plugin:3.5.0:cleanVersions (versions) @
> deltaspike-jpa-module-api ---
> [INFO]
> [INFO] --- maven-antrun-plugin:1.8:run (javadoc.resources) @
> deltaspike-jpa-module-api ---
> [WARNING] Parameter tasks is deprecated, use target instead
> [INFO] Executing tasks
>
> main:
> [INFO] Executed tasks
> [WARNING] Failed to getClass for
> org.apache.maven.plugins.source.SourceJarMojo
> [INFO]
> [INFO] <<< maven-source-plugin:3.0.0:jar (default-cli) < generate-sources
> @ deltaspike-jpa-module-api <<<
> [INFO]
> [INFO] --- maven-source-plugin:3.0.0:jar (default-cli) @
> deltaspike-jpa-module-api ---
> [INFO] Building jar: <
> https://builds.apache.org/job/DeltaSpike%20Deploy/ws/deltaspike/modules/jpa/api/target/deltaspike-jpa-module-api-1.9.1-SNAPSHOT-sources.jar
> >
> [INFO]
>
> [INFO]
> 
> [INFO] Building Apache DeltaSpike JPA-Module Impl 1.9.1-SNAPSHOT
> [INFO]
> 
> [INFO]
> [INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @
> deltaspike-jpa-module-impl ---
> [INFO]
> [INFO] --- apache-rat-plugin:0.12:check (default) @
> deltaspike-jpa-module-impl ---
> [INFO] Enabled default license matchers.
> [INFO] Will parse SCM ignores for exclusions...
> [INFO] Finished adding exclusions from SCM ignore files.
> [INFO] 61 implicit excludes (use -debug for more details).
> [INFO] Exclude: .idea/**/*
> [INFO] Exclude: readme/**/*
> [INFO] Exclude: **/*.log
> [INFO] Exclude: target/**
> [INFO] Exclude: test-ee7/target/**
> [INFO] Exclude: **/*.iml
> [INFO] Exclude: **/MANIFEST.MF
> [INFO] 163 resources included (use -debug for more details)
> [INFO] Rat check: Summary over all files. Unapproved: 1, unknown: 1,
> generated: 0, approved: 162 licenses.
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache DeltaSpike .. SUCCESS [
> 11.800 s]
> [INFO] Apache DeltaSpike Sources .. SUCCESS [
> 7.591 s]
> [INFO] Apache DeltaSpike CheckStyle-rules . SUCCESS [
> 11.445 s]
> [INFO] Apache DeltaSpike Parent ... SUCCESS [
> 13.079 s]
> [INFO] Apache DeltaSpike Test-Utils ... SUCCESS [
> 17.626 s]
> [INFO] Apache DeltaSpike Code Parent .. SUCCESS [
> 11.696 s]
> [INFO] Apache DeltaSpike Core . SUCCESS [
> 11.195 s]
> [INFO] Apache DeltaSpike Core-API . SUCCESS [01:16
> min]
> [INFO] Apache DeltaSpike Core-Implementation .. SUCCESS [01:01
> min]
> [INFO] Apache DeltaSpike ContainerControl parent .. SUCCESS [
> 11.625 s]
> [INFO] Apache DeltaSpike CDI ContainerControl API . SUCCESS [
> 16.230 s]
> [INFO] Apache DeltaSpike CDI ContainerControl TCK . SUCCESS [
> 16.969 s]
> [INFO] Apache DeltaSpike CDI OWB-ContainerControl . SUCCESS [
> 20.184 s]
> [INFO] Apache DeltaSpike CDI Weld-ContainerControl  SUCCESS [
> 16.282 s]
> [INFO] Apache DeltaSpike CDI OpenEJB-ContainerControl . SUCCESS [
> 24.234 s]
> [INFO] Apache DeltaSpike CDI Servlet-ContainerControl . SUCCESS [
> 19.821 s]
> [INFO] Apache DeltaSpike Modules .. SUCCESS [
> 11.960 s]
> [INFO] Apache DeltaSpike Proxy-Module . SUCCESS [
> 11.657 s]
> [INFO] Apache DeltaSpike Proxy-Module API . SUCCESS [
> 16.457 s]
> [INFO] Apache DeltaSpike Proxy-Module Impl ASM  SUCCESS [
> 21.125 s]
> [INFO] Apache DeltaSpike Security-Module .. SUCCESS [
> 10.707 s]
> [INFO] Apache DeltaSpike Security-Module API .. SUCCESS [
> 15.446 s]
> [INFO] Apache DeltaSpike Security-Module Impl . SUCCESS [
> 21.874 s]
> [INFO] Apache DeltaSpike JPA-Module 

Re: CI for Weld2 error

[John D. Ament]

What versions of weld 2 have you tried?

On Thu, Jun 7, 2018, 5:11 PM Mark Struberg 
wrote:

> Hi!
>
> I've tried to fix the CI for Weld2, but it seems that there is nothing
> wrong with DeltaSpike but a bug in Weld2 regarding alternatives in
> beans.xml if they get disabled via ProcessAnnotatedType#veto(). Weld 1 and
> Weld3 both work perfectly fine, as does various OWB versions.
>
> What to do?
>
> LieGrue,
> strub

[jira] [Resolved] (DELTASPIKE-1326) Clean up Java 8 support in data module

[John D. Ament (JIRA)]

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

John D. Ament resolved DELTASPIKE-1326.
---
Resolution: Fixed

> Clean up Java 8 support in data module
> --
>
> Key: DELTASPIKE-1326
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1326
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>    Reporter: John D. Ament
>    Assignee: John D. Ament
>Priority: Major
> Fix For: 1.9.0
>
>
> Data Module currently uses Java 8 Stream/Optional support.  We can clean up 
> this integration now that we're on Java 8 as a baseline.



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

[jira] [Created] (DELTASPIKE-1328) Add a Java 8 base repository

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1328:
-

 Summary: Add a Java 8 base repository
 Key: DELTASPIKE-1328
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1328
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Data-Module
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 1.9.0


Add a base repository, like {{EntityRepository}} but for Java 8 
{{Optional/Stream}} use cases.



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

[jira] [Commented] (DELTASPIKE-1177) [Deltaspike Data] Regoznize Entity Type by method returned type if @Repository.forEntity is set to default

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1177:
---

Hi [~tibor17] basically, the issue is that the entity object is known at the 
repository layer not the method layer 
[https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/meta/RepositoryMetadata.java]

 

For your use case to work, you need to move that entity, or duplicate it, at 
the method level.  

> [Deltaspike Data] Regoznize Entity Type by method returned type if 
> @Repository.forEntity is set to default
> --
>
> Key: DELTASPIKE-1177
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1177
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.7.0
>Reporter: Tibor Digana
>Priority: Major
>
> I want to use Deltaspike Data Repo as a Service because it is simplistic and 
> not DAO.
> Since of service operates over multiple entities I want the extension to 
> recognize the Entity type dynamically by method return type.
> Notice the example does not implement _EntityRepository_ and therefore the 
> only return type should be checked.
> {code}
> @Repository
> public interface Java8Repository {
>   MyEntity findByCourse(@NotNull String courseName);
>   AnotherEntity findByCustomer(@NotNull String customerName);
>   @Query("")
>   Object[] findMultipleEntityTypes(@NotNull String attribute);
> }
> {code}



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

[jira] [Updated] (DELTASPIKE-1177) [Deltaspike Data] Regoznize Entity Type by method returned type if @Repository.forEntity is set to default

[John D. Ament (JIRA)]

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

John D. Ament updated DELTASPIKE-1177:
--
Fix Version/s: (was: 1.9.0)

> [Deltaspike Data] Regoznize Entity Type by method returned type if 
> @Repository.forEntity is set to default
> --
>
> Key: DELTASPIKE-1177
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1177
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.7.0
>Reporter: Tibor Digana
>Priority: Major
>
> I want to use Deltaspike Data Repo as a Service because it is simplistic and 
> not DAO.
> Since of service operates over multiple entities I want the extension to 
> recognize the Entity type dynamically by method return type.
> Notice the example does not implement _EntityRepository_ and therefore the 
> only return type should be checked.
> {code}
> @Repository
> public interface Java8Repository {
>   MyEntity findByCourse(@NotNull String courseName);
>   AnotherEntity findByCustomer(@NotNull String customerName);
>   @Query("")
>   Object[] findMultipleEntityTypes(@NotNull String attribute);
> }
> {code}



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

[jira] [Updated] (DELTASPIKE-1177) [Deltaspike Data] Regoznize Entity Type by method returned type if @Repository.forEntity is set to default

[John D. Ament (JIRA)]

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

John D. Ament updated DELTASPIKE-1177:
--
Fix Version/s: 1.9.0

> [Deltaspike Data] Regoznize Entity Type by method returned type if 
> @Repository.forEntity is set to default
> --
>
> Key: DELTASPIKE-1177
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1177
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.7.0
>Reporter: Tibor Digana
>Priority: Major
> Fix For: 1.9.0
>
>
> I want to use Deltaspike Data Repo as a Service because it is simplistic and 
> not DAO.
> Since of service operates over multiple entities I want the extension to 
> recognize the Entity type dynamically by method return type.
> Notice the example does not implement _EntityRepository_ and therefore the 
> only return type should be checked.
> {code}
> @Repository
> public interface Java8Repository {
>   MyEntity findByCourse(@NotNull String courseName);
>   AnotherEntity findByCustomer(@NotNull String customerName);
>   @Query("")
>   Object[] findMultipleEntityTypes(@NotNull String attribute);
> }
> {code}



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

[jira] [Created] (DELTASPIKE-1326) Clean up Java 8 support in data module

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1326:
-

 Summary: Clean up Java 8 support in data module
 Key: DELTASPIKE-1326
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1326
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 1.9.0


Data Module currently uses Java 8 Stream/Optional support.  We can clean up 
this integration now that we're on Java 8 as a baseline.



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

[jira] [Updated] (DELTASPIKE-1324) @Transactional annotation at method level doesn't override the one at class level any more

[John D. Ament (JIRA)]

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

John D. Ament updated DELTASPIKE-1324:
--
Fix Version/s: 1.9.0

> @Transactional annotation at method level doesn't override the one at class 
> level any more
> --
>
> Key: DELTASPIKE-1324
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1324
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: Jens Berke
>Assignee: John D. Ament
>Priority: Major
> Fix For: 1.9.0
>
>
> Hi. The behaviour of @Transactional has changed with 1.8.1:
> Until version 1.8.0 @Transactional annotations at method level overrode those 
> at the class level. Like this:
> {code:java}
> @Transactional(readOnly = true)
> public class MyClass {
>     public void doSomethingReadOnly()
>     @Transactional
>     public void writeSomething(){code}
> This stopped working with version 1.8.1 because the @Transactional annotation 
> at method level seems to be ignored and the transaction for the method 
> remains read-only. The cause is probably the change introduced with 
> DELTASPIKE-940, where the following method was added to 
> org.apache.deltaspike.jpa.impl.transaction.TransactionStrategyHelper:
> {code:java}
> EntityManagerMetadata createEntityManagerMetadata(InvocationContext context)
> {
>     EntityManagerMetadata metadata = new EntityManagerMetadata();
>     metadata.readFrom(context.getMethod(), beanManager);
>     metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
>     return metadata;
> }{code}
> If first reads the data at method level and then at class level, which seems 
> to be the wrong order. Swapping these lines would restore the correct 
> behaviour:
> {code:java}
> metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
> metadata.readFrom(context.getMethod(), beanManager);{code}



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

[jira] [Commented] (DELTASPIKE-1324) @Transactional annotation at method level doesn't override the one at class level any more

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1324:
---

BTW is 1.9.0 an OK place to fix for you?  That release will target Java 8.

> @Transactional annotation at method level doesn't override the one at class 
> level any more
> --
>
> Key: DELTASPIKE-1324
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1324
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: Jens Berke
>Assignee: John D. Ament
>Priority: Major
> Fix For: 1.9.0
>
>
> Hi. The behaviour of @Transactional has changed with 1.8.1:
> Until version 1.8.0 @Transactional annotations at method level overrode those 
> at the class level. Like this:
> {code:java}
> @Transactional(readOnly = true)
> public class MyClass {
>     public void doSomethingReadOnly()
>     @Transactional
>     public void writeSomething(){code}
> This stopped working with version 1.8.1 because the @Transactional annotation 
> at method level seems to be ignored and the transaction for the method 
> remains read-only. The cause is probably the change introduced with 
> DELTASPIKE-940, where the following method was added to 
> org.apache.deltaspike.jpa.impl.transaction.TransactionStrategyHelper:
> {code:java}
> EntityManagerMetadata createEntityManagerMetadata(InvocationContext context)
> {
>     EntityManagerMetadata metadata = new EntityManagerMetadata();
>     metadata.readFrom(context.getMethod(), beanManager);
>     metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
>     return metadata;
> }{code}
> If first reads the data at method level and then at class level, which seems 
> to be the wrong order. Swapping these lines would restore the correct 
> behaviour:
> {code:java}
> metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
> metadata.readFrom(context.getMethod(), beanManager);{code}



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

[jira] [Assigned] (DELTASPIKE-1324) @Transactional annotation at method level doesn't override the one at class level any more

[John D. Ament (JIRA)]

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

John D. Ament reassigned DELTASPIKE-1324:
-

Assignee: John D. Ament

> @Transactional annotation at method level doesn't override the one at class 
> level any more
> --
>
> Key: DELTASPIKE-1324
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1324
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: Jens Berke
>Assignee: John D. Ament
>Priority: Major
>
> Hi. The behaviour of @Transactional has changed with 1.8.1:
> Until version 1.8.0 @Transactional annotations at method level overrode those 
> at the class level. Like this:
> {code:java}
> @Transactional(readOnly = true)
> public class MyClass {
>     public void doSomethingReadOnly()
>     @Transactional
>     public void writeSomething(){code}
> This stopped working with version 1.8.1 because the @Transactional annotation 
> at method level seems to be ignored and the transaction for the method 
> remains read-only. The cause is probably the change introduced with 
> DELTASPIKE-940, where the following method was added to 
> org.apache.deltaspike.jpa.impl.transaction.TransactionStrategyHelper:
> {code:java}
> EntityManagerMetadata createEntityManagerMetadata(InvocationContext context)
> {
>     EntityManagerMetadata metadata = new EntityManagerMetadata();
>     metadata.readFrom(context.getMethod(), beanManager);
>     metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
>     return metadata;
> }{code}
> If first reads the data at method level and then at class level, which seems 
> to be the wrong order. Swapping these lines would restore the correct 
> behaviour:
> {code:java}
> metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
> metadata.readFrom(context.getMethod(), beanManager);{code}



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

[jira] [Commented] (DELTASPIKE-1324) @Transactional annotation at method level doesn't override the one at class level any more

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1324:
---

Good catch, will fix.  Sorry about that!

> @Transactional annotation at method level doesn't override the one at class 
> level any more
> --
>
> Key: DELTASPIKE-1324
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1324
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: Jens Berke
>Priority: Major
>
> Hi. The behaviour of @Transactional has changed with 1.8.1:
> Until version 1.8.0 @Transactional annotations at method level overrode those 
> at the class level. Like this:
> {code:java}
> @Transactional(readOnly = true)
> public class MyClass {
>     public void doSomethingReadOnly()
>     @Transactional
>     public void writeSomething(){code}
> This stopped working with version 1.8.1 because the @Transactional annotation 
> at method level seems to be ignored and the transaction for the method 
> remains read-only. The cause is probably the change introduced with 
> DELTASPIKE-940, where the following method was added to 
> org.apache.deltaspike.jpa.impl.transaction.TransactionStrategyHelper:
> {code:java}
> EntityManagerMetadata createEntityManagerMetadata(InvocationContext context)
> {
>     EntityManagerMetadata metadata = new EntityManagerMetadata();
>     metadata.readFrom(context.getMethod(), beanManager);
>     metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
>     return metadata;
> }{code}
> If first reads the data at method level and then at class level, which seems 
> to be the wrong order. Swapping these lines would restore the correct 
> behaviour:
> {code:java}
> metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
> metadata.readFrom(context.getMethod(), beanManager);{code}



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

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 <rmannibu...@gmail.com>:
>
> > 2018-03-01 15:50 GMT+01:00 John D. Ament <johndam...@apache.org>:
> >
> > > 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 <cody.le...@gmail.com>
> 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" <strub...@yahoo.de.invalid>
> > > > 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-1316) add dynamic annotations feature, configurable via config

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1316:
---

Since this is an external code import, don't forget you must submit IP 
Clearance.

> add dynamic annotations feature, configurable via config
> 
>
> Key: DELTASPIKE-1316
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1316
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.8.1
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.8.2
>
>
> A long time ago I created a CDI Extension which can dynamically add 
> annotations to classes identified via a regular expression.
> The Extension is called InterDyn (Interceptor Dynamics) and is hosted at 
> github.
> [https://github.com/struberg/InterDyn]
>  
> I'm the sole originary author, so I have all the IP.
> The project actually consists of two parts: InterDyn for dynamic interceptors 
> and InvoMon, an invocation monitor interceptor. Kind of small man profiler.
> The InterDyn part is actually not restricted to add interceptor annotations, 
> but really could be anything. But adding interceptors obviously makes the 
> most sense. This should go into ds-core-impl. It doesn't even need any api 
> changes.
>  
> The 2nd part (the performance InvocationMonitor. Might become either part of 
> core, or a separate module.
>  
>  



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

Wrong license on proxy-module impl-asm

[John D. Ament]

The license for proxy-module's impl-asm binary JAR is generated
incorrectly.  Do we need to include a shaded ASM?  If we do, we need to
include the BSD-3-Clause license in the generated JAR.

John

Re: Build failed in Jenkins: DeltaSpike Deploy » Apache DeltaSpike Proxy-Module #2173

[John D. Ament]

The rat failure is pointing to the target directory on impl-asm5 ->
https://builds.apache.org/job/DeltaSpike%20Deploy/org.apache.deltaspike.modules$proxy-module-project/ws/target/rat.txt

Looks like the module got renamed, so its probably just a matter of
cleaning up the workspace.

John

On Thu, Jan 11, 2018 at 9:39 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> Hmm no idea. Proxy modules rat:check runs fine on localhost.
> However, it fails in the datamodule for files in the target dir, which
> should actually be excluded (deltaspike/modules/data/test-java8/target/)
>
> 2018-01-11 15:23 GMT+01:00 John D. Ament <johndam...@apache.org>:
>
> > Anyone looking at the build failures?
> >
> > On Thu, Jan 11, 2018 at 8:51 AM Apache Jenkins Server <
> > jenk...@builds.apache.org> wrote:
> >
> > > See <
> > > https://builds.apache.org/job/DeltaSpike%20Deploy/org.
> > apache.deltaspike.modules$proxy-module-project/2173/display/redirect
> > > >
> > >
> > > --
> > > [INFO]
> > > [INFO]
> > >
> 
> > > [INFO] Building Apache DeltaSpike Proxy-Module 1.8.2-SNAPSHOT
> > > [INFO]
> > >
> 
> > > [INFO]
> > > [INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @
> > > proxy-module-project ---
> > > [INFO] Deleting <
> > > https://builds.apache.org/job/DeltaSpike%20Deploy/org.
> > apache.deltaspike.modules$proxy-module-project/ws/target
> > > >
> > > [INFO]
> > > [INFO] --- apache-rat-plugin:0.12:check (default) @
> proxy-module-project
> > > ---
> > > [INFO] Enabled default license matchers.
> > > [INFO] Will parse SCM ignores for exclusions...
> > > [INFO] Finished adding exclusions from SCM ignore files.
> > > [INFO] 63 implicit excludes (use -debug for more details).
> > > [INFO] Exclude: .idea/**/*
> > > [INFO] Exclude: readme/**/*
> > > [INFO] Exclude: **/*.log
> > > [INFO] Exclude: target/**
> > > [INFO] Exclude: test-ee7/target/**
> > > [INFO] Exclude: **/*.iml
> > > [INFO] Exclude: **/MANIFEST.MF
> > > [INFO] 42 resources included (use -debug for more details)
> > > [INFO] Rat check: Summary over all files. Unapproved: 10, unknown: 10,
> > > generated: 0, approved: 6 licenses.
> > >
> >
>

Re: Build failed in Jenkins: DeltaSpike Deploy » Apache DeltaSpike Proxy-Module #2173

[John D. Ament]

Anyone looking at the build failures?

On Thu, Jan 11, 2018 at 8:51 AM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://builds.apache.org/job/DeltaSpike%20Deploy/org.apache.deltaspike.modules$proxy-module-project/2173/display/redirect
> >
>
> --
> [INFO]
> [INFO]
> 
> [INFO] Building Apache DeltaSpike Proxy-Module 1.8.2-SNAPSHOT
> [INFO]
> 
> [INFO]
> [INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @
> proxy-module-project ---
> [INFO] Deleting <
> https://builds.apache.org/job/DeltaSpike%20Deploy/org.apache.deltaspike.modules$proxy-module-project/ws/target
> >
> [INFO]
> [INFO] --- apache-rat-plugin:0.12:check (default) @ proxy-module-project
> ---
> [INFO] Enabled default license matchers.
> [INFO] Will parse SCM ignores for exclusions...
> [INFO] Finished adding exclusions from SCM ignore files.
> [INFO] 63 implicit excludes (use -debug for more details).
> [INFO] Exclude: .idea/**/*
> [INFO] Exclude: readme/**/*
> [INFO] Exclude: **/*.log
> [INFO] Exclude: target/**
> [INFO] Exclude: test-ee7/target/**
> [INFO] Exclude: **/*.iml
> [INFO] Exclude: **/MANIFEST.MF
> [INFO] 42 resources included (use -debug for more details)
> [INFO] Rat check: Summary over all files. Unapproved: 10, unknown: 10,
> generated: 0, approved: 6 licenses.
>

Re: provide a default Scheduler which is not using quartz as default?

[John D. Ament]

On Fri, Jan 5, 2018 at 2:00 PM John D. Ament <johndam...@apache.org> wrote:

> On Fri, Jan 5, 2018 at 1:21 PM Mark Struberg <strub...@yahoo.de.invalid>
> wrote:
>
>> > Shouldnąt we just disable the update check in our quartz configuration?
>>
>> Well there is a flag to disable this behaviour, but a.) it's hard to set
>> (requires -D) and it doesn't disable 100%.
>> The code still does some http calls out :/
>>
>
> You can disable it programmatically.  I've done wireshark checks, there is
> no other HTTP calls made out.  Here's a quick patch that does it:
>
>
> https://github.com/johnament/deltaspike/commit/5a4fec98ff3f8f6ed6b54c36332bb8621cd3b09d
>

Here's a more interesting thing, looks like for Quartz 2.3 they changed
from an opt out to an opt in -
https://github.com/quartz-scheduler/quartz/commit/dfe1e5a3cc248e2a46a6ea55567aaa6dc8e15ca5

John


>
>
> John
>
>
>>
>> That's really bad, and the terracotta community (or rather the firm
>> behind it) declined to disable it by default since 2010 :/
>>
>> @Tomas, yes there is additional effort to maintain it. But imo it's worth
>> it.
>>
>> @Romain, John the question for me is rather where we do like to keep the
>> code.
>> Either here in DeltaSpike or at geronimo? The reason is that we might
>> also later use this in other projects (TomEE) as well.
>>
>> For now I'd just start to play a bit with it over here and then we can
>> still move it around later.
>>
>> LieGrue,
>> strub
>>
>>
>> > Am 05.01.2018 um 17:44 schrieb Arne Limburg <
>> arne.limb...@openknowledge.de>:
>> >
>> > Hi Mark,
>> >
>> > Shouldnąt we just disable the update check in our quartz configuration?
>> >
>> > Cheers,
>> > Arne
>> >
>> >
>> > Am 05.01.18 17:39 schrieb "Mark Struberg" unter
>> > <strub...@yahoo.de.INVALID>:
>> >
>> >> Hi folks!
>> >> Since I've now had a few complaints about Quartz 'phoning home'
>> (totally
>> >> useless update check), I'm really inclined to just kick out quartz and
>> >> implement the Scheduler ourselves.
>> >> Implementing a proper Scheduler is not that complicated anyway, so do
>> we
>> >> like to roll this ourselves?
>> >> Or do you think I underestimate the effort?
>> >>
>> >> LieGrue,strub
>> >
>>
>>

Re: provide a default Scheduler which is not using quartz as default?

[John D. Ament]

On Fri, Jan 5, 2018 at 1:21 PM Mark Struberg 
wrote:

> > Shouldnąt we just disable the update check in our quartz configuration?
>
> Well there is a flag to disable this behaviour, but a.) it's hard to set
> (requires -D) and it doesn't disable 100%.
> The code still does some http calls out :/
>

You can disable it programmatically.  I've done wireshark checks, there is
no other HTTP calls made out.  Here's a quick patch that does it:

https://github.com/johnament/deltaspike/commit/5a4fec98ff3f8f6ed6b54c36332bb8621cd3b09d

John


>
> That's really bad, and the terracotta community (or rather the firm behind
> it) declined to disable it by default since 2010 :/
>
> @Tomas, yes there is additional effort to maintain it. But imo it's worth
> it.
>
> @Romain, John the question for me is rather where we do like to keep the
> code.
> Either here in DeltaSpike or at geronimo? The reason is that we might also
> later use this in other projects (TomEE) as well.
>
> For now I'd just start to play a bit with it over here and then we can
> still move it around later.
>
> LieGrue,
> strub
>
>
> > Am 05.01.2018 um 17:44 schrieb Arne Limburg <
> arne.limb...@openknowledge.de>:
> >
> > Hi Mark,
> >
> > Shouldnąt we just disable the update check in our quartz configuration?
> >
> > Cheers,
> > Arne
> >
> >
> > Am 05.01.18 17:39 schrieb "Mark Struberg" unter
> > :
> >
> >> Hi folks!
> >> Since I've now had a few complaints about Quartz 'phoning home' (totally
> >> useless update check), I'm really inclined to just kick out quartz and
> >> implement the Scheduler ourselves.
> >> Implementing a proper Scheduler is not that complicated anyway, so do we
> >> like to roll this ourselves?
> >> Or do you think I underestimate the effort?
> >>
> >> LieGrue,strub
> >
>
>

Re: provide a default Scheduler which is not using quartz as default?

[John D. Ament]

-0

There's already so many solutions around scheduling.  It makes sense to
disable it out of the box using configuration, as well as documenting it
for users.  I'm not sure how well maintained quartz is.

John

On Fri, Jan 5, 2018 at 11:39 AM Mark Struberg 
wrote:

> Hi folks!
> Since I've now had a few complaints about Quartz 'phoning home' (totally
> useless update check), I'm really inclined to just kick out quartz and
> implement the Scheduler ourselves.
> Implementing a proper Scheduler is not that complicated anyway, so do we
> like to roll this ourselves?
> Or do you think I underestimate the effort?
>
> LieGrue,strub
>

[jira] [Commented] (DELTASPIKE-1311) Allow Excluded Repositories

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1311:
---

[~gpetracek] thanks for the reminder.  We already support Deactivatable on 
repositories - 
https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/RepositoryExtension.java#L87

I've got a response I'll share on user list that the person can use immediately.

> Allow Excluded Repositories
> ---
>
> Key: DELTASPIKE-1311
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1311
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.8.1
>    Reporter: John D. Ament
>    Assignee: John D. Ament
> Fix For: 1.8.2
>
>
> When a repository is discovered, if it has @Exclude on it, then don't include 
> it as a possible repository bean.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1311) Allow Excluded Repositories

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1311:
---

[~romain.manni-bucau] no this is a common use case (the on list reporter 
mentions CDI 2.0).  Vetoed will work, I just worry about not having a solution 
for EE6 use cases.  The problem is that the repository is not an actual bean, 
but we register one, so we want to use {{@Vetoed}} or similar to indicate it 
should not have a repository bean registered.

[~gpetracek] [~tandraschko] what about the idea of also introducing a config 
property, e.g. {{com.mycompany.repository.RepositoryClass.vetoed=true}} to see 
if it should be vetoed?  Considered {{false}} by default.

> Allow Excluded Repositories
> ---
>
> Key: DELTASPIKE-1311
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1311
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.8.1
>    Reporter: John D. Ament
>    Assignee: John D. Ament
> Fix For: 1.8.2
>
>
> When a repository is discovered, if it has @Exclude on it, then don't include 
> it as a possible repository bean.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1311) Allow Excluded Repositories

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1311:
---

It probably works well as a minimal slice.  We can iterate over it as we gain 
user input on the enhancement.  No reason to boil the ocean.

> Allow Excluded Repositories
> ---
>
> Key: DELTASPIKE-1311
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1311
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.8.1
>    Reporter: John D. Ament
>    Assignee: John D. Ament
> Fix For: 1.8.2
>
>
> When a repository is discovered, if it has @Exclude on it, then don't include 
> it as a possible repository bean.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (DELTASPIKE-1311) Allow Excluded Repositories

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1311:
-

 Summary: Allow Excluded Repositories
 Key: DELTASPIKE-1311
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1311
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Affects Versions: 1.8.1
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 1.8.2


When a repository is discovered, if it has @Exclude on it, then don't include 
it as a possible repository bean.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1299) Order by items are applied in alphabetic order

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1299:
---

[~tandraschko] I don't know what this ticket has to do with ASM upgrade?

> Order by items are applied in alphabetic order
> --
>
> Key: DELTASPIKE-1299
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1299
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.0
>Reporter: Moritz Becker
> Fix For: 1.8.2
>
>
> DeltaSpike data applies the order bys in parsed methods in alphabetic order 
> which leads to semantically incorrect queries.
> For example, the method {{findAllOrderByNameAscIdDesc}} produces the 
> following query:
> {code:sql}
> select * from ... order by id desc, name asc
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] release Apache DeltaSpike-1.8.1

[John D. Ament]

I didn't see an answer on this, but I'm fine with releasing as is
considering the contents so here's my +1.

On Sat, Dec 30, 2017 at 11:59 AM John D. Ament <johndam...@apache.org>
wrote:

> Where did it break jenkins?
>
>
> https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike_TomEE/1220/
>  passed
>
> https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike_Payara_4.1.x/48/
>  passed
>
> https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike_Wildfly_10.1/63/
>  passed
>
> In fact, I asked the contributor to rebase to ensure that CI was passing
> since CI was failing.
>
> John
>
>
> On Sat, Dec 30, 2017 at 11:48 AM Mark Struberg <strub...@yahoo.de.invalid>
> wrote:
>
>> I've moved 1299 to 1.8.2. It did break Jenkins, so we should look at it
>> again and take time as needed.
>> But we should really get this release out of the door asap as it contains
>> important security fixes.
>>
>> Happy to run an 1.8.2 release in the next weeks.
>>
>> LieGrue,
>> strub
>>
>> > Am 30.12.2017 um 17:43 schrieb John D. Ament <johndam...@apache.org>:
>> >
>> > Hmmm looks like we crossed wires.  Can you rerun with current master?  I
>> > want to ensure that 1299 is included.
>> >
>> > On Sat, Dec 30, 2017 at 11:39 AM Mark Struberg
>> <strub...@yahoo.de.invalid>
>> > wrote:
>> >
>> >> Hi folks!
>> >>
>> >> I did run the necessary steps for releasing DeltaSpike-1.8.1
>> >>
>> >> The following bugs and improvements got implemented:
>> >>
>> >> Bug
>> >>
>> >>• [DELTASPIKE-1252] - data-documentation missing Optional return
>> >> value
>> >>• [DELTASPIKE-1271] - [perf] cache Transactional
>> >>• [DELTASPIKE-1272] - ConfigResolver asList breaks if no value
>> is
>> >> found
>> >>• [DELTASPIKE-1275] - Build fails on Linux because Testclass
>> >> filenames are to long
>> >>• [DELTASPIKE-1278] - PropertyFileConfig does not respect
>> optional
>> >> on external resources
>> >>• [DELTASPIKE-1281] - Deltaspike does not pass BeanManager to
>> >> persistenf factory config using "javax.persistence.bean.manager"
>> >>• [DELTASPIKE-1287] - asList() getValue() fails with a NPE if no
>> >> configured value exists
>> >>• [DELTASPIKE-1288] - Default values are not interpolated
>> >>• [DELTASPIKE-1294] - Secured Stereotypes are not applied to
>> >> inherited methods
>> >>• [DELTASPIKE-1296] - PropertyFileConfig doesn't work with
>> >> internal extensions
>> >>• [DELTASPIKE-1302] - ThreadPoolManager: ExecutorService map is
>> >> always empty
>> >>• [DELTASPIKE-1303] - @Configuration proxies should support List
>> >> without converters
>> >>• [DELTASPIKE-1305] - Multiple ds:windowId leads to multiple
>> >> redirects
>> >>• [DELTASPIKE-1306] - IE sometimes doesn't set window.name
>> >> correctly
>> >>• [DELTASPIKE-1307] - Deltaspike JSF: XSS
>> WindowIdHtmlRenderer.java
>> >> Improvement
>> >>
>> >>• [DELTASPIKE-940] - @Transactional and @EntityManagerConfig
>> each
>> >> use a different method to resolve EntityManagers
>> >>• [DELTASPIKE-1070] - Refactor RepositoryComponent/s
>> >>• [DELTASPIKE-1258] - skip flush with one EntityManager
>> >>• [DELTASPIKE-1267] - Remove second factory mechanism of
>> >> QueryBuilder's
>> >>• [DELTASPIKE-1268] - QueryProcessorFactory should be a bean
>> >>• [DELTASPIKE-1269] - [perf] Cache singleResultType per method
>> >>• [DELTASPIKE-1270] - [perf] cache requiresTransaction per
>> method
>> >>• [DELTASPIKE-1274] - Refactor proxy-module / improve
>> performance
>> >>• [DELTASPIKE-1279] - SimpleSecurityViolation needs
>> equals/hashcode
>> >>• [DELTASPIKE-1283] - Placeholders not supported for defaults
>> >>• [DELTASPIKE-1289] - GlobalInterceptorExtension could reuse
>> >> BeanManager
>> >>• [DELTASPIKE-1293] - CDI qualifiers support for JSF converters
>> >>• [DELTASPIKE-1304] - Make CdiTestRunner use "flat" deployment
>> on
>> >> Weld by d

Re: [VOTE] release Apache DeltaSpike-1.8.1

[John D. Ament]

Where did it break jenkins?

https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike_TomEE/1220/
 passed
https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike_Payara_4.1.x/48/
 passed
https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike_Wildfly_10.1/63/
 passed

In fact, I asked the contributor to rebase to ensure that CI was passing
since CI was failing.

John

On Sat, Dec 30, 2017 at 11:48 AM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> I've moved 1299 to 1.8.2. It did break Jenkins, so we should look at it
> again and take time as needed.
> But we should really get this release out of the door asap as it contains
> important security fixes.
>
> Happy to run an 1.8.2 release in the next weeks.
>
> LieGrue,
> strub
>
> > Am 30.12.2017 um 17:43 schrieb John D. Ament <johndam...@apache.org>:
> >
> > Hmmm looks like we crossed wires.  Can you rerun with current master?  I
> > want to ensure that 1299 is included.
> >
> > On Sat, Dec 30, 2017 at 11:39 AM Mark Struberg <strub...@yahoo.de.invalid
> >
> > wrote:
> >
> >> Hi folks!
> >>
> >> I did run the necessary steps for releasing DeltaSpike-1.8.1
> >>
> >> The following bugs and improvements got implemented:
> >>
> >> Bug
> >>
> >>• [DELTASPIKE-1252] - data-documentation missing Optional return
> >> value
> >>• [DELTASPIKE-1271] - [perf] cache Transactional
> >>• [DELTASPIKE-1272] - ConfigResolver asList breaks if no value is
> >> found
> >>• [DELTASPIKE-1275] - Build fails on Linux because Testclass
> >> filenames are to long
> >>• [DELTASPIKE-1278] - PropertyFileConfig does not respect
> optional
> >> on external resources
> >>• [DELTASPIKE-1281] - Deltaspike does not pass BeanManager to
> >> persistenf factory config using "javax.persistence.bean.manager"
> >>• [DELTASPIKE-1287] - asList() getValue() fails with a NPE if no
> >> configured value exists
> >>• [DELTASPIKE-1288] - Default values are not interpolated
> >>• [DELTASPIKE-1294] - Secured Stereotypes are not applied to
> >> inherited methods
> >>• [DELTASPIKE-1296] - PropertyFileConfig doesn't work with
> >> internal extensions
> >>• [DELTASPIKE-1302] - ThreadPoolManager: ExecutorService map is
> >> always empty
> >>• [DELTASPIKE-1303] - @Configuration proxies should support List
> >> without converters
> >>• [DELTASPIKE-1305] - Multiple ds:windowId leads to multiple
> >> redirects
> >>• [DELTASPIKE-1306] - IE sometimes doesn't set window.name
> >> correctly
> >>• [DELTASPIKE-1307] - Deltaspike JSF: XSS
> WindowIdHtmlRenderer.java
> >> Improvement
> >>
> >>• [DELTASPIKE-940] - @Transactional and @EntityManagerConfig each
> >> use a different method to resolve EntityManagers
> >>• [DELTASPIKE-1070] - Refactor RepositoryComponent/s
> >>• [DELTASPIKE-1258] - skip flush with one EntityManager
> >>• [DELTASPIKE-1267] - Remove second factory mechanism of
> >> QueryBuilder's
> >>• [DELTASPIKE-1268] - QueryProcessorFactory should be a bean
> >>• [DELTASPIKE-1269] - [perf] Cache singleResultType per method
> >>• [DELTASPIKE-1270] - [perf] cache requiresTransaction per method
> >>• [DELTASPIKE-1274] - Refactor proxy-module / improve performance
> >>• [DELTASPIKE-1279] - SimpleSecurityViolation needs
> equals/hashcode
> >>• [DELTASPIKE-1283] - Placeholders not supported for defaults
> >>• [DELTASPIKE-1289] - GlobalInterceptorExtension could reuse
> >> BeanManager
> >>• [DELTASPIKE-1293] - CDI qualifiers support for JSF converters
> >>• [DELTASPIKE-1304] - Make CdiTestRunner use "flat" deployment on
> >> Weld by default
> >> Task
> >>
> >>• [DELTASPIKE-1259] - upgraded version numbers
> >>• [DELTASPIKE-1297] - add test with a customized
> DynamicMockManager
> >>• [DELTASPIKE-1298] - document customization of a
> >> DynamicMockManager
> >> Test
> >>
> >>• [DELTASPIKE-1273] - Test against OWB 2
> >>
> >>
> >>
> >> The staging repo is
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1046/
> >>
> >> The source release can be found at
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1046/org/apache/deltaspike/deltaspike/1.8.1/
> >> sha1
> >> <
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1046/org/apache/deltaspike/deltaspike/1.8.1/sha1
> >
> >> is 4d7db712629261a92e6dcddfdcb7a446015bf432
> >>
> >>
> >> Please VOTE:
> >>
> >> [+1] yea, let's ship it
> >> [+0] meh, don't care
> >> [-1] yikes, stop because ${showstopper}
> >>
> >> The VOTE is open for 72h.
> >>
> >>
> >> Here is my own +1
> >>
> >> txs and LieGrue,
> >> strub
>
>

Re: [VOTE] release Apache DeltaSpike-1.8.1

[John D. Ament]

Hmmm looks like we crossed wires.  Can you rerun with current master?  I
want to ensure that 1299 is included.

On Sat, Dec 30, 2017 at 11:39 AM Mark Struberg 
wrote:

> Hi folks!
>
> I did run the necessary steps for releasing DeltaSpike-1.8.1
>
> The following bugs and improvements got implemented:
>
> Bug
>
> • [DELTASPIKE-1252] - data-documentation missing Optional return
> value
> • [DELTASPIKE-1271] - [perf] cache Transactional
> • [DELTASPIKE-1272] - ConfigResolver asList breaks if no value is
> found
> • [DELTASPIKE-1275] - Build fails on Linux because Testclass
> filenames are to long
> • [DELTASPIKE-1278] - PropertyFileConfig does not respect optional
> on external resources
> • [DELTASPIKE-1281] - Deltaspike does not pass BeanManager to
> persistenf factory config using "javax.persistence.bean.manager"
> • [DELTASPIKE-1287] - asList() getValue() fails with a NPE if no
> configured value exists
> • [DELTASPIKE-1288] - Default values are not interpolated
> • [DELTASPIKE-1294] - Secured Stereotypes are not applied to
> inherited methods
> • [DELTASPIKE-1296] - PropertyFileConfig doesn't work with
> internal extensions
> • [DELTASPIKE-1302] - ThreadPoolManager: ExecutorService map is
> always empty
> • [DELTASPIKE-1303] - @Configuration proxies should support List
> without converters
> • [DELTASPIKE-1305] - Multiple ds:windowId leads to multiple
> redirects
> • [DELTASPIKE-1306] - IE sometimes doesn't set window.name
> correctly
> • [DELTASPIKE-1307] - Deltaspike JSF: XSS WindowIdHtmlRenderer.java
> Improvement
>
> • [DELTASPIKE-940] - @Transactional and @EntityManagerConfig each
> use a different method to resolve EntityManagers
> • [DELTASPIKE-1070] - Refactor RepositoryComponent/s
> • [DELTASPIKE-1258] - skip flush with one EntityManager
> • [DELTASPIKE-1267] - Remove second factory mechanism of
> QueryBuilder's
> • [DELTASPIKE-1268] - QueryProcessorFactory should be a bean
> • [DELTASPIKE-1269] - [perf] Cache singleResultType per method
> • [DELTASPIKE-1270] - [perf] cache requiresTransaction per method
> • [DELTASPIKE-1274] - Refactor proxy-module / improve performance
> • [DELTASPIKE-1279] - SimpleSecurityViolation needs equals/hashcode
> • [DELTASPIKE-1283] - Placeholders not supported for defaults
> • [DELTASPIKE-1289] - GlobalInterceptorExtension could reuse
> BeanManager
> • [DELTASPIKE-1293] - CDI qualifiers support for JSF converters
> • [DELTASPIKE-1304] - Make CdiTestRunner use "flat" deployment on
> Weld by default
> Task
>
> • [DELTASPIKE-1259] - upgraded version numbers
> • [DELTASPIKE-1297] - add test with a customized DynamicMockManager
> • [DELTASPIKE-1298] - document customization of a
> DynamicMockManager
> Test
>
> • [DELTASPIKE-1273] - Test against OWB 2
>
>
>
> The staging repo is
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1046/
>
> The source release can be found at
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1046/org/apache/deltaspike/deltaspike/1.8.1/
> sha1
> 
> is 4d7db712629261a92e6dcddfdcb7a446015bf432
>
>
> Please VOTE:
>
> [+1] yea, let's ship it
> [+0] meh, don't care
> [-1] yikes, stop because ${showstopper}
>
> The VOTE is open for 72h.
>
>
> Here is my own +1
>
> txs and LieGrue,
> strub

[jira] [Resolved] (DELTASPIKE-1299) Order by items are applied in alphabetic order

[John D. Ament (JIRA)]

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

John D. Ament resolved DELTASPIKE-1299.
---
Resolution: Fixed

Thanks for the patch, applied!

> Order by items are applied in alphabetic order
> --
>
> Key: DELTASPIKE-1299
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1299
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.0
>Reporter: Moritz Becker
> Fix For: 1.8.1
>
>
> DeltaSpike data applies the order bys in parsed methods in alphabetic order 
> which leads to semantically incorrect queries.
> For example, the method {{findAllOrderByNameAscIdDesc}} produces the 
> following query:
> {code:sql}
> select * from ... order by id desc, name asc
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (DELTASPIKE-1299) Order by items are applied in alphabetic order

[John D. Ament (JIRA)]

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

John D. Ament updated DELTASPIKE-1299:
--
Fix Version/s: 1.8.1

> Order by items are applied in alphabetic order
> --
>
> Key: DELTASPIKE-1299
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1299
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.0
>Reporter: Moritz Becker
> Fix For: 1.8.1
>
>
> DeltaSpike data applies the order bys in parsed methods in alphabetic order 
> which leads to semantically incorrect queries.
> For example, the method {{findAllOrderByNameAscIdDesc}} produces the 
> following query:
> {code:sql}
> select * from ... order by id desc, name asc
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (DELTASPIKE-1262) Remove CdiContainer control

[John D. Ament (JIRA)]

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

John D. Ament reopened DELTASPIKE-1262:
---

[~struberg] This is for a planned 2.0 (who knows when it will happen).  You can 
still accomplish what you're talking about with SeContainer though, but the 
question is why would you?  
https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/se/SeContainerInitializer.java#L259-L268

> Remove CdiContainer control
> ---
>
> Key: DELTASPIKE-1262
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1262
> Project: DeltaSpike
>  Issue Type: Improvement
>        Reporter: John D. Ament
> Fix For: 2.0
>
>
> The bootstrap mechanisms for CDI are present in CDI 2.0.  We no longer need 
> this functionality.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-940:
--

Yep, simply forgot to upate JIRA!

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>    Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.1
>
> Attachments: ds940.patch
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: CI for DeltaSpike?

[John D. Ament]

I'm not sure if its the cause or not, but I see this when running the
failing tests on wildfly 10.1

10:31:46,124 WARN  [org.jboss.modules] (Weld Thread Pool -- 6) Failed to
define class
org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator$1 in
Module "deployment.nav-event-uc001.war:main" from Service Module Loader:
java.lang.NoClassDefFoundError: Failed to link
org/apache/deltaspike/proxy/impl/AsmDeltaSpikeProxyClassGenerator$1 (Module
"deployment.nav-event-uc001.war:main" from Service Module Loader):
org/objectweb/asm/ClassVisitor
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:446)
at
org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274)
at
org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78)
at org.jboss.modules.Module.loadModuleClass(Module.java:606)
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
at
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
at
org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68)
at
org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadClass(AnnotatedTypeLoader.java:65)
at
org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType(AnnotatedTypeLoader.java:60)
at
org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotatedType(FastAnnotatedTypeLoader.java:96)
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:98)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:65)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:62)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)

10:31:46,125 INFO  [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 1)
WELD-000119: Not generating any bean definitions from
org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator because
of underlying class loading error: Type org.objectweb.asm.ClassVisitor from
[Module "deployment.nav-event-uc001.war:main" from Service Module Loader]
not found.  If this is unexpected, enable DEBUG logging to see the full
error.
10:31:46,126 INFO  [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 6)
WELD-000119: Not generating any bean definitions from
org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator$1 because
of underlying class loading error: Type Failed to link
org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator$1 (Module
"deployment.nav-event-uc001.war:main" from Service Module Loader):
org.objectweb.asm.ClassVisitor not found.  If this is unexpected, enable
DEBUG logging to see the full error.

If that's the case, then it should be as simple as adding the missing
libraries.

On Fri, Dec 1, 2017 at 6:52 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> @matej
> You also reopened a issue that i created.
> I'm currently in brasil, so i dont have time to look at it.
> I removed this call as its actually not required and the wrapping in
> PrimeFaces works fine. Not sure why it breaks navigation but we can simple
> revert it for this release.
>
> Am Freitag, 1. Dezember 2017 schrieb Gerhard Petracek :
>
> > hi matej,
> >
> > imo the main point here is that in the past we received too many wrong
> > failures and almost no commit really broke the backward compatibility.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2017-12-01 11:49 GMT+01:00 Matej Novotny  > >:
> >
> > > Hi Gerhard,
> > >
> > > > i'm not sure if others are still following it. at the time i did the
> > > > releases, it was a mandatory step.
> > >
> > > Yes, I hope nobody releases without actually testing it at all.
> > > But this check IMO comes too late - there are multiple "fixes" present,
> > > where the author apparently didn't even execute the tests.
> > > Checking this before release means you bump into problems with issues
> > > which were "fixed" six months ago.
> > > Hence I am suggesting whether we shouldn't 

Re: CI for DeltaSpike?

[John D. Ament]

The main issues are that we're all independent contributors to DS, all with
the same level of rights to write to the repo.  We typically don't do PRs.
We actually do have a PR job in Jenkins for those external parties that do
raise PRs ->
https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike-PR-Builder/

As for the state of the builds, agreed that it's a pain point.  We have too
many permutations of our tests, and it's pretty hard to test all of them
locally.  We need to come up with either a definitive short list of tests
to always run, or figure out a way to better modularize DeltaSpike to limit
the impacts.

I do still think it's worthwhile to re envision our pipeline to have better
control over what tests are run and how they are managed.

John

On Wed, Nov 29, 2017 at 10:47 AM Matej Novotny  wrote:

> Hello
>
> I wanted to bring up a topic of CI (Continuous Irritation - eh, I meant
> Integration OFC) and DeltaSpike.
> Apparently, there is no such thing now and even while some CI jobs exist
> (where are they, anyway?), nobody really pays attention to them.
> I mean those for Weld ones must have been failing for few months and yet
> the JIRAs causing that were happily marked as Resolved.
> Meaning whoever fixed that probably only ran smoke tests with OWB.
>
> Today I noticed there is going to be a release soon and so I quikly went
> to check how the build/tests fare with Weld profiles.
> Turned out to be a disaster. So I then have to spend considerable time
> backtracking the changes and figuring out the actual problem.
> And it's not the first time this happened either.
>
> Therefore I wanted to bring up the topic of CI to avoid this in the
> future. The ideal scenario is sending PRs and having them checked *before*
> merging - obviously not an option here.
> The GH repo is but a mirror (something we have to stick to I presume)
> which makes it more complex, but still, it should be possible to set up a
> Travis build on GH master which will execute after every sync.
> That way the failures would be readily visible (via the travis status
> "button").
> In order to discover most problems there is no need for a complete test
> matrix, it would do to just have two version of OWB and Weld without EE
> container (with just the Arq. one).
>
>
> A penny for your thoughts?
>
>
> Regards
> Matej
>

[jira] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-940:
--

got it.  The issue looks pretty straight forward, should be a simple fix.

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>    Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.1
>
> Attachments: ds940.patch
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Build failed in Jenkins: DeltaSpike Deploy #2115

[John D. Ament]

Looks like this was the one job where that profile was still working right,
I tweaked the job config and restarted it

:-(

If there are any other java 8 jobs that are broken now, just add
-Pjava8.tests to the maven config.

John

On Thu, Nov 30, 2017 at 10:15 AM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://builds.apache.org/job/DeltaSpike%20Deploy/2115/display/redirect?page=changes
> >
>
> Changes:
>
> [john.d.ament] Disabling java 8 tests as recent jenkins changes make this
> profile
>
> --
> [...truncated 966.43 KB...]
> [INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @
> data-module-project ---
> [INFO] Deleting <
> https://builds.apache.org/job/DeltaSpike%20Deploy/ws/deltaspike/modules/data/target
> >
> [INFO]
> [INFO] --- apache-rat-plugin:0.12:check (default) @ data-module-project ---
> [INFO] Enabled default license matchers.
> [INFO] Will parse SCM ignores for exclusions...
> [INFO] Finished adding exclusions from SCM ignore files.
> [INFO] 63 implicit excludes (use -debug for more details).
> [INFO] Exclude: .idea/**/*
> [INFO] Exclude: readme/**/*
> [INFO] Exclude: **/*.log
> [INFO] Exclude: target/**
> [INFO] Exclude: test-ee7/target/**
> [INFO] Exclude: **/*.iml
> [INFO] Exclude: **/MANIFEST.MF
> [INFO] 72 resources included (use -debug for more details)
> [INFO] Rat check: Summary over all files. Unapproved: 6, unknown: 6,
> generated: 0, approved: 46 licenses.
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache DeltaSpike .. SUCCESS [
> 9.930 s]
> [INFO] Apache DeltaSpike Sources .. SUCCESS [
> 7.132 s]
> [INFO] Apache DeltaSpike CheckStyle-rules . SUCCESS [
> 21.050 s]
> [INFO] Apache DeltaSpike Parent ... SUCCESS [
> 10.937 s]
> [INFO] Apache DeltaSpike Test-Utils ... SUCCESS [
> 15.391 s]
> [INFO] Apache DeltaSpike Code Parent .. SUCCESS [
> 10.614 s]
> [INFO] Apache DeltaSpike Core . SUCCESS [
> 9.761 s]
> [INFO] Apache DeltaSpike Core-API . SUCCESS [01:14
> min]
> [INFO] Apache DeltaSpike Core-Implementation .. SUCCESS [
> 52.458 s]
> [INFO] Apache DeltaSpike ContainerControl parent .. SUCCESS [
> 9.824 s]
> [INFO] Apache DeltaSpike CDI ContainerControl API . SUCCESS [
> 14.664 s]
> [INFO] Apache DeltaSpike CDI ContainerControl TCK . SUCCESS [
> 14.598 s]
> [INFO] Apache DeltaSpike CDI OWB-ContainerControl . SUCCESS [
> 16.990 s]
> [INFO] Apache DeltaSpike CDI Weld-ContainerControl  SUCCESS [
> 14.853 s]
> [INFO] Apache DeltaSpike CDI OpenEJB-ContainerControl . SUCCESS [
> 20.835 s]
> [INFO] Apache DeltaSpike CDI Servlet-ContainerControl . SUCCESS [
> 17.783 s]
> [INFO] Apache DeltaSpike Modules .. SUCCESS [
> 9.985 s]
> [INFO] Apache DeltaSpike Proxy-Module . SUCCESS [
> 9.963 s]
> [INFO] Apache DeltaSpike Proxy-Module API . SUCCESS [
> 14.253 s]
> [INFO] Apache DeltaSpike Proxy-Module Impl ASM5 ... SUCCESS [
> 18.959 s]
> [INFO] Apache DeltaSpike Security-Module .. SUCCESS [
> 9.698 s]
> [INFO] Apache DeltaSpike Security-Module API .. SUCCESS [
> 14.664 s]
> [INFO] Apache DeltaSpike Security-Module Impl . SUCCESS [
> 19.988 s]
> [INFO] Apache DeltaSpike JPA-Module ... SUCCESS [
> 9.662 s]
> [INFO] Apache DeltaSpike JPA-Module API ... SUCCESS [
> 14.761 s]
> [INFO] Apache DeltaSpike JPA-Module Impl .. SUCCESS [
> 26.463 s]
> [INFO] Apache DeltaSpike Servlet-Module ... SUCCESS [
> 9.581 s]
> [INFO] Apache DeltaSpike Servlet-Module API ... SUCCESS [
> 13.733 s]
> [INFO] Apache DeltaSpike Servlet-Module Impl .. SUCCESS [
> 15.576 s]
> [INFO] Apache DeltaSpike JSF-Module ... SUCCESS [
> 9.730 s]
> [INFO] Apache DeltaSpike JSF-Module API ... SUCCESS [
> 15.936 s]
> [INFO] Apache DeltaSpike JSF-Module Impl .. SUCCESS [
> 31.941 s]
> [INFO] Apache DeltaSpike JSF-Module Impl (EE6 only) ... SUCCESS [
> 16.465 s]
> [INFO] Apache DeltaSpike Partial-Bean-Module .. SUCCESS [
> 9.889 s]
> [INFO] Apache DeltaSpike Partial-Bean-Module API .. SUCCESS [
> 26.509 s]
> [INFO] Apache DeltaSpike Partial-Bean-Module Impl . SUCCESS [
> 20.169 s]
> [INFO] Apache DeltaSpike BeanValidation-Module  SUCCESS [
> 10.116 s]
> [INFO] Apache DeltaSpike BeanValidation-Module API  SUCCESS [
> 13.972 s]
> [INFO] Apache DeltaSpike BeanValidation-Module Impl ... SUCCESS [
> 17.688 s]
> [INFO] Apache DeltaSpike Data-Module .. FAILURE [
> 0.781 s]
> [INFO] Apache DeltaSpike Data-Module API 

[jira] [Commented] (DELTASPIKE-1302) ThreadPoolManager: ExecutorService map is always empty

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1302:
---

I like Romain's idea.  Makes sense.

> ThreadPoolManager: ExecutorService map is always empty
> --
>
> Key: DELTASPIKE-1302
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1302
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.8.0
>Reporter: Alonso Gonzalez
>Priority: Minor
>
> ThreadPoolManager contains a ConcurrentHashMap that maps from a pool name to 
> an ExecutorService. Unfortunately the map never gets populated. It's always 
> empty.
> I need this because I want to use a specific ExecutorService with @Futureable.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1301) java.lang.IllegalStateException,message=Could not find EntityManager with default qualifier.

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1301:
---

You mentioned this in a prior comment:

{code}
 13:13:22,225 ERROR [io.undertow.request] (default task-1) UT005023: Exception 
handling request to /path/: org.jboss.resteasy.spi.UnhandledException: 
javax.persistence.TransactionRequiredException: WFLYJPA0060: Transaction is 
required to perform this operation (either use a transaction or extended 
persistence context)
{code}

Is it in fact that exception? Because that's a different issue.

> java.lang.IllegalStateException,message=Could not find EntityManager with 
> default qualifier.
> 
>
> Key: DELTASPIKE-1301
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1301
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.0
> Environment: Wildfly 10.1.0, Ubuntu 16.04
>Reporter: Nicolas Duminil
>
> Hello,
> I have the following data-module repository:
> {code}
> @Repository
> public interface CustomerManagementRepository extends 
> EntityRepository<Customer, BigInteger>
> {
>   ...
> }
> {code}
> This repository is called from a stateless session bean, as follows:
> {code}
>   @Inject
>   private CustomerManagementRepository repo;
>   
>   public List findByFirsName(String firstName)
>   {
> return repo.findByFirsName(firstName);
>   }
> {code}
> The following CDI producer is provided as well:
> {code}
> public class EntityManagerProducer
> {
>   @PersistenceContext
>   private EntityManager em;
>   @Produces
>   public EntityManager createEntityManager()
>   {
> return em;
>   }
> }
> {code}
> When calling the staeless bean from a JAX-RS service, as follows:
> {code}
>   @EJB
>   private CustomerManagementFacade facade;
>   @POST
>   @Consumes(MediaType.APPLICATION_JSON)
>   public Response createCustomer(Customer customer)
>   {
> Customer newCustomer = facade.saveAndFlushAndRefresh(customer);
> return Response.created(URI.create("/customers/" + 
> newCustomer.getId())).build();
>   }
> {code}
> the following exception is raised:
> {code}
> 15:48:14,914 ERROR [org.jboss.as.ejb3.invocation] (default task-1) 
> WFLYEJB0034: EJB Invocation failed on component CustomerManagementFacade for 
> method public fr.simplex_software.customer_management.data.Customer 
> fr.simplex_software.customer_management.facade.CustomerManagementFacade.saveAndFlushAndRefresh(fr.simplex_software.customer_management.data.Customer):
>  javax.ejb.EJBException: 
> org.apache.deltaspike.data.api.QueryInvocationException: Exception calling 
> Repository: [Repository=class 
> fr.simplex_software.customer_management.repository.CustomerManagementRepository$$DSPartialBeanProxy,method=saveAndFlushAndRefresh],exception=class
>  java.lang.IllegalStateException,message=Could not find EntityManager with 
> default qualifier.
> {code}
> What seems to happen is that the CDI producer doesn't get called. Do I do 
> anything wrong here ? Please don't send me links to the documentation 'cause 
> I've read it before posting.
> Many thanks in advance,
> Nicolas
> P.S. I have the following in apache-deltaspike.properties:
> {code}
> globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1301) java.lang.IllegalStateException,message=Could not find EntityManager with default qualifier.

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1301:
---

Just wondering, did you try adding {{@Dependent}} to your producer class/field?

> java.lang.IllegalStateException,message=Could not find EntityManager with 
> default qualifier.
> 
>
> Key: DELTASPIKE-1301
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1301
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.0
> Environment: Wildfly 10.1.0, Ubuntu 16.04
>Reporter: Nicolas Duminil
>
> Hello,
> I have the following data-module repository:
> {code}
> @Repository
> public interface CustomerManagementRepository extends 
> EntityRepository<Customer, BigInteger>
> {
>   ...
> }
> {code}
> This repository is called from a stateless session bean, as follows:
> {code}
>   @Inject
>   private CustomerManagementRepository repo;
>   
>   public List findByFirsName(String firstName)
>   {
> return repo.findByFirsName(firstName);
>   }
> {code}
> The following CDI producer is provided as well:
> {code}
> public class EntityManagerProducer
> {
>   @PersistenceContext
>   private EntityManager em;
>   @Produces
>   public EntityManager createEntityManager()
>   {
> return em;
>   }
> }
> {code}
> When calling the staeless bean from a JAX-RS service, as follows:
> {code}
>   @EJB
>   private CustomerManagementFacade facade;
>   @POST
>   @Consumes(MediaType.APPLICATION_JSON)
>   public Response createCustomer(Customer customer)
>   {
> Customer newCustomer = facade.saveAndFlushAndRefresh(customer);
> return Response.created(URI.create("/customers/" + 
> newCustomer.getId())).build();
>   }
> {code}
> the following exception is raised:
> {code}
> 15:48:14,914 ERROR [org.jboss.as.ejb3.invocation] (default task-1) 
> WFLYEJB0034: EJB Invocation failed on component CustomerManagementFacade for 
> method public fr.simplex_software.customer_management.data.Customer 
> fr.simplex_software.customer_management.facade.CustomerManagementFacade.saveAndFlushAndRefresh(fr.simplex_software.customer_management.data.Customer):
>  javax.ejb.EJBException: 
> org.apache.deltaspike.data.api.QueryInvocationException: Exception calling 
> Repository: [Repository=class 
> fr.simplex_software.customer_management.repository.CustomerManagementRepository$$DSPartialBeanProxy,method=saveAndFlushAndRefresh],exception=class
>  java.lang.IllegalStateException,message=Could not find EntityManager with 
> default qualifier.
> {code}
> What seems to happen is that the CDI producer doesn't get called. Do I do 
> anything wrong here ? Please don't send me links to the documentation 'cause 
> I've read it before posting.
> Many thanks in advance,
> Nicolas
> P.S. I have the following in apache-deltaspike.properties:
> {code}
> globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (DELTASPIKE-1301) java.lang.IllegalStateException,message=Could not find EntityManager with default qualifier.

[John D. Ament (JIRA)]

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

John D. Ament updated DELTASPIKE-1301:
--
Description: 
Hello,

I have the following data-module repository:

{code}
@Repository
public interface CustomerManagementRepository extends 
EntityRepository<Customer, BigInteger>
{
  ...
}
{code}

This repository is called from a stateless session bean, as follows:

{code}
  @Inject
  private CustomerManagementRepository repo;
  
  public List findByFirsName(String firstName)
  {
return repo.findByFirsName(firstName);
  }
{code}

The following CDI producer is provided as well:

{code}
public class EntityManagerProducer
{
  @PersistenceContext
  private EntityManager em;

  @Produces
  public EntityManager createEntityManager()
  {
return em;
  }
}
{code}

When calling the staeless bean from a JAX-RS service, as follows:

{code}
  @EJB
  private CustomerManagementFacade facade;

  @POST
  @Consumes(MediaType.APPLICATION_JSON)
  public Response createCustomer(Customer customer)
  {
Customer newCustomer = facade.saveAndFlushAndRefresh(customer);
return Response.created(URI.create("/customers/" + 
newCustomer.getId())).build();
  }
{code}

the following exception is raised:

{code}
15:48:14,914 ERROR [org.jboss.as.ejb3.invocation] (default task-1) WFLYEJB0034: 
EJB Invocation failed on component CustomerManagementFacade for method public 
fr.simplex_software.customer_management.data.Customer 
fr.simplex_software.customer_management.facade.CustomerManagementFacade.saveAndFlushAndRefresh(fr.simplex_software.customer_management.data.Customer):
 javax.ejb.EJBException: 
org.apache.deltaspike.data.api.QueryInvocationException: Exception calling 
Repository: [Repository=class 
fr.simplex_software.customer_management.repository.CustomerManagementRepository$$DSPartialBeanProxy,method=saveAndFlushAndRefresh],exception=class
 java.lang.IllegalStateException,message=Could not find EntityManager with 
default qualifier.
{code}

What seems to happen is that the CDI producer doesn't get called. Do I do 
anything wrong here ? Please don't send me links to the documentation 'cause 
I've read it before posting.

Many thanks in advance,

Nicolas

P.S. I have the following in apache-deltaspike.properties:

{code}
globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy
{code}

  was:
Hello,

I have the following data-module repository:

@Repository
public interface CustomerManagementRepository extends 
EntityRepository<Customer, BigInteger>
{
  ...
}

This repository is called from a stateless session bean, as follows:

  @Inject
  private CustomerManagementRepository repo;
  
  public List findByFirsName(String firstName)
  {
return repo.findByFirsName(firstName);
  }

The following CDI producer is provided as well:

public class EntityManagerProducer
{
  @PersistenceContext
  private EntityManager em;

  @Produces
  public EntityManager createEntityManager()
  {
return em;
  }
}

When calling the staeless bean from a JAX-RS service, as follows:

  @EJB
  private CustomerManagementFacade facade;

  @POST
  @Consumes(MediaType.APPLICATION_JSON)
  public Response createCustomer(Customer customer)
  {
Customer newCustomer = facade.saveAndFlushAndRefresh(customer);
return Response.created(URI.create("/customers/" + 
newCustomer.getId())).build();
  }

the following exception is raised:

15:48:14,914 ERROR [org.jboss.as.ejb3.invocation] (default task-1) WFLYEJB0034: 
EJB Invocation failed on component CustomerManagementFacade for method public 
fr.simplex_software.customer_management.data.Customer 
fr.simplex_software.customer_management.facade.CustomerManagementFacade.saveAndFlushAndRefresh(fr.simplex_software.customer_management.data.Customer):
 javax.ejb.EJBException: 
org.apache.deltaspike.data.api.QueryInvocationException: Exception calling 
Repository: [Repository=class 
fr.simplex_software.customer_management.repository.CustomerManagementRepository$$DSPartialBeanProxy,method=saveAndFlushAndRefresh],exception=class
 java.lang.IllegalStateException,message=Could not find EntityManager with 
default qualifier.

What seems to happen is that the CDI producer doesn't get called. Do I do 
anything wrong here ? Please don't send me links to the documentation 'cause 
I've read it before posting.

Many thanks in advance,

Nicolas

P.S. I have the following in apache-deltaspike.properties:

globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy



> java.lang.IllegalStateException,message=Could not find EntityManager with 
> default qualifier.
> 

Re: Build failed in Jenkins: DeltaSpike RAT-Check #2806

[John D. Ament]

Can you fix this Gerhard?

On Tue, Oct 31, 2017 at 2:40 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://builds.apache.org/job/DeltaSpike%20RAT-Check/2806/display/redirect?page=changes
> >
>
> Changes:
>
> [gpetracek] DELTASPIKE-1297 added test with a customized DynamicMockManager
>
> --
> [...truncated 481.51 KB...]
> [INFO] Apache DeltaSpike CheckStyle-rules . SUCCESS [
> 3.785 s]
> [INFO] Apache DeltaSpike Parent ... SUCCESS [
> 6.595 s]
> [INFO] Apache DeltaSpike Test-Utils ... SUCCESS [
> 7.616 s]
> [INFO] Apache DeltaSpike Code Parent .. SUCCESS [
> 3.940 s]
> [INFO] Apache DeltaSpike Core . SUCCESS [
> 3.319 s]
> [INFO] Apache DeltaSpike Core-API . SUCCESS [
> 11.475 s]
> [INFO] Apache DeltaSpike Core-Implementation .. SUCCESS [
> 8.875 s]
> [INFO] Apache DeltaSpike ContainerControl parent .. SUCCESS [
> 3.243 s]
> [INFO] Apache DeltaSpike CDI ContainerControl API . SUCCESS [
> 4.655 s]
> [INFO] Apache DeltaSpike CDI ContainerControl TCK . SUCCESS [
> 4.810 s]
> [INFO] Apache DeltaSpike CDI OWB-ContainerControl . SUCCESS [
> 5.425 s]
> [INFO] Apache DeltaSpike CDI Weld-ContainerControl  SUCCESS [
> 5.555 s]
> [INFO] Apache DeltaSpike CDI OpenEJB-ContainerControl . SUCCESS [
> 8.260 s]
> [INFO] Apache DeltaSpike CDI Servlet-ContainerControl . SUCCESS [
> 4.784 s]
> [INFO] Apache DeltaSpike Modules .. SUCCESS [
> 3.204 s]
> [INFO] Apache DeltaSpike Proxy-Module . SUCCESS [
> 3.143 s]
> [INFO] Apache DeltaSpike Proxy-Module API . SUCCESS [
> 5.964 s]
> [INFO] Apache DeltaSpike Proxy-Module Impl ASM5 ... SUCCESS [
> 7.231 s]
> [INFO] Apache DeltaSpike Security-Module .. SUCCESS [
> 3.119 s]
> [INFO] Apache DeltaSpike Security-Module API .. SUCCESS [
> 6.127 s]
> [INFO] Apache DeltaSpike Security-Module Impl . SUCCESS [
> 6.527 s]
> [INFO] Apache DeltaSpike JPA-Module ... SUCCESS [
> 3.058 s]
> [INFO] Apache DeltaSpike JPA-Module API ... SUCCESS [
> 6.585 s]
> [INFO] Apache DeltaSpike JPA-Module Impl .. SUCCESS [
> 7.019 s]
> [INFO] Apache DeltaSpike Servlet-Module ... SUCCESS [
> 3.338 s]
> [INFO] Apache DeltaSpike Servlet-Module API ... SUCCESS [
> 4.350 s]
> [INFO] Apache DeltaSpike Servlet-Module Impl .. SUCCESS [
> 5.217 s]
> [INFO] Apache DeltaSpike JSF-Module ... SUCCESS [
> 3.209 s]
> [INFO] Apache DeltaSpike JSF-Module API ... SUCCESS [
> 5.078 s]
> [INFO] Apache DeltaSpike JSF-Module Impl .. SUCCESS [
> 11.296 s]
> [INFO] Apache DeltaSpike JSF-Module Impl (EE6 only) ... SUCCESS [
> 6.417 s]
> [INFO] Apache DeltaSpike Partial-Bean-Module .. SUCCESS [
> 3.356 s]
> [INFO] Apache DeltaSpike Partial-Bean-Module API .. SUCCESS [
> 5.595 s]
> [INFO] Apache DeltaSpike Partial-Bean-Module Impl . SUCCESS [
> 6.030 s]
> [INFO] Apache DeltaSpike BeanValidation-Module  SUCCESS [
> 3.111 s]
> [INFO] Apache DeltaSpike BeanValidation-Module API  SUCCESS [
> 4.449 s]
> [INFO] Apache DeltaSpike BeanValidation-Module Impl ... SUCCESS [
> 5.898 s]
> [INFO] Apache DeltaSpike Data-Module .. SUCCESS [
> 3.152 s]
> [INFO] Apache DeltaSpike Data-Module API .. SUCCESS [
> 5.954 s]
> [INFO] Apache DeltaSpike Data-Module Impl . SUCCESS [
> 11.200 s]
> [INFO] Apache DeltaSpike Data-Module Tests with Java 8  SUCCESS [
> 6.075 s]
> [INFO] Apache DeltaSpike Scheduler-Module . SUCCESS [
> 3.296 s]
> [INFO] Apache DeltaSpike Scheduler-Module API . SUCCESS [
> 5.863 s]
> [INFO] Apache DeltaSpike Scheduler-Module Impl  SUCCESS [
> 6.120 s]
> [INFO] Apache DeltaSpike Test-Control-Module .. SUCCESS [
> 3.054 s]
> [INFO] Apache DeltaSpike Test-Control-Module API .. SUCCESS [
> 5.969 s]
> [INFO] Apache DeltaSpike Test-Control-Module Impl . FAILURE [
> 0.770 s]
> [INFO] Apache DeltaSpike Examples . SKIPPED
> [INFO] Apache DeltaSpike Java-SE Examples . SKIPPED
> [INFO] Apache DeltaSpike JSF Examples . SKIPPED
> [INFO] Apache DeltaSpike JSF Playground ... SKIPPED
> [INFO] Apache DeltaSpike Security Example CDI . SKIPPED
> [INFO] Apache DeltaSpike Security Example PicketLink .. SKIPPED
> [INFO] Apache DeltaSpike Java-SE Scheduler Examples ... SKIPPED
> [INFO] Apache DeltaSpike JPA Examples . SKIPPED
> [INFO] Apache DeltaSpike Data Examples  SKIPPED
> [INFO] Apache DeltaSpike Distribution . SKIPPED
> 

Re: CDI extension: error with specialization beans

[John D. Ament]

The error you're getting is more to do with EJB than it does with CDI.
JBoss AS 7 is very old.  I doubt specializing an EJB would have ever worked
(I'm not even sure it works today, specializing is more to do with how CDI
works).  Does it need to be an EJB?

On Sun, Sep 24, 2017 at 4:59 PM Antonio  wrote:

> Hi all,
> We’re working in a java Project and we wanted to extend our application
> with specialization beans in external classes.
>
> We were trying to include one of those beans to our context dynamically
> using DeltaSpike. This bean specializes another one, as you can see in the
> code below:
>
> @Stateless
> public ClassA implements InterfaceA {…}
>
> @Stateless
> @Specializes
> public class SpecializationOfClassA extends ClassA {…}
>
> Firstly we tried to use BeforeBeanDiscovery event to add the annotated
> type to the Bean manager:
>
> public void beforeBeanDiscovery(@Observes BeforeBeanDiscovery bbd,
> BeanManager bm) {
> try {
>final javax.enterprise.inject.spi.AnnotatedType at =
> bm.createAnnotatedType(SpecializationOfClassA.class);
>bbd.addAnnotatedType(at);
>  . . .
>
> The above code triggered the following exception: WELD-47 Specializing
> bean must extend another bean
> This makes no sense for us, because the class we are passing extends
> another one.
>
> Then we tried to use AfterBeanDiscovery event to include the new bean to
> the bean manager:
>
> public void addCdiBeans(final @Observes AfterBeanDiscovery abd, final
> BeanManager bm) throws Exception {
>   AnnotatedType annotatedType = new
> AnnotatedTypeBuilder().readFromType(SpecializationOfClassA.class).create();
>   final InjectionTarget it =
> bm.createInjectionTarget(annotatedType);
>   final BeanBuilder beanBuilder =
>new BeanBuilder(bm)
>
>  .readFromType(annotatedType)
>
>  .injectionPoints(it.getInjectionPoints())
>  ;
>   final Bean cdiBean = beanBuilder.create();
>   abd.addBean(cdiBean);
> }
>
> The code above does not trigger any exceptions but it does not work
> because ClassA is injected instead of its specialization
> SpecializationOfClassA.
>
> We are deploying the application in JBoss 7.1.1.
> Do you know if this would be posible using DeltaSpike or there’s a problem
> with specialization classes?
>
> Thanks a lot and best regards.
>

[jira] [Resolved] (DELTASPIKE-1292) deltaspike distribution BOM has wrong parent - rendering it useless

[John D. Ament (JIRA)]

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

John D. Ament resolved DELTASPIKE-1292.
---
Resolution: Duplicate

Marking as a duplicate.

> deltaspike distribution BOM has wrong parent - rendering it useless
> ---
>
> Key: DELTASPIKE-1292
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1292
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.8.0
>Reporter: Jörg Sesterhenn
>    Assignee: John D. Ament
>  Labels: maven
>
> In Version 1.8.0 of the deltaspike distribution bom the parent was changed to
> {code}
> org.apache.deltaspike.distribution
> distributions-project
> 1.8.0
> {code}
> This change leads to several unwanted dependency management entries (for 
> libraries not concerning deltaspike) in our projects after importing your bom.
> Please revert this change and verify that importing your BOM only sets 
> versions for deltaspike artifacts.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (DELTASPIKE-1278) PropertyFileConfig does not respect optional on external resources

[John D. Ament (JIRA)]

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

John D. Ament resolved DELTASPIKE-1278.
---
   Resolution: Fixed
 Assignee: John D. Ament
Fix Version/s: 1.8.1

Thanks for the contribution, merged!

> PropertyFileConfig does not respect optional on external resources
> --
>
> Key: DELTASPIKE-1278
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1278
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.8.0
>Reporter: Dennis Rippinger
>    Assignee: John D. Ament
> Fix For: 1.8.1
>
>
> Adding a property file from an external location (e.g. local file system) 
> marked as optional is not respected by {{PropertyFileUtils}}. It creates a 
> list of possible resource URLs, but does not check for their existence in all 
> branches of its logic. This results in a list of possible nonexistent 
> resources which could be optional, leading to an IllegalStateException.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-940:
--

[~tandraschko] sorry thought I had already responded.  The problem with pulling 
it out is that it has to be in two places, since this annotation can control 
both transactions and repository.  Having it in a common place makes more sense.

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>    Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.1
>
> Attachments: ds940.patch
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (DELTASPIKE-1281) Deltaspike does not pass BeanManager to persistenf factory config using "javax.persistence.bean.manager"

[John D. Ament (JIRA)]

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

John D. Ament resolved DELTASPIKE-1281.
---
Resolution: Fixed

Done.

> Deltaspike does not pass BeanManager to persistenf factory config using 
> "javax.persistence.bean.manager"
> 
>
> Key: DELTASPIKE-1281
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1281
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JPA-Module
>Affects Versions: 1.8.0
> Environment: Deltaspike 1.8, Weld 3.0, Java 8 (JSE) JPA with 
> HIbernate 5.2.10
>    Reporter: Alex Roytman
>Assignee: John D. Ament
> Fix For: 1.8.1
>
>
> As the result no injections were working in JPA listeners.
> Per specs Persistence UnitFactory expects BeanManager in 
> javax.persistence.bean.manager property passed when instantiate it but 
> org.apache.deltaspike.jpa.impl.entitymanager.PersistenceConfigurationProviderImpl
>  does not pass it
> this simple override took care of it but I should not need to do it:
> {code:java}
> @ApplicationScoped
> @Alternative
> @Priority(Interceptor.Priority.APPLICATION + 10)
> public class CdiAwarePersistenceConfigurationProviderImpl extends 
> PersistenceConfigurationProviderImpl implements 
> PersistenceConfigurationProvider {
>   @Inject BeanManager beanManager;
>   @Override public Properties getEntityManagerFactoryConfiguration(String 
> persistenceUnitName) {
> final Properties conf = 
> super.getEntityManagerFactoryConfiguration(persistenceUnitName);
> conf.put("javax.persistence.bean.manager", beanManager);
> return conf;
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (DELTASPIKE-1281) Deltaspike does not pass BeanManager to persistenf factory config using "javax.persistence.bean.manager"

[John D. Ament (JIRA)]

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

John D. Ament reassigned DELTASPIKE-1281:
-

Assignee: John D. Ament

> Deltaspike does not pass BeanManager to persistenf factory config using 
> "javax.persistence.bean.manager"
> 
>
> Key: DELTASPIKE-1281
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1281
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JPA-Module
>Affects Versions: 1.8.0
> Environment: Deltaspike 1.8, Weld 3.0, Java 8 (JSE) JPA with 
> HIbernate 5.2.10
>    Reporter: Alex Roytman
>Assignee: John D. Ament
> Fix For: 1.8.1
>
>
> As the result no injections were working in JPA listeners.
> Per specs Persistence UnitFactory expects BeanManager in 
> javax.persistence.bean.manager property passed when instantiate it but 
> org.apache.deltaspike.jpa.impl.entitymanager.PersistenceConfigurationProviderImpl
>  does not pass it
> this simple override took care of it but I should not need to do it:
> {code:java}
> @ApplicationScoped
> @Alternative
> @Priority(Interceptor.Priority.APPLICATION + 10)
> public class CdiAwarePersistenceConfigurationProviderImpl extends 
> PersistenceConfigurationProviderImpl implements 
> PersistenceConfigurationProvider {
>   @Inject BeanManager beanManager;
>   @Override public Properties getEntityManagerFactoryConfiguration(String 
> persistenceUnitName) {
> final Properties conf = 
> super.getEntityManagerFactoryConfiguration(persistenceUnitName);
> conf.put("javax.persistence.bean.manager", beanManager);
> return conf;
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (DELTASPIKE-1281) Deltaspike does not pass BeanManager to persistenf factory config using "javax.persistence.bean.manager"

[John D. Ament (JIRA)]

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

John D. Ament updated DELTASPIKE-1281:
--
Fix Version/s: 1.8.1

> Deltaspike does not pass BeanManager to persistenf factory config using 
> "javax.persistence.bean.manager"
> 
>
> Key: DELTASPIKE-1281
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1281
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JPA-Module
>Affects Versions: 1.8.0
> Environment: Deltaspike 1.8, Weld 3.0, Java 8 (JSE) JPA with 
> HIbernate 5.2.10
>Reporter: Alex Roytman
> Fix For: 1.8.1
>
>
> As the result no injections were working in JPA listeners.
> Per specs Persistence UnitFactory expects BeanManager in 
> javax.persistence.bean.manager property passed when instantiate it but 
> org.apache.deltaspike.jpa.impl.entitymanager.PersistenceConfigurationProviderImpl
>  does not pass it
> this simple override took care of it but I should not need to do it:
> {code:java}
> @ApplicationScoped
> @Alternative
> @Priority(Interceptor.Priority.APPLICATION + 10)
> public class CdiAwarePersistenceConfigurationProviderImpl extends 
> PersistenceConfigurationProviderImpl implements 
> PersistenceConfigurationProvider {
>   @Inject BeanManager beanManager;
>   @Override public Properties getEntityManagerFactoryConfiguration(String 
> persistenceUnitName) {
> final Properties conf = 
> super.getEntityManagerFactoryConfiguration(persistenceUnitName);
> conf.put("javax.persistence.bean.manager", beanManager);
> return conf;
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1275) Build fails on Linux because Testclass filenames are to long

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1275:
---

what distro?

> Build fails on Linux because Testclass filenames are to long
> 
>
> Key: DELTASPIKE-1275
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1275
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JPA-Module
>Affects Versions: 1.8.0
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 1.8.1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (DELTASPIKE-1252) data-documentation missing Optional return value

[John D. Ament (JIRA)]

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

John D. Ament resolved DELTASPIKE-1252.
---
Resolution: Fixed

> data-documentation missing Optional return value
> 
>
> Key: DELTASPIKE-1252
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1252
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module, Documentation
>Affects Versions: 1.7.2
>Reporter: Jan Matèrne
>    Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.1
>
>
> http://deltaspike.apache.org/documentation/data.html lists the format for 
> methods:
> (Entity|List) (prefix)(Property[Comparator]){Operator Property 
> [Comparator]}
> Here java.util.Optional is missing:
> "(Entity|Optional|List) 
> (prefix)(Property[Comparator]){Operator Property [Comparator]}
>  
> Or in more concrete words:
> • The query method must either return an entity or an java.util.Optional 
> or a list of entities.
> • It must start with the findBy prefix ..."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (DELTASPIKE-1273) Test against OWB 2

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1273:
-

 Summary: Test against OWB 2
 Key: DELTASPIKE-1273
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1273
 Project: DeltaSpike
  Issue Type: Test
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 1.8.1


Add tests against OWB 2.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Testing Against OWB 2

[John D. Ament]

I'm planning to push up a new profile based on OWB 2, in the state of what
we used for OWB 1/1.5.  There's some test failures, I haven't looked at
yet, but wanted to get it running through Jenkins to make sure it's not my
machine.

John

[jira] [Created] (DELTASPIKE-1264) Remove portions of BeanProvider/BeanManagerProvider

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1264:
-

 Summary: Remove portions of BeanProvider/BeanManagerProvider
 Key: DELTASPIKE-1264
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1264
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: John D. Ament
 Fix For: 2.0


These internal utilities may not be needed based on CDI.current() from CDI 1.1.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (DELTASPIKE-1263) Remove BeanBuilder

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1263:
-

 Summary: Remove BeanBuilder
 Key: DELTASPIKE-1263
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1263
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: John D. Ament
 Fix For: 2.0


CDI 2.0 introduces bean configurators, which handle the use cases of 
BeanBuilder.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (DELTASPIKE-1260) Remove Servlet Module

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1260:
-

 Summary: Remove Servlet Module
 Key: DELTASPIKE-1260
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1260
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: John D. Ament
 Fix For: 2.0


The Servlet module is fully supported by features of Java EE 7+, and is no 
longer useful.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (DELTASPIKE-1261) Remove BeanVal Module

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1261:
-

 Summary: Remove BeanVal Module
 Key: DELTASPIKE-1261
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1261
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: John D. Ament
 Fix For: 2.0


The Bean Validation module is fully supposed by Java EE 7+ and can be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Creating a branch for DeltaSpike 2.0? Or 1.x maintenance?

[John D. Ament]

I agree with Thomas.  While always minimal, if we can trim our internal
libraries and make them a bit more user friendly, it will simplify how
users leverage our modules (e.g. maybe we don't have a core module
anymore).  This means better module isolation.  If Mark brings config to
Geronimo via MP then we could even provide the legacy DeltaSpike Config as
a compatibility layer for those using it.

I'm also confused about the comment around "micro-profile" as well as "cdi2
as a new baseline once its really useful"

John

On Sat, Jun 3, 2017 at 2:58 PM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> IMO we should try to do a cut in 2.0 and do a big cleanup (1.x should be in
> maintenance to support < JavaEE8):
> - Drop bval module and the servlet module. AFAIR the injection support is
> already in JavaEE 8.
> - We can also try to remove some core APIs (BeanManagerProvider)
> - Cleanup the JSF Module (injection support is also available in JavaEE8)
> - Cleanup Java8 hacks
>
> What parts to you mean which are required for a microprofile?
>
>
>
> 2017-06-03 17:42 GMT+02:00 Gerhard Petracek <gpetra...@apache.org>:
>
> > imo there's not a lot we should drop, because users might need those
> parts
> > e.g. for applications based on the micro-profile.
> > maybe it's just a matter of documenting an useful combination of ee8 + ds
> > and/or to highlight which parts of ds are covered by ee8.
> >
> > @ds2:
> > maybe we should mainly take the chance to improve the consistency (= few
> > but breaking api-changes).
> > (+ only use cdi2,... as a new baseline once it's really useful.)
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2017-06-03 16:35 GMT+02:00 Thomas Andraschko <
> andraschko.tho...@gmail.com
> > >:
> >
> > > basically +1
> > > we can do some cleanup (like removing features + modules which are
> > > available in JavaEE8)
> > > BUT - many user won't use JavaEE8 until next year as the AS' are not
> > ready.
> > > So IMO it's not necessary now.
> > >
> > > I will currently start to do some internal cleanup on the Data Module
> > e.g.
> > >
> > > 2017-06-03 16:21 GMT+02:00 Gerhard Petracek <gpetra...@apache.org>:
> > >
> > > > @romain: +1
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2017-06-03 16:19 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> > > >
> > > > > Hi
> > > > >
> > > > > Any strong feature from cdi 2 we need? If so +1 otherwise -1
> > > > >
> > > > > Le 3 juin 2017 16:07, "John D. Ament" <johndam...@apache.org> a
> > écrit
> > > :
> > > > >
> > > > > > Hey guys
> > > > > >
> > > > > > I'm not sure there's much more for us to do in 1.x as far as
> > feature
> > > > > goes,
> > > > > > but I could be wrong.  I do think we should start to ramp up work
> > > > > > DeltaSpike 2.0:
> > > > > >
> > > > > > - Baseline on CDI 2.0, Java EE 8, Java 8
> > > > > > - Remove older components that are not needed any more
> > > > > > - See if there's new features we can add
> > > > > >
> > > > > > Thoughts?  I'm thinking this could either be a 2.x branch, or we
> > move
> > > > > > master to a 1.x maintenance branch while we work on 2.0 in
> master.
> > > > > >
> > > > > > John
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] [CANCEL] Release Apache DeltaSpike-1.8.0

[John D. Ament]

I've updated the website (not published) as well, but need to add to news.
Javadocs are there now as well.

On Sat, Jun 3, 2017 at 7:33 AM Gerhard Petracek <gpetra...@apache.org>
wrote:

> short addition:
>
> it looks like all release steps after the (git) push are missing (see [1]).
>
> regards,
> gerhard
>
> [1] http://deltaspike.apache.org/staging/steps_for_a_release.html
>
>
>
> 2017-06-03 13:24 GMT+02:00 Gerhard Petracek <gpetra...@apache.org>:
>
> > hi thomas,
> >
> > thx for the heads-up!
> > we discussed it in the irc-channel already...
> > i've pushed the fix, but we also have to upload the files for the
> > download-page,...
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2017-06-03 12:57 GMT+02:00 Thomas Andraschko <
> andraschko.tho...@gmail.com>
> > :
> >
> >> Hi Mark,
> >>
> >> is everything ok with the current builds?
> >> I did a fresh checkout today i cant build anymore:
> >>
> >> The build could not read 1 project -> [Help 1]
> >>
> >>   The project
> >> org.apache.deltaspike.modules:deltaspike-data-module-test-ja
> >> va8:1.8.0-SNAPSHOT
> >> (/home/tandraschko/NetBeansProjects/deltaspike/deltaspike/mo
> >> dules/data/test-java8/pom.xml)
> >> has 1 error
> >> Non-resolvable parent POM: Could not find artifact
> >> org.apache.deltaspike.modules:data-module-project:pom:1.8.0-SNAPSHOT and
> >> 'parent.relativePath' points at wrong local POM @ line 22, column 13 ->
> >> [Help 2]
> >>
> >>
> >> It seems that deltaspike-data-module-test-java8 still points to
> >> 1.8.0-SNAPSHOT
> >>
> >> Regards,
> >> Thomas
> >>
> >> 2017-05-28 10:16 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:
> >>
> >> > Hi John!
> >> >
> >> > > I'd recommend just running a mvn deploy -Pdistribution from the
> 1.8.0
> >> > tag,
> >> > > that should resolve this.
> >> >
> >> > Sadly not. Since the dist modules only get added conditionally they
> >> didn't
> >> > even have been included in the version bump.
> >> > So they are still on the 1.8.0-SNAPSHOT.
> >> >
> >> > I gonna clean up all our build and reroll the release.
> >> >
> >> > LieGrue,
> >> > strub
> >> >
> >> >
> >> > > Am 27.05.2017 um 22:33 schrieb John D. Ament <johndam...@apache.org
> >:
> >> > >
> >> > > On Sat, May 27, 2017 at 12:41 PM Mark Struberg
> >> <strub...@yahoo.de.invalid
> >> > >
> >> > > wrote:
> >> > >
> >> > >> Found them locally. Seems they are not treated as attached
> artifacts?
> >> > Why
> >> > >> so?
> >> > >>
> >> > >> I'm not able to replicate the issue when I follow the release
> >> > > instructions, I just staged a release and got all of the artifacts.
> >> > >
> >> > > I'd recommend just running a mvn deploy -Pdistribution from the
> 1.8.0
> >> > tag,
> >> > > that should resolve this.
> >> > >
> >> > >
> >> > >> I can put them to dist/dev.
> >> > >> Which of the artifacts do you need?
> >> > >>
> >> > >
> >> > > bom, full distribution.
> >> > >
> >> > >
> >> > >>
> >> > >> LieGrue,
> >> > >> strub
> >> > >>
> >> > >>> Am 27.05.2017 um 17:15 schrieb John D. Ament <
> johndam...@apache.org
> >> >:
> >> > >>>
> >> > >>> BTW while the release only matters about source, we know users
> care
> >> > about
> >> > >>> binaries [1] [2]
> >> > >>>
> >> > >>>
> >> > >>> [1]: https://issues.apache.org/jira/browse/DELTASPIKE-1194
> >> > >>> [2]:
> >> > >>>
> >> > >>
> https://lists.apache.org/thread.html/72191470ff23a7b11a16b3b8e9d16e
> >> > ba48a755e552b58b9c88b426c2@%3Cusers.deltaspike.apache.org%3E
> >> > >>>
> >> > >>>
> >> > >>> On Sat, May 27, 2017 at 11:10 AM John D. Ament <
> >> john.d.am...@gmail.com
> >> > >

Re: [1/2] deltaspike git commit: further release fixes

[John D. Ament]

We can look at it later, its not blocking for now.  I created
https://issues.apache.org/jira/browse/DELTASPIKE-1257 to track.

On Sun, May 28, 2017 at 11:36 AM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> The error I got was something else. This happened even with the
> distribution profile.
> Maven complained that the bom pom points to an illegal parent pom
> (warning) and kept complaining about 'unresolved snaphots left' asking me
> to specify the version for the various deltaspike modules.
>
> Maybe this only happens with more recent Maven versions, don't know...
> In any case, if a pom is part of the reactor, then it should also
> reference back to the build chain somehow.
>
> LieGrue,
> strub
>
>
> > Am 28.05.2017 um 17:24 schrieb John D. Ament <johndam...@apache.org>:
> >
> > I think that was the goal of the requestor's ask:
> >
> > - Not provide a bad bom
> > - Only bring in our stuff
> >
> > DeltaSpike is very odd in the landscape, we don't directly declare
> > dependencies.  That's what makes a bom like this very useful and easy to
> > manage, it doesn't bring in anything else.  What would happen previously
> is
> > with the parent structure it would actually bring in our profiles and
> some
> > of the dependencies within those profiles.  That doesn't happen with the
> > structure I had put in place + dependency management section.  With
> this, a
> > user ends up getting our internal build profiles, which may not match
> what
> > they're expecting to do.
> >
> > And I disagree about this breaking maven.  The release failed because you
> > didn't use the release profiles that have been mentioned since
> > ~0.3-incubating.  I've done it before as well and ended up with similar
> > results, but I was able to catch it before throwing the vote (however, I
> > missed that the binary dist was empty :-D)
> >
> > John
> >
> > On Sun, May 28, 2017 at 10:36 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> I'm kind of sharing Mark's feedback, each time I tried to use it
> >> (arquillian, spring, ...) it just had a very bad user experience after
> the
> >> first manually added dependency so not sure it does worth all the tricks
> >> the build would require or if we even really want to propose it to end
> >> users.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> >> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>
> >> 2017-05-28 16:33 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:
> >>
> >>> Except that it broke Maven.
> >>>
> >>> In general I find this bom very questionable.
> >>> Why would one use that?
> >>>
> >>> Usually boms get created as 'mashup' project to combine different
> >>> separately released artifacts
> >>> And there almost exclusively to pin down the versions of those various
> >>> artifacts.
> >>>
> >>> So why would one import a bom instead of just writing
> >>>
> >>> ${deltaspike.version} >>>
> >>> ?
> >>>
> >>> Also the boms are really error prone. They ONLY work in the exact pom
> you
> >>> declare them in.
> >>> So if you import the bom in your parent project and then reference the
> >>> various deltaspike modules only in some specific parts of your build
> then
> >>> it doesn't work anyway. It's just not worth it!
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>> Am 28.05.2017 um 14:54 schrieb John D. Ament <johndam...@apache.org>:
> >>>>
> >>>> Mark,
> >>>>
> >>>> On Sun, May 28, 2017 at 6:37 AM <strub...@apache.org> wrote:
> >>>>
> >>>>> Repository: deltaspike
> >>>>> Updated Branches:
> >>>>> refs/heads/master 6721ca6ec -> a62a93fca
> >>>>>
> >>>>>
> >>>>> further release fixes
> >>>>>
> >>>>>
> >>>>> Project: http://git-wip-us.apache.org/repos/asf/deltaspike/repo
> >>>>> Co

Re: [VOTE] Apache DeltaSpike 1.8.0 - 2nd take

[John D. Ament]

+1

On Sun, May 28, 2017 at 6:42 AM Mark Struberg 
wrote:

> Hi!
>
> I just rerolled the release.
> release branch and tag again staged at my github account
> https://github.com/struberg/deltaspike/tree/release_deltaspike_1.8.0
>
> Staging repo is
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1045/
>
> Source release is
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1045/org/apache/deltaspike/deltaspike/1.8.0/
>
> Please VOTE:
>
> [+1] yeah dude, let's ship it!
> [+0] meh, don't care
> [-1] woah, stop there is a ${showstopper}
>
> The VOTE is open for 72h.
>
> Here is my own +1
>
> d
> txs and LieGrue,
> strub

[jira] [Created] (DELTASPIKE-1257) Research why BOM isn't working right in a release

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1257:
-

 Summary: Research why BOM isn't working right in a release
 Key: DELTASPIKE-1257
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1257
 Project: DeltaSpike
  Issue Type: Task
Reporter: John D. Ament
Assignee: John D. Ament


https://lists.apache.org/thread.html/655162d82786d1201c2b33a20d82db8a36a642d0d9afc20042584b0d@%3Cdev.deltaspike.apache.org%3E

Something causes the release to work incorrectly with the BOM not inheriting 
from DS parent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-1257) Research why BOM isn't working right in a release

[John D. Ament (JIRA)]

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

John D. Ament updated DELTASPIKE-1257:
--
Fix Version/s: 1.8.1

> Research why BOM isn't working right in a release
> -
>
> Key: DELTASPIKE-1257
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1257
> Project: DeltaSpike
>  Issue Type: Task
>Affects Versions: 1.8.0
>    Reporter: John D. Ament
>    Assignee: John D. Ament
> Fix For: 1.8.1
>
>
> https://lists.apache.org/thread.html/655162d82786d1201c2b33a20d82db8a36a642d0d9afc20042584b0d@%3Cdev.deltaspike.apache.org%3E
> Something causes the release to work incorrectly with the BOM not inheriting 
> from DS parent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-1257) Research why BOM isn't working right in a release

[John D. Ament (JIRA)]

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

John D. Ament updated DELTASPIKE-1257:
--
Affects Version/s: 1.8.0

> Research why BOM isn't working right in a release
> -
>
> Key: DELTASPIKE-1257
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1257
> Project: DeltaSpike
>  Issue Type: Task
>Affects Versions: 1.8.0
>    Reporter: John D. Ament
>    Assignee: John D. Ament
> Fix For: 1.8.1
>
>
> https://lists.apache.org/thread.html/655162d82786d1201c2b33a20d82db8a36a642d0d9afc20042584b0d@%3Cdev.deltaspike.apache.org%3E
> Something causes the release to work incorrectly with the BOM not inheriting 
> from DS parent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [1/2] deltaspike git commit: further release fixes

[John D. Ament]

I think that was the goal of the requestor's ask:

- Not provide a bad bom
- Only bring in our stuff

DeltaSpike is very odd in the landscape, we don't directly declare
dependencies.  That's what makes a bom like this very useful and easy to
manage, it doesn't bring in anything else.  What would happen previously is
with the parent structure it would actually bring in our profiles and some
of the dependencies within those profiles.  That doesn't happen with the
structure I had put in place + dependency management section.  With this, a
user ends up getting our internal build profiles, which may not match what
they're expecting to do.

And I disagree about this breaking maven.  The release failed because you
didn't use the release profiles that have been mentioned since
~0.3-incubating.  I've done it before as well and ended up with similar
results, but I was able to catch it before throwing the vote (however, I
missed that the binary dist was empty :-D)

John

On Sun, May 28, 2017 at 10:36 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> I'm kind of sharing Mark's feedback, each time I tried to use it
> (arquillian, spring, ...) it just had a very bad user experience after the
> first manually added dependency so not sure it does worth all the tricks
> the build would require or if we even really want to propose it to end
> users.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-05-28 16:33 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:
>
> > Except that it broke Maven.
> >
> > In general I find this bom very questionable.
> > Why would one use that?
> >
> > Usually boms get created as 'mashup' project to combine different
> > separately released artifacts
> > And there almost exclusively to pin down the versions of those various
> > artifacts.
> >
> > So why would one import a bom instead of just writing
> >
> > ${deltaspike.version} >
> > ?
> >
> > Also the boms are really error prone. They ONLY work in the exact pom you
> > declare them in.
> > So if you import the bom in your parent project and then reference the
> > various deltaspike modules only in some specific parts of your build then
> > it doesn't work anyway. It's just not worth it!
> >
> > LieGrue,
> > strub
> >
> > > Am 28.05.2017 um 14:54 schrieb John D. Ament <johndam...@apache.org>:
> > >
> > > Mark,
> > >
> > > On Sun, May 28, 2017 at 6:37 AM <strub...@apache.org> wrote:
> > >
> > >> Repository: deltaspike
> > >> Updated Branches:
> > >>  refs/heads/master 6721ca6ec -> a62a93fca
> > >>
> > >>
> > >> further release fixes
> > >>
> > >>
> > >> Project: http://git-wip-us.apache.org/repos/asf/deltaspike/repo
> > >> Commit: http://git-wip-us.apache.org/repos/asf/deltaspike/commit/
> > 3ab179f6
> > >> Tree: http://git-wip-us.apache.org/repos/asf/deltaspike/tree/3ab179f6
> > >> Diff: http://git-wip-us.apache.org/repos/asf/deltaspike/diff/3ab179f6
> > >>
> > >> Branch: refs/heads/master
> > >> Commit: 3ab179f6bc469b16fb211775bacbee93b1eebdf5
> > >> Parents: 6721ca6
> > >> Author: Mark Struberg <strub...@apache.org>
> > >> Authored: Sun May 28 11:04:05 2017 +0200
> > >> Committer: Mark Struberg <strub...@apache.org>
> > >> Committed: Sun May 28 11:09:26 2017 +0200
> > >>
> > >> --
> > >> deltaspike/cdictrl/pom.xml   | 12 
> > >> deltaspike/dist/bom/pom.xml  |  6 +++---
> > >> deltaspike/dist/full/pom.xml | 32 ++--
> > >> 3 files changed, 17 insertions(+), 33 deletions(-)
> > >> --
> > >>
> > >>
> > >>
> > >> http://git-wip-us.apache.org/repos/asf/deltaspike/blob/
> > 3ab179f6/deltaspike/cdictrl/pom.xml
> > >> --
> > >> diff --git a/deltaspike/cdictrl/pom.xml b/deltaspike/cdictrl/pom.xml
> > >> index ece910f..bb9287d 100644
> > >> --- a/deltaspike/cdictr

Re: [1/2] deltaspike git commit: further release fixes

[John D. Ament]

Mark,

On Sun, May 28, 2017 at 6:37 AM  wrote:

> Repository: deltaspike
> Updated Branches:
>   refs/heads/master 6721ca6ec -> a62a93fca
>
>
> further release fixes
>
>
> Project: http://git-wip-us.apache.org/repos/asf/deltaspike/repo
> Commit: http://git-wip-us.apache.org/repos/asf/deltaspike/commit/3ab179f6
> Tree: http://git-wip-us.apache.org/repos/asf/deltaspike/tree/3ab179f6
> Diff: http://git-wip-us.apache.org/repos/asf/deltaspike/diff/3ab179f6
>
> Branch: refs/heads/master
> Commit: 3ab179f6bc469b16fb211775bacbee93b1eebdf5
> Parents: 6721ca6
> Author: Mark Struberg 
> Authored: Sun May 28 11:04:05 2017 +0200
> Committer: Mark Struberg 
> Committed: Sun May 28 11:09:26 2017 +0200
>
> --
>  deltaspike/cdictrl/pom.xml   | 12 
>  deltaspike/dist/bom/pom.xml  |  6 +++---
>  deltaspike/dist/full/pom.xml | 32 ++--
>  3 files changed, 17 insertions(+), 33 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/deltaspike/blob/3ab179f6/deltaspike/cdictrl/pom.xml
> --
> diff --git a/deltaspike/cdictrl/pom.xml b/deltaspike/cdictrl/pom.xml
> index ece910f..bb9287d 100644
> --- a/deltaspike/cdictrl/pom.xml
> +++ b/deltaspike/cdictrl/pom.xml
> @@ -93,6 +93,18 @@
>  
>
>  
> +apache-release
> +
> +
> +api
> +impl-owb
> +impl-weld
> +impl-openejb
> +servlet
> +tck
> +
> +
> +
>  distribution
>
>  
>
>
> http://git-wip-us.apache.org/repos/asf/deltaspike/blob/3ab179f6/deltaspike/dist/bom/pom.xml
> --
> diff --git a/deltaspike/dist/bom/pom.xml b/deltaspike/dist/bom/pom.xml
> index dfae97f..090a129 100644
> --- a/deltaspike/dist/bom/pom.xml
> +++ b/deltaspike/dist/bom/pom.xml
> @@ -21,9 +21,9 @@
>  4.0.0
>
>  
> -org.apache
> -apache
> -18
> +org.apache.deltaspike.distribution
> +distributions-project
> +1.8.0-SNAPSHOT
>  
>
>
This was a change explicitly requested in
https://issues.apache.org/jira/browse/DELTASPIKE-1088 , with this setup
we're now including the transitive dependencies in the BOM.


>  org.apache.deltaspike.distribution
>
>
> http://git-wip-us.apache.org/repos/asf/deltaspike/blob/3ab179f6/deltaspike/dist/full/pom.xml
> --
> diff --git a/deltaspike/dist/full/pom.xml b/deltaspike/dist/full/pom.xml
> index 0b3d6f0..1467c68 100644
> --- a/deltaspike/dist/full/pom.xml
> +++ b/deltaspike/dist/full/pom.xml
> @@ -21,8 +21,8 @@
>  4.0.0
>
>  
> -org.apache.deltaspike.distribution
> -distributions-project
> +org.apache.deltaspike.distribution
> +distributions-project
>  1.8.0-SNAPSHOT
>  
>
> @@ -38,90 +38,77 @@
>  
>  org.apache.deltaspike.core
>  deltaspike-core-api
> -${project.version}
>  compile
>  
>
>  
>  org.apache.deltaspike.core
>  deltaspike-core-impl
> -${project.version}
>  runtime
>  
>
>  
>  org.apache.deltaspike.modules
>  deltaspike-security-module-api
> -${project.version}
>  compile
>  
>
>  
>  org.apache.deltaspike.modules
>  deltaspike-security-module-impl
> -${project.version}
>  runtime
>  
>
>  
>  org.apache.deltaspike.modules
>  deltaspike-jpa-module-api
> -${project.version}
>  compile
>  
>
>  
>  org.apache.deltaspike.modules
>  deltaspike-jpa-module-impl
> -${project.version}
>  runtime
>  
>
>  
>  org.apache.deltaspike.modules
>  deltaspike-servlet-module-api
> -${project.version}
>  compile
>  
>
>  
>  org.apache.deltaspike.modules
>  deltaspike-servlet-module-impl
> -${project.version}
>  runtime
>  
>
>  
>  org.apache.deltaspike.modules
>  deltaspike-jsf-module-api
> -${project.version}
>  compile
>  
>
>  
>  org.apache.deltaspike.modules
>  deltaspike-jsf-module-impl
> -${project.version}
>  runtime
>  
>  
>  org.apache.deltaspike.modules
>  deltaspike-jsf-module-impl-ee6
> - 

Re: [2/2] deltaspike git commit: clean up superfluous stuff in our poms

[John D. Ament]

This is actually pretty import to keep, all of the dependencies in the dist
pom.  Without these with the explicit scope of compile, the remaining
targets won't work correctly.

On Sun, May 28, 2017 at 6:37 AM  wrote:

> clean up superfluous stuff in our poms
>
> yet another dependencyManagement where a ${deltaspike.version} would have
> been enough...
>
>
> Project: http://git-wip-us.apache.org/repos/asf/deltaspike/repo
> Commit: http://git-wip-us.apache.org/repos/asf/deltaspike/commit/a62a93fc
> Tree: http://git-wip-us.apache.org/repos/asf/deltaspike/tree/a62a93fc
> Diff: http://git-wip-us.apache.org/repos/asf/deltaspike/diff/a62a93fc
>
> Branch: refs/heads/master
> Commit: a62a93fca4b9664f523077ce86fa25b9dc41915d
> Parents: 3ab179f
> Author: Mark Struberg 
> Authored: Sun May 28 11:11:48 2017 +0200
> Committer: Mark Struberg 
> Committed: Sun May 28 11:37:34 2017 +0200
>
> --
>  deltaspike/cdictrl/pom.xml |  18 +---
>  deltaspike/dist/pom.xml| 198 
>  deltaspike/parent/pom.xml  |  14 +++
>  3 files changed, 17 insertions(+), 213 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/deltaspike/blob/a62a93fc/deltaspike/cdictrl/pom.xml
> --
> diff --git a/deltaspike/cdictrl/pom.xml b/deltaspike/cdictrl/pom.xml
> index bb9287d..157d53d 100644
> --- a/deltaspike/cdictrl/pom.xml
> +++ b/deltaspike/cdictrl/pom.xml
> @@ -36,9 +36,6 @@
>  
>  
>  OWB
> -
> -true
> -
>
>  
>  api
> @@ -93,19 +90,10 @@
>  
>
>  
> -apache-release
> -
> -
> -api
> -impl-owb
> -impl-weld
> -impl-openejb
> -servlet
> -tck
> -
> -
> -
>  distribution
> +
> +true
> +
>
>  
>  api
>
>
> http://git-wip-us.apache.org/repos/asf/deltaspike/blob/a62a93fc/deltaspike/dist/pom.xml
> --
> diff --git a/deltaspike/dist/pom.xml b/deltaspike/dist/pom.xml
> index 1ca37eb..88e6f8f 100644
> --- a/deltaspike/dist/pom.xml
> +++ b/deltaspike/dist/pom.xml
> @@ -34,204 +34,6 @@
>
>  Apache DeltaSpike Distribution
>
> -
> -
> -
> -org.apache.deltaspike.core
> -deltaspike-core-api
> -${project.version}
> -compile
> -
> -
> -
> -org.apache.deltaspike.core
> -deltaspike-core-impl
> -${project.version}
> -runtime
> -
> -
> -
> -org.apache.deltaspike.modules
> -deltaspike-security-module-api
> -${project.version}
> -compile
> -
> -
> -
> -org.apache.deltaspike.modules
> -deltaspike-security-module-impl
> -${project.version}
> -runtime
> -
> -
> -
> -org.apache.deltaspike.modules
> -deltaspike-jpa-module-api
> -${project.version}
> -compile
> -
> -
> -
> -org.apache.deltaspike.modules
> -deltaspike-jpa-module-impl
> -${project.version}
> -runtime
> -
> -
> -
> -org.apache.deltaspike.modules
> -deltaspike-servlet-module-api
> -${project.version}
> -compile
> -
> -
> -
> -org.apache.deltaspike.modules
> -deltaspike-servlet-module-impl
> -${project.version}
> -runtime
> -
> -
> -
> -org.apache.deltaspike.modules
> -deltaspike-jsf-module-api
> -${project.version}
> -compile
> -
> -
> -
> -org.apache.deltaspike.modules
> -deltaspike-jsf-module-impl
> -${project.version}
> -runtime
> -
> -
> -org.apache.deltaspike.modules
> -deltaspike-jsf-module-impl-ee6
> -${project.version}
> -runtime
> -
> -
> -
> -org.apache.deltaspike.modules
> -deltaspike-data-module-api
> -${project.version}
> -compile
> -
> -
> -   

Re: [VOTE] Release Apache DeltaSpike-1.8.0

[John D. Ament]

On Sat, May 27, 2017 at 12:41 PM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> Found them locally. Seems they are not treated as attached artifacts? Why
> so?
>
> I'm not able to replicate the issue when I follow the release
instructions, I just staged a release and got all of the artifacts.

I'd recommend just running a mvn deploy -Pdistribution from the 1.8.0 tag,
that should resolve this.


> I can put them to dist/dev.
> Which of the artifacts do you need?
>

bom, full distribution.


>
> LieGrue,
> strub
>
> > Am 27.05.2017 um 17:15 schrieb John D. Ament <johndam...@apache.org>:
> >
> > BTW while the release only matters about source, we know users care about
> > binaries [1] [2]
> >
> >
> > [1]: https://issues.apache.org/jira/browse/DELTASPIKE-1194
> > [2]:
> >
> https://lists.apache.org/thread.html/72191470ff23a7b11a16b3b8e9d16eba48a755e552b58b9c88b426c2@%3Cusers.deltaspike.apache.org%3E
> >
> >
> > On Sat, May 27, 2017 at 11:10 AM John D. Ament <john.d.am...@gmail.com>
> > wrote:
> >
> >> Did you run with -Pdistribution -DreleaseProfiles=distribution as
> >> mentioned on [1]?
> >>
> >> [1]: http://deltaspike.apache.org/steps_for_a_release.html
> >>
> >> On Sat, May 27, 2017 at 11:06 AM Mark Struberg
> <strub...@yahoo.de.invalid>
> >> wrote:
> >>
> >>> Nothing has been changed in the build afaik.
> >>> So if the bom was not produced via the maven build then it is not here
> -
> >>> and most probably never has been.
> >>>
> >>> Note that an ASF release is ONLY about the sources and not about any
> >>> binary.
> >>> Binaries are just served for convenience.
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>> Am 27.05.2017 um 15:37 schrieb John D. Ament <johndam...@apache.org>:
> >>>>
> >>>> Hi Mark,
> >>>>
> >>>> I don't see the actual binary distribution/distribution bom in the
> >>> release
> >>>> repo.  Are they missing?  If they are I'm -1, I use the bom in my
> >>> project
> >>>> today.
> >>>>
> >>>> John
> >>>>
> >>>> On Wed, May 24, 2017 at 10:48 AM Mark Struberg
> >>> <strub...@yahoo.de.invalid>
> >>>> wrote:
> >>>>
> >>>>> Hi folks!
> >>>>>
> >>>>> I'd like to call a VOTE on releasing Apache DeltaSpike-1.8.0
> >>>>>
> >>>>> There have been lots of improvements and bug fixes:
> >>>>>
> >>>>>
> >>>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312820=12338003
> >>>>>
> >>>>>
> >>>>> The staging repository is
> >>>>>
> >>>>>
> >>>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1043/
> >>>>>
> >>>>> I've pushed the build branch to my github repo.
> >>>>> https://github.com/struberg/deltaspike/tree/release_deltaspike_1.8.0
> >>>>> the tag is
> >>> https://github.com/struberg/deltaspike/tree/deltaspike-1.8.0
> >>>>>
> >>>>> This will get merge and pushed to ASF master once the VOTE succeeds.
> >>>>>
> >>>>> The source release is here
> >>>>>
> >>>>>
> >>>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1043/org/apache/deltaspike/deltaspike/1.8.0/
> >>>>>
> >>>>> Please VOTE:
> >>>>>
> >>>>> [+1] yeah dude, let's ship it!
> >>>>> [+0] meh, don't care
> >>>>> [-1] woah, stop there is a ${showstopper}
> >>>>>
> >>>>> The VOTE is open for 72h.
> >>>>>
> >>>>> txs and LieGrue,
> >>>>> strub
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
>
>

Re: [VOTE] Release Apache DeltaSpike-1.8.0

[John D. Ament]

BTW while the release only matters about source, we know users care about
binaries [1] [2]


[1]: https://issues.apache.org/jira/browse/DELTASPIKE-1194
[2]:
https://lists.apache.org/thread.html/72191470ff23a7b11a16b3b8e9d16eba48a755e552b58b9c88b426c2@%3Cusers.deltaspike.apache.org%3E


On Sat, May 27, 2017 at 11:10 AM John D. Ament <john.d.am...@gmail.com>
wrote:

> Did you run with -Pdistribution -DreleaseProfiles=distribution as
> mentioned on [1]?
>
> [1]: http://deltaspike.apache.org/steps_for_a_release.html
>
> On Sat, May 27, 2017 at 11:06 AM Mark Struberg <strub...@yahoo.de.invalid>
> wrote:
>
>> Nothing has been changed in the build afaik.
>> So if the bom was not produced via the maven build then it is not here -
>> and most probably never has been.
>>
>> Note that an ASF release is ONLY about the sources and not about any
>> binary.
>> Binaries are just served for convenience.
>>
>> LieGrue,
>> strub
>>
>>
>> > Am 27.05.2017 um 15:37 schrieb John D. Ament <johndam...@apache.org>:
>> >
>> > Hi Mark,
>> >
>> > I don't see the actual binary distribution/distribution bom in the
>> release
>> > repo.  Are they missing?  If they are I'm -1, I use the bom in my
>> project
>> > today.
>> >
>> > John
>> >
>> > On Wed, May 24, 2017 at 10:48 AM Mark Struberg
>> <strub...@yahoo.de.invalid>
>> > wrote:
>> >
>> >> Hi folks!
>> >>
>> >> I'd like to call a VOTE on releasing Apache DeltaSpike-1.8.0
>> >>
>> >> There have been lots of improvements and bug fixes:
>> >>
>> >>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312820=12338003
>> >>
>> >>
>> >> The staging repository is
>> >>
>> >>
>> https://repository.apache.org/content/repositories/orgapachedeltaspike-1043/
>> >>
>> >> I've pushed the build branch to my github repo.
>> >> https://github.com/struberg/deltaspike/tree/release_deltaspike_1.8.0
>> >> the tag is
>> https://github.com/struberg/deltaspike/tree/deltaspike-1.8.0
>> >>
>> >> This will get merge and pushed to ASF master once the VOTE succeeds.
>> >>
>> >> The source release is here
>> >>
>> >>
>> https://repository.apache.org/content/repositories/orgapachedeltaspike-1043/org/apache/deltaspike/deltaspike/1.8.0/
>> >>
>> >> Please VOTE:
>> >>
>> >> [+1] yeah dude, let's ship it!
>> >> [+0] meh, don't care
>> >> [-1] woah, stop there is a ${showstopper}
>> >>
>> >> The VOTE is open for 72h.
>> >>
>> >> txs and LieGrue,
>> >> strub
>> >>
>> >>
>> >>
>>
>>

Re: [VOTE] Release Apache DeltaSpike-1.8.0

[John D. Ament]

Did you run with -Pdistribution -DreleaseProfiles=distribution as mentioned
on [1]?

[1]: http://deltaspike.apache.org/steps_for_a_release.html

On Sat, May 27, 2017 at 11:06 AM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> Nothing has been changed in the build afaik.
> So if the bom was not produced via the maven build then it is not here -
> and most probably never has been.
>
> Note that an ASF release is ONLY about the sources and not about any
> binary.
> Binaries are just served for convenience.
>
> LieGrue,
> strub
>
>
> > Am 27.05.2017 um 15:37 schrieb John D. Ament <johndam...@apache.org>:
> >
> > Hi Mark,
> >
> > I don't see the actual binary distribution/distribution bom in the
> release
> > repo.  Are they missing?  If they are I'm -1, I use the bom in my project
> > today.
> >
> > John
> >
> > On Wed, May 24, 2017 at 10:48 AM Mark Struberg <strub...@yahoo.de.invalid
> >
> > wrote:
> >
> >> Hi folks!
> >>
> >> I'd like to call a VOTE on releasing Apache DeltaSpike-1.8.0
> >>
> >> There have been lots of improvements and bug fixes:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312820=12338003
> >>
> >>
> >> The staging repository is
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1043/
> >>
> >> I've pushed the build branch to my github repo.
> >> https://github.com/struberg/deltaspike/tree/release_deltaspike_1.8.0
> >> the tag is https://github.com/struberg/deltaspike/tree/deltaspike-1.8.0
> >>
> >> This will get merge and pushed to ASF master once the VOTE succeeds.
> >>
> >> The source release is here
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1043/org/apache/deltaspike/deltaspike/1.8.0/
> >>
> >> Please VOTE:
> >>
> >> [+1] yeah dude, let's ship it!
> >> [+0] meh, don't care
> >> [-1] woah, stop there is a ${showstopper}
> >>
> >> The VOTE is open for 72h.
> >>
> >> txs and LieGrue,
> >> strub
> >>
> >>
> >>
>
>

Re: jbossas 7.1.1.Final build

[John D. Ament]

Mark,

Is it the same issue as [1]?

John

[1]:
https://lists.apache.org/thread.html/d01555301db719485d5ced44b15f4e875af3472a8693e78193410308@%3Cdev.deltaspike.apache.org%3E

On Sun, May 21, 2017 at 11:49 AM Mark Struberg 
wrote:

> Hi folks!
>
> Could someone from JBoss take a quick look at the 7.1.1.Final build?
>
> mvn clean install -Pjbossas-build-managed-7
>
> This stops at core-impl. I literally mean 'stops'.
>
>
> txs and LieGrue,
> strub
>

[jira] [Assigned] (DELTASPIKE-1212) Introduce a ConfigResolver.resolveAllProperties method

[John D. Ament (JIRA)]

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

John D. Ament reassigned DELTASPIKE-1212:
-

Assignee: John D. Ament

> Introduce a ConfigResolver.resolveAllProperties method
> --
>
> Key: DELTASPIKE-1212
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1212
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.7.0
>    Reporter: John D. Ament
>    Assignee: John D. Ament
> Fix For: 1.8.1
>
>
> Invoking ConfigResolver.getAllProperties does not expand out any inlined 
> variables.  In addition, assume the following properties file and project 
> stage = Development
> {code}
> some-service-url=${edge-server-url}/some-service
> edge-server-url=undefined
> edge-server-url.Development=http://development:8081
> edge-server-url.Staging=http://staging:8081
> edge-server-url.Production=http://prod:8081
> {code}
> calling {{getAllProperties}} returns the raw output of this file.  
> Introducing a new {{resolveAllProperties}} method would only return back the 
> active values.  The expected result would be
> {code}
> some-service-url=http://development:8081/some-service
> edge-server-url=http://development:8081
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1212) Introduce a ConfigResolver.resolveAllProperties method

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1212:
---

I disagree with closing hard to implement things as won't fix.  We'll come up 
with a way to solve this, even if its expensive.

> Introduce a ConfigResolver.resolveAllProperties method
> --
>
> Key: DELTASPIKE-1212
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1212
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.7.0
>    Reporter: John D. Ament
> Fix For: 1.8.1
>
>
> Invoking ConfigResolver.getAllProperties does not expand out any inlined 
> variables.  In addition, assume the following properties file and project 
> stage = Development
> {code}
> some-service-url=${edge-server-url}/some-service
> edge-server-url=undefined
> edge-server-url.Development=http://development:8081
> edge-server-url.Staging=http://staging:8081
> edge-server-url.Production=http://prod:8081
> {code}
> calling {{getAllProperties}} returns the raw output of this file.  
> Introducing a new {{resolveAllProperties}} method would only return back the 
> active values.  The expected result would be
> {code}
> some-service-url=http://development:8081/some-service
> edge-server-url=http://development:8081
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

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

John D. Ament updated DELTASPIKE-940:
-
Fix Version/s: (was: 2.0)
   1.8.0

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>    Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.0
>
> Attachments: ds940.patch
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

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

John D. Ament updated DELTASPIKE-940:
-
Attachment: ds940.patch

This is basically what I had in mind for the first pass.  Deprecate the 
existing behavior, and let that be baked in.

To support the existing, we can create a qualifier based implementation in SPI, 
especially since it doesn't support qualifiers with parameters in them.

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>    Assignee: John D. Ament
>Priority: Minor
> Fix For: 2.0
>
> Attachments: ds940.patch
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [DISCUSS] release 1.8.0 next week?

[John D. Ament]

IMHO, we should resolve [1] first, and then figure out if when we want to
cut 1.8.0.

[1]:
https://lists.apache.org/thread.html/dd64597c0e79c7b2dfc2c5bdea09d7d12efc1979b41dc494b1ee8da4@%3Cdev.deltaspike.apache.org%3E


On Tue, May 9, 2017 at 8:18 AM Mark Struberg 
wrote:

> Hi folks!
>
> I'm currently working on a few tickets and would love to release early
> next week.
> Any objections?
>
> If you like to tacke some features and tickets then please shout out, so
> we can better coordinate the work on it.
>
> txs and LieGrue,
> strub

[jira] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-940:
--

While we shouldn't remove the old behavior pre-DS 2.0, it would be good to 
provide similar capabilities in both.

As a result, I think it makes sense to include qualifier in the look up while 
still allowing class based resolution.

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>    Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.0
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

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

John D. Ament updated DELTASPIKE-940:
-
Fix Version/s: 1.8.0

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>    Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.0
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

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

John D. Ament reassigned DELTASPIKE-940:


Assignee: John D. Ament  (was: Thomas Hug)

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>    Assignee: John D. Ament
>Priority: Minor
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (DELTASPIKE-1193) Repository methods should consider Boolean and boolean the same

[John D. Ament (JIRA)]

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

John D. Ament reassigned DELTASPIKE-1193:
-

Assignee: John D. Ament

> Repository methods should consider Boolean and boolean the same
> ---
>
> Key: DELTASPIKE-1193
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1193
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>    Reporter: John D. Ament
>    Assignee: John D. Ament
>
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/property/MethodPropertyImpl.java#L79
> In this case, we're treating boolean as valid for is methods, the same is not 
> applied to Boolean types.  This means your entities can't have Boolean 
> methods.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (DELTASPIKE-1225) deltaspike.testcontrol.stop_container should stop the container after all tests executed

[John D. Ament (JIRA)]

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

John D. Ament reassigned DELTASPIKE-1225:
-

Assignee: John D. Ament

> deltaspike.testcontrol.stop_container should stop the container after all 
> tests executed
> 
>
> Key: DELTASPIKE-1225
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1225
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: TestControl
>Affects Versions: 1.7.2
>Reporter: Remo
>Assignee: John D. Ament
>Priority: Minor
>
> deltaspike.testcontrol.stop_container is very useful to speed up test cases. 
> However, it results that the container does not getting shutdown at all. This 
> should still be done after ALL the tests have been executed.
> With Gradle the current behavior is quite a problem. The Gradle Wrappers keep 
> by default the VM running. And as such, test cases must properly cleanup and 
> free resources. Otherwise the Gradle wrapper consumes more and more memory 
> and dies at some point.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (DELTASPIKE-1229) Allow the use of @Alternative to implement a custom TimestampsProvider

[John D. Ament (JIRA)]

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

John D. Ament reassigned DELTASPIKE-1229:
-

Assignee: John D. Ament

> Allow the use of @Alternative to implement a custom TimestampsProvider
> --
>
> Key: DELTASPIKE-1229
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1229
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Data-Module, JPA-Module
>Affects Versions: 1.7.2
> Environment: Deltaspike 1.7.2. CDI 1.1 Wildfly AS 9.0.2.Final
>Reporter: Nico Schlebusch
>Assignee: John D. Ament
>
> I'm using the JPA {{@EntityListeners(AuditEntityListener.class)}} and the 
> audit functionality of Deltaspike Data ({{@CreatedOn}}, {{@ModifiedOn}} and 
> {{@ModifiedBy}} annotations) on an entity bean with the difference that I 
> have a custom implementation of {{java.time.ChronoLocalDateTime}} which 
> converts any {{LocalDateTime}} + {{ZoneOffset}} OR a {{ZonedDateTime}} to be 
> the UTC date & time.
> Is there a way to implement my own 
> {{org.apache.deltaspike.data.impl.audit.PrePersistAuditListener}} and 
> {{org.apache.deltaspike.data.impl.audit.PreUpdateAuditListener}} and use them 
> to create the instance of {{UTCDateTime}} required by he fields marked with 
> {{@InsertedOn}} and {{@ModiefiedOn}}?
> See this [SO 
> Question|http://stackoverflow.com/questions/41057116/deltaspike-data-cdi-jpa-custom-prepersistauditlistener-and-preupdateauditlis]
>  and the discussion on this [mail 
> thread|https://lists.apache.org/thread.html/c47a6187d03fc8f665c6b3c7ab760e80084db3b8d4f83fe9d34015d8@%3Cusers.deltaspike.apache.org%3E]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (DELTASPIKE-1236) unit testing a servlet that uses injection

[John D. Ament (JIRA)]

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

John D. Ament closed DELTASPIKE-1236.
-
Resolution: Won't Fix

> unit testing a servlet that uses injection
> --
>
> Key: DELTASPIKE-1236
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1236
> Project: DeltaSpike
>  Issue Type: Improvement
>Affects Versions: 1.7.2
> Environment: Tomcat
>Reporter: Stephen More
>
> I have been using org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner 
> to test JSF backing beans and everything seems to be working well.
> At this point I am struggling how to test a plain old servlet that uses 
> injection, are there any examples anywhere ?
> The current - non working test code can be found here: 
> https://github.com/mores/maven-examples/tree/master/prime-deltaspike
> Servlet works as expected when deployed - output is survey says: 3.96 
> (https://github.com/mores/maven-examples/blob/master/prime-deltaspike/src/main/java/org/test/MyServlet.java)
> But when trying to run the test, windowContext appears to be null. ( 
> https://github.com/mores/maven-examples/blob/master/prime-deltaspike/src/test/java/org/test/MyServletTest.java
>  )



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1240) [Config] add List support

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1240:
---

FYI, while there's documentation committed in this ticket it was never 
published.  I'm about to publish the docs.

> [Config] add List support
> -
>
> Key: DELTASPIKE-1240
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1240
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.0
>
>
> Currently there is no built-in way to configure lists of values. This is 
> useful if you think about e.g. something like
> {code}
> mycompany.myproj.batch.error.email=someone@mycomp,else@mycomp,ops@mycomp
> {code}
> Any ',' character inside the payload might get escaped via '\,' and a single 
> backslash '\' itself with double-backslash '\\'



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (DELTASPIKE-1252) data-documentation missing Optional return value

[John D. Ament (JIRA)]

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

John D. Ament resolved DELTASPIKE-1252.
---
Resolution: Fixed

> data-documentation missing Optional return value
> 
>
> Key: DELTASPIKE-1252
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1252
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module, Documentation
>Affects Versions: 1.7.2
>Reporter: Jan Matèrne
>    Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.0
>
>
> http://deltaspike.apache.org/documentation/data.html lists the format for 
> methods:
> (Entity|List) (prefix)(Property[Comparator]){Operator Property 
> [Comparator]}
> Here java.util.Optional is missing:
> "(Entity|Optional|List) 
> (prefix)(Property[Comparator]){Operator Property [Comparator]}
>  
> Or in more concrete words:
> • The query method must either return an entity or an java.util.Optional 
> or a list of entities.
> • It must start with the findBy prefix ..."



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1252) data-documentation missing Optional return value

[John D. Ament (JIRA)]

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

John D. Ament commented on DELTASPIKE-1252:
---

Fair point... stream is missing there as well.

> data-documentation missing Optional return value
> 
>
> Key: DELTASPIKE-1252
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1252
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module, Documentation
>Affects Versions: 1.7.2
>Reporter: Jan Matèrne
>Priority: Minor
> Fix For: 1.8.0
>
>
> http://deltaspike.apache.org/documentation/data.html lists the format for 
> methods:
> (Entity|List) (prefix)(Property[Comparator]){Operator Property 
> [Comparator]}
> Here java.util.Optional is missing:
> "(Entity|Optional|List) 
> (prefix)(Property[Comparator]){Operator Property [Comparator]}
>  
> Or in more concrete words:
> • The query method must either return an entity or an java.util.Optional 
> or a list of entities.
> • It must start with the findBy prefix ..."



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-1252) data-documentation missing Optional return value

[John D. Ament (JIRA)]

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

John D. Ament updated DELTASPIKE-1252:
--
Fix Version/s: 1.8.0

> data-documentation missing Optional return value
> 
>
> Key: DELTASPIKE-1252
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1252
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module, Documentation
>Affects Versions: 1.7.2
>Reporter: Jan Matèrne
>    Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.0
>
>
> http://deltaspike.apache.org/documentation/data.html lists the format for 
> methods:
> (Entity|List) (prefix)(Property[Comparator]){Operator Property 
> [Comparator]}
> Here java.util.Optional is missing:
> "(Entity|Optional|List) 
> (prefix)(Property[Comparator]){Operator Property [Comparator]}
>  
> Or in more concrete words:
> • The query method must either return an entity or an java.util.Optional 
> or a list of entities.
> • It must start with the findBy prefix ..."



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (DELTASPIKE-1252) data-documentation missing Optional return value

[John D. Ament (JIRA)]

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

John D. Ament reassigned DELTASPIKE-1252:
-

Assignee: John D. Ament

> data-documentation missing Optional return value
> 
>
> Key: DELTASPIKE-1252
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1252
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module, Documentation
>Affects Versions: 1.7.2
>Reporter: Jan Matèrne
>    Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.0
>
>
> http://deltaspike.apache.org/documentation/data.html lists the format for 
> methods:
> (Entity|List) (prefix)(Property[Comparator]){Operator Property 
> [Comparator]}
> Here java.util.Optional is missing:
> "(Entity|Optional|List) 
> (prefix)(Property[Comparator]){Operator Property [Comparator]}
>  
> Or in more concrete words:
> • The query method must either return an entity or an java.util.Optional 
> or a list of entities.
> • It must start with the findBy prefix ..."



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [DISCUSS] updating prerequisite to Java 1.7 for DeltaSpike-1.8.x and higher?

[John D. Ament]

What feature is that?

On May 8, 2017 2:51 PM, "Mark Struberg"  wrote:

Paths and other nio features for accessing file attributes.
Those are only available in Java7, and I need those now for a new
DeltaSpike feature...

Java6 is EOL since 2013 anyway.
I don't even have a java6 jdk anymore...

LieGrue,
strub



> Am 08.05.2017 um 20:28 schrieb Romain Manni-Bucau :
>
> +0 for the same reason
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | JavaEE Factory
> 
>
> 2017-05-08 20:25 GMT+02:00 Thomas Andraschko :
>
>> +0
>> There is no big benefit for using java7.
>> IMO we should just upgrade to java8 if we start DS 2.0.
>>
>> 2017-05-08 17:44 GMT+02:00 Mark Struberg :
>>
>>> Java9 is just around the corner and we still support Java6.
>>> Do we finally like to raise our prerequisites to Java7 at least?
>>> This would be for the upcoming 1.8.0 release and onwards.
>>>
>>> Wdyt?
>>>
>>> LieGrue,
>>> strub
>>>
>>

Re: [DISCUSS] streamline our support

[John D. Ament]

Some notes in line:

On Sun, Apr 2, 2017 at 3:55 PM Mark Struberg 
wrote:

> Hi folks!
>
> I would like to start a discussion about which Containers we like to
> support in 1.8.0 and later.
> We still have CI builds for ancient servers which are known to be buggy
> and will never get any updates anymore.
> So imo we should drop those.
>
>
Of the tests that fail, there are few that I would consider to be outside
the realm of bugs in our code.  For instance, Transactional repositories
don't run on Wildfly, last I checked, and its because of something we're
doing outside the spec, but turns out RedHat components do it as well.  Not
sure if its been fixed, or maybe we just need to fix our tests to be a bit
less buggy.

Most of our build failures are due to lack of maintenance on our side -
there's way too many jobs, and keeping up with them is a pain.  I know Gav
for instance tends to edit files directly when making broad changes.  Some
of our builds have broken recently from it (haven't dug into it too much,
was actually planning to look tonight/tomorrow).


> For me the most important containers I'd definitly keep are
>
> * OWB-1.2.x (latest CDI-1.0)
> * OWB-1.7.x (latest CDI-1.2)
> * Weld-xxx? (latest CDI-1.0, input regarding version needed)
>
Weld 1.1.34 released 2 months ago

> * Weld-xxx? (latest CDI-1.2), input regarding version needed)
>
Weld 2.4.2.SP2,  2.4.3 is coming soon I suspect.  I also have a job
pointing to Weld 3 so we can test against the CRs.

> * TomEE EE6 latest version
> * TomEE EE7 latest version
> * Wildfly EE7 latest version
>
10.1 , 11 Alphas just started.

> * Wildfly EE6 IF there is anything still maintained? (guess rather not,
> right?
>
Wildfly was always EE7 and up.  Before that, JBoss AS 7 was the EE 6
edition.  The last patch release I see against EAP is 6.4 from about 2
years ago.

> * GlassFish 4 IF it is still maintained (which I think is not, so this
> will likely get kicked)
> * GlassFish 4 IF it is stil maintained (not sure about the status)
> * Payara (will check with Mike which version officially have support for)
>
Our build points to 4.1.1.162, 4.1.1.171.1 is the latest I see they've
published.

> * WLS-12c (not sure who runs it, but I think it is still maintained)
>
12.2.1.2


>
> Anything else?
> We currently have a bunch of ancient CI jobs which are a.) often broken
> and spam our lists b.) are expensive to maintain and run.
>
> Any input?
>
>
Personally, I would love to take this opportunity to switch our build
system to be based on Jenkinsfile and a pipeline, instead of all of these
build jobs.  This way we can maintain in source control what we run CI
against, and provide a more straight-forward set of build tasks to run.  It
would also reduce Jenkins overhead dramatically since its fewer jobs net to
run.  Please it looks prettier.

For anything we're saying we're kicking, I would like to avoid deleting
maven profiles, and instead just delete jenkins jobs.  This way if someone
locally wants to take it on, they still can.

Would there be any benefit to seeing if there's a way to run our test suite
against Wildfly Swarm?  And potentially Websphere Liberty?


> txs and LieGrue,
> strub
>
>

Re: JBossAS 7 build stuck

[John D. Ament]

Are you running Java 8 as your JVM?

John

On Sun, Apr 2, 2017 at 8:24 AM Mark Struberg 
wrote:

> hi folks!
>
> mvn clean install -Pjbossas-build-managed-7 | tee mvn-jbossas_7.log
>
> This gets stuck whenever I run it. Used to work in the (maybe distant)
> past.
> Any idea?
>
> output is
>
> ---
>  T E S T S
> ---
> Concurrency config is parallel='none', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> Apr 02, 2017 2:19:17 PM
> org.jboss.as.arquillian.container.managed.ManagedDeployableContainer
> startInternal
> INFORMATION: Starting container with:
> [/Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/bin/java,
> -client, -noverify, -Xms64m, -Xmx1024m, -XX:MaxPermSize=512m,
> -Djboss.socket.binding.port-offset=4,
> -Dcdicontainer.version=weld-1.1.9.Final, -ea,
> -Djboss.home.dir=/var/folders/cc/5g6j5x3x74154g2rmmtpz_4wgn/T//deltaspike-arquillian-containers/jboss-as-7.1.1.Final,
> -Dorg.jboss.boot.log.file=/var/folders/cc/5g6j5x3x74154g2rmmtpz_4wgn/T//deltaspike-arquillian-containers/jboss-as-7.1.1.Final/standalone/log/boot.log,
> -Dlogging.configuration=file:/var/folders/cc/5g6j5x3x74154g2rmmtpz_4wgn/T//deltaspike-arquillian-containers/jboss-as-7.1.1.Final/standalone/configuration/logging.properties,
> -Djboss.modules.dir=/private/var/folders/cc/5g6j5x3x74154g2rmmtpz_4wgn/T/deltaspike-arquillian-containers/jboss-as-7.1.1.Final/modules,
> -Djboss.bundles.dir=/private/var/folders/cc/5g6j5x3x74154g2rmmtpz_4wgn/T/deltaspike-arquillian-containers/jboss-as-7.1.1.Final/bundles,
> -jar,
> /var/folders/cc/5g6j5x3x74154g2rmmtpz_4wgn/T/deltaspike-arquillian-containers/jboss-as-7.1.1.Final/jboss-modules.jar,
> -mp,
> /var/folders/cc/5g6j5x3x74154g2rmmtpz_4wgn/T//deltaspike-arquillian-containers/jboss-as-7.1.1.Final/modules,
> -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone,
> -server-config, standalone.xml]
> Apr 02, 2017 2:19:18 PM org.xnio.Xnio 
> INFO: XNIO Version 3.0.0.GA
> Apr 02, 2017 2:19:18 PM org.xnio.nio.NioXnio 
> INFO: XNIO NIO Implementation Version 3.0.0.GA
> Apr 02, 2017 2:19:18 PM org.jboss.remoting3.EndpointImpl 
> INFO: JBoss Remoting version 3.2.3.GA
>
> I'd love to update the various built in profiles to more recent versions,
> so plz feel free to take over. I'll focus on OWB + TomEE right now.
>
> Txs and LieGrue,
> strub
>
>
>
>

[jira] [Updated] (DELTASPIKE-1238) Create a better default TransactionStrategy

[John D. Ament (JIRA)]

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

John D. Ament updated DELTASPIKE-1238:
--
Description: Create a better default TransactionStrategy that handles more 
use cases out of the box.  (was: Make EnvironmentAwareTransactionStrategy the 
default transaction strategy, since it properly looks up container managed, 
resource local without requiring the user to do anything.)

> Create a better default TransactionStrategy
> ---
>
> Key: DELTASPIKE-1238
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1238
> Project: DeltaSpike
>  Issue Type: Improvement
>        Reporter: John D. Ament
>    Assignee: John D. Ament
>
> Create a better default TransactionStrategy that handles more use cases out 
> of the box.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-1238) Create a better default TransactionStrategy

[John D. Ament (JIRA)]

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

John D. Ament updated DELTASPIKE-1238:
--
Summary: Create a better default TransactionStrategy  (was: Make 
EnvironmentAwareTransactionStrategy the default)

> Create a better default TransactionStrategy
> ---
>
> Key: DELTASPIKE-1238
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1238
> Project: DeltaSpike
>  Issue Type: Improvement
>        Reporter: John D. Ament
>    Assignee: John D. Ament
>
> Make EnvironmentAwareTransactionStrategy the default transaction strategy, 
> since it properly looks up container managed, resource local without 
> requiring the user to do anything.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (DELTASPIKE-1238) Make EnvironmentAwareTransactionStrategy the default

[John D. Ament (JIRA)]

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

John D. Ament reopened DELTASPIKE-1238:
---

Hey, I disagree. We can talk through it more, but it isn't a top priority for 
me right now.

> Make EnvironmentAwareTransactionStrategy the default
> 
>
> Key: DELTASPIKE-1238
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1238
> Project: DeltaSpike
>  Issue Type: Improvement
>        Reporter: John D. Ament
>    Assignee: John D. Ament
>
> Make EnvironmentAwareTransactionStrategy the default transaction strategy, 
> since it properly looks up container managed, resource local without 
> requiring the user to do anything.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (DELTASPIKE-1195) Servlet module forces application to use distributed sessions

[John D. Ament (JIRA)]

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

John D. Ament resolved DELTASPIKE-1195.
---
Resolution: Won't Fix

Wasn't me, but the user mentioned that issue is not ours, so I think we're good.

> Servlet module forces application to use distributed sessions
> -
>
> Key: DELTASPIKE-1195
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1195
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Servlet-Module
>Affects Versions: 1.7.1
>Reporter: Klaasjan Brand
>    Assignee: John D. Ament
>Priority: Minor
>
> The deltaspike-servlet-module-impl jar contains a web-fragment.xml file 
> containing a  tag. This forces every web application 
> including this jar file to support distributed sessions.
> I know it's possible to disable the parsing of fragments, but we use 
> fragments for other libraries. Besides, I don't think it's the responsibility 
> of deltaspike to decide if web application sessions are distributable.
> Could you consider removing this line?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)