Re: Jakarta EE10 support

[Rudy De Busscher]

Besides the conversion javax-> jakarta, there are also some methods removed
from the CDI API, so the usage needs to be adjusted also before Deltaspike
can run in a Jakarta EE 10 environment. For example .fireEvent() and
.createInjectTarget() are removed. (were deprecated for some time)

Rudy

On Sun, 13 Nov 2022 at 10:19, Mark Struberg 
wrote:

> Hi Joren!
>
> Indeed, there is work to be done. I'll try to invest time over the next
> weeks.
>
> LieGrue,
> strub
>
> > Am 04.11.2022 um 12:59 schrieb Joren Inghelbrecht :
> >
> > Hi all,
> >
> > We're currently validating if we can migrate our applications to EE10. I
> > saw the work was captured in this ticket
> >  and is present
> on
> > the master branch
> > <
> https://github.com/rzo1/deltaspike/blob/master/deltaspike/parent/code/pom.xml#L165
> >.
> > The latest changes are however not yet released. Would it be possible to
> > launch a new release?
> >
> > I would be happy to provide any additional javax -> jakarta relocations
> if
> > necessary.
> >
> > Thank you in advance!
> >
> > Kind regards,
> > Joren Inghelbrecht
> > Harmoney NV
>
>

Re: [DISCUSS] ds for cdi 1.2+ only

[Rudy De Busscher]

I have not a clear view of the workarounds which are made and how
'bad'/hacky they are. But when we don't have major complaints about it (now
or in the past) I would not invest too much time in a temporary version for
CDI 1.2.

so #3.

Rudy

On 3 April 2018 at 22:34, Romain Manni-Bucau  wrote:

> All work for me and the apps i work on since a few years.
>
> Le 3 avr. 2018 22:17, "Thomas Andraschko"  a
> écrit :
>
> > +1 for 3)
> > the workarounds are really not that big...
> >
> > i would leave it as it is for now and start with DS 2.0 (= CDI2.0 only)
> the
> > next months.
> >
> > 2018-04-03 22:06 GMT+02:00 Gerhard Petracek :
> >
> > > hi @ all,
> > >
> > > since we will need to maintain v1.8.x for a while and it's too early
> for
> > > using cdi 2.0 (for a while), we should discuss if we should have one
> > branch
> > > using cdi 1.2+.
> > > it would allow to get rid of several workarounds (and the corresponding
> > > warnings during the bootstrapping process).
> > >
> > > we had a short discussion in the irc-channel about the following
> options:
> > > #1) ds v1.x as it is right now; ds v2: jdk8 with cdi 1.2+
> > >
> > > vs
> > >
> > > #2) ds v1.8.x: as it is right now; ds > v1.8.x && < v2.x: jdk8 with cdi
> > > v1.2+; ds v2: jdk8 with cdi 2.0+
> > >
> > > vs
> > >
> > > #3) we don't care about v1.2 as a min. requirement at all
> > > (the workarounds are minimal anyway and users can continue to ignore
> the
> > > warnings during the bootstrapping process)
> > >
> > > or for sure
> > > #4) [any other nice suggestion]
> > >
> > > -> please send your preferred approach
> > >
> > > regards,
> > > gerhard
> > >
> >
>

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

[Rudy De Busscher]

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

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

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

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

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

[Rudy De Busscher]

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

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

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

Rudy

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

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

Re: [VOTE] release Apache DeltaSpike-1.8.1

[Rudy De Busscher]

+1

Rudy

On 31 December 2017 at 08:48, Mark Struberg 
wrote:

> Yes you are right, checked directly on our Jenkins - all fine still.
>
> It was just my mail client who fooled me. It still had the subject „..
> failed..“ on the thread still.
> But the last mail was an OK message.
>
> Sorry and LieGrue,
> Strub
>
> > Am 31.12.2017 um 00:22 schrieb 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 
> > 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
> 
> >> 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 :
> 
>  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

[jira] [Resolved] (DELTASPIKE-1279) SimpleSecurityViolation needs equals/hashcode

[Rudy De Busscher (JIRA)]

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

Rudy De Busscher resolved DELTASPIKE-1279.
--
Resolution: Fixed

> SimpleSecurityViolation needs equals/hashcode
> -
>
> Key: DELTASPIKE-1279
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1279
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>    Reporter: Rudy De Busscher
>Assignee: Rudy De Busscher
> Fix For: 1.8.1
>
>
> SimpleSecurityViolation can be used to add violations to the Set of 
> violations when writing a custom voter.
> Creation of the instance can be done by 
> org.apache.deltaspike.security.api.authorization.AbstractDecisionVoter#newSecurityViolation
> But since the class SimpleSecurityViolation has no equals/hashcode, adding 2 
> or more violations with the same reason results in multiple entries within 
> the Set.
> A simple equals/hashcode based on the reason String property solves this.



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

[jira] [Updated] (DELTASPIKE-1279) SimpleSecurityViolation needs equals/hashcode

[Rudy De Busscher (JIRA)]

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

Rudy De Busscher updated DELTASPIKE-1279:
-
Fix Version/s: 1.8.1

> SimpleSecurityViolation needs equals/hashcode
> -
>
> Key: DELTASPIKE-1279
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1279
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>    Reporter: Rudy De Busscher
>Assignee: Rudy De Busscher
> Fix For: 1.8.1
>
>
> SimpleSecurityViolation can be used to add violations to the Set of 
> violations when writing a custom voter.
> Creation of the instance can be done by 
> org.apache.deltaspike.security.api.authorization.AbstractDecisionVoter#newSecurityViolation
> But since the class SimpleSecurityViolation has no equals/hashcode, adding 2 
> or more violations with the same reason results in multiple entries within 
> the Set.
> A simple equals/hashcode based on the reason String property solves this.



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

[jira] [Created] (DELTASPIKE-1279) SimpleSecurityViolation needs equals/hashcode

[Rudy De Busscher (JIRA)]

Rudy De Busscher created DELTASPIKE-1279:


 Summary: SimpleSecurityViolation needs equals/hashcode
 Key: DELTASPIKE-1279
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1279
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Core
Reporter: Rudy De Busscher


SimpleSecurityViolation can be used to add violations to the Set of violations 
when writing a custom voter.

Creation of the instance can be done by 
org.apache.deltaspike.security.api.authorization.AbstractDecisionVoter#newSecurityViolation

But since the class SimpleSecurityViolation has no equals/hashcode, adding 2 or 
more violations with the same reason results in multiple entries within the Set.

A simple equals/hashcode based on the reason String property solves this.



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

Re: [jira] [Updated] (DELTASPIKE-1250) create a master/client encryption handling

[Rudy De Busscher]

I looked up the code which I used recently related to AES.

We used the GCM block mode (as it is the most secure and fast, non-stream
based AES encryption mode.)

Something like

   * Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");*

*byte[] nonce = new byte[GCM_NONCE_LENGTH];*

*random.nextBytes(nonce);  // nonce == IV*

*GCMParameterSpec spec = new GCMParameterSpec(GCM_TAG_LENGTH, nonce);*

*cipher.init(Cipher.ENCRYPT_MODE, key, spec);*


problem is that GCM is only available with Java 8 :(

So we can probably stick with the current version (default is
AES/ECB/PKCS5Padding)


Although the idea is to just make things harder than using plain text (And
I agree that although it is not absolute or perfectly secure it is a good
thing) I propose to use SHA-256 instead of the SHA-1 (= indicated as
insecure nowadays) hashing algorithm. Just changing the name is required,
no other changes needed. This makes it harder to guess/break the masterSalt
for example. (key in master.hash file)


A few other small remarks

1) Creation of the deltaspike directory in the user home directory is wrong

line 63  if (!masterFile.mkdirs())  -> if
(!masterFile.getParentFile().mkdirs())

2) Exception message on line 109 should use the masterSalt value (as that
is the value that needs to be used to create an entry in the master.hash
file)


regards

Rudy

On 12 May 2017 at 16:09, Mark Struberg (JIRA)  wrote:

>
>  [ https://issues.apache.org/jira/browse/DELTASPIKE-1250?
> page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Mark Struberg updated DELTASPIKE-1250:
> --
> Description:
> 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.
>
>   was:
> 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 has derived from a master
> password and box-locale 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 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.
>
>
> > 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)
>

Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[Rudy De Busscher]

Hi Mark,

As I'm working lately quite a lot with security and encryption, I was
interested in your implementation.

I don't have the time today to look into details, but I already have some
questions

- Why hashing with SHA-1 (not a secure hashing algorithm anymore). Why the
additional hashing (before AES encryption) as you mention that we try only
to 'obscure'.
- When I use AES, I always use an Initialization Vector (IV) and specify
the Block mode and padding.

I'll try to find some time this weekend to study the code in detail.

best regards
Rudy


On 11 May 2017 at 19:05, Mark Struberg (JIRA)  wrote:

>
> [ https://issues.apache.org/jira/browse/DELTASPIKE-1250?
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&
> focusedCommentId=16006784#comment-16006784 ]
>
> Mark Struberg commented on DELTASPIKE-1250:
> ---
>
> A first design proposal can be found on my github repo
> https://github.com/struberg/deltaspike/tree/DELTASPIKE-1250
>
> Will now add a main method to generate the master password and encrypt
> content
>
> > 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 has derived from a master
> password and box-locale 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 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)
>

Re: 1.6 to be the last release to support Java 1.6?

[Rudy De Busscher]

+1

On 28 March 2016 at 18:30, Marcelo Souza Vieira 
wrote:

> +1
>
> 2016-03-28 12:39 GMT-03:00 Jason Porter :
>
> > +1
> >
> > On Sat, Mar 26, 2016 at 11:36 AM, Harald Wellmann <
> hwellmann...@gmail.com>
> > wrote:
> >
> > > +1
> > >
> > > 2016-03-26 17:49 GMT+01:00 Christian Kaltepoth  >:
> > >
> > > > +1
> > > >
> > > > 2016-03-26 16:50 GMT+01:00 Daniel Cunha :
> > > >
> > > > > +1 :)
> > > > >
> > > > > On Sat, Mar 26, 2016 at 10:34 AM, John D. Ament <
> > johndam...@apache.org
> > > >
> > > > > wrote:
> > > > >
> > > > > > All,
> > > > > >
> > > > > > Here's the announcement I'm going to post to the site.  Let me
> know
> > > if
> > > > > you
> > > > > > have any comments on the change.
> > > > > >
> > > > > > == End of Support Announcement - Java 6
> > > > > >
> > > > > >
> > > > > > The Apache DeltaSpike team has decided to begin dropping support
> > for
> > > > > >
> > > > > > Java 6.  The next release, 1.6.0 is currently planned to be the
> > last
> > > > > >
> > > > > > minor release to support Java 6.  Patch fixes on 1.6.x will
> > continue
> > > > > >
> > > > > > to support it, but our next minor release (1.7.0) will require
> > > > > >
> > > > > > Java 7 at a minimum.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Mar 25, 2016 at 8:17 AM Harald Wellmann <
> > > > hwellmann...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > 2016-03-25 13:09 GMT+01:00 John D. Ament <
> johndam...@apache.org
> > >:
> > > > > > >
> > > > > > > > BTW, if we do agree to drop Java 6, do we create a 1.6
> > > maintenance
> > > > > > branch
> > > > > > > > or just leave the tag, and if need be cut a bug fix release
> > then?
> > > > > > > >
> > > > > > > > John
> > > > > > > >
> > > > > > > > On Fri, Mar 25, 2016 at 8:06 AM John D. Ament <
> > > > johndam...@apache.org
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > To me, dropping support for Java 6 doesn't mean rewriting
> the
> > > > code
> > > > > > base
> > > > > > > > to
> > > > > > > > > only be compliant with Java 7 and up.
> > > > > > > > >
> > > > > > > > > It does allow for some new stuff in our codebase, if we
> want
> > to
> > > > go
> > > > > > back
> > > > > > > > > and clean it up:
> > > > > > > > >
> > > > > > > > > - try-with-resources
> > > > > > > > > - automatic type inference on generics.
> > > > > > > > >
> > > > > > > > > But those are just clean ups, no real new functionality.
> > > > > > > > >
> > > > > > > > > John
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Mar 25, 2016 at 4:24 AM Thomas Andraschko <
> > > > > > > > > andraschko.tho...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > >> basically +1
> > > > > > > > >> Most of our customers are using 1.7 since this year.
> > > > > > > > >>
> > > > > > > > >> I just wonder whats the benefit for us?
> > > > > > > > >> I think there are no language features which would improve
> > our
> > > > > code
> > > > > > > > base.
> > > > > > > > >>
> > > > > > > > >> 2016-03-25 3:25 GMT+01:00 John D. Ament <
> > > johndam...@apache.org
> > > > >:
> > > > > > > > >>
> > > > > > > > >> > Hey guys,
> > > > > > > > >> >
> > > > > > > > >> > I've brought this topic up before without much positive
> > > > > > response.  I
> > > > > > > > >> figure
> > > > > > > > >> > I'll bring it up again.
> > > > > > > > >> >
> > > > > > > > >> > I'd like to propose that DeltaSpike 1.6 be the last
> minor
> > > > > release
> > > > > > to
> > > > > > > > >> > support Java 1.6.  I suspect that most users are already
> > > using
> > > > > > Java
> > > > > > > 7
> > > > > > > > or
> > > > > > > > >> > higher.  None of our builds in CI (builds.apache.org)
> > > > currently
> > > > > > run
> > > > > > > > on
> > > > > > > > >> 1.6
> > > > > > > > >> > either, so while we can say from a syntax standpoint
> we're
> > > 1.6
> > > > > > > > compliant
> > > > > > > > >> > I'm not sure we can say from a JDK Library standpoint we
> > > don't
> > > > > > rely
> > > > > > > on
> > > > > > > > >> > anything from Java 7.
> > > > > > > > >> >
> > > > > > > > >> > We're one of the few projects that probably still
> supports
> > > > Java
> > > > > 6
> > > > > > > as a
> > > > > > > > >> > mainline development, so I was hoping we could just cut
> > 1.6
> > > as
> > > > > 1.6
> > > > > > > > >> > compliant, if we need to cut patch releases of 1.6 to
> > apply
> > > > > > patches,
> > > > > > > > but
> > > > > > > > >> > with DeltaSpike 1.7 and on, focus on Java 7 and up.
> > > > > > > > >> >
> > > > > > > > >> > John
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Daniel Cunha
> > > > > https://twitter.com/dvlc_
> > > > > http://www.tomitribe.com
> > > > > http://www.tomitribe.io
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Christian Kaltepoth
> > 

Re: Java EE 6 support

[Rudy De Busscher]

All,

Most of my clients still work with Java EE 6 (on Java SE 7), so I think it
is too early to abandon that version.

+1 for setting compile version to SE 7.

Regards
Rudy


On 25 March 2016 at 13:48, Gerhard Petracek  wrote:

> hi @ all,
>
> imo the benefit is too limited.
> cdi 1.1 added some nice parts, but mainly for users.
> we would just drop the bv-module as well as some parts of the servlet
> module.
> the jsf-module already contains optional ee7 support (-> we would just get
> rid of one small workaround).
> for the rest the benefit is minimal as well (or there won't be a change at
> all).
> ee7 is great for users and therefore we support it already, however,
> internally the benefit is too limited and ee6 servers will be around the
> next few years.
>
> -> imo v2 should be based on cdi 2.0 (-> ee8).
>
> regards,
> gerhard
>
>
>
> 2016-03-25 13:29 GMT+01:00 Romain Manni-Bucau :
>
> > Se 8 is surely too early (~1 year I think). +1 to drop ee6 from master.
> > Le 25 mars 2016 13:27, "Harald Wellmann"  a
> écrit
> > :
> >
> > > Since John raised the question about Java SE 6 support, what about Java
> > EE
> > > 6?
> > >
> > > Dropping support for Java EE 6/CDI 1.0 would simplify the code base
> > > significantly (a lot more so than moving from Java 1.6 to Java 1.7).
> > >
> > > How about starting a new release line DeltaSpike 2.x targeting Java EE
> 7+
> > > and Java SE 8+, with continued support for Java EE 6 on the 1.x branch
> > for
> > > as long as people are willing to work on backward compatibility?
> > >
> > > Regards,
> > > Harald
> > >
> >
>

Re: [VOTE] Release of Apache DeltaSpike 1.4.0

[Rudy De Busscher]

+1

On 19 May 2015 at 11:27, Gerhard Petracek gerhard.petra...@gmail.com
wrote:

 @harald:
 thx for reviewing it! we can fix that with v1.4.1 (which we could release
 short afterwards - we postponed some other patches as well).
 currently we don't maintain the osgi config actively (just because nobody
 is doing it)
 - it would be great if you can check it once the advance notice is on the
 list (see first steps for the next release).

 regards,
 gerhard



 2015-05-19 10:26 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:

  can't it be just wrap?
 
 
  Romain Manni-Bucau
  @rmannibucau https://twitter.com/rmannibucau |  Blog
  http://rmannibucau.wordpress.com | Github 
  https://github.com/rmannibucau |
  LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
  http://www.tomitribe.com
 
  2015-05-19 10:25 GMT+02:00 Harald Wellmann hwellmann...@gmail.com:
 
   -1, since this version won't work on OSGi.
  
   deltaspike-partialbean-module-impl imports package
   org.apache.deltaspike.proxy.api, but the new proxy modules are missing
  OSGi
   manifest headers.
  
   Regards,
   Harald
  
 

Re: first steps for the next release

[Rudy De Busscher]

+1

Rudy

On 8 May 2015 at 13:40, Thomas Andraschko andraschko.tho...@gmail.com
wrote:

 +1

 Am Freitag, 8. Mai 2015 schrieb Romain Manni-Bucau :

  +1
  Le 8 mai 2015 13:13, Gerhard Petracek gpetra...@apache.org
  javascript:; a écrit :
 
   hi @ all,
  
   if there are no objections, i will start with the first steps for the
  next
   release (v1.4.0) by the end of next week.
  
   regards,
   gerhard
  
 

[jira] [Commented] (DELTASPIKE-798) Support for uber-jar creation in SE support

[Rudy De Busscher (JIRA)]

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

Rudy De Busscher commented on DELTASPIKE-798:
-

I investigated the problem a bit more.

And for OWB, I already have a solution

The asm:asm:3.3.1 dependency was missing from the created jar and there was a 
need for merging the *javax.enterprise.inject.spi.Extension* files.

Within the _maven shade config_, you can achieve it by adding the following.

configuration
   transformers
  transformer 
implementation=org.apache.maven.plugins.shade.resource.ServicesResourceTransformer/
   /transformers
/configuration

For weld, I still get the  _WELD-001409 Ambiguous dependencies for type_ 
(multiple ones)  I'll try to find out why.


 Support for uber-jar creation in SE support
 ---

 Key: DELTASPIKE-798
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-798
 Project: DeltaSpike
  Issue Type: New Feature
  Components: CdiControl
Affects Versions: 1.2.0
Reporter: Rudy De Busscher
Assignee: Rafael Benevides
Priority: Minor

 When a single jar file is created with all dependencies (maven-shade-plugin) 
 the program doesn't run



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-798) Support for uber-jar creation in SE support

[Rudy De Busscher (JIRA)]

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

Rudy De Busscher commented on DELTASPIKE-798:
-

So, in attachment a maven project structure which works for OWB and Weld and 
this from within IDE and from single jar.

OWB from within IDE (ignore the maven shaded artifacts )
*mvn clean package -P OWB*

Weld from within IDE (ignore the maven shaded artifacts )
*mvn clean package -P Weld*

OWB from command-line with single jar
*mvn clean package -P OWB,shade*
*java -jar grid.jar*

Weld from command-line with single jar
*mvn clean package -P Weld*
*java -jar grid.jar*





 Support for uber-jar creation in SE support
 ---

 Key: DELTASPIKE-798
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-798
 Project: DeltaSpike
  Issue Type: New Feature
  Components: CdiControl
Affects Versions: 1.2.0
Reporter: Rudy De Busscher
Assignee: Rafael Benevides
Priority: Minor

 When a single jar file is created with all dependencies (maven-shade-plugin) 
 the program doesn't run



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-798) Support for uber-jar creation in SE support

[Rudy De Busscher (JIRA)]

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

Rudy De Busscher commented on DELTASPIKE-798:
-

Until documented, maybe this issue should be kept open.

 Support for uber-jar creation in SE support
 ---

 Key: DELTASPIKE-798
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-798
 Project: DeltaSpike
  Issue Type: New Feature
  Components: CdiControl
Affects Versions: 1.2.0
Reporter: Rudy De Busscher
Assignee: Rafael Benevides
Priority: Minor

 When a single jar file is created with all dependencies (maven-shade-plugin) 
 the program doesn't run



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-798) Support for uber-jar creation in SE support

[Rudy De Busscher (JIRA)]

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

Rudy De Busscher updated DELTASPIKE-798:

Attachment: DS_SE_Single_Jar.zip

maven example project for using maven shade plugin and DeltaSpike SE features.

 Support for uber-jar creation in SE support
 ---

 Key: DELTASPIKE-798
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-798
 Project: DeltaSpike
  Issue Type: New Feature
  Components: CdiControl
Affects Versions: 1.2.0
Reporter: Rudy De Busscher
Assignee: Rafael Benevides
Priority: Minor
 Attachments: DS_SE_Single_Jar.zip


 When a single jar file is created with all dependencies (maven-shade-plugin) 
 the program doesn't run



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-798) Support for uber-jar creation in SE support

[Rudy De Busscher (JIRA)]

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

Rudy De Busscher commented on DELTASPIKE-798:
-

Could be documented in DS documentation as people using DS will have the same 
issue as I had.

I can do it in the following weeks. Asked Gerhard already where I should put it.

 Support for uber-jar creation in SE support
 ---

 Key: DELTASPIKE-798
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-798
 Project: DeltaSpike
  Issue Type: New Feature
  Components: CdiControl
Affects Versions: 1.2.0
Reporter: Rudy De Busscher
Assignee: Rafael Benevides
Priority: Minor
 Attachments: DS_SE_Single_Jar.zip


 When a single jar file is created with all dependencies (maven-shade-plugin) 
 the program doesn't run



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-798) Support for uber-jar creation in SE support

[Rudy De Busscher (JIRA)]

Rudy De Busscher created DELTASPIKE-798:
---

 Summary: Support for uber-jar creation in SE support
 Key: DELTASPIKE-798
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-798
 Project: DeltaSpike
  Issue Type: New Feature
  Components: CdiControl
Affects Versions: 1.2.0
Reporter: Rudy De Busscher


When a single jar file is created with all dependencies (maven-shade-plugin) 
the program doesn't run



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-798) Support for uber-jar creation in SE support

[Rudy De Busscher (JIRA)]

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

Rudy De Busscher commented on DELTASPIKE-798:
-

Using the the jse-examples project

Add this to the POM

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-shade-plugin/artifactId
version2.3/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
version2.4/version
configuration
archive
manifest

mainClassorg.apache.deltaspike.example.beanmanagement.SimpleBeanLookupExample/mainClass
/manifest
/archive
/configuration
/plugin

run *maven -jar deltaspike...  .jar*
- java.lang.ClassNotFoundException

Running from within IDE, everything is fine.


 Support for uber-jar creation in SE support
 ---

 Key: DELTASPIKE-798
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-798
 Project: DeltaSpike
  Issue Type: New Feature
  Components: CdiControl
Affects Versions: 1.2.0
Reporter: Rudy De Busscher

 When a single jar file is created with all dependencies (maven-shade-plugin) 
 the program doesn't run



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-798) Support for uber-jar creation in SE support

[Rudy De Busscher (JIRA)]

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

Rudy De Busscher commented on DELTASPIKE-798:
-

Using my program,

I get a lot of issues
*with weld* 
- WELD-001409 Ambiguous dependencies 
*With OWB*
UnsatisfiedResolutionException : ExceptionControlExtension
and a lot of Class not founds 

 Support for uber-jar creation in SE support
 ---

 Key: DELTASPIKE-798
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-798
 Project: DeltaSpike
  Issue Type: New Feature
  Components: CdiControl
Affects Versions: 1.2.0
Reporter: Rudy De Busscher

 When a single jar file is created with all dependencies (maven-shade-plugin) 
 the program doesn't run



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Commented] (DELTASPIKE-589) Support WLS Profile in Data Module

[Rudy De Busscher]

Hi Thomas,

I did some testing of DeltaSpike on WLS more then  a year ago.

The issues that I had are described in
DELTASPIKE-241
DELTASPIKE-261

I stopped testing because there where more weird issues with the
classloader and didn't had the time to verify all those things.

regards
Rudy


On 11 May 2014 00:15, Thomas Hug (JIRA) j...@apache.org wrote:


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

 Thomas Hug commented on DELTASPIKE-589:
 ---

 Anyone seen this problem while running tests on WLS?

 Simple Deployment:

 {code:java}
 @Deployment
 public static Archive? deployment()
 {
 WebArchive archive = ShrinkWrap
 .create(WebArchive.class, test.war)
 .addAsWebInfResource(EmptyAsset.INSTANCE,
 ArchivePaths.create(beans.xml))
 .addAsLibraries(
 Maven.resolver().loadPomFromFile(pom.xml)
 .resolve(

 org.apache.deltaspike.core:deltaspike-core-api,

 org.apache.deltaspike.core:deltaspike-core-impl)
 .withTransitivity()
 .asFile()
 );
 return archive;
 }
 {code}

 Fails to deploy with

 {code}
 weblogic.management.DeploymentException:
 org.jboss.weld.exceptions.DeploymentException: Exception List with 4
 exceptions:
 Exception 0 :
 org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied
 dependencies for type [MBeanExtension] with qualifiers [@Default] at
 injection point [[field] @Inject private
 org.apache.deltaspike.core.impl.jmx.BroadcasterProducer.extension]
 at
 org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311)
 ...
 Exception 0 :
 org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied
 dependencies for type [ExceptionControlExtension] with qualifiers
 [@Default] at injection point [[field] @Inject private
 org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageProducer.exceptionControlExtension]
 at
 org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311)
 ...
 Exception 0 :
 org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied
 dependencies for type [DeltaSpikeContextExtension] with qualifiers
 [@Default] at injection point [[field] @Inject private
 org.apache.deltaspike.core.impl.scope.conversation.GroupedConversationArtifactProducer.deltaSpikeContextExtension]
 at
 org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311)
 ...
 Exception 0 :
 org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied
 dependencies for type [DeltaSpikeContextExtension] with qualifiers
 [@Default] at injection point [[field] @Inject private
 org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.deltaSpikeContextExtension]
 at
 org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311)
 ...
 {code}

  Support WLS Profile in Data Module
  --
 
  Key: DELTASPIKE-589
  URL:
 https://issues.apache.org/jira/browse/DELTASPIKE-589
  Project: DeltaSpike
   Issue Type: Task
   Components: Build, Data-Module
 Affects Versions: 0.7
 Reporter: Thomas Hug
 Assignee: Thomas Hug
  Fix For: 0.8
 
 
  Add a WLS-specific test-persistence.xml included by the WLS profiles.



 --
 This message was sent by Atlassian JIRA
 (v6.2#6252)

[Proposal] messages stored but not tied to JSF system.

[Rudy De Busscher]

All,

With the JsfMessage interface, you can add messages to the FacesContext so
that they are displayed on screen the next rendering.

But what if your CDI beans are used within a JSF context AND a REST
context. When processing the REST request, there is no facesContext
available and exceptions occur.

My proposal is to have, aside the JsfMessage interface, a similar one,
something like BusinessMessage, that works exactly the same but which
doesn't store the message in FacesContext but in a custom ThreadLocal
variable.

Then the messages can be picked up by a REST interceptor and added to the,
for example, JSON response.  But it can also be picked up by a JSF
lifecycle interceptor.

I can commit the code which I have developped for a demo application that
uses it.

WDYT?

Regards
Rudy

Also problems with WLS 12.1.2 for the integration tests.

[Rudy De Busscher]

I tried the latest version of WLS 12C, 12.1.2, for the integration tests.

*mvn clean install -Pwls-remote-12c

*But on every deployment I receive a Weld error:

*WELD-001408 Unsatisfied dependencies for type [DeltaSpikeContextExtension]
with qualifiers [@Default] at injection point [[field] @Inject private
org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.deltaSpikeContextExtension]
*

This is a bit odd as the DeltaSpikeContextExtension is in the same package
as the WindowContextProducer.  But the fact that the classes are in a jar
file included in the war, leads to the idea that WLS still has problem by
defining the Bean Archive.

A bug report for WELD-001408 error with version WLS 12.1.1 is marked as
fixed, although the description isn't exactly the same (classes not
injectable if in different jar files) a similar problem still exists.

When running with the older version 12.1.0, I receive another error.
*
java.lang.IllegalStateException: Could not find beans for Type=class
org.apache.deltaspike.core.impl.scope.window.WindowBeanHolder and
qualifiers:[]
at
org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:150)
at
org.apache.deltaspike.core.impl.scope.window.DeltaSpikeContextExtension.initializeDeltaSpikeContexts(DeltaSpikeContextExtension.java:50)
*
Here it can't find the CDI bean from the Bean Manager when deployment
validation is done  (Does this mean that the DeltaSpikeContextExtension is
injected in the WindowContextProducer, the place where the new version
fails ??)


Anyway, it seems that we need to unpack the deltaspike jars, the same as we
needed to do with CODI (1)

I'll verify that next week.

Regards
Rudy

(1)
http://jsfcorner.blogspot.be/2012/01/codi-on-oracle-weblogic-server-12c.html