[jira] [Commented] (DELTASPIKE-1354) CDI producer does not work properly after application restart on weblogic 12c
[
https://issues.apache.org/jira/browse/DELTASPIKE-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607194#comment-16607194
]
Mark Struberg commented on DELTASPIKE-1354:
---
Hi Theodoros!
Thanks for the bug report, I will look into it.
Unfortunately I had to delete the webapp zip as it seems it contains sensible
customer information in cyrilic letters (although I'm not 100% sure, but better
safe than sorry, right?).
I'm not yet sure, but it looks very likely to be a WebLogic bug. If you
undeploy a WAR application, then all resources must be freed up. It actually
must even use a new ClassLoader when the app gets restarted. So it's really
unlikely that CDI messes something up.
>From looking at the stacktrace I suspect that the EntityManagerFactory doesn't
>get freed up.
All that DeltaSpike does here is to call
`return entityManager().find(entityClass(), primaryKey);`
This will in turn look up the EntityManagerFactory as Resource from the
Container via JNDI. And here is where things seems to go mad:
{noformat}
Caused By: javax.naming.NameNotFoundException: While trying to look up
comp/env/ssp.sandbox.util.EMProducer/entityManagerFactory in
/app/webapp/ssp.sandbox.war/486607339.; remaining name
'comp/env/ssp/sandbox/util/EMProducer/entityManagerFactory'
at
weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:1292)
{noformat}
Happy to help further, but your EMProducer.java looks fine and the rest has not
much impact.
So I'm back to believing this is likely a WLS glitch.
> CDI producer does not work properly after application restart on weblogic 12c
> -
>
> Key: DELTASPIKE-1354
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1354
> Project: DeltaSpike
> Issue Type: Bug
> Components: CdiControl, Data-Module
>Affects Versions: 1.8.0
> Environment: Windows 10, Weblogic 12.2.1.3, Java EE7, JDK 1.8.0_172
>Reporter: THEODOROS CHAIKALIS
>Priority: Major
> Labels: cdi, entitymanager, producer, repository
>
> I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3.
> Attached you will find a mini application that demonstrates the problem,
> please use it.
> The scenario to reproduce the problem is as follows:
> 1. Deploy the application on Weblogic.
> 2. Run a REST service that uses a Deltaspike repository:
> [http://localhost:7001/ssp.sandbox/persons/all]
> or
> [http://localhost:7001/ssp.sandbox/persons/byId/1]
> 3. Observe that the request runs smoothly. If you want to populate db with
> data run the Arquillian test in TestA class
> 4. from the weblogic console, stop the application
> 5. Start the application
> 6. run again a REST call from step 2. The following will happen:
>
> [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee]
>
> Note: in order for the example to run properly, please remove the "Provided"
> scopes from the respective dependencies
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DELTASPIKE-1354) CDI producer does not work properly after application restart on weblogic 12c
[ https://issues.apache.org/jira/browse/DELTASPIKE-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated DELTASPIKE-1354: -- Attachment: (was: EnterpriseWebApp.zip) > CDI producer does not work properly after application restart on weblogic 12c > - > > Key: DELTASPIKE-1354 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1354 > Project: DeltaSpike > Issue Type: Bug > Components: CdiControl, Data-Module >Affects Versions: 1.8.0 > Environment: Windows 10, Weblogic 12.2.1.3, Java EE7, JDK 1.8.0_172 >Reporter: THEODOROS CHAIKALIS >Priority: Major > Labels: cdi, entitymanager, producer, repository > > I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. > Attached you will find a mini application that demonstrates the problem, > please use it. > The scenario to reproduce the problem is as follows: > 1. Deploy the application on Weblogic. > 2. Run a REST service that uses a Deltaspike repository: > [http://localhost:7001/ssp.sandbox/persons/all] > or > [http://localhost:7001/ssp.sandbox/persons/byId/1] > 3. Observe that the request runs smoothly. If you want to populate db with > data run the Arquillian test in TestA class > 4. from the weblogic console, stop the application > 5. Start the application > 6. run again a REST call from step 2. The following will happen: > > [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] > > Note: in order for the example to run properly, please remove the "Provided" > scopes from the respective dependencies > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DELTASPIKE-1354) CDI producer does not work properly after application restart on weblogic 12c
[ https://issues.apache.org/jira/browse/DELTASPIKE-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] THEODOROS CHAIKALIS updated DELTASPIKE-1354: Description: I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. Attached you will find a mini application that demonstrates the problem, please use it. The scenario to reproduce the problem is as follows: 1. Deploy the application on Weblogic. 2. Run a REST service that uses a Deltaspike repository: [http://localhost:7001/ssp.sandbox/persons/all] or [http://localhost:7001/ssp.sandbox/persons/byId/1] 3. Observe that the request runs smoothly. If you want to populate db with data run the Arquillian test in TestA class 4. from the weblogic console, stop the application 5. Start the application 6. run again a REST call from step 2. The following will happen: [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] Note: in order for the example to run properly, please remove the "Provided" scopes. was: I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. Attached you will find a mini application that demonstrates the problem, please use it. The scenario to reproduce the problem is as follows: 1. Deploy the application on Weblogic. 2. Run a REST service that uses a Deltaspike repository: [http://localhost:7001/ssp.sandbox/persons/all] or [http://localhost:7001/ssp.sandbox/persons/byId/1] 3. Observe that the request runs smoothly. If you want to populate db with data run the Arquillian test in TestA class 4. from the weblogic console, stop the application 5. Start the application 6. run again a REST call from step 2. The following will happen: [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] > CDI producer does not work properly after application restart on weblogic 12c > - > > Key: DELTASPIKE-1354 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1354 > Project: DeltaSpike > Issue Type: Bug > Components: CdiControl, Data-Module >Affects Versions: 1.8.0 > Environment: Windows 10, Weblogic 12.2.1.3, Java EE7, JDK 1.8.0_172 >Reporter: THEODOROS CHAIKALIS >Priority: Major > Labels: cdi, entitymanager, producer, repository > Attachments: EnterpriseWebApp.zip > > > I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. > Attached you will find a mini application that demonstrates the problem, > please use it. > The scenario to reproduce the problem is as follows: > 1. Deploy the application on Weblogic. > 2. Run a REST service that uses a Deltaspike repository: > [http://localhost:7001/ssp.sandbox/persons/all] > or > [http://localhost:7001/ssp.sandbox/persons/byId/1] > 3. Observe that the request runs smoothly. If you want to populate db with > data run the Arquillian test in TestA class > 4. from the weblogic console, stop the application > 5. Start the application > 6. run again a REST call from step 2. The following will happen: > > [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] > > Note: in order for the example to run properly, please remove the "Provided" > scopes. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DELTASPIKE-1354) CDI producer does not work properly after application restart on weblogic 12c
[ https://issues.apache.org/jira/browse/DELTASPIKE-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] THEODOROS CHAIKALIS updated DELTASPIKE-1354: Description: I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. Attached you will find a mini application that demonstrates the problem, please use it. The scenario to reproduce the problem is as follows: 1. Deploy the application on Weblogic. 2. Run a REST service that uses a Deltaspike repository: [http://localhost:7001/ssp.sandbox/persons/all] or [http://localhost:7001/ssp.sandbox/persons/byId/1] 3. Observe that the request runs smoothly. If you want to populate db with data run the Arquillian test in TestA class 4. from the weblogic console, stop the application 5. Start the application 6. run again a REST call from step 2. The following will happen: [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] Note: in order for the example to run properly, please remove the "Provided" scopes from the respective dependencies was: I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. Attached you will find a mini application that demonstrates the problem, please use it. The scenario to reproduce the problem is as follows: 1. Deploy the application on Weblogic. 2. Run a REST service that uses a Deltaspike repository: [http://localhost:7001/ssp.sandbox/persons/all] or [http://localhost:7001/ssp.sandbox/persons/byId/1] 3. Observe that the request runs smoothly. If you want to populate db with data run the Arquillian test in TestA class 4. from the weblogic console, stop the application 5. Start the application 6. run again a REST call from step 2. The following will happen: [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] Note: in order for the example to run properly, please remove the "Provided" scopes. > CDI producer does not work properly after application restart on weblogic 12c > - > > Key: DELTASPIKE-1354 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1354 > Project: DeltaSpike > Issue Type: Bug > Components: CdiControl, Data-Module >Affects Versions: 1.8.0 > Environment: Windows 10, Weblogic 12.2.1.3, Java EE7, JDK 1.8.0_172 >Reporter: THEODOROS CHAIKALIS >Priority: Major > Labels: cdi, entitymanager, producer, repository > Attachments: EnterpriseWebApp.zip > > > I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. > Attached you will find a mini application that demonstrates the problem, > please use it. > The scenario to reproduce the problem is as follows: > 1. Deploy the application on Weblogic. > 2. Run a REST service that uses a Deltaspike repository: > [http://localhost:7001/ssp.sandbox/persons/all] > or > [http://localhost:7001/ssp.sandbox/persons/byId/1] > 3. Observe that the request runs smoothly. If you want to populate db with > data run the Arquillian test in TestA class > 4. from the weblogic console, stop the application > 5. Start the application > 6. run again a REST call from step 2. The following will happen: > > [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] > > Note: in order for the example to run properly, please remove the "Provided" > scopes from the respective dependencies > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DELTASPIKE-1354) CDI producer does not work properly after application restart on weblogic 12c
[ https://issues.apache.org/jira/browse/DELTASPIKE-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] THEODOROS CHAIKALIS updated DELTASPIKE-1354: Environment: Windows 10, Weblogic 12.2.1.3, Java EE7, JDK 1.8.0_172 (was: Windows 10, Weblogic 12.2.1.3, Java EE7, JDK 8_1) > CDI producer does not work properly after application restart on weblogic 12c > - > > Key: DELTASPIKE-1354 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1354 > Project: DeltaSpike > Issue Type: Bug > Components: CdiControl, Data-Module >Affects Versions: 1.8.0 > Environment: Windows 10, Weblogic 12.2.1.3, Java EE7, JDK 1.8.0_172 >Reporter: THEODOROS CHAIKALIS >Priority: Major > Labels: cdi, entitymanager, producer, repository > Attachments: EnterpriseWebApp.zip > > > I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. > Attached you will find a mini application that demonstrates the problem, > please use it. > The scenario to reproduce the problem is as follows: > 1. Deploy the application on Weblogic. > 2. Run a REST service that uses a Deltaspike repository: > [http://localhost:7001/ssp.sandbox/persons/all] > or > [http://localhost:7001/ssp.sandbox/persons/byId/1] > 3. Observe that the request runs smoothly. If you want to populate db with > data run the Arquillian test in TestA class > 4. from the weblogic console, stop the application > 5. Start the application > 6. run again a REST call from step 2. The following will happen: > > [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DELTASPIKE-1354) CDI producer does not work properly after application restart on weblogic 12c
[ https://issues.apache.org/jira/browse/DELTASPIKE-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] THEODOROS CHAIKALIS updated DELTASPIKE-1354: Environment: Windows 10, Weblogic 12.2.1.3, Java EE7, JDK 8_1 (was: Windows 10, Weblogic 12.2.1.3, ) > CDI producer does not work properly after application restart on weblogic 12c > - > > Key: DELTASPIKE-1354 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1354 > Project: DeltaSpike > Issue Type: Bug > Components: CdiControl, Data-Module >Affects Versions: 1.8.0 > Environment: Windows 10, Weblogic 12.2.1.3, Java EE7, JDK 8_1 >Reporter: THEODOROS CHAIKALIS >Priority: Major > Labels: cdi, entitymanager, producer, repository > Attachments: EnterpriseWebApp.zip > > > I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. > Attached you will find a mini application that demonstrates the problem, > please use it. > The scenario to reproduce the problem is as follows: > 1. Deploy the application on Weblogic. > 2. Run a REST service that uses a Deltaspike repository: > [http://localhost:7001/ssp.sandbox/persons/all] > or > [http://localhost:7001/ssp.sandbox/persons/byId/1] > 3. Observe that the request runs smoothly. If you want to populate db with > data run the Arquillian test in TestA class > 4. from the weblogic console, stop the application > 5. Start the application > 6. run again a REST call from step 2. The following will happen: > > [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DELTASPIKE-1354) CDI producer does not work properly after application restart on weblogic 12c
[ https://issues.apache.org/jira/browse/DELTASPIKE-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] THEODOROS CHAIKALIS updated DELTASPIKE-1354: Description: I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. Attached you will find a mini application that demonstrates the problem, please use it. The scenario to reproduce the problem is as follows: 1. Deploy the application on Weblogic. 2. Run a REST service that uses a Deltaspike repository: [http://localhost:7001/ssp.sandbox/persons/all] or [http://localhost:7001/ssp.sandbox/persons/byId/1] 3. Observe that the request runs smoothly. If you want to populate db with data run the Arquillian test in TestA class 4. from the weblogic console, stop the application 5. Start the application 6. run again a REST call from step 2. The following will happen: [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] was: I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. Attached you will find a mini application that demonstrates the problem, please use it. The scenario to reproduce the problem is as follows: 1. Deploy the application on Weblogic. 2. Run a REST service that uses a Deltaspike repository: [http://localhost:7001/ssp.sandbox/persons/all] or [http://localhost:7001/ssp.sandbox/persons/byId/1] 3. Observe that the request runs smoothly. If you want to populate db with data run the Arquillian test in TestA class 4. from the weblogic console, stop the application 5. Start the application 6. run again a rest from step 2. The following will happen: [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] > CDI producer does not work properly after application restart on weblogic 12c > - > > Key: DELTASPIKE-1354 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1354 > Project: DeltaSpike > Issue Type: Bug > Components: CdiControl, Data-Module >Affects Versions: 1.8.0 > Environment: Windows 10, Weblogic 12.2.1.3, >Reporter: THEODOROS CHAIKALIS >Priority: Major > Labels: cdi, entitymanager, producer, repository > Attachments: EnterpriseWebApp.zip > > > I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. > Attached you will find a mini application that demonstrates the problem, > please use it. > The scenario to reproduce the problem is as follows: > 1. Deploy the application on Weblogic. > 2. Run a REST service that uses a Deltaspike repository: > [http://localhost:7001/ssp.sandbox/persons/all] > or > [http://localhost:7001/ssp.sandbox/persons/byId/1] > 3. Observe that the request runs smoothly. If you want to populate db with > data run the Arquillian test in TestA class > 4. from the weblogic console, stop the application > 5. Start the application > 6. run again a REST call from step 2. The following will happen: > > [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DELTASPIKE-1354) CDI producer does not work properly after application restart on weblogic 12c
[ https://issues.apache.org/jira/browse/DELTASPIKE-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] THEODOROS CHAIKALIS updated DELTASPIKE-1354: Description: I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. Attached you will find a mini application that demonstrates the problem, please use it. The scenario to reproduce the problem is as follows: 1. Deploy the application on Weblogic. 2. Run a REST service that uses a Deltaspike repository: [http://localhost:7001/ssp.sandbox/persons/all] or [http://localhost:7001/ssp.sandbox/persons/byId/1] 3. Observe that the request runs smoothly. If you want to populate db with data run the Arquillian test in TestA class 4. from the weblogic console, stop the application 5. Start the application 6. run again a rest from step 2. The following will happen: [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] was: I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. Attached you will find a mini application that demonstrates the problem, please use it. The scenario to reproduce the problem is as follows: 1. Deploy the application on Weblogic. 2. Run a REST service that uses a Deltaspike repository: [http://localhost:7001/ssp.sandbox/persons/all] or [http://localhost:7001/ssp.sandbox/persons/byId/1] 3. Observe that the request runs smoothly. If you want Data run the TestA class 4. from the weblogic console, stop the application 5. Start the application 6. run again a rest from step 2. The following will happen: [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] > CDI producer does not work properly after application restart on weblogic 12c > - > > Key: DELTASPIKE-1354 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1354 > Project: DeltaSpike > Issue Type: Bug > Components: CdiControl, Data-Module >Affects Versions: 1.8.0 > Environment: Windows 10, Weblogic 12.2.1.3, >Reporter: THEODOROS CHAIKALIS >Priority: Major > Labels: cdi, entitymanager, producer, repository > Attachments: EnterpriseWebApp.zip > > > I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. > Attached you will find a mini application that demonstrates the problem, > please use it. > The scenario to reproduce the problem is as follows: > 1. Deploy the application on Weblogic. > 2. Run a REST service that uses a Deltaspike repository: > [http://localhost:7001/ssp.sandbox/persons/all] > or > [http://localhost:7001/ssp.sandbox/persons/byId/1] > 3. Observe that the request runs smoothly. If you want to populate db with > data run the Arquillian test in TestA class > 4. from the weblogic console, stop the application > 5. Start the application > 6. run again a rest from step 2. The following will happen: > > [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DELTASPIKE-1354) CDI producer does not work correctly after application restart on weblogic 12c
THEODOROS CHAIKALIS created DELTASPIKE-1354: --- Summary: CDI producer does not work correctly after application restart on weblogic 12c Key: DELTASPIKE-1354 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1354 Project: DeltaSpike Issue Type: Bug Components: CdiControl, Data-Module Affects Versions: 1.8.0 Environment: Windows 10, Weblogic 12.2.1.3, Reporter: THEODOROS CHAIKALIS Attachments: EnterpriseWebApp.zip I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. Attached you will find a mini application that demonstrates the problem, please use it. The scenario to reproduce the problem is as follows: 1. Deploy the application on Weblogic. 2. Run a REST service that uses a Deltaspike repository: [http://localhost:7001/ssp.sandbox/persons/all] or [http://localhost:7001/ssp.sandbox/persons/byId/1] 3. Observe that the request runs smoothly. If you want Data run the TestA class 4. from the weblogic console, stop the application 5. Start the application 6. run again a rest from step 2. The following will happen: [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DELTASPIKE-1354) CDI producer does not work properly after application restart on weblogic 12c
[ https://issues.apache.org/jira/browse/DELTASPIKE-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] THEODOROS CHAIKALIS updated DELTASPIKE-1354: Summary: CDI producer does not work properly after application restart on weblogic 12c (was: CDI producer does not work correctly after application restart on weblogic 12c) > CDI producer does not work properly after application restart on weblogic 12c > - > > Key: DELTASPIKE-1354 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1354 > Project: DeltaSpike > Issue Type: Bug > Components: CdiControl, Data-Module >Affects Versions: 1.8.0 > Environment: Windows 10, Weblogic 12.2.1.3, >Reporter: THEODOROS CHAIKALIS >Priority: Major > Labels: cdi, entitymanager, producer, repository > Attachments: EnterpriseWebApp.zip > > > I have an application using Deltaspike 1.8.0 that runs on Weblogic 12.2.1.3. > Attached you will find a mini application that demonstrates the problem, > please use it. > The scenario to reproduce the problem is as follows: > 1. Deploy the application on Weblogic. > 2. Run a REST service that uses a Deltaspike repository: > [http://localhost:7001/ssp.sandbox/persons/all] > or > [http://localhost:7001/ssp.sandbox/persons/byId/1] > 3. Observe that the request runs smoothly. If you want Data run the TestA > class > 4. from the weblogic console, stop the application > 5. Start the application > 6. run again a rest from step 2. The following will happen: > > [https://gist.github.com/teohaik/933d4bc47d38c4441ca9a7409bc90eee] > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1318) Unsatisfied dependencies for type ApplicationContext (deltaspike-cdictrl-weld) in payara 4.1.2.174
[
https://issues.apache.org/jira/browse/DELTASPIKE-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607059#comment-16607059
]
Matej Novotny commented on DELTASPIKE-1318:
---
It should be injectable, according to
[docs|http://docs.jboss.org/weld/reference/latest-master/en-US/html_single/#_managing_the_built_in_contexts]
it is _unmanaged_ and _unbound_ context.
Can you try injecting {{ApplicationContext}} somewhere else in your app without
using DS? Having the result of that we could see if the problem is in your
app(or paraya/osgi) or in DS.
Alternatively, if you can provide a reproducer?
> Unsatisfied dependencies for type ApplicationContext
> (deltaspike-cdictrl-weld) in payara 4.1.2.174
> --
>
> Key: DELTASPIKE-1318
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1318
> Project: DeltaSpike
> Issue Type: Bug
> Components: CdiControl
>Affects Versions: 1.8.1
> Environment: payara 4.1.2.174
>Reporter: Andreas Keefer
>Assignee: Matej Novotny
>Priority: Major
>
> ApplicationContext can't be injected in WeldContextControl on payara 4.1.2.174
>
> Maven dependencies
> {code:java}
>
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-api
> compile
>
>
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-weld
> runtime
>
> {code}
> Sample Bean:
> {code:java}
> @Singleton
> @Startup
> public class KafkaVehicleReceiver {
> @Inject
> private ContextControl contextControl;
> ...
> }{code}
> payara log:
> {code:java}
> [2018-02-27T00:40:54.713+0100] [Payara 4.1] [SCHWERWIEGEND] [NCLS-CORE-00026]
> [javax.enterprise.system.core] [tid: _ThreadID=47
> _ThreadName=admin-thread-pool::admin-listener(1)] [timeMillis: 1519688454713]
> [levelValue: 1000] [[
> Exception during lifecycle processing
> org.glassfish.deployment.common.DeploymentException: CDI deployment
> failure:WELD-001408: Unsatisfied dependencies for type ApplicationContext
> with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private
> org.apache.deltaspike.cdise.weld.WeldContextControl.applicationContext
> at
> org.apache.deltaspike.cdise.weld.WeldContextControl.applicationContext(WeldContextControl.java:0)
> at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:270)
> at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
> at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:333)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:220)
> at
> org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:508)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:544)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:540)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:539)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:570)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:562)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:561)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1469)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:111)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1851)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1727)
> at
> org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:407)
> at
> org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> at
>
[VOTE] Release Apache DeltaSpike 1.9.0
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
[jira] [Updated] (DELTASPIKE-1241) [Config] fallback chain logic
[
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.9.0)
1.9.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
>Priority: Major
> Fix For: 1.9.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
(v7.6.3#76005)
[jira] [Updated] (DELTASPIKE-1328) Add a Java 8 base repository
[
https://issues.apache.org/jira/browse/DELTASPIKE-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated DELTASPIKE-1328:
--
Fix Version/s: (was: 1.9.0)
1.9.1
> 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
>Priority: Major
> Fix For: 1.9.1
>
>
> 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] [Updated] (DELTASPIKE-1323) upgrade maven-bundle-plugin to more recent version
[ https://issues.apache.org/jira/browse/DELTASPIKE-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated DELTASPIKE-1323: -- Fix Version/s: (was: 1.9.0) 1.9.1 > upgrade maven-bundle-plugin to more recent version > -- > > Key: DELTASPIKE-1323 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1323 > Project: DeltaSpike > Issue Type: Task > Components: Build >Affects Versions: 1.9.0 >Reporter: Mark Struberg >Priority: Major > Fix For: 1.9.1 > > > we currently use a very old OSGi bundle plugin version which doesn't work > with Java8 constructs. > > I've tried to update to any more recent version but failed. My OSGi mojo is > not strong enough. > maven-bundle-plugin 2.5.0 complains about wrong imports and any more recent > version (e.g. 3.5.0) totally breaks the compilation. > > The only workaround I found so far is to switch from 'bundle' to 'jar' > packaging. > > Would be great if someone with OSGi knowledge could take a look at it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (DELTASPIKE-1198) BeanManagerProvider.isActive() returns true after container shutdown
[
https://issues.apache.org/jira/browse/DELTASPIKE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved DELTASPIKE-1198.
---
Resolution: Fixed
Fix Version/s: 1.9.0
> BeanManagerProvider.isActive() returns true after container shutdown
>
>
> Key: DELTASPIKE-1198
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1198
> Project: DeltaSpike
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.7.0, 1.7.2
>Reporter: Sean Flanigan
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
>
> While trying to implement DELTASPIKE-1197 I found that
> {{BeanManagerProvider.isActive()}} returns true after container shutdown.
> The javadocs for {{isActive()}} say "@return true if the BeanManagerProvider
> is ready to be used", but when it is in this state, the BeanManagerProvider
> can't actually be used because the CDI container is not active.
> In the case of Weld, when {{BeanProvider.getContextualReference()}} was
> called I got errors like "java.lang.IllegalStateException: Singleton not set
> for STATIC_INSTANCE => []". There was no stack trace, but that message comes
> from Weld's RegistrySingletonProvider.java.
> It would seem reasonable to reset bmpSingleton to null during
> cleanupStoredBeanManagerOnShutdown, but for some reason this breaks a lot of
> tests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1198) BeanManagerProvider.isActive() returns true after container shutdown
[
https://issues.apache.org/jira/browse/DELTASPIKE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16606991#comment-16606991
]
ASF subversion and git services commented on DELTASPIKE-1198:
-
Commit 20ba0e9f7d0c944885092bafb85f3df51b8ed7df in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=20ba0e9 ]
DELTASPIKE-1198 check if the _current_ beanManager is still attached.
This will deal with shutting down the container
> BeanManagerProvider.isActive() returns true after container shutdown
>
>
> Key: DELTASPIKE-1198
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1198
> Project: DeltaSpike
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.7.0, 1.7.2
>Reporter: Sean Flanigan
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
>
> While trying to implement DELTASPIKE-1197 I found that
> {{BeanManagerProvider.isActive()}} returns true after container shutdown.
> The javadocs for {{isActive()}} say "@return true if the BeanManagerProvider
> is ready to be used", but when it is in this state, the BeanManagerProvider
> can't actually be used because the CDI container is not active.
> In the case of Weld, when {{BeanProvider.getContextualReference()}} was
> called I got errors like "java.lang.IllegalStateException: Singleton not set
> for STATIC_INSTANCE => []". There was no stack trace, but that message comes
> from Weld's RegistrySingletonProvider.java.
> It would seem reasonable to reset bmpSingleton to null during
> cleanupStoredBeanManagerOnShutdown, but for some reason this breaks a lot of
> tests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (DELTASPIKE-1277) Force refresh of cached config values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved DELTASPIKE-1277.
---
Resolution: Fixed
Fix Version/s: 1.9.0
> Force refresh of cached config values
> -
>
> Key: DELTASPIKE-1277
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
>Reporter: Alexander Falb
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
> Attachments: central_caching.patch, forcerefresh.patch
>
>
> When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled,
> there is no way of bypassing the cache and forcefully reloading the value
> from underlying datasources.
> The attached patch is a proposal of creating such an mechanism. It introduces
> a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this
> method by resetting the {{reloadAfter}} field and adds a unit test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1318) Unsatisfied dependencies for type ApplicationContext (deltaspike-cdictrl-weld) in payara 4.1.2.174
[
https://issues.apache.org/jira/browse/DELTASPIKE-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16606982#comment-16606982
]
Mark Struberg commented on DELTASPIKE-1318:
---
[~manovotn] could you probably take a quick look at this?
> Unsatisfied dependencies for type ApplicationContext
> (deltaspike-cdictrl-weld) in payara 4.1.2.174
> --
>
> Key: DELTASPIKE-1318
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1318
> Project: DeltaSpike
> Issue Type: Bug
> Components: CdiControl
>Affects Versions: 1.8.1
> Environment: payara 4.1.2.174
>Reporter: Andreas Keefer
>Assignee: Matej Novotny
>Priority: Major
>
> ApplicationContext can't be injected in WeldContextControl on payara 4.1.2.174
>
> Maven dependencies
> {code:java}
>
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-api
> compile
>
>
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-weld
> runtime
>
> {code}
> Sample Bean:
> {code:java}
> @Singleton
> @Startup
> public class KafkaVehicleReceiver {
> @Inject
> private ContextControl contextControl;
> ...
> }{code}
> payara log:
> {code:java}
> [2018-02-27T00:40:54.713+0100] [Payara 4.1] [SCHWERWIEGEND] [NCLS-CORE-00026]
> [javax.enterprise.system.core] [tid: _ThreadID=47
> _ThreadName=admin-thread-pool::admin-listener(1)] [timeMillis: 1519688454713]
> [levelValue: 1000] [[
> Exception during lifecycle processing
> org.glassfish.deployment.common.DeploymentException: CDI deployment
> failure:WELD-001408: Unsatisfied dependencies for type ApplicationContext
> with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private
> org.apache.deltaspike.cdise.weld.WeldContextControl.applicationContext
> at
> org.apache.deltaspike.cdise.weld.WeldContextControl.applicationContext(WeldContextControl.java:0)
> at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:270)
> at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
> at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:333)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:220)
> at
> org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:508)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:544)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:540)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:539)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:570)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:562)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:561)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1469)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:111)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1851)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1727)
> at
> org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:407)
> at
> org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
> at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
> at
>
[jira] [Assigned] (DELTASPIKE-1318) Unsatisfied dependencies for type ApplicationContext (deltaspike-cdictrl-weld) in payara 4.1.2.174
[
https://issues.apache.org/jira/browse/DELTASPIKE-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reassigned DELTASPIKE-1318:
-
Assignee: Matej Novotny (was: Mark Struberg)
> Unsatisfied dependencies for type ApplicationContext
> (deltaspike-cdictrl-weld) in payara 4.1.2.174
> --
>
> Key: DELTASPIKE-1318
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1318
> Project: DeltaSpike
> Issue Type: Bug
> Components: CdiControl
>Affects Versions: 1.8.1
> Environment: payara 4.1.2.174
>Reporter: Andreas Keefer
>Assignee: Matej Novotny
>Priority: Major
>
> ApplicationContext can't be injected in WeldContextControl on payara 4.1.2.174
>
> Maven dependencies
> {code:java}
>
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-api
> compile
>
>
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-weld
> runtime
>
> {code}
> Sample Bean:
> {code:java}
> @Singleton
> @Startup
> public class KafkaVehicleReceiver {
> @Inject
> private ContextControl contextControl;
> ...
> }{code}
> payara log:
> {code:java}
> [2018-02-27T00:40:54.713+0100] [Payara 4.1] [SCHWERWIEGEND] [NCLS-CORE-00026]
> [javax.enterprise.system.core] [tid: _ThreadID=47
> _ThreadName=admin-thread-pool::admin-listener(1)] [timeMillis: 1519688454713]
> [levelValue: 1000] [[
> Exception during lifecycle processing
> org.glassfish.deployment.common.DeploymentException: CDI deployment
> failure:WELD-001408: Unsatisfied dependencies for type ApplicationContext
> with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private
> org.apache.deltaspike.cdise.weld.WeldContextControl.applicationContext
> at
> org.apache.deltaspike.cdise.weld.WeldContextControl.applicationContext(WeldContextControl.java:0)
> at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:270)
> at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
> at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:333)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:220)
> at
> org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:508)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:544)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:540)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:539)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:570)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:562)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:561)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1469)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:111)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1851)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1727)
> at
> org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:407)
> at
> org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
> at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
> at
>
[jira] [Commented] (DELTASPIKE-1333) Support default methods in interface based configuration
[
https://issues.apache.org/jira/browse/DELTASPIKE-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16606967#comment-16606967
]
Mark Struberg commented on DELTASPIKE-1333:
---
I looked into it and it is not exactly trivial. It would require a subclassing
proxy which does _not_ implement default methods. But java.lang.reflect Proxies
don't work that way. You cannot turn them off.
So what happens is that the `invoke(Object proxy, Method m, Object[] args)`
method gets called on the proxy.
Here we could easily detect that this method is actually a default method from
the interface. And we could also do a method.invoke() on it.
But what should we pass? Obviously we have just the proxy. And calling the
default method on the proxy we will be back in the InvocationHandler ending up
in an endless loop.
In Java7 and 8 there was a somewhat hacky way to solve this via MethodHandlers.
See
https://rmannibucau.wordpress.com/2014/03/27/java-8-default-interface-methods-and-jdk-dynamic-proxies/
Sadly this also doesn't work anymore in Java9. There are other tricks with
Java9&10 by using the new MethodHandles findSpecial + privateLookupIn. But
those methods do not yet exist in Java8...
Summary: default methods in java.lang.reflect proxies are a pain. There is no
consistently working solution. The only viable solution is to generate the
proxy ourselves via native bytecode manipulation. I've done this for OpenJPA
and OpenWebBeans (got ported over here as well). But this requires a low level
bytecode lib like BCEL or ASM. So I'd rather not support it by default
> Support default methods in interface based configuration
>
>
> Key: DELTASPIKE-1333
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1333
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
>Affects Versions: 1.8.1
> Environment: Java 8, DeltaSpike 1.8.1
>Reporter: Niels Ull Harremoes
>Assignee: Mark Struberg
>Priority: Minor
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> I wanted to implement a default method in one of my configuration methods as
> a simple way to configure a Duration:
> {code:java}
> @Configuration
> interface CacheConfig {
> @ConfigProperty(name = "cache.lifetime", defaultValue = "P1D")
> String cacheLifetime();
> default Duration getCacheLifetimeDuration() {
> try {
> return Duration.parse(cacheLifetime());
> } catch (DateTimeParseException e) {
> ...
> }
> }
> {code}
> However, a runtime I get the error
> {quote}java.lang.UnsupportedOperationException: public default
> java.time.Duration com.example.CacheConfig.getLifetimeDuration() doesn't have
> @ConfigProperty and therefore is illegal
> {quote}
> It would be nice if default methods were not processed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (DELTASPIKE-1335) allow atomic access to n different TypedResolver values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved DELTASPIKE-1335.
---
Resolution: Fixed
> allow atomic access to n different TypedResolver values
> ---
>
> Key: DELTASPIKE-1335
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1335
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Configuration
>Affects Versions: 1.9.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.0
>
>
> If multiple related config values (TypedResolver) are accessed in the same
> request and the underlying config changes then we might up with a wild
> mixture of old and new values.
> An example would be to access some 'myapp.host' and 'myapp.port':
> The underlying values are 'oldserver' and '8080'.
> Now consider the following code:
> {code}
> // get the current host value
> TypedResolver hostCfg config.resolve("myapp.host");
> // and right inbetween the underlying values get
> // changed to 'newserver' and port 8082
> // get the current port for the host
> TypedResolver portCfg config.resolve("myapp.port");
> {code}
> In ths above code we would get the combination of 'oldserver' but with the
> new port 8081. And this will obviously blow up because that host+port
> combination doesn't exist.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (DELTASPIKE-1336) Regression: deltaspike-cdictrl-weld 1.8.0 depends on weld-api 1.1.Final
[
https://issues.apache.org/jira/browse/DELTASPIKE-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved DELTASPIKE-1336.
---
Resolution: Fixed
After consulting with [~manovotn] we did only set it to 'provided'.
Can you please retest if this is fine for you? txs!
> Regression: deltaspike-cdictrl-weld 1.8.0 depends on weld-api 1.1.Final
> ---
>
> Key: DELTASPIKE-1336
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1336
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.8.0
>Reporter: Christophe Chisogne
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 1.9.0
>
> Attachments: pom-ds-1.7.2.xml, pom-ds-1.8.0-fix.xml, pom-ds-1.8.0.xml
>
>
> The {{deltaspike-cdictrl-weld}} module introduces a new dependency since
> 1.8.0: {{org.jboss.weld:weld-api:jar:1.1.Final}}. This wasn't the case in
> 1.7.2.
> This causes issues when depending on other weld versions, like 2.3. For
> example
> {code}
> java.lang.NoSuchMethodError:
> org.jboss.weld.context.SingletonContext.invalidate()V
> {code}
> To reproduce: execute a simple {{mvn dependency:tree}} on the attached
> pom.xml files.
> The issue is probably caused by the {{weld.version}} property (1.1.9.Final)
> added to the deltaspike parent pom.xml.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1336) Regression: deltaspike-cdictrl-weld 1.8.0 depends on weld-api 1.1.Final
[
https://issues.apache.org/jira/browse/DELTASPIKE-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16606862#comment-16606862
]
ASF subversion and git services commented on DELTASPIKE-1336:
-
Commit eb145ca585a97837a076aa5182e4ec62c8a57aa0 in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=eb145ca ]
DELTASPIKE-1336 set weld-api to 'provided'
quickly cross checked by manovotn, txs!
> Regression: deltaspike-cdictrl-weld 1.8.0 depends on weld-api 1.1.Final
> ---
>
> Key: DELTASPIKE-1336
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1336
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.8.0
>Reporter: Christophe Chisogne
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 1.9.0
>
> Attachments: pom-ds-1.7.2.xml, pom-ds-1.8.0-fix.xml, pom-ds-1.8.0.xml
>
>
> The {{deltaspike-cdictrl-weld}} module introduces a new dependency since
> 1.8.0: {{org.jboss.weld:weld-api:jar:1.1.Final}}. This wasn't the case in
> 1.7.2.
> This causes issues when depending on other weld versions, like 2.3. For
> example
> {code}
> java.lang.NoSuchMethodError:
> org.jboss.weld.context.SingletonContext.invalidate()V
> {code}
> To reproduce: execute a simple {{mvn dependency:tree}} on the attached
> pom.xml files.
> The issue is probably caused by the {{weld.version}} property (1.1.9.Final)
> added to the deltaspike parent pom.xml.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1336) Regression: deltaspike-cdictrl-weld 1.8.0 depends on weld-api 1.1.Final
[
https://issues.apache.org/jira/browse/DELTASPIKE-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16606851#comment-16606851
]
Mark Struberg commented on DELTASPIKE-1336:
---
setting this dependency to 'provided' and 'optional' should hopefully help!
> Regression: deltaspike-cdictrl-weld 1.8.0 depends on weld-api 1.1.Final
> ---
>
> Key: DELTASPIKE-1336
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1336
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.8.0
>Reporter: Christophe Chisogne
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 1.9.0
>
> Attachments: pom-ds-1.7.2.xml, pom-ds-1.8.0-fix.xml, pom-ds-1.8.0.xml
>
>
> The {{deltaspike-cdictrl-weld}} module introduces a new dependency since
> 1.8.0: {{org.jboss.weld:weld-api:jar:1.1.Final}}. This wasn't the case in
> 1.7.2.
> This causes issues when depending on other weld versions, like 2.3. For
> example
> {code}
> java.lang.NoSuchMethodError:
> org.jboss.weld.context.SingletonContext.invalidate()V
> {code}
> To reproduce: execute a simple {{mvn dependency:tree}} on the attached
> pom.xml files.
> The issue is probably caused by the {{weld.version}} property (1.1.9.Final)
> added to the deltaspike parent pom.xml.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (DELTASPIKE-1336) Regression: deltaspike-cdictrl-weld 1.8.0 depends on weld-api 1.1.Final
[
https://issues.apache.org/jira/browse/DELTASPIKE-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reassigned DELTASPIKE-1336:
-
Assignee: Mark Struberg
> Regression: deltaspike-cdictrl-weld 1.8.0 depends on weld-api 1.1.Final
> ---
>
> Key: DELTASPIKE-1336
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1336
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.8.0
>Reporter: Christophe Chisogne
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 1.9.0
>
> Attachments: pom-ds-1.7.2.xml, pom-ds-1.8.0-fix.xml, pom-ds-1.8.0.xml
>
>
> The {{deltaspike-cdictrl-weld}} module introduces a new dependency since
> 1.8.0: {{org.jboss.weld:weld-api:jar:1.1.Final}}. This wasn't the case in
> 1.7.2.
> This causes issues when depending on other weld versions, like 2.3. For
> example
> {code}
> java.lang.NoSuchMethodError:
> org.jboss.weld.context.SingletonContext.invalidate()V
> {code}
> To reproduce: execute a simple {{mvn dependency:tree}} on the attached
> pom.xml files.
> The issue is probably caused by the {{weld.version}} property (1.1.9.Final)
> added to the deltaspike parent pom.xml.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DELTASPIKE-1336) Regression: deltaspike-cdictrl-weld 1.8.0 depends on weld-api 1.1.Final
[
https://issues.apache.org/jira/browse/DELTASPIKE-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated DELTASPIKE-1336:
--
Fix Version/s: 1.9.0
> Regression: deltaspike-cdictrl-weld 1.8.0 depends on weld-api 1.1.Final
> ---
>
> Key: DELTASPIKE-1336
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1336
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.8.0
>Reporter: Christophe Chisogne
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 1.9.0
>
> Attachments: pom-ds-1.7.2.xml, pom-ds-1.8.0-fix.xml, pom-ds-1.8.0.xml
>
>
> The {{deltaspike-cdictrl-weld}} module introduces a new dependency since
> 1.8.0: {{org.jboss.weld:weld-api:jar:1.1.Final}}. This wasn't the case in
> 1.7.2.
> This causes issues when depending on other weld versions, like 2.3. For
> example
> {code}
> java.lang.NoSuchMethodError:
> org.jboss.weld.context.SingletonContext.invalidate()V
> {code}
> To reproduce: execute a simple {{mvn dependency:tree}} on the attached
> pom.xml files.
> The issue is probably caused by the {{weld.version}} property (1.1.9.Final)
> added to the deltaspike parent pom.xml.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
