[JBoss JIRA] (WFLY-11818) wildfly-16.0.0.Final: "From address" is no more used as default from in email
by Wolfgang Mayer (Jira)
Wolfgang Mayer created WFLY-11818:
-------------------------------------
Summary: wildfly-16.0.0.Final: "From address" is no more used as default from in email
Key: WFLY-11818
URL: https://issues.jboss.org/browse/WFLY-11818
Project: WildFly
Issue Type: Bug
Components: Mail
Affects Versions: 16.0.0.Final
Environment: mvn -v
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T20:41:47+02:00)
Maven home: /apps/apache-maven-3.6.0
Java version: 11.0.2, vendor: Oracle Corporation, runtime: /usr/java/jdk-11.0.2
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "4.12.14-lp150.12.48-default", arch: "amd64", family: "unix"
Reporter: Wolfgang Mayer
Assignee: Tomaz Cerar
As mentioned in the Help (description) of 'Mail Session' configuration:
From: *From address that is used as default from, if not set when sending*
Apparently this is not the case anymore in wildfly-16.0.0.Final.
For example I made a test with quickstart-16.0/mail/.
When omitting the line
*message.setFrom(new InternetAddress(from));*
Sending mail fails with:
com.sun.mail.smtp.SMTPSendFailedException: 554-Transaction failed
554 Unauthorized sender address.
I have the same issue when replacing the line above with
message.setFrom(new InternetAddress());
I am pretty sure that this is working in wildfly-15
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (WFLY-11817) CDI @Resource(lookup=...) processing does not start corresponding binding service
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11817?page=com.atlassian.jira.plugin... ]
Matej Novotny commented on WFLY-11817:
--------------------------------------
[~pferraro] I am not at all familiar with these bits, do you have some reproducer for this that could be debugged?
Also what part of WFLY services handles binding service?
> CDI @Resource(lookup=...) processing does not start corresponding binding service
> ---------------------------------------------------------------------------------
>
> Key: WFLY-11817
> URL: https://issues.jboss.org/browse/WFLY-11817
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 16.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Matej Novotny
> Priority: Major
>
> If the corresponding binding service (the service responsible for creating the jndi binding) is not ACTIVE (e.g. clustering binding services are always PASSIVE) or, due to a race condition, has not yet started completely, a null value will be returned.
> The ee subsystem processes @Resource(lookup=...) correctly by establishing a dependency on the corresponding binder service.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (JBSER-133) Infinite Stack trace getting logged using jboss-serialization.jar - 1.0.3 GA ( in jboss 5.x )
by Suresh Ragala (Jira)
[ https://issues.jboss.org/browse/JBSER-133?page=com.atlassian.jira.plugin.... ]
Suresh Ragala commented on JBSER-133:
-------------------------------------
We are getting infinite stack trace as follows :
2019-02-17 21:36:37,246 FATAL [org.jboss.serial.persister.RegularObjectPersister] (WorkerThread#31[10.108.56.61:20883]) error
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor277.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.serial.persister.RegularObjectPersister2.writeSlotWithMethod(RegularObjectPersister2.java:138)
at org.jboss.serial.persister.RegularObjectPersister2.defaultWrite(RegularObjectPersister2.java:104)
at org.jboss.serial.persister.RegularObjectPersister2.writeData(RegularObjectPersister2.java:78)
at org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:81)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:390)
at org.jboss.serial.persister.RegularObjectPersister2.writeSlotWithFields(RegularObjectPersister2.java:204)
at org.jboss.serial.persister.RegularObjectPersister2.defaultWrite(RegularObjectPersister2.java:108)
at org.jboss.serial.persister.RegularObjectPersister2.writeData(RegularObjectPersister2.java:78)
at org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:81)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:390)
at org.jboss.serial.persister.RegularObjectPersister2.writeSlotWithFields(RegularObjectPersister2.java:204)
at org.jboss.serial.persister.RegularObjectPersister2.defaultWrite(RegularObjectPersister2.java:108)
at org.jboss.serial.persister.RegularObjectPersister2.writeData(RegularObjectPersister2.java:78)
at org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:81)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:390)
at org.jboss.serial.persister.ObjectOutputStreamProxy2.writeObjectOverride(ObjectOutputStreamProxy2.java:64)
at org.jboss.serial.persister.ObjectOutputStreamProxy.writeObjectOverride(ObjectOutputStreamProxy.java:62)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at java.util.ArrayList.writeObject(Unknown Source)
at sun.reflect.GeneratedMethodAccessor277.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.serial.persister.RegularObjectPersister2.writeSlotWithMethod(RegularObjectPersister2.java:138)
at org.jboss.serial.persister.RegularObjectPersister2.defaultWrite(RegularObjectPersister2.java:104)
> Infinite Stack trace getting logged using jboss-serialization.jar - 1.0.3 GA ( in jboss 5.x )
> ----------------------------------------------------------------------------------------------
>
> Key: JBSER-133
> URL: https://issues.jboss.org/browse/JBSER-133
> Project: JBoss Serialization
> Issue Type: Bug
> Environment: Jboss as 5.x , JDK 1.7
> Reporter: Suresh Ragala
> Assignee: Clebert Suconic
> Priority: Critical
>
> - When we get extensive OptimisticLockExceptions related to business entity changes from parallel processes, we are getting this infinite stack trace.
> version we are using : jboss Serialization 1.0.3 GA ( in jboss as 5.x )
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (JBSER-133) Infinite Stack trace getting logged using jboss-serialization.jar - 1.0.3 GA ( in jboss 5.x )
by Suresh Ragala (Jira)
Suresh Ragala created JBSER-133:
-----------------------------------
Summary: Infinite Stack trace getting logged using jboss-serialization.jar - 1.0.3 GA ( in jboss 5.x )
Key: JBSER-133
URL: https://issues.jboss.org/browse/JBSER-133
Project: JBoss Serialization
Issue Type: Feature Request
Environment: Jboss as 5.x , JDK 1.7
Reporter: Suresh Ragala
Assignee: Clebert Suconic
- When we get extensive OptimisticLockExceptions related to business entity changes from parallel processes, we are getting this infinite stack trace.
version we are using : jboss Serialization 1.0.3 GA ( in jboss as 5.x )
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (WFLY-4621) RESTEasy SMIME doesn't work with WildFly current module setup
by Marek Kopecký (Jira)
[ https://issues.jboss.org/browse/WFLY-4621?page=com.atlassian.jira.plugin.... ]
Marek Kopecký edited comment on WFLY-4621 at 3/7/19 2:15 AM:
-------------------------------------------------------------
bq. It looks like the problem was solved in RESTEasy 3.0.12.Final. Wildfly 9.0.2.Final shipped with RESTEasy 3.0.11.Final, and Wildfly 10.0.0.Final shipped with 3.0.14.Final, so I think I should use 10.0.0.Final as the Fix Version. But will that cause any problems?
[~ron_sigal] In this case, I believe that "10.0.0.Final" fix-version on this jira won't cause any problems ..
was (Author: mkopecky):
bq. It looks like the problem was solved in RESTEasy 3.0.12.Final. Wildfly 9.0.2.Final shipped with RESTEasy 3.0.11.Final, and Wildfly 10.0.0.Final shipped with 3.0.14.Final, so I think I should use 10.0.0.Final as the Fix Version. But will that cause any problems?
In this case, I believe that "10.0.0.Final" fix-version on this jira won't cause any problems ..
> RESTEasy SMIME doesn't work with WildFly current module setup
> -------------------------------------------------------------
>
> Key: WFLY-4621
> URL: https://issues.jboss.org/browse/WFLY-4621
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 9.0.0.CR1
> Reporter: Weinan Li
> Assignee: Weinan Li
> Priority: Major
> Attachments: patch_WFLY-4621_all, patch_WFLY-4621_new
>
>
> RESTEasy provides the functions of SMIME encryption and here is an example that can be deployed into WildFly:
> https://github.com/liweinan/digital-signatures/tree/master/smime
> And currently resteasy-crypto module doesn't work properly in WildFly unless applied the following patch:
> {code:diff}
> power:modules weinanli$ git diff
> warning: LF will be replaced by CRLF in system/layers/base/org/bouncycastle/main/module.xml.
> The file will have its original line endings in your working directory.
> diff --git a/system/layers/base/org/bouncycastle/main/module.xml b/system/layers/base/org/bouncycastle/main/module.xml
> index 5d13395..83ae97c 100644
> --- a/system/layers/base/org/bouncycastle/main/module.xml
> +++ b/system/layers/base/org/bouncycastle/main/module.xml
> @@ -24,12 +24,17 @@
> <module xmlns="urn:jboss:module:1.3" name="org.bouncycastle">
> <resources>
> + <!--
> <resource-root path="bcprov-jdk15on-1.52.jar"/>
> <resource-root path="bcmail-jdk15on-1.52.jar"/>
> + -->
> + <resource-root path="bcprov-jdk16-1.46.jar"/>
> + <resource-root path="bcmail-jdk16-1.46.jar"/>
> <resource-root path="bcpkix-jdk15on-1.52.jar"/>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> + <module name="javax.mail.api"/>
> + <module name="javax.activation.api"/>
> </dependencies>
> -
> </module>
> {code}
> After applying the above patch then the example can pass all the tests:
> {code}
> power:smime weinanli$ mvn -q clean package
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> power:smime weinanli$ mvn -q wildfly:deploy
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> May 11, 2015 9:24:27 PM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.0.Final
> May 11, 2015 9:24:27 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.0.Final
> May 11, 2015 9:24:27 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.7.Final
> power:smime weinanli$ mvn -q integration-test
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.jboss.resteasy.tests.smime.SMIMETest
> Encrypted Message From Server:
> Customer{name='Bill'}
> Signed Message From Server:
> Customer{name='Bill'}
> Customer{name='Bill'}
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.682 sec - in org.jboss.resteasy.tests.smime.SMIMETest
> Results :
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0
> power:smime weinanli$
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (WFLY-4621) RESTEasy SMIME doesn't work with WildFly current module setup
by Marek Kopecký (Jira)
[ https://issues.jboss.org/browse/WFLY-4621?page=com.atlassian.jira.plugin.... ]
Marek Kopecký commented on WFLY-4621:
-------------------------------------
bq. It looks like the problem was solved in RESTEasy 3.0.12.Final. Wildfly 9.0.2.Final shipped with RESTEasy 3.0.11.Final, and Wildfly 10.0.0.Final shipped with 3.0.14.Final, so I think I should use 10.0.0.Final as the Fix Version. But will that cause any problems?
In this case, I believe that "10.0.0.Final" fix-version on this jira won't cause any problems ..
> RESTEasy SMIME doesn't work with WildFly current module setup
> -------------------------------------------------------------
>
> Key: WFLY-4621
> URL: https://issues.jboss.org/browse/WFLY-4621
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 9.0.0.CR1
> Reporter: Weinan Li
> Assignee: Weinan Li
> Priority: Major
> Attachments: patch_WFLY-4621_all, patch_WFLY-4621_new
>
>
> RESTEasy provides the functions of SMIME encryption and here is an example that can be deployed into WildFly:
> https://github.com/liweinan/digital-signatures/tree/master/smime
> And currently resteasy-crypto module doesn't work properly in WildFly unless applied the following patch:
> {code:diff}
> power:modules weinanli$ git diff
> warning: LF will be replaced by CRLF in system/layers/base/org/bouncycastle/main/module.xml.
> The file will have its original line endings in your working directory.
> diff --git a/system/layers/base/org/bouncycastle/main/module.xml b/system/layers/base/org/bouncycastle/main/module.xml
> index 5d13395..83ae97c 100644
> --- a/system/layers/base/org/bouncycastle/main/module.xml
> +++ b/system/layers/base/org/bouncycastle/main/module.xml
> @@ -24,12 +24,17 @@
> <module xmlns="urn:jboss:module:1.3" name="org.bouncycastle">
> <resources>
> + <!--
> <resource-root path="bcprov-jdk15on-1.52.jar"/>
> <resource-root path="bcmail-jdk15on-1.52.jar"/>
> + -->
> + <resource-root path="bcprov-jdk16-1.46.jar"/>
> + <resource-root path="bcmail-jdk16-1.46.jar"/>
> <resource-root path="bcpkix-jdk15on-1.52.jar"/>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> + <module name="javax.mail.api"/>
> + <module name="javax.activation.api"/>
> </dependencies>
> -
> </module>
> {code}
> After applying the above patch then the example can pass all the tests:
> {code}
> power:smime weinanli$ mvn -q clean package
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> power:smime weinanli$ mvn -q wildfly:deploy
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> May 11, 2015 9:24:27 PM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.0.Final
> May 11, 2015 9:24:27 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.0.Final
> May 11, 2015 9:24:27 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.7.Final
> power:smime weinanli$ mvn -q integration-test
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.jboss.resteasy.tests.smime.SMIMETest
> Encrypted Message From Server:
> Customer{name='Bill'}
> Signed Message From Server:
> Customer{name='Bill'}
> Customer{name='Bill'}
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.682 sec - in org.jboss.resteasy.tests.smime.SMIMETest
> Results :
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0
> power:smime weinanli$
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (WFLY-1049) Add equivalent @WebContext for JAX-RS?
by Marek Kopecký (Jira)
[ https://issues.jboss.org/browse/WFLY-1049?page=com.atlassian.jira.plugin.... ]
Marek Kopecký commented on WFLY-1049:
-------------------------------------
bq. Marek Kopecký, there doesn't seem to be much interest, does there?
[~ron_sigal]: Agree, there doesn't seem to be much interest. There is no activity for ~6 years ...
> Add equivalent @WebContext for JAX-RS?
> --------------------------------------
>
> Key: WFLY-1049
> URL: https://issues.jboss.org/browse/WFLY-1049
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Reporter: Fernando Rubbo
> Priority: Major
> Labels: BASIC_AUTH, FORM_AUTH, JAX-RS,
>
> Currently, in our application we use @WebContext to set a different contextRoot for JAX-WS. For example:
>
> {code:java}
> @Stateless
> @SecurityDomain("test2")
> @WebService(name = "HelloSoap", portName = "HelloSoapPort", serviceName = "HelloSoap", targetNamespace = "http://com.test")
> @WebContext(contextRoot = "/ws", urlPattern = "/HelloSoap", secureWSDLAccess = false, authMethod = "BASIC", transportGuarantee = "NONE")
> public class HelloSoap { ... }
> {code}
> We would like to have an equivalent annotation for JAX-RS? It is required whenever a web app uses FORM_AUTH and there exists web services (JAX-WS and JAX-RS), inside of the same package, using as BASIC_AUTH.
>
> Thankyou in advance,
> Fernando Rubbo
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (WFCORE-4363) Need to disable console error page by console-enabled
by Chao Wang (Jira)
[ https://issues.jboss.org/browse/WFCORE-4363?page=com.atlassian.jira.plugi... ]
Chao Wang moved JBEAP-16510 to WFCORE-4363:
-------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-4363 (was: JBEAP-16510)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Management
(was: Management)
Affects Version/s: 8.0.0.Final
(was: 7.2.0.GA)
> Need to disable console error page by console-enabled
> -----------------------------------------------------
>
> Key: WFCORE-4363
> URL: https://issues.jboss.org/browse/WFCORE-4363
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Affects Versions: 8.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
>
> Cannot disable connsole error page even if console-enabled is false.
> 1. Disable console-enabled.
> {quote}
> /core-service=management/management-interface=http-interface:write-attribute(name=console-enabled,value=false)
> {quote}
> 2. Start EAP server, and access below.
> {quote}
> http://localhost:9990/error/index.html
> {quote}
> You can confirm error page.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months