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

2017-05-16 Thread 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

2017-05-16 Thread 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-1212) Introduce a ConfigResolver.resolveAllProperties method

2017-05-16 Thread Mark Struberg (JIRA) 

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

Mark Struberg updated DELTASPIKE-1212:
--
Fix Version/s: (was: 1.8.0)
   1.8.1

> 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] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

2017-05-16 Thread Mark Struberg (JIRA) 

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

Mark Struberg commented on DELTASPIKE-940:
--

--- 
deltaspike/modules/jpa/api/src/main/java/org/apache/deltaspike/jpa/api/transaction/Transactional.java
   (revision 0cdede08c07b0ed791b9018e1ea5281b690728ae)
+++ 
deltaspike/modules/jpa/api/src/main/java/org/apache/deltaspike/jpa/api/transaction/Transactional.java
   (revision )
@@ -58,8 +58,12 @@
  * {@link javax.persistence.EntityManager}s with qualifiers in a called 
method (of a different bean)
  * which isn't {@link Transactional} itself.
  *
+ * This method is now deprecated, and if you have multiple {@link 
javax.persistence.EntityManager}s you should use
+ * {@link 
org.apache.deltaspike.jpa.api.entitymanager.EntityManagerResolver}
+ *
  * @return target persistence-unit identifier
  */
+@Deprecated
 @Nonbinding Class[] qualifier() default Any.class;
 

as explained, the qualifier makes sense and is used by various projects.

> @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.3.15#6346)

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

2017-05-16 Thread 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

2017-05-16 Thread 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)

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

2017-05-16 Thread JIRA 

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

Jan Matèrne commented on DELTASPIKE-1252:
-

That commit just updates the EBNF, but left the plain text.
I had a look at the adoc and line 473 should be updated (like I said).

> 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-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

2017-05-16 Thread Mark Struberg (JIRA) 

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

Mark Struberg commented on DELTASPIKE-940:
--

+1 for moving this cleanup to 2.0 if any.

As Gerhard already explained: the Qualifier in @Transactional is to support 
multiple different Databases where we then do a 'cheap man XA'. Means we will 
first iterate over all open EntityManagers and invoke #flush() on them and only 
if that works for all connections we do a em.commit() on all.
This is not really XA, but in practice you blow up during the flush() in 98%of 
all cases.

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

2017-05-16 Thread Mark Struberg (JIRA) 

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

Mark Struberg updated DELTASPIKE-940:
-
Fix Version/s: (was: 1.8.0)
   2.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: 2.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] [Commented] (DELTASPIKE-1252) data-documentation missing Optional return value

2017-05-16 Thread Mark Struberg (JIRA) 

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

Mark Struberg commented on DELTASPIKE-1252:
---

[~johndament] [~jan] Did this commit fix the problem? Is there anything left to 
do.
Would love to either close this as resolved in 1.8.0 or move it to 1.8.1 - txs!

> 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] [Updated] (DELTASPIKE-1222) Allow query by example method expression wtih @Query annotation

2017-05-16 Thread Mark Struberg (JIRA) 

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

Mark Struberg updated DELTASPIKE-1222:
--
Fix Version/s: (was: 1.8.0)
   1.8.1

> Allow query by example method expression wtih @Query annotation
> ---
>
> Key: DELTASPIKE-1222
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1222
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Data-Module
>Reporter: Richard Juso
>  Labels: features
> Fix For: 1.8.1, 2.0
>
>
> ability to either override findBy/findAll methods with @Query annotation 
> (without using params or using params, but also allowing the E example 
> pattern)  or add support for custom method expression that could be used for 
> this purpose.  the E example would only appy to the main Entity restrictions, 
> the additional params could apply to nested entities based on param index
> ie. @Query(value = "select r from Range r where r.customId IN (select 
> e.customId from EbsUserStub e)")
>   public abstract List findBy(Range paramE, 
> SingularAttribute paramArrayOfSingularAttribute);
> or 
> @Query(value = "select r from Range r where r.customId IN (select e.customId 
> from EbsUserStub e)")
>   public abstract List findUsing(Range paramE, 
> SingularAttribute paramArrayOfSingularAttribute);
> or 
> @Query(value = "select r from Range r where r.customId IN (select e.customId 
> from EbsUserStub e where e.miscField = ?2)")
>   public abstract List findByMiscField(Range paramE, 
> SingularAttribute paramArrayOfSingularAttribute, String miscField);
> method expression could either be custom ie. findUsing,  findByEntityName, 
> findByMiscField or some other marker.



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

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

2017-05-16 Thread Mark Struberg (JIRA) 

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

Mark Struberg commented on DELTASPIKE-1212:
---

John, I'm still not sure how this could be done. 
Can we close this as wont fix?

> 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.0
>
>
> 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-1250) create a master/client encryption handling

2017-05-16 Thread ASF subversion and git services (JIRA) 

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

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

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

DELTASPIKE-1250 only log out the master.hash index key not the hash itself


> create a master/client encryption handling
> --
>
> Key: DELTASPIKE-1250
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1250
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.0
>
>
> For storing passwords in our configuration I'd like to implement a 2 stage 
> approach to symmetric encryption.
> The current ideas is to have an encrypted hash derived from a master password 
> and machine specific information (MAC, IP, expiry date, etc).
> This encrypted sequence is different on every box. But the decrypted hash is 
> not.
>  
> With this hash we can encode a user password, which is then ofc the same on 
> different boxes. 
> Of course all that is just security by obscurity, but it's still much better 
> than plaintext and even close to Hashicorp Vault.
> After all, the only really secure way is using a hardware crypto box plus the 
> user has to manually provide a password and not using static passwords but 
> 1-time consumable tokens.



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

[jira] [Updated] (DELTASPIKE-1241) [Config] fallback chain logic

2017-05-16 Thread Mark Struberg (JIRA) 

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

Mark Struberg updated DELTASPIKE-1241:
--
Fix Version/s: (was: 1.8.0)
   1.8.1

> [Config] fallback chain logic
> -
>
> Key: DELTASPIKE-1241
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1241
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.1
>
>
> We got the request to add handling similar to 
> ConfigResolver#getProjectStageAwarePropertyValue and 
> ConfigResolver#getPropertyAwarePropertyValue but in a more generic way.
> Something I've been experimenting with since a long time was to introduce a 
> more generic logic based on different lookup paths with themselves represent 
> a postfix. 
> The idea is to extend the TypedResolver with a method
> {code}
> TypedResolver#withLookupPath(String... lookupPaths)
> {code} 
> where each lookupPath String could either be a hardcoded value (e.g. 
> evaluated upfront) or a variable "${somevariable}" which will be evaluted on 
> the fly. 
> ConfigResolver.getPropertyAwarePropertyValue("dbvendor") could e.g. also be 
> written as 
> {code}
> TypedResolver ds = 
> ConfigResolver.resolve("myprj.datasource")
>.withLookupPath("${dbvendor}", "${deltaspike.projectstage}");
> ds.get();
> {code}
> Assuming we are in the ProjectStage UnitTest this would result in the 
> following lookup paths:
>  * datasource.mysql.UnitTest
>  * datasource.mysql
>  * datasource.UnitTest
>  * datasource
> The lookupChain is kind of a binary field with all flags set to 1 (in the 
> sample this would be: 11) and then decremented for each lookup (11, 10, 01, 
> 00). Where 1 means to lookup with the specific postfix and 0 without.



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

[jira] [Resolved] (DELTASPIKE-1249) Pick up ~/.deltaspike/apache-deltaspike.properties from user.home folder

2017-05-16 Thread Mark Struberg (JIRA) 

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

Mark Struberg resolved DELTASPIKE-1249.
---
Resolution: Fixed

> Pick up ~/.deltaspike/apache-deltaspike.properties from user.home folder
> 
>
> Key: DELTASPIKE-1249
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1249
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.0
>
>
> It might be very useful to pick up a property file from the users home 
> folder. 
> If it is not there it simply does not do anything. 
> If available it will get picked up. 
> A sensitive default for the ordinal might be 250, but this value can of 
> course be tweaked with the usual mechanism.



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

[jira] [Commented] (DELTASPIKE-1249) Pick up ~/.deltaspike/apache-deltaspike.properties from user.home folder

2017-05-16 Thread ASF subversion and git services (JIRA) 

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

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

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

DELTASPIKE-1249 pick up configuration from usrer home folder

The location which will be looked for is
~/.deltaspike/apache-deltaspike.properties

A ConfigSource for it will only be added if this file exists.


> Pick up ~/.deltaspike/apache-deltaspike.properties from user.home folder
> 
>
> Key: DELTASPIKE-1249
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1249
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.0
>
>
> It might be very useful to pick up a property file from the users home 
> folder. 
> If it is not there it simply does not do anything. 
> If available it will get picked up. 
> A sensitive default for the ordinal might be 250, but this value can of 
> course be tweaked with the usual mechanism.



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

[jira] [Commented] (DELTASPIKE-1249) Pick up ~/.deltaspike/apache-deltaspike.properties from user.home folder

2017-05-16 Thread Mark Struberg (JIRA) 

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

Mark Struberg commented on DELTASPIKE-1249:
---

The following file now gets picked up *if available*: 
~/.deltaspike/apache-deltaspike.properties

The ordinal is 100 by default.
One can use the standard deltaspike_ordinal=xxx property value to define any 
other ordinal.

> Pick up ~/.deltaspike/apache-deltaspike.properties from user.home folder
> 
>
> Key: DELTASPIKE-1249
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1249
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.0
>
>
> It might be very useful to pick up a property file from the users home 
> folder. 
> If it is not there it simply does not do anything. 
> If available it will get picked up. 
> A sensitive default for the ordinal might be 250, but this value can of 
> course be tweaked with the usual mechanism.



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